The topic of IP address privacy in WebRTC has been problematic for years. At the recent IETF meeting a new proposal from Apple offered an alternate approach to solving this problem. In this webinar we will briefly review this new approach.

1. WebRTC Standards Q&A
Amir Zmora
TheNewDialTone
Dan Burnett
StandardsPlay

2. Watch video recording of this session
http://ccst.io/e/webrtcstandards27

3. Session sponsored by
WebRTC.ventures is a custom design and development shop dedicated to building WebRTC based applications
for web and mobile. We have built end-to-end broadcast solutions for events and entertainment clients,
telehealth solutions for multiple clients, live support tools, as well as communication tools for a variety of other
applications. WebRTC.ventures is a recognized development partner of TokBox and has also built native
WebRTC solutions

4. We use CrowdCast….It’s WebRTC

5. WebRTCStandards.info
Sponsored by

6. About Us
• Amir Zmora • Dan Burnett

7. IP address privacy revisited

8. We have discussed this before
• July 2016
• https://www.crowdcast.io/e/webrtcstandards6/
• The problem: ICE returns addresses at which your browser can be reached
• Local Address – useful for testing and local-network media
• can reveal internal network structure
• can be used for fingerprinting
• Public Address – needed for everything else
• any unencrypted path to a STUN server provides an address
• all such addresses are available to all applications in all browsers
• this is a problem for VPN users if not all traffic goes over the VPN (the so-called'

9. Recommended behavior at that time
• Recommended default behavior for the "drive-by web":
• Browser will identify the default route (the route used by normal HTTP traffic)
• It will use only that route for STUN traffic
• It will only reveal the local address associated with that route/interface
• Recommended behavior once camera & mic permission have been given:
• WebRTC will bind to and use all available addresses, all routes
• This will reveal everything
• In short, giving camera and mic access also gives full IP address access

10. Behavior options today
• https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-09
• Mode 1 – reveal all IP addresses ('after permission given')
• Mode 2 – reveal only default route and associated local addresses ('drive-by web')
• Mode 3 – reveal only default route
• Mode 4 – force proxy

11. A concern with mode 2
• Raised at the last IETF meeting: https://datatracker.ietf.org/meeting/102/materials/slides-
102-rtcweb-ip-handling-00
• Some local IPs still give away too much network config or fingerprinting info
• Apparently too many web pages are still making suspicious use of WebRTC
• Safari has only been giving out IP addresses already known to the web page, i.e. no local
addresses
• … but this has broken various games and file transfer apps

12. A better solution for local addresses is needed
• At the IETF meeting the following was proposed:
• Instead of giving out local IPv4 addresses, give out mDNS addresses.

13. Status
• RTCWEB Working Group in IETF agreed to adopt the doc to work on
• But no new draft exists yet
• And plenty of concerns were raised during the meeting

14. ?

15. Joining WebRTC Standards: Jan-Ivar Bruaroey

16. Many thanks to Dan Burnett for his work over the last
3 years

17. Session sponsored by

18. WebRTC Standards & Implementation
Q&A
Amir Zmora
TheNewDialTone
Dan Burnett
StandardsPlay