Local Network Privacy and iOS 14

[Chris Eagleston]

Hi,

I'm posting because I didn't notice any discussion about the changes to network privacy in iOS 14. There is an Apple Developer Forum Thread where myself and others have been trying to convince Apple to make some changes but I doubt we will be successful before the GM release of 14.0.

As of iOS 14.0 beta 4, applications require user permission in order to communicate with devices on the local network. Your application may be impacted if you use WebRTC to communicate directly with other Peers (as opposed to a star with an SFU or MCU in the middle). For example, the following cases will trigger a permissions request.

1. Gathering mDNS host candidates.

2. Resolving mDNS host candidates.

3. Sending STUN requests or responses to host candidates that are within your local network prefix.

4. Communicating via an HTTPS proxy or TURN server where the client address is within your local network prefix.

If permissions are declined, then accessing the local network usually results in the offending UDP or TCP socket being closed with an error. The kicker is that there is no Apple API to determine the user's permissions before creating a PeerConnection. To add further insult to injury, Mobile Safari seems to be exempt from the new permissions checks and happily uses the local network.

I'm curious how others have been thinking about this problem. In the case of Twilio we have been leaning towards filtering remote host candidates when we know the other party is not a media server and gathering server reflexive and relay candidates as early as possible. There are more complex filtering strategies that could yield more usable host candidates but I am hopeful that there is a better solution to this problem in the long term.

Best,

Chris

[Philipp Hancke]

Am So., 16. Aug. 2020 um 11:11 Uhr schrieb 'Chris Eagleston' via discuss-webrtc <discuss...@googlegroups.com>:

Hi,

I'm posting because I didn't notice any discussion about the changes to network privacy in iOS 14. There is an Apple Developer Forum Thread where myself and others have been trying to convince Apple to make some changes but I doubt we will be successful before the GM release of 14.0.

I have not either. Can you file a bug at https://bugs.chromium.org/p/webrtc/issues/list so people can star it to show interest?

 

As of iOS 14.0 beta 4, applications require user permission in order to communicate with devices on the local network. Your application may be impacted if you use WebRTC to communicate directly with other Peers (as opposed to a star with an SFU or MCU in the middle). For example, the following cases will trigger a permissions request.

1. Gathering mDNS host candidates.

2. Resolving mDNS host candidates.

3. Sending STUN requests or responses to host candidates that are within your local network prefix.

4. Communicating via an HTTPS proxy or TURN server where the client address is within your local network prefix.

If permissions are declined, then accessing the local network usually results in the offending UDP or TCP socket being closed with an error. The kicker is that there is no Apple API to determine the user's permissions before creating a PeerConnection. To add further insult to injury, Mobile Safari seems to be exempt from the new permissions checks and happily uses the local network.

I'm curious how others have been thinking about this problem. In the case of Twilio we have been leaning towards filtering remote host candidates when we know the other party is not a media server and gathering server reflexive and relay candidates as early as possible. There are more complex filtering strategies that could yield more usable host candidates but I am hopeful that there is a better solution to this problem in the long term.

Only exchange host candidates when you *know* that you are on the same network (i.e. have the same srflx candidate)?

Because of (not) hairpinning issues this will affect connectivity rates so I hope this restriction can be averted...

 

Best,

Chris

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/c5192990-74f2-4385-9471-371c669a258bn%40googlegroups.com.

[Gustavo García]

Hi Chris,

We are also filtering the remote host candidates in iOS14+ to workaround this issue.  Instead of removing all of them right now we are filtering only the ones in private ranges to allow direct connections between endpoints with public addresses.

We still don't have numbers from real users in terms of impact on connectivity and % of users still affected after this change on the candidates filtering but we should have them soon.

The other option we considered was to disable the generation of host candidates as that's something easy with the native libwebrtc API, but that wouldn't be backwards compatible and would impact users of any OS and OS version.  So we stayed with the filtering of remote candidates.

Apart from that, from the ux point of view, the applications can customize the alert message and maybe also decide the best moment to ask for that permission (not completely sure about this).

Regards,

--

[Chris Eagleston]

Hi Gustavo and Philipp,

Thank you for the advice, I will be sure to avoid filtering public host candidates.

With no changes in iOS 14 beta 5 release today, I am off to file a webrtc bug. There may be some use cases that are severely impacted by this change, like native apps that connect to on-premises media servers. I can think of at least one company that deploys these kind of solutions for the enterprise market.

Best,

Chris

[Chris Eagleston]

Here you go, happy to add more context if needed.

https://bugs.chromium.org/p/webrtc/issues/detail?id=11859

[Chuck Hays]

I have a dev device set up with iOS 14, I'll do some testing tomorrow and see what happens.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/fdd5268a-8877-4f4d-a673-19a8f357f214n%40googlegroups.com.

[Chuck Hays]

Oops, replied to the wrong fork of this email, apologies for the noise.

[Chris Eagleston]

Hi Gustavo,

> Apart from that, from the ux point of view, the applications can customize the alert message and maybe also decide the best moment to ask for that permission (not completely sure about this).

The end user experience is what troubles me the most. There is no API to explicitly request permissions or to check their status and this is different than managing the camera and microphone permissions on iOS. This means that the first run experience is going to be pretty poor, with the app requesting permissions at an inopportune time after you've opened a PeerConnection and gathered candidates.

As an SDK developer, I am forced to take a defensive posture with no good alternatives. I had thought about writing a pre-flight permissions check using Network.framework sockets, but I doubt Apple would sanction this solution. For enterprise apps, it might be possible to accept permissions automatically with MDM profiles.

Best,

Chris