An experiment to use mDNS to obfuscate host candidate IP addresses has started in Chrome Canary (M73).
With this feature, host IPs will no longer directly be exposed by the RTCPeerConnection API, increasing privacy. Host candidates will only indirectly be exposed through a randomly generated mDNS hostname.
Purpose and mechanisms used are described in this spec:
https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-02
The expected effects on connectivity between 2 WebRTC agents are:
No application code is affected by this feature, so there are no actions for developers with regard to this experiment.
This experiment affects Chrome on Windows, MacOS and Linux.
Regards,
Jeroen
Is this controlled by a flag?
--
---
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/2e70bed1-bd45-47fa-8552-087c91d45c10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
---
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/7d0083ad-bc3a-4ad6-ae06-2a90d78c11bd%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOqqYVHuh%3DDcasgC35vLvzoahbiRHAyWa8-5ME4ocUm0mYkKAQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/043b2f7a-5e7f-4c23-b75a-fa5f2dd4a9a1%40googlegroups.com.
If you don't understand FQDN addresses, just ignore them. The rationale here has been discussed at length and while there are bugs that will be fixed, arguing against the use of FQDNs (which were explicitly permitted by RFC5245) is not productive.
--
---
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/e9349b10-b9d5-43df-b945-91dd27ca7d8c%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/e9349b10-b9d5-43df-b945-91dd27ca7d8c%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/88a18d36-8fcb-4524-8eee-378d2d2d8312%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/954f9a2b-c477-4473-a0eb-a9e193289ee9%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/fa828a1c-ac59-487f-8c08-be95b906829b%40googlegroups.com.
which is a problem why? The server will announce non-mdns candidates and the client will attempt to connect to them, no?(I typically don't even bother to send candidates to my servers, but they're ice-lite so...)
OK. Failure when you a) don't have TURN or STUN candidates and b) don't understand MDNS is expected, I think (you can't start performing connectivity checks). Part of the point of the experiment is to see if the breakage caused by this situation is acceptable or unacceptable.
--
---
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/6ae24db6-60e3-4a03-b480-a874a415809e%40googlegroups.com.
If you don't use STUN or TURN servers, your application probably didn't work very well before...
Regardless, even if one side doesn't understand mDNS, things will continue to work. The non-mDNS side will send an IP address candidate, the mDNS side will form a candidate pair with that address, and then the non-mDNS side will get an incoming connectivity check which will cause it to form a prflx candidate, and everything is good.
Regards,_____________
Roman Shpount
--
---
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/CAD5OKxtr-B0gzAYSciCihcenSb4i3NN0ApVeoK%3DRhMB-szRoUA%40mail.gmail.com.
On Thu, Feb 7, 2019 at 8:42 AM Roman Shpount <rshp...@gmail.com> wrote:On Thu, Feb 7, 2019 at 11:32 AM 'Justin Uberti' via discuss-webrtc <discuss...@googlegroups.com> wrote:If you don't use STUN or TURN servers, your application probably didn't work very well before...Why? If you have a server running on public IP with UDP and TCP candidates, it works extremely well without STUN or TURN. In fact, all STUN or TURN servers do in this case are slowing call setup down and, in case of TURN, add latency by introducing extra hop.Regardless, even if one side doesn't understand mDNS, things will continue to work. The non-mDNS side will send an IP address candidate, the mDNS side will form a candidate pair with that address, and then the non-mDNS side will get an incoming connectivity check which will cause it to form a prflx candidate, and everything is good.In the above described case, server ends up with no usable candidates. So, the ICE nomination process on the server stops before getting any prflx candidates.That doesn't happen with trickle ICE. But if you are using vanilla ICE and all you need is a candidate to prevent the ICE process for terminating, just make up a fake address, e.g. 0.0.0.1 or some such.
On Thu, Feb 7, 2019 at 12:07 PM 'Justin Uberti' via discuss-webrtc <discuss...@googlegroups.com> wrote:On Thu, Feb 7, 2019 at 8:42 AM Roman Shpount <rshp...@gmail.com> wrote:On Thu, Feb 7, 2019 at 11:32 AM 'Justin Uberti' via discuss-webrtc <discuss...@googlegroups.com> wrote:If you don't use STUN or TURN servers, your application probably didn't work very well before...Why? If you have a server running on public IP with UDP and TCP candidates, it works extremely well without STUN or TURN. In fact, all STUN or TURN servers do in this case are slowing call setup down and, in case of TURN, add latency by introducing extra hop.Regardless, even if one side doesn't understand mDNS, things will continue to work. The non-mDNS side will send an IP address candidate, the mDNS side will form a candidate pair with that address, and then the non-mDNS side will get an incoming connectivity check which will cause it to form a prflx candidate, and everything is good.In the above described case, server ends up with no usable candidates. So, the ICE nomination process on the server stops before getting any prflx candidates.That doesn't happen with trickle ICE. But if you are using vanilla ICE and all you need is a candidate to prevent the ICE process for terminating, just make up a fake address, e.g. 0.0.0.1 or some such.Even with trickle ICE this will happen when end of candidates is received but no usable candidates were sent.
Setting up some sort of reasonable time-out (40 seconds) before stopping the nomination process even when no usable candidates are available should resolve this issue.
--_____________Regards,
Roman Shpount
---
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/CAD5OKxuQ_7hLOWB61XQ1rhBJMuG98Wvi8KF7217zLSoAujiarw%40mail.gmail.com.
On Thu, Feb 7, 2019 at 10:23 AM Roman Shpount <rshp...@gmail.com> wrote:On Thu, Feb 7, 2019 at 12:07 PM 'Justin Uberti' via discuss-webrtc <discuss...@googlegroups.com> wrote:On Thu, Feb 7, 2019 at 8:42 AM Roman Shpount <rshp...@gmail.com> wrote:On Thu, Feb 7, 2019 at 11:32 AM 'Justin Uberti' via discuss-webrtc <discuss...@googlegroups.com> wrote:If you don't use STUN or TURN servers, your application probably didn't work very well before...Why? If you have a server running on public IP with UDP and TCP candidates, it works extremely well without STUN or TURN. In fact, all STUN or TURN servers do in this case are slowing call setup down and, in case of TURN, add latency by introducing extra hop.Regardless, even if one side doesn't understand mDNS, things will continue to work. The non-mDNS side will send an IP address candidate, the mDNS side will form a candidate pair with that address, and then the non-mDNS side will get an incoming connectivity check which will cause it to form a prflx candidate, and everything is good.In the above described case, server ends up with no usable candidates. So, the ICE nomination process on the server stops before getting any prflx candidates.That doesn't happen with trickle ICE. But if you are using vanilla ICE and all you need is a candidate to prevent the ICE process for terminating, just make up a fake address, e.g. 0.0.0.1 or some such.Even with trickle ICE this will happen when end of candidates is received but no usable candidates were sent.Hmm, this is a good point, but won't this already happen today? That is, if you supply a single 192.168.x.x host candidate from the client, won't the server fail its ICE checks to that candidate immediately, leading to termination of ICE?
--
---
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/9e2633f0-60b2-41f7-82f1-f699963ac532%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/2d2f1a9d-e6d2-4449-b2d8-001a751985eb%40googlegroups.com.
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/4Yggl6ZzqZk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/2d2f1a9d-e6d2-4449-b2d8-001a751985eb%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAEk4y02aMMKDypBkX1ZxsA%3DJoDTauu7jL2hQnsY8jQF5cgDNgg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/69e84ecf-1830-47c2-96da-da94fcf86b68%40googlegroups.com.
Within an enterprise, with multiple network segments (for example), you don't need a STUN server today. With mDNS, you would need one. The bureaucracy, overhead, maintenance, etc, of deploying another server seems unnecessary and prohibitive (external STUN may also not be an option due to security policies).
However, resolution of https://bugs.chromium.org/p/chromium/issues/detail?id=930339 should make this a non-issue.
On Sunday, February 10, 2019 at 12:29:48 AM UTC+1, Justin Uberti wrote:However, resolution of https://bugs.chromium.org/p/chromium/issues/detail?id=930339 should make this a non-issue.+1, that's a good improvement for media based applications (using host candidates for tracking is definitely not nice).However, it means that for enterprise users of datachannel-only applications, they now have the choice between accepting the privacy implications of explicitly giving microphone/camera permissions to an application that does not require microphone or camera, versus accepting the privacy implications of data traffic going through a third party TURN server even though both clients are in the same network.I understand the aversion to adding more prompts, but I'm still convinced that an "Allow this application to establish a direct data connection" prompt for non-media applications would solve a lot of those issues. First of all it would not require data-only applications to request camera and microphone access, and you could apply the same technique as in issue 930339 for data channels. If the permission is granted, return plain host IPs, otherwise return mDNS FQDNs.
Within an enterprise, with multiple network segments (for example), you don't need a STUN server today. With mDNS, you would need one. The bureaucracy, overhead, maintenance, etc, of deploying another server seems unnecessary and prohibitive (external STUN may also not be an option due to security policies).By the way, that doesn't only apply to VLAN based network segments, but for example many WiFi access points (e.g. by Cisco Small Business) also drop any mDNS broadcasts at the WiFi-boundary (and this can't be turned off). That means that mDNS candidates can only be resolved when the two sides are connected to the same AP within the company.Are there any stats being collected about the "resolvability" of mDNS-candidates versus regular IP candidates in the wild? Is there a significant difference?
On Sunday, February 10, 2019 at 12:29:48 AM UTC+1, Justin Uberti wrote:However, resolution of https://bugs.chromium.org/p/chromium/issues/detail?id=930339 should make this a non-issue.+1, that's a good improvement for media based applications (using host candidates for tracking is definitely not nice).However, it means that for enterprise users of datachannel-only applications, they now have the choice between accepting the privacy implications of explicitly giving microphone/camera permissions to an application that does not require microphone or camera, versus accepting the privacy implications of data traffic going through a third party TURN server even though both clients are in the same network.I understand the aversion to adding more prompts, but I'm still convinced that an "Allow this application to establish a direct data connection" prompt for non-media applications would solve a lot of those issues. First of all it would not require data-only applications to request camera and microphone access, and you could apply the same technique as in issue 930339 for data channels. If the permission is granted, return plain host IPs, otherwise return mDNS FQDNs.It's really hard to convey the meaning seemingly unrelated permissions to the user. Case in point: In Android the user needs to grant location permission in order to establish BLE connections. Of course, BLE can be used for tracking, therefore the location permission makes sense to an informed developer, but just check out Fitbit forums to see how many people are upset because the Fitbit app wants to access the location. The same thing could happen with the getUserMedia permission.
Danilo
--
---
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/0ecef485-734b-4128-82c8-cf663cb4c56d%40googlegroups.com.
An experiment to use mDNS to obfuscate host candidate IP addresses has started in Chrome Canary (M73).
With this feature, host IPs will no longer directly be exposed by the RTCPeerConnection API, increasing privacy. Host candidates will only indirectly be exposed through a randomly generated mDNS hostname.
Purpose and mechanisms used are described in this spec:
https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-02
The expected effects on connectivity between 2 WebRTC agents are:
- Two WebRTC agents using this feature, running in the same private network, may no longer be able to communicate directly if they are not in the same mDNS broadcast domain.
- A WebRTC agent using this feature will still be able to communicate with other agents on the same private network when the other agent does not have this feature (implemented or enabled). In this case, the other agent would classify the obfuscated host candidates as peer-reflexive candidates.
- Connectivity using server-reflexive or relay candidates will be unaffected.
No application code is affected by this feature, so there are no actions for developers with regard to this experiment.
This experiment affects Chrome on Windows, MacOS and Linux.
Regards,
Jeroen
--
---
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/CAM6ffLJoag6MpF7s827Lq-wHd%3DtZ3aRvQiHqq60%3DX-5%2BHVAKSg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CACHtiy_s6k35kWTpD2F%3Dsx%3D8aj2s1P8LdFW%2B_5-yMuMjJHxVaw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOJ7v-1JukWmYBvmckfSnT7r-%2BYMSqVMk5di-Gi6C9Crn4Uf4g%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/d939c142-3950-4a2d-b126-4535a79c83fe%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/7889997f-37b6-4592-96af-419b673e4303%40googlegroups.com.
This experiment affects Chrome on Windows, MacOS, Linux and ChromeOS.
Best regards,
Qingsi
subscriber send offer (receivevideo: true, recvaudio: true), SFU send answer. SFU is faster on sending candidates back to chrome.
Chrome tries to connect to our SFU and succeeded in that, so it only send a mdns.local candidate to SFU.
This candidate is not already supported by libnice, which drops that candidate.
Chrome sees the peerconnection in Connected state, so it doesn’t bother to send other candidates to our SFU (should send at least one srflx imo).
But for libnice, no remote candidates are received since the only mdns.local was dropped.
This prevents libnice to start it’s own connectivity check (by design, even if there are few proposal to handle this mdns candidates, still working on it), so for our SFU, no clients are currently “connected”, even if chrome is indeed in connected state.
So my current workaround is to “fake” a remote candidate when a .local is received and I wasn’t able to resolve it, to force libnice to start connectivity check and let him “know” that a remote peer is already connected, so it calls a callback and our codebase can start working.
I would not call this an "experiment"
--
---
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/8c5f68bd-c740-4d30-a71a-1ad716adcf8a%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CA%2Bm752L9mx6Lv0qTXSxjemNbkTD5SXmn7u%2B090wcQ%3D0v81CVBA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CADxkKiJ3%2BvqcKsObpP3MV%3Da5Ggv3c0oWfooVDqbULO8WjEHTZw%40mail.gmail.com.
> Chrome sees the peerconnection in Connected state, so it doesn’t bother to send other candidates to our SFUDoes it mean RTCPeerConnection.onicecandidate is not triggered? Other candidates should surface from the peer connection regardless of whether it's connected or not. If onicecandidate is not triggered, please file a bug on crbug.com and I'll look into it. Can you also confirm this is not the behavior of the web app in handling candidates?
On Tue, Jul 16, 2019 at 5:33 AM Francesco Durighetto <francesco...@gmail.com> wrote:
Am I the only one not receiving srflx candidates alongside a single uuid.local mDns address even with valid turn and stun config?--Chrome: 75.0.3770.100SCENARIO:subscriber only (chrome) —> SFU (ICE stack based on libnice)subscriber send offer (receivevideo: true, recvaudio: true), SFU send answer. SFU is faster on sending candidates back to chrome.
Chrome tries to connect to our SFU and succeeded in that, so it only send a mdns.local candidate to SFU.This candidate is not already supported by libnice, which drops that candidate.
Chrome sees the peerconnection in Connected state, so it doesn’t bother to send other candidates to our SFU (should send at least one srflx imo).But for libnice, no remote candidates are received since the only mdns.local was dropped.
This prevents libnice to start it’s own connectivity check (by design, even if there are few proposal to handle this mdns candidates, still working on it), so for our SFU, no clients are currently “connected”, even if chrome is indeed in connected state.
So my current workaround is to “fake” a remote candidate when a .local is received and I wasn’t able to resolve it, to force libnice to start connectivity check and let him “know” that a remote peer is already connected, so it calls a callback and our codebase can start working.
I would not call this an "experiment"
---
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/aee22b90-875f-49df-9649-d8678d72fa39%40googlegroups.com.