Summary
WebRTC currently lets web applications discover private IP addresses to enable direct connectivity between hosts on a local network. While private IP addresses do not uniquely identify browser users, they may still be used for tracking purposes. To prevent this misuse, private IP addresses returned by RTCPeerConnection will now be masked with mDNS hostnames in certain situations. While this change should be transparent to most WebRTC applications, some developers may need to update their client and backend services.
This change is currently enabled for 50% of Chrome users, and is expected to fully roll out in August 2019 as part of the Chrome 76 release. WebRTC services can verify whether their services are affected by setting the following flag in Chrome 73 or later: chrome://flags/#enable-webrtc-hide-local-ips-with-mdns
Why are we doing this?
We have observed a trend of web sites using WebRTC specifically to obtain private IP addresses, presumably for tracking purposes. Accordingly, we have collaborated with other browser vendors to address this problem by using mDNS hostnames instead of private IP addresses in WebRTC, as described in this pending IETF spec. We have also experimentally verified the efficacy of the mDNS technique, following the initial announcement of this feature in January.
Impact on applications
When the feature is active, private IP addresses in ICE host candidates will be replaced by an mDNS hostname, e.g., 1f4712db-ea17-4bcf-a596-105139dfd8bf.local. Currently, this feature is active for all sites except those that have getUserMedia permissions, which are presumed to have a higher degree of user trust.
WebRTC services that do not support addresses in the above format may be impacted, causing sessions to fail or use a less direct connection path. WebRTC services may be especially affected if they parse out addresses from RTCSessionDescription or RTCIceCandidate objects and assume those addresses are IP addresses, or have server components that do the same. In particular, older versions of the libnice library, used by some applications, do not parse such addresses properly.
Impact on connectivity
mDNS does not work in all situations; on some networks, mDNS may be disabled, or an endpoint may be too many hops away to resolve an mDNS hostname. In these cases, fallback to STUN will be required, and this may sometimes fail; as such, some amount of impact on connection success rate is to be expected.
From a broad analysis of peer-to-peer connections in the experimental deployment, the overall impact of mDNS on connectivity is modest, a 2% (relative) reduction in connection rate when mDNS was used by Chrome on both sides. In this population, the percentage of successful connections that used STUN on one side or the other increased from 94% to 97%, with a corresponding decrease in host-to-host connections. We believe the connectivity impact stems primarily from connections that previously worked host-to-host, but do not work with mDNS, and cannot fall back to STUN due to lack of hairpin support in the NAT.
Somewhat surprisingly, for connections between Chrome and non-mDNS endpoints, we observed a larger impact, roughly 3% (relative) reduction in connection rate when the remote side supplied private IPs and 7% (relative) when the remote side supplied only public IPs. While mDNS should have zero impact in these cases, we believe this is explained by problems triggered by mDNS in third-party ICE stacks, including the aforementioned issues regarding parsing mDNS candidates as well as issues discovering peer-reflexive candidates from ICE connectivity checks.
Given the success of the mDNS technique in combating tracking via private IP addresses, we believe this small impact on connection rate is an acceptable tradeoff. We will continue to investigate improvements to this technique to further minimize the downsides.
General recommendations
Improvements in Chrome are frequently rolled out as experiments and deploy first in Chrome Canary and the pre-stable Dev and Beta versions. Important experiments are also announced via email at the start of the rollout. We highly recommend WebRTC developers to:
Join blink-dev and discuss-webrtc to follow PSAs and other important announcements
Systematically test in Chrome Canary to see how your application behaves with upcoming Chrome changes
Provide feedback on the relevant bugs/forum threads
--
---
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/32c0563f-8329-4491-9494-29d9b5208666%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.
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/c854741c-91ee-4554-911d-1f13c5b852f9%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CA%2Bm752J1%2BF6wq%3DK%3Dfycc6acOM%3D88y4XKL3v9B0GATCGN_%3DdwoQ%40mail.gmail.com.
--
---
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/1e975569-ab29-457e-ad09-5e6a831d8878%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CA%2Bb7xQt143Y%3DqFFr08Pm8vyGodXX-%3D87Qg1K9Y9%2Bve2gfG0J_g%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.
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/9b82c4ea-ebc0-4604-8817-bef7b038394c%40googlegroups.com.
Eric, your application (and all client-to-server applications) should be unaffected by this change, assuming you don't malfunction when receiving mDNS candidates (you can simply ignore them).We explicitly recommend against asking for gUM permission to bypass the mDNS feature, as it should not be necessary, and is pretty weird for the user, as you point out.
On Thu, Aug 15, 2019 at 10:09 AM 'Qingsi Wang' via discuss-webrtc <discuss...@googlegroups.com> wrote:
For the permission API, there is an ongoing discussion on direct connections: https://github.com/w3c/webrtc-pc/pull/2175#issue-271288320.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/c854741c-91ee-4554-911d-1f13c5b852f9%40googlegroups.com.
--
---
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CA%2Bm752J1%2BF6wq%3DK%3Dfycc6acOM%3D88y4XKL3v9B0GATCGN_%3DdwoQ%40mail.gmail.com.
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/514fd07c-f807-493b-8e17-2da1f2000c68%40googlegroups.com.
--
---
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/59fcf8fa-039e-43b0-8df9-2986f74af986%40googlegroups.com.
--
---
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/9460a6bc-caa4-4a6a-987f-bd4ef4cb7695%40googlegroups.com.
Hey,
Why would something like DH not be possible?
Javascript can be assumed to be hostile. The WebRTC engine just gives you a candidate string and a public key (and waits to get a public key from the other side)
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOqqYVHgcL%2BVQQfbN8vGmq-3RXgUXSoG3xwhKkEiQ7XH8G0_Ng%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/9460a6bc-caa4-4a6a-987f-bd4ef4cb7695%40googlegroups.com.
--
---
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-webrtc+unsubscribe@googlegroups.com.
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/9460a6bc-caa4-4a6a-987f-bd4ef4cb7695%40googlegroups.com.
--
---
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/CAOqqYVHgcL%2BVQQfbN8vGmq-3RXgUXSoG3xwhKkEiQ7XH8G0_Ng%40mail.gmail.com.
--
---
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/829653f3-552f-47ec-8a7c-8ad32094b508%40googlegroups.com.
I don’t believe a MITM is the issue though (TLS would have the same problems then) However my idea doesn’t work. This only keeps the signaling safe, but an attacker could just run a WebRTC server and decrypt them there. This only fixes leaking IPs when browsers only.
re: crbug no worries! I don’t think there is a solution, the queries need to happen so people just need to deal with it 😊
thanks
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOJ7v-1f4UCuaMK8OnykzZUBk9Ww3RVC2b92cQXjekrb0Z_WqA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8C57B074-FFFD-4708-9AB1-88F281587F6A%40pion.ly.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8C57B074-FFFD-4708-9AB1-88F281587F6A%40pion.ly.
I can't say exactly when that permission might come to Chrome, so I wouldn't count on that as a near-term solution.For your application, are both sides of the connection Chrome instances? If so, are you able to configure them using Chrome enterprise policies?
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/514fd07c-f807-493b-8e17-2da1f2000c68%40googlegroups.com.
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/b6960bd9-67d0-41f5-a723-eeb9795c53b1%40googlegroups.com.
Chrome policy to manage the mDNS feature in enterprise deployments
As part of our continuing effort to minimize disruption from the mDNS obfuscation technique, we are preparing to add a new Chrome enterprise policy (tentatively named “WebRtcLocalIPsAllowedUrls”) to control whether the exposure of local IP addresses is allowed in ICE candidates for specific origins in managed networks. The mDNS obfuscation will be effective for an origin only if this new policy does not whitelist the origin for IP exposure and the feature flag (chrome://flags/#enable-webrtc-hide-local-ips-with-mdns) is enabled.
When available, this new policy can be deployed by enterprises the same way as existing Chrome policies. Please refer to Chrome Browser Deployment Guide on Policies and Templates for the procedure on different platforms.
Are there any plans to add a permission dialog to allow application to expose the private IP without asking for GetUserMedia?Thank You,
--
---
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/6d070b38-40b4-476d-a166-6d6cc61a78b5%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOJ7v-1w6jC7xMT8aXn70_jPLntrBavMNOGTU%3Duc4mBxSMmrkQ%40mail.gmail.com.
Popups are a pain to the users.Another option being explored is to put something into "site settings", accessible via the lock icon, which already gives access to a host of specific permissions.
On Tue, Oct 15, 2019 at 9:36 PM 'Justin Uberti' via discuss-webrtc <discuss...@googlegroups.com> wrote:
It is being discussed, but it is not yet clear that a new permission is the best solution; we hope that the Chrome enterprise policy route will avoid pushing this complexity onto users.
On Tue, Oct 15, 2019 at 11:50 AM Roman Shpount <rshp...@gmail.com> wrote:
Are there any plans to add a permission dialog to allow application to expose the private IP without asking for GetUserMedia?--Thank You,
---
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/6d070b38-40b4-476d-a166-6d6cc61a78b5%40googlegroups.com.
--
---
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...@googlegroups.com.
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/a8f016f2-a54d-4b56-98b8-69faa74f0624%40googlegroups.com.
Until a permission API comes, having at least the possibility to deactivate it in Chrome Enterprise would be great.
--
---
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/0c63666a-8f81-45ea-9f9f-8a77ca65c8dc%40googlegroups.com.
After reading the exchange here, I'm quite baffled. I feel the prerequisites of some interventions are rather out of touch. I don't think the argument that permission API is a necessity because there is no practical alternative is relevant.If your business somehow requires custom convoluted API to access local addresses in SDP, you might want to take a step back and consider that your particular use case was a diverted use of WebRTC in the first place. I guess expecting it to be maintained at all costs by the standard would be rather uncalled for.Companies like Peer5 and Streamroot relying on such a borderline trick doesn't seem like a valid argument to encumber the web with technical privacy-related choices users can't answer properly. From a UI perspective, adding request permissions for such petty issues most end users can't even understand would just degrade their overall browsing experience and encourage them to accept anything.
I understand some people have business stakes in this, however there is a bigger picture here
Le lundi 14 octobre 2019 16:19:52 UTC+2, Nikolay Rodionov a écrit :
Until a permission API comes, having at least the possibility to deactivate it in Chrome Enterprise would be great.
Le jeudi 17 octobre 2019 04:05:39 UTC+2, Roman Shpount a écrit :Yes, popups are pain, but "site settings" behind the lock icon are even worse. It is almost impossible to explain to the end user what you want from them when asking to change something there. For instance now it requires support call and a lot of hand-holding to explain to the end user how to re-enable denied access to GetUserMedia.WebRtcLocalIPsAllowedUrls enterprise policy would help but would still be problematic. Consider the typical use case, which is P2P delivery network used to deliver a live streaming event in the enterprise, such as town-hall meeting. These events can use the same delivery service, such as Peer5 or streamroot, but the actual site running the player would likely have a new domain name for each event (townhall2019.com vs townhall2020.com). Another problem is that local admin fails to provision the new URL in the enterprise policy, this issue would typically only get detected when actual large video event is actually running, since all the viewers in the company location would fail over to regular CDN and overload the corporate internet connection.So, what is likely required, is an ability for an application to ask user to change the site permission to expose local IP and detect if this permission is not given. This is, more or less, the same thing as GetUserMedia permission but without asking for media. I understand the difficulty in designing this permission dialog, but I am not sure what workable alternative solutions are there <irony>apart from everyone moving to IPv6 and exposing temporary IPv6 addresses detectable via STUN </irony>.
On Wednesday, October 16, 2019 at 2:27:27 AM UTC-4, Harald Alvestrand wrote:Popups are a pain to the users.Another option being explored is to put something into "site settings", accessible via the lock icon, which already gives access to a host of specific permissions.
--
---
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/0c63666a-8f81-45ea-9f9f-8a77ca65c8dc%40googlegroups.com.
That you need to get the local ip for that and then people abused it... is a problem that is finally addressed by mdns host candidates.
This is why I initiated a proposal for a "Permission API for receive-only media and data use cases" earlier this year to the WebRTC spec. Support is very welcome.
Alice,Not sure why this is the stance.WebRTC is used for many things. All of them important, useful and relevant.To give an example, Google is using WebRTC for Standia, a cloud gaming service that never was part of the initial arguments for doing WebRTC in the first place.Some would argue that Stadia is using a borderline trick rather than what the people behind WebRTC (whoever they are) intended it for.Who is any of us to say what is the correct use or incorrect use of WebRTC?People rely on WebRTC to deliver their services. It would only make sense to hear them out and try to figure a way to make WebRTC inclusive to their needs.--Regards,Tsahi Levent-LeviAnalyst & ConsultantWant to get more of your WebRTC sessions effectivly connected? Enroll to my free video course: http://bit.ly/32Y3qZK
On Thu, Oct 17, 2019 at 5:14 PM Alice R. <alice.de...@gmail.com> wrote:
--After reading the exchange here, I'm quite baffled. I feel the prerequisites of some interventions are rather out of touch. I don't think the argument that permission API is a necessity because there is no practical alternative is relevant.If your business somehow requires custom convoluted API to access local addresses in SDP, you might want to take a step back and consider that your particular use case was a diverted use of WebRTC in the first place. I guess expecting it to be maintained at all costs by the standard would be rather uncalled for.Companies like Peer5 and Streamroot relying on such a borderline trick doesn't seem like a valid argument to encumber the web with technical privacy-related choices users can't answer properly. From a UI perspective, adding request permissions for such petty issues most end users can't even understand would just degrade their overall browsing experience and encourage them to accept anything.I understand some people have business stakes in this, however there is a bigger picture here.Le lundi 14 octobre 2019 16:19:52 UTC+2, Nikolay Rodionov a écrit :Until a permission API comes, having at least the possibility to deactivate it in Chrome Enterprise would be great.
Le jeudi 17 octobre 2019 04:05:39 UTC+2, Roman Shpount a écrit :Yes, popups are pain, but "site settings" behind the lock icon are even worse. It is almost impossible to explain to the end user what you want from them when asking to change something there. For instance now it requires support call and a lot of hand-holding to explain to the end user how to re-enable denied access to GetUserMedia.WebRtcLocalIPsAllowedUrls enterprise policy would help but would still be problematic. Consider the typical use case, which is P2P delivery network used to deliver a live streaming event in the enterprise, such as town-hall meeting. These events can use the same delivery service, such as Peer5 or streamroot, but the actual site running the player would likely have a new domain name for each event (townhall2019.com vs townhall2020.com). Another problem is that local admin fails to provision the new URL in the enterprise policy, this issue would typically only get detected when actual large video event is actually running, since all the viewers in the company location would fail over to regular CDN and overload the corporate internet connection.So, what is likely required, is an ability for an application to ask user to change the site permission to expose local IP and detect if this permission is not given. This is, more or less, the same thing as GetUserMedia permission but without asking for media. I understand the difficulty in designing this permission dialog, but I am not sure what workable alternative solutions are there <irony>apart from everyone moving to IPv6 and exposing temporary IPv6 addresses detectable via STUN </irony>.
On Wednesday, October 16, 2019 at 2:27:27 AM UTC-4, Harald Alvestrand wrote:Popups are a pain to the users.Another option being explored is to put something into "site settings", accessible via the lock icon, which already gives access to a host of specific permissions.
---
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/0c63666a-8f81-45ea-9f9f-8a77ca65c8dc%40googlegroups.com.
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/33a08467-dd98-420e-9136-9a6af3224867%40googlegroups.com.
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/33a08467-dd98-420e-9136-9a6af3224867%40googlegroups.com.
Thanks for the clarification.Indeed I thought the idea was to be able to read the IP to identify the user on the network a bit like like on the stackoverflow discussion. I didn't know mDNS needed enabling on corporate networks, in that case the policy to disable it makes sense.
--
---
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/6a49f931-38fe-4629-8a60-3289b416d8f3%40googlegroups.com.
--
---
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/d40b4f6c-663f-484c-85df-53d2893fca30%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.
--
---
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/c9cd71b2-b2d6-4d39-8883-8c3d5c8e3a7co%40googlegroups.com.
--