W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2015

Re: Security mitigations for IP leakage

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>

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

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

>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:
>Justin recently brought a proposal to the RTCWeb list on how to manage
>this mostly from a protocol perspective:
>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
>* 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)
>1. https://www.w3.org/wiki/Privacy/IPAddresses

Received on Wednesday, 22 April 2015 09:50:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:43 UTC