Thanks for writing this up and adding the great explanations, Andrea! I think your proposal has a lot of benefits and I don't have any major concerns about it, I would just like to add a few comments:
Just to reiterate, per your proposal the cookie policy (network.cookieBehavior pref) and permission will be stored on the load info. As you said, after this change, we should definitely add some notice in our UI to make users aware of the fact that they need to reload their tabs for the setting to take effect. I would absolutely advise against silently reloading tabs (which was suggested somewhere in this thread) and potentially discarding user data without explicit choice, though. If our UX designer find a good way to offer users the choice to reload all tabs via an optional button, that might be a good middle ground. To be honest, either way I think this is a slight degradation in user experience. Nobody likes restarting/reloading their things after updating settings. Given the benefits this is probably acceptable. In general, I don't think a lot of people regularly update their cookie exceptions. There might be a larger group of people who occasionally modify their cookie policy, but I doubt that many of them regularly switch between two settings, making this something that is most likely to be noticed in artificial conditions e.g. by web developers or other power users. Hence, I totally expect to receive bug reports once we start changing this. All in all this seems like a fair compromise to me. Thanks, Johann On Mon, Jan 28, 2019 at 10:32 AM Andrea Marchesini <[email protected]> wrote: > > > On Fri, Jan 25, 2019 at 11:55 PM Ehsan Akhgari <[email protected]> > wrote: > >> On Fri, Jan 25, 2019 at 2:51 PM Daniel Veditz <[email protected]> >> 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. >>> >> >> Cookies have been dynamic and racey since the dawn of time, both at the >> HTTP layer and in their reflection in DOM (document.cookie). Clearing your >> cookies isn't something that is changed by this proposal. I'm not too sure >> how Andrea was planning to handle cookie policy at the Necko layer but we >> have a lot of flexibility here and pages also can probably tolerate dynamic >> changes to document.cookie. I *think* handling the cookie policy globally >> at the Necko layer is probably easier but I'm curious to know Andrea's >> thoughts. >> > > As Ehsan says, I don't want to change how we cleanup cookies but only how > we expose cookie policy and how to treat cookie permissions. > About the implementation, I would store the current cookie policy and > cookie permission into the nsILoadInfo object of a document/subdocument > nsIChannel. This information will be used in nsCookieService, > document.cookies() getter/setter and propagated to any > storage/communication API as described in this email thread (from > BroadcastChannel to localStorage). I also would audit any cookie-permission > check and any cookie-policy preference getter call. > > In this way, when the cookie behavior or a cookie permission changes, the > document will not be affected because it has its own 'copy' of the previous > values. > We also need to improve the UI to communicate the the changes will apply > at the next reload of the current tabs. > _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
