Re: Cookie policy/permission in live documents - proposal
Hi Andrea, others, I am mostly ignorant of these matters, so please correct me when I'm wrong. On Wed, Jan 23, 2019 at 5:24 AM Andrea Marchesini wrote: > Hi all, > > When the cookie policy or a cookie permission changes, firefox applies the > new behavior to any existing documents immediately. I would like to change > this, applying the new behavior to new documents only. > > The reasons why I think we should not apply the new behavior to > live-documents are this: > > *websites can break* > If we go from BEHAVIOR_ACCEPT to BEHAVIOR_REJECT (or ACCEPT_DENY), all the > storage APIs will start throwing exceptions (or reject promises). This is > an unpredictable behavior which can break the website's logic and makes the > storage APIs inconsistent. Note that this is different than blocking > cookies since the document loading. > Plus it doesn't give any extra security/privacy benefit: the website could > have already copied cookie data into local variables and it can still send > this data to the server. > If we go from BEHAVIOR_REJECT to BEHAVIOR_ACCEPT (or ACCEPT_ALLOW), > basically no website can "recover" itself without a reloading. > > subdocument content, stores the cookie behavior (permission + policy) for > its principal at creation time. The policy is applied to the whole > document's cookie jar and it doesn't change. > For BEHAVIOR_REJECT_TRACKER, when the storage access is granted (see > AccessStorage API and the anti-tracking heuristics), we recalculate the > document's cookie policy. > > When the cookie policy or a cookie permission is changed, we inform the > user that the current tabs must be reloaded in order to apply the new > settings. > You pointed out one case of unpredictable behaviour: a website's logic cannot preserve assumptions across the entire duration of it's JS execution context. But if we don't apply the policy instantly, isn't the reverse situation also possible? When the browser tells me to reload a tab I generally open a new tab and navigate back -- who knows what state I wanted that would be lost. Now suppose I do that and have the same origin in two tabs. In your situation the two tabs can have different policies for their JS execution lifetimes, correct? And some of these "cookie" mechanisms -- particularly localStorage -- are used for communicating between tabs, IIUC. I am not sure if cookies themselves matter between tabs, but perhaps they do. Now my two tabs might see subtly different data for the same origin. Is this an issue in theory? Will it be an issue in the wild? I'm totally willing to hear that I don't understand our document/origin/something else model. Thanks! Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookie policy/permission in live documents - proposal
> You pointed out one case of unpredictable behaviour: a website's logic > cannot preserve assumptions across the entire duration of it's JS execution > context. But if we don't apply the policy instantly, isn't the reverse > situation also possible? With my proposal, you will have 2 tabs, loading the same origin with 2 different cookie behaviors. Let's assume that one is BEHAVIOR_ACCEPT and the other one BEHAVIOR_REJECT, doesn't matter the order. The 2 tabs will not be able to communicate to each other because: - we don't dispatch storage events, and/or they will not considered by the other tab. - sessionStorage, localStorage, indexedDB, ... let's say storage APIs throw exceptions in the tab with BEHAVIOR_REJECT policy. - that tab will not be able to use APIs such as SharedWorkers, or BroadcastChannels. In general, we allow tab communication only if they have both BEHAVIOR_ACCEPT cookie policy (or the corresponding permission: ACCEPT_ALLOW). Note that what I'm describing here already exists for private browsing contexts which are unable to talk with same origins in normal contexts. b ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookie policy/permission in live documents - proposal
On Thu, Jan 24, 2019 at 8:33 AM Andrea Marchesini wrote: > With my proposal, you will have 2 tabs, loading the same origin with 2 > different cookie behaviors. > Let's assume that one is BEHAVIOR_ACCEPT and the other one BEHAVIOR_REJECT, > doesn't matter the order. > The 2 tabs will not be able to communicate to each other because: > Presumably if there is an opener relationship between the tabs, things might be a little odd, because you can postMessage, but not use localStorage. So I don't think that this is exactly like private-normal browsing. I get that this is difficult, but can you talk a bit about what you think the driving principles are here? You mention presenting a consistent experience with respect to access to state, which is a fine principle. If we model access to that state as a permission that can be actively requested by a site - as per - document.requestStorageAccess - how does that fit? (I confess to not having good kept up with developments on that API, so I apologize if this is off the reservation.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookie policy/permission in live documents - proposal
On Wed, Jan 23, 2019 at 11:33 AM Andrea Marchesini wrote: > > You pointed out one case of unpredictable behaviour: a website's logic >> cannot preserve assumptions across the entire duration of it's JS >> execution >> context. But if we don't apply the policy instantly, isn't the reverse >> situation also possible? > > > With my proposal, you will have 2 tabs, loading the same origin with 2 > different cookie behaviors. > Let's assume that one is BEHAVIOR_ACCEPT and the other one > BEHAVIOR_REJECT, doesn't matter the order. > The 2 tabs will not be able to communicate to each other because: > > - we don't dispatch storage events, and/or they will not considered by the > other tab. > - sessionStorage, localStorage, indexedDB, ... let's say storage APIs > throw exceptions in the tab with BEHAVIOR_REJECT policy. > - that tab will not be able to use APIs such as SharedWorkers, or > BroadcastChannels. > > In general, we allow tab communication only if they have both > BEHAVIOR_ACCEPT cookie policy (or the corresponding permission: > ACCEPT_ALLOW). > > Note that what I'm describing here already exists for private browsing > contexts which are unable to talk with same origins in normal contexts. > Ah -- this private browsing analogy clarifies some things for me. For PB we make private tabs be in a different window. I don't know of that's a choice or a technical limitation. If it's a choice, should we be separating tabs with different cookie behaviours in some way? If we're concerned about this being confusing (like private tabs mixed with non-private), can we force existing tabs to close or reload right then so there's never this dual state you're working to change? Best, Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookie policy/permission in live documents - proposal
> > Presumably if there is an opener relationship between the tabs, things > might be a little odd, because you can postMessage, but not use > localStorage. So I don't think that this is exactly like private-normal > browsing. > > Yes. This is right. But I don't think we should block postMessage(). Btw, the same issue can be used as workaround for document.requestStorageAccess(). I get that this is difficult, but can you talk a bit about what you think > the driving principles are here? You mention presenting a consistent > experience with respect to access to state, which is a fine principle. If > we model access to that state as a permission that can be actively > requested by a site - as per - document.requestStorageAccess - how does > that fit? (I confess to not having good kept up with developments on that > API, so I apologize if this is off the reservation.) > requestStorageAccess is part of the Storage API and it's meant to be used by 3rd party contexts, marked as trackers by the URL-Classifier. We deliberately block their cookie jar before document.requestStorageAccess() or before the heuristic. So, trackers are a corner case. We are planning to create a fully separate cookie jar for them and I'll tell you more at the end of this email. I think I described why we should go in the direction of my proposal, in particular for normal websites: performance; less code complexity; consistency in APIs. I would like to add a couple of reasons more: - security/privacy/bugs: at the moment, many APIs are not able to deal with changes in cookie permission/policy: after the changes, they behave as before. This is definitely a bug, but it's also true that it's hard to support these changes correctly and consistently. I would say: security/privacy because each 'broken' API can be used to workaround the new cookie policy - at least until the page is reloaded. - cookie permission vs other permissions: Let me compare geolocation and cookie permissions: geolocation is strongly connected with 1 API and its setting is usually triggered by that API (the user must accept it via permission prompt, of course). The API knows that, in order to have geo data, it must ask for it, and it must handle a possible rejection. The workflow is: asking, permission granted or denied (callback-based, or promise-based). This is a different model compared with cookie policy. Cookie policy is a kind-of internal browser setting which should not be exposed to webpages when changing. Cookie permission is a way to implement exceptions on top of the cookie policy. We should not treat the cookie policy as a normal permission setting. For the anti-tracking project, we are planning to introduce the concept of 'StoragePrincipal' (Q2?). The details are not finalized yet, but here is the rough idea: a StoragePrincipal is, for non-tracker documents, equal to the document's origin, which, in gecko-world, is called the NodePrincipal (nsIPrincipal interface). For trackers, before having the storage access permission granted, StoragePrincipal will be the NodePrincipal plus first-party-isolation. This means that trackers will have a separate cookie jar, double-keyed with the top-level origin: same tracker, as 3rd party on different websites, will have separate cookie jars. We want to use StoragePrincipal everywhere we give access to the cookie jar, such as storage APIs, network/image cache and messaging APIs (BroadcastChannel, Reporting API and so on). When the storage access permission is granted (by the heuristic or by the Storage Access API), we reset the StoragePrincipal to be equal to the NodePrincipal and we recreate sessionStorage, localStorage and so on. At this point, the tracker will have access to its first-party cookie jar. There are several comments to do here: - localStorage objects (or any other storage API) before and after the permission granted will be different and, both will work after, but pointing to different cookie jars. - postMessages between window will work as it does today, because it will use the NodePrincipal, and not the StoragePrincipal. I suspect that all of this is out of topic. StoragePrincipal has been discussed during several anti-tracking meeting and with during the last All-Hands too. If interested I can send a separate email when we will have a concrete plan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookie policy/permission in live documents - proposal
Thanks for the piece about StoragePrincipal. I think that motivates this well for me. Changing principal is not something we can do trivially (or not something we should even contemplate ideally). I do want to pick out one comment you made, which is probably off-topic for the thread, but I think important in this context. I'm happy to discuss more separately if you think I'm taking this too far afield. On Fri, Jan 25, 2019 at 12:23 AM Andrea Marchesini wrote: > We should not treat the cookie policy as a normal permission setting. > I want to challenge this, because I think that our posture toward storage might set a pattern for how we deal with other things as well. The question here is what sort of special treatment we give to storage/cookie access. There are two aspects I think that you are concerned with: hiding what we are doing from pages, and the whole discussion we're having on this thread. There are two reasons I can see why we might consider access to storage to require "hiding" of some sort. The first is that we want to make sure that pages that were built with an expectation of access to persistent storage, continue to work more or less as they did before. We don't want them to be able to track people, but we don't want them to suddenly catch fire. In that light, we're not really hiding the fact that we are compartmentalizing persisted data, we're just ensuring that those pages aren't surprised by errors. The second possibility is that we might want to be able to present a fake environment to trackers that mimics a real one, but is limited. That is, they might think that they are operating in an unconstrained iframe, but they really aren't. I think that the fact that you can query with document.hasStorageAccess puts us firmly in the first bucket. While we might present a somewhat functional API, we're only doing that to avoid bustage for old documents, and we're not trying to hide the fact that we're blocking their ability to track. From that perspective, having this modelled as a permission (and even allowing permission.query() to work) is probably OK. So this is really about the dynamism aspects of this. Clearly, building a system where you can switch out the fake storage with the real one dynamically is hard. The surface area is surprisingly big and the changes are pervasive. That's infeasible. But I think that rather than saying that permissions are a poor fit, I think that it would pay to think more about how maybe we might fix this in permissions. Because I think that this is something that works with permissions in many other respects - it's something that we might want to bake into feature policy for instance. When we talked about permissions recently, we concluded that there were some aspects of the .query() API that didn't properly reflect the range of policies that might apply. For instance, permission for some actions is conditional on an engagement gesture (a click or key press). Here I think that we might have a new condition: the permission is conditional on the page being refreshed. Now, I concede that perhaps this is too ambitious and in the absence of other cases that share this constraint this might be overgeneralizing, but I think that this fits reasonably well. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookie policy/permission in live documents - proposal
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. -Dan Veditz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookie policy/permission in live documents - proposal
On Thu, Jan 24, 2019 at 5:34 PM Martin Thomson wrote: > There are two reasons I can see why we might consider access to storage to > require "hiding" of some sort. > > The first is that we want to make sure that pages that were built with an > expectation of access to persistent storage, continue to work more or less > as they did before. We don't want them to be able to track people, but we > don't want them to suddenly catch fire. In that light, we're not really > hiding the fact that we are compartmentalizing persisted data, we're just > ensuring that those pages aren't surprised by errors. > > The second possibility is that we might want to be able to present a fake > environment to trackers that mimics a real one, but is limited. That is, > they might think that they are operating in an unconstrained iframe, but > they really aren't. > > I think that the fact that you can query with document.hasStorageAccess > puts us firmly in the first bucket. While we might present a somewhat > functional API, we're only doing that to avoid bustage for old documents, > and we're not trying to hide the fact that we're blocking their ability to > track. From that perspective, having this modelled as a permission (and > even allowing permission.query() to work) is probably OK. > Note that hasStorageAccess() doesn't reveal whether you have "storage" access, rather it reveals whether you have "storage access". The difference is very subtle, but here "storage access" means the thing that you gain if you'd called requestStorageAccess() before, or if the browser determines that you're eligible to receive the kind of access that function is capable of granting you. That is effectively a subversion of our soon-to-be-default cookie policy for third-party trackers for web compatibility, not "storage" access in the sense you're referring to here. But anyways, there is navigator.cookieEnabled which reveals the kind of storage access I think you're alluding to here, so the rest of your point is still valid. :-) > So this is really about the dynamism aspects of this. Clearly, building a > system where you can switch out the fake storage with the real one > dynamically is hard. The surface area is surprisingly big and the changes > are pervasive. That's infeasible. But I think that rather than saying > that permissions are a poor fit, I think that it would pay to think more > about how maybe we might fix this in permissions. Because I think that > this is something that works with permissions in many other respects - it's > something that we might want to bake into feature policy for instance. > > When we talked about permissions recently, we concluded that there were > some aspects of the .query() API that didn't properly reflect the range of > policies that might apply. For instance, permission for some actions is > conditional on an engagement gesture (a click or key press). Here I think > that we might have a new condition: the permission is conditional on the > page being refreshed. Now, I concede that perhaps this is too ambitious > and in the absence of other cases that share this constraint this might be > overgeneralizing, but I think that this fits reasonably well. > I think the reason why Andrea said permissions are a poor fit here is the dynamism aspect. For example, web pages aren't typically written with the expectation that localStorage/indexedDB methods will throw until a permission is granted out of band, or they start throwing when a permission is revoked. Our current behaviour which is exactly that will cause pages to break when the user does something to change permissions while there are live documents around. I don't think the problem is really about whether Permissions.query() is a good fit to query this type of permission. -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookie policy/permission in live documents - proposal
On Fri, Jan 25, 2019 at 2:51 PM Daniel Veditz 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. -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookie policy/permission in live documents - proposal
On Fri, Jan 25, 2019 at 8:50 PM Daniel Veditz 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
Re: Cookie policy/permission in live documents - proposal
On Fri, Jan 25, 2019 at 11:55 PM Ehsan Akhgari wrote: > On Fri, Jan 25, 2019 at 2:51 PM Daniel Veditz 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 dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookie policy/permission in live documents - proposal
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 wrote: > > > On Fri, Jan 25, 2019 at 11:55 PM Ehsan Akhgari > wrote: > >> On Fri, Jan 25, 2019 at 2:51 PM Daniel Veditz >> 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 dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookie policy/permission in live documents - proposal
On Mon, Jan 28, 2019 at 12:57 AM Andrea Marchesini wrote: > 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. > That's a great point in favor of your proposal. I'm still concerned about "infinite-page" sites (facebook/twitter/etc) where a user typically rarely reloads. Would it be too ugly to apply an infobar to each active tab that says "The cookie policy has changed. Reload to apply the new policy [Reload]"? Or maybe has a [Reload this tab][Reload All] set of buttons. I have serious misgivings about my UX suggestion here, but maybe it will spark better ideas on how to communicate to users. An alert/doorhanger in the pref page where the setting is changed that warns the user it only applies to new pages and offers to reload all active tabs? -Dan Veditz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookie policy/permission in live documents - proposal
On Mon, Jan 28, 2019 at 10:51 AM Daniel Veditz wrote: > On Mon, Jan 28, 2019 at 12:57 AM Andrea Marchesini < > amarches...@mozilla.com> wrote: > >> 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. >> > > That's a great point in favor of your proposal. I'm still concerned about > "infinite-page" sites (facebook/twitter/etc) where a user typically rarely > reloads. Would it be too ugly to apply an infobar to each active tab that > says "The cookie policy has changed. Reload to apply the new policy > [Reload]"? Or maybe has a [Reload this tab][Reload All] set of buttons. I > have serious misgivings about my UX suggestion here, but maybe it will > spark better ideas on how to communicate to users. An alert/doorhanger in > the pref page where the setting is changed that warns the user it only > applies to new pages and offers to reload all active tabs? > One option that we have for handling this change is to modify the way we apply the change in the Preferences UI instead of asking people to reload their pages. For example, we can ask the user to restart their browser when they make changes to the cookie policy/permissions (similar to how turning permanent private browsing on/off works), or add a notice in the Preferences saying that the changes made will only affect pages loaded from now on, etc. I don't think showing a message on every open tab to ask the user to reload it is the only UX that is possible for solving this problem, it's only one rough idea (AFAIK nobody has talked to the UX team about it yet!)... Cheers, -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookie policy/permission in live documents - proposal
On Monday, January 28, 2019 at 11:08:32 AM UTC-5, Ehsan Akhgari wrote: > On Mon, Jan 28, 2019 at 10:51 AM Daniel Veditz wrote: > > > On Mon, Jan 28, 2019 at 12:57 AM Andrea Marchesini < > > amarches...@mozilla.com> wrote: > > > >> 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. > >> > > > > That's a great point in favor of your proposal. I'm still concerned about > > "infinite-page" sites (facebook/twitter/etc) where a user typically rarely > > reloads. Would it be too ugly to apply an infobar to each active tab that > > says "The cookie policy has changed. Reload to apply the new policy > > [Reload]"? Or maybe has a [Reload this tab][Reload All] set of buttons. I > > have serious misgivings about my UX suggestion here, but maybe it will > > spark better ideas on how to communicate to users. An alert/doorhanger in > > the pref page where the setting is changed that warns the user it only > > applies to new pages and offers to reload all active tabs? > > > > One option that we have for handling this change is to modify the way we > apply the change in the Preferences UI instead of asking people to reload > their pages. For example, we can ask the user to restart their browser > when they make changes to the cookie policy/permissions (similar to how > turning permanent private browsing on/off works), or add a notice in the > Preferences saying that the changes made will only affect pages loaded from > now on, etc. > > I don't think showing a message on every open tab to ask the user to reload > it is the only UX that is possible for solving this problem, it's only one > rough idea (AFAIK nobody has talked to the UX team about it yet!)... > > Cheers, > -- > Ehsan >From a UX perspective I think your proposal makes sense, Baku. I feel that having a user manually reload each individual tab they have open is too much to ask. I spoke with Bryan Bell and we share Ehsan thinking. If a user changes preferences that affect the cookie policy they get an extra box that appears and explains they need to reload tabs in order for the new policy to apply. Did a quick mock up to show what this might look like (note the mock isn't final and the copy hasn't been reviewed) Mock can be found here: https://cl.ly/7b6cc1e85e36 Also, instead of reloading the tabs we can restart their browser as Ehsan mentioned. We'll just have to be careful and explain that all their tabs will be reopened. Is one way more performant than the other? Regards, Eric ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookie policy/permission in live documents - proposal
In my experience having to restart applications to make settings apply is the worst thing ever, hence I really like your mock. We should make sure to include it in the bug (or a follow-up) for this proposed change. On Thu, Jan 31, 2019 at 8:13 PM wrote: > On Monday, January 28, 2019 at 11:08:32 AM UTC-5, Ehsan Akhgari wrote: > > On Mon, Jan 28, 2019 at 10:51 AM Daniel Veditz > wrote: > > > > > On Mon, Jan 28, 2019 at 12:57 AM Andrea Marchesini < > > > amarches...@mozilla.com> wrote: > > > > > >> 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. > > >> > > > > > > That's a great point in favor of your proposal. I'm still concerned > about > > > "infinite-page" sites (facebook/twitter/etc) where a user typically > rarely > > > reloads. Would it be too ugly to apply an infobar to each active tab > that > > > says "The cookie policy has changed. Reload to apply the new policy > > > [Reload]"? Or maybe has a [Reload this tab][Reload All] set of > buttons. I > > > have serious misgivings about my UX suggestion here, but maybe it will > > > spark better ideas on how to communicate to users. An alert/doorhanger > in > > > the pref page where the setting is changed that warns the user it only > > > applies to new pages and offers to reload all active tabs? > > > > > > > One option that we have for handling this change is to modify the way we > > apply the change in the Preferences UI instead of asking people to reload > > their pages. For example, we can ask the user to restart their browser > > when they make changes to the cookie policy/permissions (similar to how > > turning permanent private browsing on/off works), or add a notice in the > > Preferences saying that the changes made will only affect pages loaded > from > > now on, etc. > > > > I don't think showing a message on every open tab to ask the user to > reload > > it is the only UX that is possible for solving this problem, it's only > one > > rough idea (AFAIK nobody has talked to the UX team about it yet!)... > > > > Cheers, > > -- > > Ehsan > > > From a UX perspective I think your proposal makes sense, Baku. > > I feel that having a user manually reload each individual tab they have > open is too much to ask. > > I spoke with Bryan Bell and we share Ehsan thinking. > If a user changes preferences that affect the cookie policy they get an > extra box that appears and explains they need to reload tabs in order for > the new policy to apply. > > Did a quick mock up to show what this might look like (note the mock isn't > final and the copy hasn't been reviewed) > > Mock can be found here: https://cl.ly/7b6cc1e85e36 > > Also, instead of reloading the tabs we can restart their browser as Ehsan > mentioned. We'll just have to be careful and explain that all their tabs > will be reopened. Is one way more performant than the other? > > Regards, > Eric > ___ > 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
Re: Cookie policy/permission in live documents - proposal
I think Johann is right. Thanks for the design, Eric, this looks great to me. I think reloading all tabs is a much better idea than restarting the browser. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1526075 for this. On Mon, Feb 4, 2019 at 8:16 AM Johann Hofmann wrote: > In my experience having to restart applications to make settings apply is > the worst thing ever, hence I really like your mock. We should make sure to > include it in the bug (or a follow-up) for this proposed change. > > On Thu, Jan 31, 2019 at 8:13 PM wrote: > > > On Monday, January 28, 2019 at 11:08:32 AM UTC-5, Ehsan Akhgari wrote: > > > On Mon, Jan 28, 2019 at 10:51 AM Daniel Veditz > > wrote: > > > > > > > On Mon, Jan 28, 2019 at 12:57 AM Andrea Marchesini < > > > > amarches...@mozilla.com> wrote: > > > > > > > >> 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. > > > >> > > > > > > > > That's a great point in favor of your proposal. I'm still concerned > > about > > > > "infinite-page" sites (facebook/twitter/etc) where a user typically > > rarely > > > > reloads. Would it be too ugly to apply an infobar to each active tab > > that > > > > says "The cookie policy has changed. Reload to apply the new policy > > > > [Reload]"? Or maybe has a [Reload this tab][Reload All] set of > > buttons. I > > > > have serious misgivings about my UX suggestion here, but maybe it > will > > > > spark better ideas on how to communicate to users. An > alert/doorhanger > > in > > > > the pref page where the setting is changed that warns the user it > only > > > > applies to new pages and offers to reload all active tabs? > > > > > > > > > > One option that we have for handling this change is to modify the way > we > > > apply the change in the Preferences UI instead of asking people to > reload > > > their pages. For example, we can ask the user to restart their browser > > > when they make changes to the cookie policy/permissions (similar to how > > > turning permanent private browsing on/off works), or add a notice in > the > > > Preferences saying that the changes made will only affect pages loaded > > from > > > now on, etc. > > > > > > I don't think showing a message on every open tab to ask the user to > > reload > > > it is the only UX that is possible for solving this problem, it's only > > one > > > rough idea (AFAIK nobody has talked to the UX team about it yet!)... > > > > > > Cheers, > > > -- > > > Ehsan > > > > > > From a UX perspective I think your proposal makes sense, Baku. > > > > I feel that having a user manually reload each individual tab they have > > open is too much to ask. > > > > I spoke with Bryan Bell and we share Ehsan thinking. > > If a user changes preferences that affect the cookie policy they get an > > extra box that appears and explains they need to reload tabs in order for > > the new policy to apply. > > > > Did a quick mock up to show what this might look like (note the mock > isn't > > final and the copy hasn't been reviewed) > > > > Mock can be found here: https://cl.ly/7b6cc1e85e36 > > > > Also, instead of reloading the tabs we can restart their browser as Ehsan > > mentioned. We'll just have to be careful and explain that all their tabs > > will be reopened. Is one way more performant than the other? > > > > Regards, > > Eric > > ___ > > 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 > -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform