PSA: Private IP addresses exposed by WebRTC changing to mDNS hostnames

[Qingsi Wang]

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

[Qingsi Wang]

[Silvia Pfeiffer]

"except those that have getUserMedia permissions"

Does this mean that if you have getUserMedia permissions, you still get normal IP addresses going forward?

Thanks,

Silvia.

--

---
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.

[Qingsi Wang]

Yes. If the peer connection has either audio or video capture permission, IP addresses are returned in host candidates.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.

[eric littley]

We use chrome as a client for receiving video over WebRTC from a server. The chrome client has no need to record video or audio, as a result, most of the machines that our application is serving will not have microphone/camera recording present and enabled. It looks like getUserMedia will fail if no recording devices are present. Also, it is pretty weird for the user to allow video/audio recording for an application that does not use it. Is there any path forward for an application to ask the user's permission to expose their IP without asking for permission to use their microphone/camera?

[Qingsi Wang]

For the permission API, there is an ongoing discussion on direct connections: https://github.com/w3c/webrtc-pc/pull/2175#issue-271288320.

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.

[Justin Uberti]

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.

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.

[Roman Shpount]

Do you know if Chrome on Android supports mDNS candidates?

As far as I know mDNS URLs are not supported by Chrome (https://bugs.chromium.org/p/chromium/issues/detail?id=405925), but I was not sure if mDNS candidates are handled differently.

If mDNS candidates are not resolved by anything on Android this will have significant effect on local P2P connectivity.

If mDNS candidates are resolved by Chrome on Android, can you point out how exactly this is done? Is this done in browser code or is this delegated to the OS?

Thank You,

[Qingsi Wang]

The mDNS stack is currently not built into Chrome on Android. As a result it will also send out candidates with plain IPs, and this should work for most local P2P communications plus the peer-reflexive logic, if the peer ever signals mDNS candidates.

--

---
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.

[Sean DuBois]

What will happen if the PeerConnection that supports mDNS candidates
is controlled. If the controlling Agent only gets mDNS candidates (and
does not support them) is there anything it can do?

Is there anything in ICE/libwebrtc where the controlled agent would be
sending traffic if the controlling Agent has sent nothing? Anything
that has authentication and would generate those PRFLX candidates.

thanks!

> To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CA%2Bm752Jq_hUAfx1wXp-5s2O%3DTbREGC_c2ZJ0PzN6cf7SBsaUeA%40mail.gmail.com.

[Qingsi Wang]

The role does not stop the controlled side doing connectivity checks. If the controlling side signals any reachable candidate to the controlled side, the controlled would do its due diligence in connectivity checks, including a check for the pair formed by its mDNS candidate and this reachable one from the controlling. The controlling would 1) learn a prflx candidate from the incoming check, 2) send a response, and 3) form a pair. 2) would help the controlled side establish its ICE connectivity. 3) would let the controlling side either schedule an ordinary check or a triggered check. If this check succeeds, it then establishes the ICE connectivity on the controlling side. The 4-way handshake completes. In addition, the learnt prflx candidate would not prevent the controlling side from nominating a pair formed with it.

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.

[Roman Shpount]

Hi Qingsi,

Is mDNS resolution for ICE candidate on desktop is build-in the Chrome browser or is this being passed to the OS?

Thank You,

To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.

[Qingsi Wang]

Hi Roman, I think the resolution on desktop uses the stack built into Chrome.

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 littley]

Justin, our software is used in security surveillance camera networks (its a VMS). A common use case for our software is transmitting video across local subnets (for example: a school system in which the video surveillance network is separated from the administration network). It appears that, in many cases, mDNS resolution does not work across subnets without extra network configuration. The permission API Qingsi has linked looks like it might be the right path forward for us (I need to review it more). It looks like a pull request has been opened for this but has been marked as "Virtual Interim" (not sure what that means exactly). Does this look like something that would be added in the near future?

On Friday, 16 August 2019 00:01:28 UTC-4, Justin Uberti wrote:

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.

[Justin Uberti]

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 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.

[Qingsi Wang]

Update on the rollout

This technique is currently fully enabled by default for Canary/Dev/Beta channels, and for 95% of Chrome users in the Stable channel, including M75 and above. The impact to the connection rate is continuing to improve from our peer-to-peer connection analysis during the rollout, and we will continue to investigate improvements to further minimize the downsides.

[Arun Ganeshan]

After upgrading to version 78 we are seeing issues with automation .

In version 77 we run our automation . When using fake media mdns was disabled we were guessing it was because of the fakeMEdia but looks like in chrome 78 fake media is not assumed as real streams . MDNS is enabled irrespective of getting fake media 

TO fix this we tried to set `'--disable-webrtc-hide-local-ips-with-mdns' via chromedrivers but for some reason still the value in default and the enabled. Any help on how to make it work with the automation  ? And will mdns be enabled irrespective of the getUserMedia in future ?

Regards,

Arun
CISCO

[Qingsi Wang]

Hi Arun,

Could you please try path/to/chrome --disable-field-trial-config --disable-features=WebRtcHideLocalIpsWithMdns? This should turn off the mDNS feature in the launched Chrome session.

> will mdns be enabled irrespective of the getUserMedia in future

We don't see a good reason to always enable the mDNS feature, especially with the user consent via getUserMedia.

Best,

Qingsi

--

---
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.

[Qingsi Wang]

Only --disable-features=WebRtcHideLocalIpsWithMdns should be sufficient for M78 and above.

[Shahar Mor]

Was there any consideration of using encryption to encode the private IP instead of using mDNS?

For example, peer1 could encrypt its IP using peer2's public key, so only peer2 can decrypt it for using it within WebRTC, without exposing it to the JS level.

The public keys can be transferred as part of the offer/answer.

Wouldn't that solve the issue of hiding the IP and also work around the issues with mDNS not being supported?

Is that something that can still be done? I guess it will probably take time to add to the spec, but is it generally feasible?

[Harald Alvestrand]

Since candidate exchange occurs prior to DTLS setup, the two ends don't have a shared key known to the browser while encoding candidates.

So a solution based on encrypting IP addresses would have to involve key exchange using some other mechanism - and since the address harvesting we're trying to prevent is done by the Javascript, any solution exchanging keys via Javascript is infeasible.

It's possible that it could be made to work using some other key exchange mechanism, but for many scenarios, it seems strictly more complicated than supporting mDNS.

--

---
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.

[Dubois, Sean]

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.

[Sean DuBois]

I do get it being more complicated though.

I have just been getting lots of reports from Pion users that mDNS is causing issues, but everyone loves to complain about new things :) 

* Some are hitting issues because Multicast is disabled/different subnets

* Other are frustrated about the increase in traffic they are seeing from the queries, and concerned about information leakage happening from that. Don't know how realistic that is though.

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.

[Justin Uberti]

DH isn't possible because the JS can simply MITM the DH to break the encryption. I don't think there's any trust that we can bootstrap from.

Regarding traffic increases, please file a crbug on this and we can look into it.

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.

[Dubois, Sean]

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.

[Justin Uberti]

FWIW, TLS can bootstrap trust from the server certificate.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8C57B074-FFFD-4708-9AB1-88F281587F6A%40pion.ly.

[Qingsi Wang]

> 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.

Yeah, the server and the remote peer could collude under the application control.

On Mon, Sep 30, 2019 at 5:22 PM Dubois, Sean <se...@pion.ly> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8C57B074-FFFD-4708-9AB1-88F281587F6A%40pion.ly.

[Nikolay Rodionov]

Hello Justin,

Do you know what Chrome Enterprise policy would disable the mDNS feature? I can't find it in the list here, and for us it would be of a great help - we have a P2P E-CDN solution that helps Enterprise users to avoid congesting their internal networks during their internal video broadcasts. Until a permission API comes, having at least the possibility to deactivate it in Chrome Enterprise would be great.

Le vendredi 30 août 2019 20:29:35 UTC+2, Justin Uberti a écrit :

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.

[Justin Uberti]

Understood, will be announcing our plan for this shortly.

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.

[Qingsi Wang]

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.

As an interim solution, we are going to disable the mDNS feature for Chrome Enterprise endpoints until the new policy is available in Chrome stable, which we target to arrive in Chrome 79 in early December.

[Roman Shpount]

Are there any plans to add a permission dialog to allow application to expose the private IP without asking for GetUserMedia?

Thank You,

[Justin Uberti]

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-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.

[Harald Alvestrand]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOJ7v-1w6jC7xMT8aXn70_jPLntrBavMNOGTU%3Duc4mBxSMmrkQ%40mail.gmail.com.

[Roman Shpount]

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.

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.

[Harald Alvestrand]

In an earlier incantation, the permissions spec (https://w3c.github.io/permissions/) had a "request permission" API that would have fitted the requirements here precisely.

It was removed due to consistent opposition from people who felt that its presence would encourage applications to ask for permission independently of wanting to use them.

I heard the arguments at the time, but I still think it might have been the wrong call. public-w...@w3.org is the place where that discussion needs to happen if someone has the fortitude to revisit it.

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.

[Alice R.]

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.

[Tsahi Levent-Levi]

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-Levi

Analyst & Consultant

BlogGeek.me

Want to get more of your WebRTC sessions effectivly connected? Enroll to my free video course: http://bit.ly/32Y3qZK

--

---
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.

--

Regards,

Tsahi Levent-Levi

Analyst & Consultant

BlogGeek.me

Want to get more of your WebRTC sessions effectivly connected? Enroll to my free video course: http://bit.ly/32Y3qZK

[Philipp Hancke]

Am Do., 17. Okt. 2019 um 16:14 Uhr schrieb Alice R. <alice.der...@gmail.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.

Establishing a local network connection was never a "borderline trick", it is one of the core features of the protocol.

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.

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.

[Lennart Grahl]

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.

Side note: Even though that proposal doesn't ask for this to be implemented as a prompt, there are a bunch of other ridiculously amusing permissions being pointed out in that thread.

[Roman Shpount]

On Thursday, October 17, 2019 at 10:22:03 AM UTC-4, Philipp Hancke wrote:

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.

Considering that mDNS is not yet implemented on mobile platforms, which are responsible for most of the HTTP access, it is too early to declare victory. I am really curios how well mDNS will work on mobile networks.

Best Regards,

[Roman Shpount]

On Thursday, October 17, 2019 at 10:57:42 AM UTC-4, Lennart Grahl wrote:

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.

The reason I asked a question about the permission prompt (or API) was to see if your proposal was being considered. I definitely support this proposal and will ask people in Peer5 comment and do the same.

Best Regards, 

[Lennart Grahl]

Thanks, Tsahi, fully agree!

If I may add another example where the same mistake is being made: The Notification permission is the only deterministic way to get the persistent storage permission in Chromium. But what if one wants to store data persistently and doesn't want to enforce notifications on the user? Such a use case now needs to add a checkbox to turn off notifications but still requires the permission being granted. What if one doesn't even have a use case for notifications? How does one explain that to the user? "Please grant the permission. I won't send you any notifications. I just want to store data persistently." It's ridiculous.

This kind of permission tieing is detrimental in regards to use case diversity because innovative ideas are being obstructed. Now, I don't blame anyone for making that mistake. But then at least be open-minded when someone comes around a corner with a use case you didn't have in mind.

Cheers

Lennart

On Thursday, 17 October 2019 16:21:39 UTC+2, Tsahi Levent-Levi wrote:

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-Levi

Analyst & Consultant

BlogGeek.me

Want 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.

[Alice R.]

Sorry, my message was a bit too heartfelt and maybe not quite clear. I actually fully agree about the issue with permissions. Your example of persistent storage is spot on.

Of course I know establishing local network connections is core to WebRTC. However, from what I gathered I was under the impression that the notification was brought up because requesting companies relied on the actual local IP addresses for some form of tracking or enterprise user identification, and therefore refused to play along in the mDNS effort. That's what I called a "borderline trick".

I might have jumped to conclusions here, I'm sorry if I've been mistaken.

[Tsahi Levent-Levi]

Alice,

The use case in question, which Streamroot, Peer5 and several others rely on is the ability to share content pieces between browsers within the same local LAN with the intent of being able to reduce the load on access to cloud streaming servers.

One of the main use cases there is townhalls, where a session is live streamed towards an enterprise and people join from their machines inside the corporate network. Instead of choking the network with the sam traffic being unicasted multiple times from an external source, the data can be streamed once (or a few times) into the local network and there, let the browsers watching the townhall sort things outs amongst themselves. What is needed for that, is knowing the local IP address (or to have mDNS enabled on the local network, which isn't always simple or possible).

Regards,

Tsahi

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.

[Philipp Hancke]

you might want to read the answers in the discussion converted to chat at https://stackoverflow.com/a/56757635/4352772

In particular the part where Harald is cleared up on what WebRTC was designed for 😂

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.

[Alice R.]

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.

[Justin Uberti]

Our position at Google is that we agree on the importance of the intranet streaming case, and are going to try to find a technical solution that obviates the need for an IP permission, to avoid pushing this complexity onto the user. 

We have several new ideas beyond mDNS, and the origin enterprise policy is just the first.

On Thu, Oct 17, 2019 at 10:49 AM Alice R. <alice.der...@gmail.com> wrote:

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.

[Arun Ganeshan]

I have been trying to enable MDNS from chrome:flags but the SDP generated doesnt have mdns candidates . I tried default, enabled and disabled all three options . Any recommendations  on how to do it ?  And is there any example out there to test it out 

[Philipp Hancke]

make sure the tab you're trying this in doesn't have getUserMedia permissions and does not ask for it. An incognito tab usually works.

--

---
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.

[Arun Ganeshan]

Thanks @philipp that worked for me 

To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.

[Ethan Rutherford]

I have a use case for grabbing the user's local ip (or more specifically, their local address range to scan and discover local services).

I'm working on a multiplayer LAN game that plays in the browser, utilizing webgl and other browser-based apis.
The idea being that one user downloads and starts up the server on their machine, and then all players navigate to that server's local ip address in their browsers.

However, LAN ips are archaic and not particularly user friendly, even discovering your own LAN ip address is not straightforward. I thought therefore, it might be nice to have an official site that runs some javascript code that could discover running games in the user's local network.
Instead of having to figure out the server machine's local ip address and communicate it to all players (with a chance for mis-reading/mis-hearing and mis-typing the address x number of players), each player loads up "example-game-website.tld/discover" and the site would scan for games, and show a list of links to any discovered LAN games.

I was excited to discover that webrtc could be used to discover the user's local network address space (by deriving it from their local ip address), but shortly after disappointed to find that it had been abused, and subsequently obfuscated in response.
I personally feel that a user permission for this would be a good compromise. It would be fairly simple to explain to the user that we need permission to scan their network for games, and the barrier to trust should be pretty low (it should be pretty obvious what we're about to use the permission to do). Asking for permission to camera or microphone could technically be used, but this is significantly more sketchy. It doesn't make sense that game discovery would need your microphone or camera, and no amount of "no seriously, we're not trying to spy on you!" would be sufficient to gain trust. It's simply not intuitive that we would need microphone/camera access to do this, nor would most users be comfortable with giving a site permission for something it doesn't actually intend to use, even as a workaround.


Is there some kind of solution to this use case? It's a bit of a bummer to have a solution that was *so close* to being possible, with no obvious alternative. A permission prompt may not be the most user-friendly solution, but a request for a seemingly unrelated permission, an enterprise policy setting, or a chrome flag is even less so for the average user. I was really hoping to have a more elegant solution than having users manually type in ip addresses.

[Philipp Hancke]

that sounds more like a use-case for mdns which was built for this kind of discovery. https://groups.google.com/forum/#!msg/discuss-webrtc/HBxzWqs2kjM/dbYJp5nmBQAJ might help.

--

---
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.

[Harald Alvestrand]

The argument against using an user prompt for this has been that no user will really understand what they have granted permission to, and some of the things that are possible if scanning is available are not so friendly.

For example, some variants of the DNSChanger attack (reconfiguring your home router to send all your DNS queries to "Attacker") use this method to find your router.

--