<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 7, 2015 at 11:48 AM, Aryeh Gregor <span dir="ltr"><<a href="mailto:ayg@aryeh.name" target="_blank">ayg@aryeh.name</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On Fri, Mar 6, 2015 at 7:27 PM, Anne van Kesteren <<a href="mailto:annevk@annevk.nl" target="_blank">annevk@annevk.nl</a>> wrote:<br>
> A large number of permissions we currently allow users to store<br>
> persistently for a given origin. I suggest we stop offering that<br>
> functionality when there's no lock in the address bar. This will make<br>
> it harder for a network attacker to abuse these permissions. This<br>
> would affect UX for:<br>
><br>
> * Geolocation<br>
> * Notification<br>
> * Fullscreen<br>
> * Pointer Lock<br>
> * Popups<br>
<br>
</span>What attack is this designed to mitigate?  If the user allows an<br>
unsecured site to use (for instance) geolocation, whether persisted or<br>
not, an MITM will be able to get the geolocation info as long as<br>
they're intercepting the traffic, right?  And if they have some way to<br>
persist their scripts via injecting modified resources with long cache<br>
timeouts or such, they can still get the info as long as the user<br>
keeps clicking "yes".  And the user will definitely keep clicking yes,<br>
because a) they clicked it the first time, and b) you have conditioned<br>
them to click "yes" a million times on the same site.  So how does not<br>
persisting this info help at all?  Probably I'm missing something<br>
obvious.</blockquote><div><br></div><div>Let's consider a different example than the one you propose: access</div><div>to the camera and microphone via getUserMedia(). Say that a site</div><div>adds a feature which lets you take a picture of yourself for your</div><div>avatar (come to think of it, I wish github did this). If the permissions<br></div><div>are persistent, then the site (or if HTTPS isn't used, any network</div><div>attacker) can access my camera and see what's going on in my</div><div>room at any time [0] and largely without my knowledge.</div><div>By contrast, if I need to click OK in order to give a remote site access</div><div>to my camera (even if I generally do consent without much thought)</div><div>this makes the attack much more difficult to mount.</div><div><br></div><div>A similar set of argument seem to me to apply to geolocation.</div><div>It's one thing to give a temporary grant of access, and quite</div><div>another to let any network attacker track me whenever they</div><div>want.</div><div><br></div><div>-Ekr</div><div><br></div><div>P.S. Anne, thanks for raising this issue.</div><div><br></div><div><br></div><div>[0] This isn't a hypothetical kind of attack. See, for instance the description</div><div>of ratters in Brocker and Checkoway. page 11.</div><div><a href="https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/brocker" target="_blank">https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/brocker</a><br></div></div></div></div>