- From: Göran Eriksson AP <goran.ap.eriksson@ericsson.com>
- Date: Wed, 22 Apr 2015 09:50:10 +0000
- To: Dominique Hazael-Massieux <dom@w3.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <D15D39B2.129D7%goran.ap.eriksson@ericsson.com>
Hi, Working more with existing and emerging web platform security mechanisms is good and personally I believe more is beneficial. Here are a few slides related to the discussion about IP address leakage as ³food for thought² and shared ³as is². BTW- they are not that recent (February). Many Regards Göran -----Original Message----- From: Dominique Hazael-Massieux <dom@w3.org> Date: Wednesday 22 April 2015 11:06 To: W3C WEBRTC <public-webrtc@w3.org> Subject: Security mitigations for IP leakage Resent-From: W3C WEBRTC <public-webrtc@w3.org> Resent-Date: Wednesday 22 April 2015 11:06 >Hi, > >As previously discussed, the ability that WebRTC gives to any random web >site to discover IP addresses that would not be otherwise detectable is >an issue that we will need to address: >https://github.com/w3c/webrtc-pc/issues/179 > >Justin recently brought a proposal to the RTCWeb list on how to manage >this mostly from a protocol perspective: >http://www.ietf.org/mail-archive/web/rtcweb/current/msg14494.html > >In complement to the protocol approach, I thought it would be worthwhile >to document what mitigation mechanisms exist on the Web platform to >limit when potentially sensitive features can be used by Web pages. > >I list below the ones I've been able to identify (but there may be >more); I think it would be useful to study at some point which of these >could be used to limit the impact of the IP address leakage ‹ but that >probably requires a good understanding of the various threats that >revealing private IP address entails (on which I have enlisted the help >of the Privacy Interest Group, with only limited results so far [1]). > >The mitigations off the top of my head (please help complete it): >* the same-origin policy (limits what can be done on and by resources >from different origins) > >* user prompt (ask the user before granting permission) > >* user forgiveness (allow by default, but let user undo the permission >grant) > >* user opt-in (denied by default, but allow the user to explicitly allow) > >* user engagement (only grant access to a feature if the user has >interacted with the page) > >* restricted to top-level browsing context (a feature can only be used >from the top frame, with sometimes the ability to explicitly grant it to >embedded content) > >* content security policy (limit set by HTTP header on what the content >can do) > >* UI indicators (give hints to the user that something is going on) > >* secure-origin only (feature only available from https) > >* frecency heuristics (feature only available if the user has come to a >given Web page recently and frequently) > >* bundled permission (permission granted if a more sensitive and related >permission has been granted) > >* whitelist / blacklist and other out-of-band mechanisms (e.g. search >engine warnings) > >Dom > >1. https://www.w3.org/wiki/Privacy/IPAddresses > >
Attachments
- application/pdf attachment: WebRTC IP leakage.pdf
Received on Wednesday, 22 April 2015 09:50:38 UTC