Cookie policy/permission in live documents - proposal

[Andrea Marchesini]

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.

Let's start with an introduction. When I say cookies, I mean cookies,
localStorage, sessionStorage, indexedDB and so on: anything that composes
the cookie jar of a website (origin).

The user, in firefox, can choose between several cookie policies: They are:
- nsICookieService::BEHAVIOR_ACCEPT - the default one in release. Any
cookie is accept.
- nsICookieService::BEHAVIOR_REJECT - all rejected.
- nsICookieService::BEHAVIOR_REJECT_FOREIGN - 3rd party context's cookies
rejected.
- nsICookieService::BEHAVIOR_LIMIT_FOREIGN - 3rd part context's cookies
rejected if that origin has not been visited previously.
- nsICookieService::BEHAVIOR_REJECT_TRACKER - by default in nightly.
Cookies from trackers are rejected (it's a bit more complex than this, but
I need to simplify).

On top of this we have cookie permissions. They allow the user to set
custom cookie policies per origin. They are many, but, exposed to
UI/webextensions, they are only these:
- nsICookiePermission::ACCEPT_DEFAULT - follow the current cookie policy.
- nsICookiePermission::ACCEPT_ALLOW - accept all for this origin.
- nsICookiePermission::ACCEPT_DENY - reject any cookie for this origin.
- nsICookiePermission::ACCEPT_SESSION - accept cookies but make them
session 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.

*complexity in our code base*
Some of our storage APIs have heavy code to switch between one cookie
behavior to another. For instance, sessionStorage and localStorage need to
choose the correct internal dataset at each getter/setter call, based on
the current cookie policy. They also need, in same cases, to move data from
1 dataset to another: for instance if we go from ACCEPT_DEFAULT to
ACCEPT_SESSION:
https://searchfox.org/mozilla-central/rev/6c784c93cfbd5119ed07773a170b59fbce1377ea/dom/storage/LocalStorageCache.cpp#184-209
https://searchfox.org/mozilla-central/rev/6c784c93cfbd5119ed07773a170b59fbce1377ea/dom/storage/SessionStorageCache.cpp#12-33

*performance*
This is not just a extra complexity, but it's also a performance issue:
checking the current cookie policy requires several steps: is the origin in
the content-blocking allow list? is the current window a 3rd party? is the
channel marked as a tracker? has this window being visited in the past? etc.
https://searchfox.org/mozilla-central/rev/6c784c93cfbd5119ed07773a170b59fbce1377ea/dom/base/nsContentUtils.cpp#8085-8451
https://searchfox.org/mozilla-central/rev/6c784c93cfbd5119ed07773a170b59fbce1377ea/toolkit/components/antitracking/AntiTrackingCommon.cpp#785-1429

What I would like to do is this: each nsIChannel loading a document or a
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.

Of course, I don't want to apply the same logic to other permissions, such
as 'geo', 'fullscreen' and so on, because them are strongly connected with
APIs, user-interaction and permission prompting.

I want to conclude describing what other browsers do:
- Safari does something similar to what firefox is currently doing: cookie
policy is immediately applied.
- Chrome does something similar to what I propose: cookie policy is applied
to new documents only.

b

[Nicholas Alexander]

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 <amarc...@mozilla.com>
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.
>

<snip introduction>

> 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.
>

<snip complexity and performance>

> 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

[Andrea Marchesini]

> 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

[Martin Thomson]

On Thu, Jan 24, 2019 at 8:33 AM Andrea Marchesini <amarc...@mozilla.com>
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.)

[Nicholas Alexander]

On Wed, Jan 23, 2019 at 11:33 AM Andrea Marchesini <amarc...@mozilla.com>
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

[Andrea Marchesini]

>
> 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.

[Martin Thomson]

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 <amarc...@mozilla.com>
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.

[Daniel Veditz]

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

[Ehsan Akhgari]

On Thu, Jan 24, 2019 at 5:34 PM Martin Thomson <m...@mozilla.com> 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

[Ehsan Akhgari]

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

[Andrea Marchesini]

On Fri, Jan 25, 2019 at 8:50 PM Daniel Veditz <dve...@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.

[Andrea Marchesini]

On Fri, Jan 25, 2019 at 11:55 PM Ehsan Akhgari <ehsan....@gmail.com>
wrote:

> On Fri, Jan 25, 2019 at 2:51 PM Daniel Veditz <dve...@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.
>>
>

> 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.

[Johann Hofmann]

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 <amarc...@mozilla.com>

[Daniel Veditz]

On Mon, Jan 28, 2019 at 12:57 AM Andrea Marchesini <amarc...@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?

-Dan Veditz

[Ehsan Akhgari]

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

[ep...@mozilla.com]

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

[Johann Hofmann]

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.

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Ehsan Akhgari]

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 <jhof...@mozilla.com> 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 <ep...@mozilla.com> wrote:
>

> > _______________________________________________
> > dev-platform mailing list
> > dev-pl...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

--
Ehsan