On Thu, Oct 17, 2019 at 1:35 PM Matthew N. <ma...@mozilla.com> wrote:
> On 2019-10-16 7:15 a.m., Paul Zühlcke wrote: > > I plan to land a patch next week which will disable OriginAttribute > > stripping in the permission manager. This will result in private browsing > > windows and containers having isolated permissions. > > Are we still planning to strip origin attributes before insertion into > the permission manager for permissions that have management UI (e.g. in > about:preferences)? If not, how do we plan to represent the origins > there? I think we wouldn't want to expose the originSuffix directly to > our users e.g. something like https://www.facebook.com^userContextId=7 > when using the Facebook container. > That's https://bugzilla.mozilla.org/show_bug.cgi?id=1556212 for FPI - there's a lot of discussion on this topic there. Based on the number of dupes we got into that bug - there is a startling lot of people who both use special cookie exceptions and file bugzilla bugs. So I would suggest handling this case explicitly before landing it. In the context of FPI, we tentatively concluded that we want to special-case the permission checks if the user has FPI enabled to to either check for a user-granted permission to the domain sans-FPI (if first party context) or default-deny (if third party context.) This varies slightly per permission, but the most common case - Cookie permissions - we think we want to work like that. I think we probably want the same behavior for userContextID. This will mean you can't set an exception for Facebook at the container granularity (e.g. 'only allow Facebook to set cookies in Container 7'). (It would be awesome if you fixed 1556212 at the same time) -tom _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
