Re: Security mitigations for IP leakage

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