I think the main question that needs to be answered here is: "How does that make the situation better?" There is an extensive document from the Chrome team <https://docs.google.com/document/d/1x5QejvpyQ71LPWhMLsaM1lWCfSsBsSQ8Dap9kJ6uLv0/edit?ts=5b857603#heading=h.ib6rctasbt3y> on their motivation, but I'd like to add some things on the Firefox side.
Let's examine the current situation in Firefox, which, in my opinion (as someone who's partly responsible and wants to fix it), is quite bad. We have two big problems: When an origin requests access to a permission (either as first or third party) and the user wants to remember this decision, the Firefox permission manager by default stores a key-value pair consisting of origin and permission value[0]. It does not "double-key", so there's no differentiation between first or third party access. This means an embedded google.com iframe, having access to your geolocation through google.com/maps, can track your geolocation around the web. Or someone deep-links into google hangouts in an iframe and records you. Fun. In Firefox's defense, unlike in Chrome, the permission is not stored permanently by default, it's an optional choice that few users actually make. This problem could be easily[1] solved by double-keying permissions. So that would be good, if it wasn't for another problem: As outlined in the Chrome document, there is strong evidence that most users (except maybe you, me and everyone else on this thread) can not reason about the concept of iframes, at all. So asking users to make a reasonable choice if "google-hangouts-secure-connection.com" on google hangouts should get camera access or not is *a lot* to ask (assuming they even look at the origin). Then there's the UX that needs to be built for managing the permissions users granted. To enable proper configuration, you basically have to model the frame tree in all your UI and hope users understand it. Some time ago the Chrome team came up with an approach to solve this. Permission delegation enabled by Feature Policy. It solves both issues outlined above by taking some responsibility away from the end user and putting more responsibility in web developers hands. I fully understand that as a security researcher you've seen how that can go wrong and that as an advanced user you feel secure with the current system. We agree to a certain extent and we've taken a *long* time considering, standardizing and implementing this approach. The concept isn't perfect and of course it clashes with double-keying, so we can't have both. As mentioned earlier, there are a few things we as Mozilla have found too lax on the security side (like the "*" attribute) and have thus modified in our implementation. You are right that this will slightly increase the impact of HTML injection attacks under certain conditions. Nonetheless, after all consideration, we think this concept is the best combined solution to both outlined problems that we've seen so far, which is why we want to move ahead and ship it. Cheers, Johann [0] it stores more than that of course, like expiry information, but not the first party identifier by default [1] conceptually easy. The implementation is messy, which we know since we've recently built this as part of first-party isolation (for Tor) and are still dealing with the fallout On Tue, Dec 3, 2019 at 3:59 PM Thomas Nguyen <tngu...@mozilla.com> wrote: > On Wednesday, November 27, 2019 at 7:50:46 PM UTC+1, s.h...@gmail.com > wrote: > > >Conversely, there would be another attack to link to > > >attacker spaces on already-trusted sites (but no top-level) >and get > silently access too. > > That is not silent, because user would have already granted permission > to that origin to access in previous model. > > > > > > >Besides, if a user granted skype.com, the origin is > > >vulnerable to HTML injection, then when an attacker > > >requests a permission grant, the users may not have any > > >context for or understanding of them, that is very > > >confusing and users tend to accept that request because > > >they are under a trusted context of the top-level origin. > > So the way you are solving this problem is, instead of showing prompt > with iframe’s origin, just delegate permission from top frame or request > permission with the origin of top frame? How did that made the situation > better? You are ultimately taking away origin indicator from people who > understood what it means :( > > > > I’m really disappointed that Firefox is taking this path. > The idea to change comes from a couple of reasons. One as I mentioned, > there were attacks, deep linking to attacker spaces on already-trusted > sites (not the top), and a couple of UI issues that could be resolved by > this simplification. > So sorry if it hurts your, anw, thanks for your idea, we will look into > that to see if we have any mitigation > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
