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:
Restricting persistent permissions is essentially about cache poisoning attacks. The assumptions seem to be that a] https is not vulnerable b] every http transaction is as vulnerable as the last Those are imperfect (which, granted, is not necessarily a reason to not proceed - but read on for fun!). 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. 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. 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. On Fri, Mar 6, 2015 at 12:27 PM, Anne van Kesteren <ann...@annevk.nl> wrote: > A large number of permissions we currently allow users to store > persistently for a given origin. I suggest we stop offering that > functionality when there's no lock in the address bar. This will make > it harder for a network attacker to abuse these permissions. This > would affect UX for: > > * Geolocation > * Notification > * Fullscreen > * Pointer Lock > * Popups > > If you are interested in demos of how these function today: > > * http://dontcallmedom.github.io/web-permissions-req/tests/geo-get.html > * > http://dontcallmedom.github.io/web-permissions-req/tests/notification.html > * http://dontcallmedom.github.io/web-permissions-req/tests/fullscreen.html > * > http://dontcallmedom.github.io/web-permissions-req/tests/pointerlock.html > * http://dontcallmedom.github.io/web-permissions-req/tests/popup.html > > Note that we have already implemented this for getUserMedia(). You can > contrast the UX for these two links: > > * > http://dontcallmedom.github.io/web-permissions-req/tests/gum-audiovideo.html > * > https://dontcallmedom.github.io/web-permissions-req/tests/gum-audiovideo.html > > This seems like a change we can make today that would be better for > our users and nudge those that require persistence to do the right > thing, without causing much harm. > > > -- > https://annevankesteren.nl/ > _______________________________________________ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
