On Fri, Jan 25, 2019 at 8:50 PM Daniel Veditz <dved...@mozilla.com> wrote:
> > Your description equating cookies and storage within a document lifetime > makes sense. Is this intended to also apply to network requests? The > first-party document already has no access to 3rd party cookies so it > shouldn't matter at that level if Necko's rules change "live". If I'm on > twitter/facebook (which make constant background requests) and I clear my > entire cookie jar those documents are going to break. If I just tossed all > my cookies that's what I want! Discovering that I'm still logged into those > sites would be disturbing. Similarly, if I flip the "block 3rd-party > cookies" pref I'm going to react negatively if I still see tracker cookies > showing up just because I've left an active page open somewhere. > Denying access to cookies doesn't make the user logged out from a website. The website can still have tokens in memory and send them to servers, for example. And also if the website is not able to identify you to the server, it will probably show the same UI as you were still logged in. This is extremely confusing. The only way to be sure you are logged out is a full reload of the opened tabs. Another good point to accept this proposal is that, when we will have the StoragePrincipal in place, going from BEHAVIOR_ACCESS to BEHAVIOR_REJECT_TRACKER would be actually a big problem without reloading the tabs. If we try to apply the new cookie policy immediately, 3rd party trackers in opened tabs should switch to a first-party-isolation storage, but they could also have already data in memory (user-tokens), and populate the new cookie jar consequentially. This would break the isolation. The solution in this case, is to apply the change only after the reloading. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
