<div dir="ltr"><div><div><div><div><div>I have a slight twist in thinking to offer on the topic of persistent permissions.. part of this falls to the level of spitballing so forgive the imprecision:<br><br></div>Restricting persistent permissions is essentially about cache poisoning attacks. The assumptions seem to be that<br></div><div>a] https is not vulnerable<br></div></div>b] every http transaction is as vulnerable as the last<br><br></div><div>Those are imperfect (which, granted, is not necessarily a reason to not proceed - but read on for fun!).<br></div><div><br></div>wrt A: We know that this assumption around https is a little sketchy due to the way the root store is commonly ...ummm.. "localized". An enterprise user allows a new trust anchor for use with their company proxy, during which time they are by definition MITM'd by consent. I'm not especially worried about that transaction - such is the nature of the consent. But then they take that laptop home to a different context without that proxy. The cached information, in this case a persistent permission, remains. There is no reason to think the trust between those two environments should overlap. The HTTP cache has fundamentally the same problem (think about a ubiquitous resource like ga.js) as the persistent permission.<br><br></div>wrt B: If a user on a home broadband connection conducts a transaction over plaintext she certainly is exposed to a MITM attack. But repeating that operation from the same location only adds small marginal risk (i.e. the risk of the path changing or the actors on that path changing - this can happen but often does not). OTOH if she moves to her neighbor's wifi or roams to 4g then its a whole new ballgame. The uri scheme isn't a good indicator of risk for each click.<br><div><div><br></div><div>Daniel Stenberg has some code that tries to establish an internal what-network-am-i-on ID. Think of a more fully implemented version of it as a hash of your network interfaces and MACs, your router's MAC, etc.. Its currently just used as part of link-change-detection.. but it could make a pretty interesting part of a cache key for things we are worried about being poisoned - the result here would be scoping of persistent permissions to the topology that you accepted them on.<br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 6, 2015 at 12:27 PM, Anne van Kesteren <span dir="ltr"><<a href="mailto:annevk@annevk.nl" target="_blank">annevk@annevk.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
If you are interested in demos of how these function today:<br>
<br>
* <a href="http://dontcallmedom.github.io/web-permissions-req/tests/geo-get.html" target="_blank">http://dontcallmedom.github.io/web-permissions-req/tests/geo-get.html</a><br>
* <a href="http://dontcallmedom.github.io/web-permissions-req/tests/notification.html" target="_blank">http://dontcallmedom.github.io/web-permissions-req/tests/notification.html</a><br>
* <a href="http://dontcallmedom.github.io/web-permissions-req/tests/fullscreen.html" target="_blank">http://dontcallmedom.github.io/web-permissions-req/tests/fullscreen.html</a><br>
* <a href="http://dontcallmedom.github.io/web-permissions-req/tests/pointerlock.html" target="_blank">http://dontcallmedom.github.io/web-permissions-req/tests/pointerlock.html</a><br>
* <a href="http://dontcallmedom.github.io/web-permissions-req/tests/popup.html" target="_blank">http://dontcallmedom.github.io/web-permissions-req/tests/popup.html</a><br>
<br>
Note that we have already implemented this for getUserMedia(). You can<br>
contrast the UX for these two links:<br>
<br>
* <a href="http://dontcallmedom.github.io/web-permissions-req/tests/gum-audiovideo.html" target="_blank">http://dontcallmedom.github.io/web-permissions-req/tests/gum-audiovideo.html</a><br>
* <a href="https://dontcallmedom.github.io/web-permissions-req/tests/gum-audiovideo.html" target="_blank">https://dontcallmedom.github.io/web-permissions-req/tests/gum-audiovideo.html</a><br>
<br>
This seems like a change we can make today that would be better for<br>
our users and nudge those that require persistence to do the right<br>
thing, without causing much harm.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
<a href="https://annevankesteren.nl/" target="_blank">https://annevankesteren.nl/</a><br>
_______________________________________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
</font></span></blockquote></div><br></div>