1245595 - Determine desired interaction between sessionStorage and cookie permissions/preferences

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, task, P2)

Description

[Nika Layzell [:nika] (ni? for response)]

Before bug 1184973, the behavior for sessionStorage/localStorage is as follows (AFAIR):

sessionStorage:
disallowed if pref or permission set to deny. Third-party windows are not treated differently.
Accesses with a subject principal which is the system principal are unconditionally allowed.
access to window.sessionStorage is allowed when sessionStorage is denied, but attempt to use any methods fails.

localStorage:
disallowed if pref or permission set to deny. Third-party windows are not treated differently.
Accesses with a subject principal which is the system principal are unconditionally allowed.
access to window.localStorage fails when localStorage is denied.

After bug 1184973 and bug 1201747, the following behavior occurs:

sessionStorage:
disallowed if pref or permission set to deny. Third-party windows are not treated differently.
Accesses with the system principal are not special.
access to window.sessionStorage is allowed when sessionStorage is denied, but attempt to use any methods fails.

localStorage:
disallowed if pref or permission set to deny. Third-party windows with disallow-third-party cookies enabled are denied.
Accesses with the system principal are not special.
access to window.localStorage fails when localStorage is denied.

SessionStorage.jsm has the following logic:
    try {
      let storageManager = aDocShell.QueryInterface(Ci.nsIDOMStorageManager);
      storage = storageManager.getStorage(window, aPrincipal);
    } catch (e) {
      // sessionStorage might throw if it's turned off, see bug 458954
    }

    if (storage && storage.length) { // <-- Raises a SecurityException
       for (let i = 0; i < storage.length; i++) {
        try {
          let key = storage.key(i);
          hostData[key] = storage.getItem(key);
        } catch (e) {
          // This currently throws for secured items (cf. bug 442048).
        }
      }
    }
which guards against most accesses to sessionStorage, but the access to storage.length isn't guarded against, which means that with the new logic, an exception is raised here when the pref is set to deny (I believe it will also occur if the permission is set to deny). (See bug 1234021 for the effects)

The reason why third-party windows are not treated differently for sessionStorage was because of the logic which lead to WONTFIXing bug 1183968. 

sessionStorage's behavior feels very odd to me. It feels like it should either act the same as localStorage, or be unaffected by the permissions/preferences. In either case, the SessionStorage.jsm code would be fixed because either the code would not throw anymore, or it would throw in a guarded area. The other option would be to catch the exception raised by storage.length, which would fix bug 1234021 I believe (not restoring sessionStorage's values when attempts to access it would be denied seems fine to me).

Comment 1

[Nika Layzell [:nika] (ni? for response)]

ni?-ing ehsan and bholley for opinions :)

Comment 2

[Loic]

I added bug 1238178 because some users reported blank tabs when restoring session with add-ons like Session Manager/Tab Mix Plus or when managing cookies with Cookie Controller. So I guess the decision should be made according to the use of popular add-ons about session/cookie management too.

Comment 3

[Bobby Holley (:bholley)]

Does the spec say what the behavior of sessionStorage and localStorage should be when the user has denied the permission?

Comment 4

[Bobby Holley (:bholley)]

Or does the spec not have a concept of permissions for storage?


(In reply to Michael Layzell [:mystor] from comment #0)
> Before bug 1184973, the behavior for sessionStorage/localStorage is as
> follows (AFAIR):
> 
> sessionStorage:
> ...
> access to window.sessionStorage is allowed when sessionStorage is denied,
> but attempt to use any methods fails.
> ...
> After bug 1184973 and bug 1201747, the following behavior occurs:
> 
> sessionStorage:
> ...
> access to window.sessionStorage is allowed when sessionStorage is denied,
> but attempt to use any methods fails.

I'm confused here. This seems to imply that the relevant behavior has not changed for sessionStorage. So why did SessionStorage.jsm break?

Comment 5

[Nika Layzell [:nika] (ni? for response)]

(In reply to Bobby Holley (busy) from comment #3)
> Does the spec say what the behavior of sessionStorage and localStorage
> should be when the user has denied the permission?

When localStorage is accessed, it allows for a SecurityException to be thrown:

"The user agent may throw a SecurityError exception and abort these steps instead of returning a Storage object if the request violates a policy decision (e.g. if the user agent is configured to not allow the page to persist data)."

However, there isn't such a statement on the sessionStorage attribute, instead it just says:

"The sessionStorage attribute must return a Storage object associated with the Document's assigned session storage area, if any, or null if there isn't one. Each Document object must have a separate object for its Window's sessionStorage attribute."

It also states on setItem (but not other methods like length, which also throw right now):

"If it couldn't set the new value, the method must throw a QuotaExceededError exception. (Setting could fail if, e.g., the user has disabled storage for the site, or if the quota has been exceeded.)" - https://html.spec.whatwg.org/multipage/webstorage.html#dom-storage-setitem

(Sorry for not including this earlier - I'm still new to this and forgot to check the spec first, I'm learning though :P)

Right now our behavior around sessionStorage doesn't seem to mesh with the spec super well, but changing it to be identical to localStorage might be wrong.

(In reply to Bobby Holley (busy) from comment #4)
> I'm confused here. This seems to imply that the relevant behavior has not
> changed for sessionStorage. So why did SessionStorage.jsm break?(In reply to Bobby Holley (busy) from comment #3)
> Does the spec say what the behavior of sessionStorage and localStorage
> should be when the user has denied the permission?

The thing which changed was the lines 
> Accesses with a subject principal which is the system principal are unconditionally allowed.
vs
> Accesses with the system principal are not special.

Basically SessionStorage accesses the .length property of sessionStorage outside of a try-catch block, and .length raises an exception. It didn't use to raise an exception, because the system principal subject principal used to be given special privileges to access SessionStorage.

The only thing broken right now is SessionStorage.jsm with the pref set, and potentially addons which try to access random websites' sessionStorage.

Comment 6

[Bobby Holley (:bholley)]

So. If the only behavioral change was related to the behavior when accessing page sessionStorage from System Principaled code, then this doesn't affect the web, except indirectly via the SessionStorage bustage above.

So the first priority (by far) is to put together a low-risk patch (with tests) that fixes the SessionStorage bustage. The easiest hack, I think, would be to access storage.length at the bottom of the try block and null out |storage| in the catch. This shouldn't result in any lost data, because the page shouldn't have been allowed to put anything in there anyway.

Again, this is urgent, because we need to get this on beta, and we're already mid-cycle here.

Once that's done, we should also sort out the mismatch between our web-visible sessionStorage behavior and the spec's. Specifically IIUC, our implementation restricts access to sessionStorage in some situations, whereas the spec doesn't. So please file a followup bug about this and loop in janv and annevk to start getting to the bottom of this.

Thanks for taking care of this!

Comment 7

[TGOS]

I still think it's highly confusing for the huge majority of users that something like a "cookie storage policy" or "cookie permission policy" applies to anything else but cookies. I still say "storage is storage". Whether a website uses cookies, DOM storage, IndexDB or any other standard or non-standard storage API, for the user there's only one question: Do I allow this website store data on my computer? If I don't, certain functions may not work. And if I do, do I want this data to survive sessions, as this puts my privacy at risk because it makes me identifiable (every data storage can be used to store tracking data - whatever is stored in a cookie can also be stored and read back with any other API).

So I still say: Make one setting for ALL storage (bug 1166710) and then make all storage behave identical. Either a site may not store data (all storage calls fail; period!), store data for the session (browser closes, data gone; period!) or store data forever (or unless manually deleted by the user). Everything else is something most users will never understand, never use correctly and only makes things complicated for absolutely no benefit. Just my 2 cent.

Comment 8

[(no longer active)]

Can we go back to making it possible for the system principal to do anything to a sessionstorage, for example by checking that before calling StorageAllowdFor?

Comment 9

[Bobby Holley (:bholley)]

(In reply to :Ehsan Akhgari (Away 2/10-2/19) from comment #8)
> Can we go back to making it possible for the system principal to do anything
> to a sessionstorage, for example by checking that before calling
> StorageAllowdFor?

What is the use-case for that, exactly?

Comment 10

[(no longer active)]

(In reply to Bobby Holley (busy) from comment #9)
> (In reply to :Ehsan Akhgari (Away 2/10-2/19) from comment #8)
> > Can we go back to making it possible for the system principal to do anything
> > to a sessionstorage, for example by checking that before calling
> > StorageAllowdFor?
> 
> What is the use-case for that, exactly?

Keeping the previous behavior and not breaking add-ons.

Comment 11

[Bobby Holley (:bholley)]

(In reply to :Ehsan Akhgari (Away 2/10-2/19) from comment #10)
> (In reply to Bobby Holley (busy) from comment #9)
> > (In reply to :Ehsan Akhgari (Away 2/10-2/19) from comment #8)
> > > Can we go back to making it possible for the system principal to do anything
> > > to a sessionstorage, for example by checking that before calling
> > > StorageAllowdFor?
> > 
> > What is the use-case for that, exactly?
> 
> Keeping the previous behavior and not breaking add-ons.

Do we have any reason to believe that there is addon bustage? Given that we shipped this, it seems like the ship has already mostly sailed there.

I don't feel super-strongly, but I think the new behavior is less confusing, and would rather not backport C++ security check changes to beta if we can avoid it.

Comment 12

[(no longer active)]

I don't feel strongly either.  Fixing SessionStorage.jsm to work around this sounds good to me too.

Comment 13

[Tanvi Vyas[:tanvi]]

(In reply to Michael Layzell [:mystor] from comment #0)
> After bug 1184973 and bug 1201747, the following behavior occurs:
> 
> sessionStorage:
> disallowed if pref or permission set to deny. Third-party windows are not
> treated differently.
> Accesses with the system principal are not special.
> access to window.sessionStorage is allowed when sessionStorage is denied,
> but attempt to use any methods fails.
> 
> localStorage:
> disallowed if pref or permission set to deny. Third-party windows with
> disallow-third-party cookies enabled are denied.
> Accesses with the system principal are not special.
> access to window.localStorage fails when localStorage is denied.
> 

Both localStorage and sessionStorage should obey the third party cookie preferences.  If the user selects to never allow third party cookies or only allow third party cookies from visited, session/localstorage should obey that preference the same way cookies do.

Comment 14

[Nika Layzell [:nika] (ni? for response)]

(In reply to (Away 2/10-2/19) from comment #12)
> I don't feel strongly either.  Fixing SessionStorage.jsm to work around this
> sounds good to me too.

That's the current plan - I am having trouble testing that the fixed behavior is correct programmatically unfortunately :(.

(In reply to Tanvi Vyas [:tanvi] from comment #13)
> Both localStorage and sessionStorage should obey the third party cookie
> preferences.  If the user selects to never allow third party cookies or only
> allow third party cookies from visited, session/localstorage should obey
> that preference the same way cookies do.

The difference between session and localstorage is that sessionstorage doesn't actually store anything on your computer. That's why it may not be necessary to block the same way, however I see the reason to make it act the same. 

If we decide to treat sessionstorage the same way as localstorage, we should get the spec changed such that it states that it may throw upon accessing. Right now the behavior is confusing in that localstorage throws on the getter, and sessionstorage throws when it is attempted to be used.

Comment 15

[Nika Layzell [:nika] (ni? for response)]

(In reply to (Away 2/10-2/19) from comment #8)
> Can we go back to making it possible for the system principal to do anything
> to a sessionstorage, for example by checking that before calling
> StorageAllowdFor?

It would definitely work and not be too difficult to do, but seems unnecessary. As bholley said though, I don't think it's a good idea to uplift this kind of permission check change unless we have to, and we can probably fix it with a simpler change like just catching an exception raised by the .length accessor for uplifting.

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

This isn't assigned to anyone -- who wants to take it on? Does it need more discussion?  I'm showing up here because we're tracking the related regression in bug 1232955. 
Andrew maybe you could help find it an owner?

Comment 17

[(no longer active)]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #16)
> This isn't assigned to anyone -- who wants to take it on? Does it need more
> discussion?  I'm showing up here because we're tracking the related
> regression in bug 1232955. 
> Andrew maybe you could help find it an owner?

The patch in bug 1234021 should be enough to fix this on Beta.

Comment 18

[Liz Henry (:lizzard) (relman/hg->git project)]

OK, thanks, fabulous. It is a bit late to make it into beta, but we can aim for 46.

Comment 19

[Elhem Enohpi]

Thanks for the patch for SessionStorage.jsm! As a cookie-denier, I've been stuck on FF 42 until now…

(In reply to Michael Layzell [:mystor] from comment #0)
> sessionStorage's behavior feels very odd to me. It feels like it should
> either act the same as localStorage, or be unaffected by the
> permissions/preferences.

I'd like to make a case for the latter. I want to block all cookies by default, but I don't want to block session storage, ever. It doesn't make sense to have them both tied to the same preference. I don't agree with the "storage is storage" in comment 7, it depends how the storage works. People may block cookies but still expect that a page can use the cache. The "accept cookies from sites" preference is in the Privacy tab, because the issue isn't about storage, but privacy. The preference didn't exist until sites started to abuse cookies to track people in ways that were never envisioned. It seems to me that session storage is closer to cache than to cookies.

The main reason a user unchecks "accept cookies from sites" is due to privacy concerns which are simply not an issue with session storage. Session cookies persist even after the window is closed, and can be read from other windows, leading to tracking via things like Facebook and Twitter buttons. Not so with session storage, which can't be read by other windows, and disappears when the tab is closed.

The availability of temporary storage is hugely useful for all kinds of client-side scripts, and sites may fail without it. Access to it shouldn't be broken just because the user is trying to avoid an unrelated security problem with cookies. Bug 1183968 decided that it was safe to allow third-party session storage even when third-party cookies are denied. I'd like to see that logic extended to first-party cookies as well.

Comment 20

[TGOS]

(In reply to Elhem Enohpi from comment #19)
> I want to block all cookies by default, but I don't want to block
> session storage, ever. It doesn't make sense to have them both tied
> to the same preference. I don't agree with the "storage is storage"
> in comment 7, it depends how the storage works.

Why are you blocking cookies? For what purpose? Privacy? To avoid being tracked? What stops server operators from storing the cookie data in DOM storage or IndexDB? No matter what a server operator uses cookies for, he can use any other storage for exactly the same purpose! So whatever you are trying to achieve by blocking cookies, you simply won't achieve it as long as you offer a replacement storage. That's what I meant by storage is storage. It doesn't matter which storage is used to track you or to invade your privacy, does it?

That's why you can currently choose for cookies if you want to allow servers to store them at all, to store them only for the session or to store them forever (or as long as the server wishes to). You can decide what you want in general and override that per site. And these rules must, of course, apply to all storages. Why would you block cookies and allow data stored with other APIs to be stored for the session? Why would you not also allow cookies for the session then? Because they will be used for tracking? Again, any storage can be used for tracking. That's no argument.

I didn't say that there is anything wrong with temporary storage for servers but why shouldn't the user be allowed to control if he wants temporary storage? Apparently you do, but then you can by simply allowing session cookies for the site which is also just another temporary storage. If I have 20 different storages that follow different rules and have different settings, how shall I be able to manage that complexity or every have an overview which server is now allow to store what and for how long?

Comment 21

[Elhem Enohpi]

(In reply to TGOS from comment #20)
> What stops server operators from storing the cookie data in DOM
> storage or IndexDB? No matter what a server operator uses cookies for, he
> can use any other storage for exactly the same purpose!

Indexed database and local storage can indeed be used for tracking in the same way cookies can. It seems reasonable to control access to them based on the cookie preference. Session storage, not so much. Cookie data could be stored, but it can't be retrieved outside of that one tab. Session storage works very differently from session cookies. It's not possible to use it for exactly the same purpose.

There may be privacy issues with session storage, but they're different enough to at least consider treating it separately from the cookie policy. Cache storage can also be used for tracking, but it's not controlled by the cookie preference.

Comment 22

[(no longer active)]

(In reply to Tanvi Vyas out til 3/14 [:tanvi] from comment #13)
> (In reply to Michael Layzell [:mystor] from comment #0)
> > After bug 1184973 and bug 1201747, the following behavior occurs:
> > 
> > sessionStorage:
> > disallowed if pref or permission set to deny. Third-party windows are not
> > treated differently.
> > Accesses with the system principal are not special.
> > access to window.sessionStorage is allowed when sessionStorage is denied,
> > but attempt to use any methods fails.
> > 
> > localStorage:
> > disallowed if pref or permission set to deny. Third-party windows with
> > disallow-third-party cookies enabled are denied.
> > Accesses with the system principal are not special.
> > access to window.localStorage fails when localStorage is denied.
> > 
> 
> Both localStorage and sessionStorage should obey the third party cookie
> preferences.  If the user selects to never allow third party cookies or only
> allow third party cookies from visited, session/localstorage should obey
> that preference the same way cookies do.

The thing that makes sessionStorage special is that it is double keyed based on the first and the third party, and also it doesn't actually store data.  Based on that, I don't think that the same reasoning with cookies applies here.  What do you think, Tanvi?

Comment 23

[TGOS]

(In reply to Elhem Enohpi from comment #21)
> Cookie data could be stored, but it can't be retrieved outside of that one tab. 

While that is technically correct, note that a value stored in sessionStorage is allowed to survive browser restarts and that would make it even more persistent than a session cookies. To quote from the spec:

>> The lifetime of a browsing context can be unrelated to the lifetime of
>> the actual user agent process itself, as the user agent may support
>> resuming sessions after a restart.

I don't know if that is currently possible in Fx at all but if all the other vendors will support that in their browsers on day and plenty of popular web pages will rely on that behavior to function properly, I highly doubt that Fx will be the only browser staying with a different behavior as that would look to the user as if all other browsers work correctly but Fx is broken.

> Cache storage can also be used for tracking, but it's not controlled by the
> cookie preference.

I don't know if "We already have done worse mistakes in the past, so let's not worry about tiny mistakes in the future" really qualifies as a valid argument. But I'm certainly willing to sign the first part of that sentence.

When I look at the current Cookie handling, I wonder why for example this here hasn't been core functionality for Fx since day one:

https://addons.mozilla.org/en-US/firefox/addon/self-destructing-cookies

It makes cookies behave a little more like sessionStorage: You close the tab and all the cookies are gone. It basically adds a fourth option for cookies. Right now you have "not all", "forever", and "for the browser session"; what this plug-in adds is "for the tab session". And that works lovely and flawlessly with all pages I've been visiting since I installed that plug-in a long time ago.

Maybe that's the actual problem here: There isn't a cookie policy right now that would match the standard behavior of ssessionStorage, as both talk about "sessions" but they mean different kind of sessions. If I allow a site to store cookies for the session, so that I can use sessionStorage properly (maybe required to make the site work), I'd also enable cookies to store data for the session, yet they are not limited to the tab and they mean the browser session and not the tab session. I acknowledge that this would be awkward as you may want to allow sessionStorage without allowing cookies for the whole browser session. Though personally I'd then rather prefer to have an option to limit cookies to a tab session, in which case I'd just choose that as default for all sites, making cookies a lot less tracking and ensuring properly working sessionStorage everywhere as well.

Comment 24

[Tanvi Vyas[:tanvi]]

(In reply to :Ehsan Akhgari from comment #22)
> The thing that makes sessionStorage special is that it is double keyed based
> on the first and the third party, and also it doesn't actually store data. 
> Based on that, I don't think that the same reasoning with cookies applies
> here.  What do you think, Tanvi?

Hi Ehsan,

I have a few questions about session storage:
Does session storage persist as long as the tab is open or as long as the browser is open?  Once the tab is closed, is the data gone?  If the tab remains open, but navigates to a different domain (a.com to b.com), will the session storage data of a.com be gone?  If the user then navigates that same tab from b.com to a.com, will a.com still have access to its previously stored data?

There are a few different types of cookie settings:
* Accept all
* Accept third party cookies only from sites that were once a first party
* Double key third party cookies (so facebook.com embedded on cnn.com doesn't get the same cookies as facebook.com on nytimes.com)
* Don't accept third party cookies
* Don't accept any cookies ever.

The middle option (Double key) doesn't exist in Firefox release now, be are doing some Platform work that may make it possible in the future, particularly for the Tor browser.  It sounds like session storage follows this Double Key setting.  For a user who has denied third party cookies, they won't expect the double keyed data to exist either.  

Most users haven't denied third party cookies.  Those that do, have made that privacy choice and know there is potential for some breakage.  What additional breakage would these users see if we made SessionStorage follows these rules?

I'd like to understand the lifetime of the data a little more and the potential breakage.

Thanks!

Comment 25

[Tanvi Vyas[:tanvi]]

Ehsan - can you take a look at my needinfo in comment 24?

Comment 26

[Ian Nartowicz]

Is this why Firefox throws an exception when accessing session storage when cookies are blocked but there is an "Allow first party only" exception for the site?

Comment 27

[Nika Layzell [:nika] (ni? for response)]

(In reply to Ian Nartowicz from comment #26)
> Is this why Firefox throws an exception when accessing session storage when
> cookies are blocked but there is an "Allow first party only" exception for
> the site?

Nope, but that does seem to be a bug. I've filed bug 1356277 to fix it :) Thanks!

Comment 28

[(no longer active)]

(In reply to Michael Layzell [:mystor] from comment #27)
> (In reply to Ian Nartowicz from comment #26)
> > Is this why Firefox throws an exception when accessing session storage when
> > cookies are blocked but there is an "Allow first party only" exception for
> > the site?
> 
> Nope, but that does seem to be a bug. I've filed bug 1356277 to fix it :)
> Thanks!

Really, thanks a lot for catching this bug.  Impressive detective work.  :-)

Comment 29

[Tanvi Vyas[:tanvi]]

Ehsan, is this bug still valid?  I would say that if third party cookies are disabled, sessionStorage for third parties should be disabled too.  Lets keep things consistent.  If you don't agree, then lets go back to my questions in comment 24 and discuss.

Comment 30

[(no longer active)]

Yeah, I still think this bug is valid, at least worth having more discussion on (and sorry that I somehow missed comment 24 for such a long time)...

(In reply to Tanvi Vyas[:tanvi] from comment #24)
> I have a few questions about session storage:
> Does session storage persist as long as the tab is open or as long as the
> browser is open?

The latter (see the docs in https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage).

> Once the tab is closed, is the data gone?

It will persist in memory.

> If the tab
> remains open, but navigates to a different domain (a.com to b.com), will the
> session storage data of a.com be gone?

No.

> If the user then navigates that same
> tab from b.com to a.com, will a.com still have access to its previously
> stored data?

Yep as long as the browser hasn't been closed (or the recent history hasn't been cleared.)

> There are a few different types of cookie settings:
> * Accept all
> * Accept third party cookies only from sites that were once a first party
> * Double key third party cookies (so facebook.com embedded on cnn.com
> doesn't get the same cookies as facebook.com on nytimes.com)
> * Don't accept third party cookies
> * Don't accept any cookies ever.
> 
> The middle option (Double key) doesn't exist in Firefox release now, be are
> doing some Platform work that may make it possible in the future,
> particularly for the Tor browser.  It sounds like session storage follows
> this Double Key setting.  For a user who has denied third party cookies,
> they won't expect the double keyed data to exist either.  
> 
> Most users haven't denied third party cookies.  Those that do, have made
> that privacy choice and know there is potential for some breakage.  What
> additional breakage would these users see if we made SessionStorage follows
> these rules?

As I said before, firstly session storage is different than cookies in that there is no persistence involved.  But more importantly, what does "third party" mean here?  A page loaded inside an <iframe> where the parent is a third-party origin?

Also, given the fact that we already double key sessionStorage (as in, a.com loaded inside b.com can't see the data stored by a.com loaded in the top-level browsing context's sessionStorage), is there a real use case to honoring the third party cookies pref?

> I'd like to understand the lifetime of the data a little more and the
> potential breakage.

About breakage, if we decide to make sessionStorage methods fail here, we need to decide what that failure should look like, and we need to spec it.  Right now only setItem() can throw a QuotaExceededError exception, so per spec the notion of the Storage object "failing" isn't even meaningful.

Comment 31

[Tanvi Vyas[:tanvi]]

We have been working on making the privacy and security settings around site storage match the user's expectations (first step is tracked in meta bug 1421690).  If a user says, clear site data, we should clear everything a website has access to.  If they say "clear recent site data", then we should clear all site data with a recent timestamp and also clear all storage types that don't have a timestamp associated with them.  If a user says to use First Party Isolation (a.k.a. double keying), we should double key all storage types.  And in this case, if a user says disable all third party site data, then third parties shouldn't be able to store any data on the user's browser.

So, despite the limited life time, if third party cookies are disabled, third party sessionStorage should be disabled instead of double keyed.  I understand that there is no prescribed way to fail.  Can a user turn off sessionStorage through an about:config pref?  What happens then?

Comment 32

[Johann Hofmann [:johannh]]

I think we should really block third-party SessionStorage when third-party cookies are disabled, simply for the sake of not compromising on the definition of "disallow third party cookies and site data".

> Also, given the fact that we already double key sessionStorage (as in, a.com
> loaded inside b.com can't see the data stored by a.com loaded in the
> top-level browsing context's sessionStorage), is there a real use case to
> honoring the third party cookies pref?

The third party frame could still track the user behavior on one specific parent origin through the entire session, even if the user switched IP addresses. It's not a gigantic threat but the guarantees provided by the disallow third party cookies setting are broken with this. Also, is there a real use case to _not_ honor the pref here?

> > I'd like to understand the lifetime of the data a little more and the
> > potential breakage.
> 
> About breakage, if we decide to make sessionStorage methods fail here, we
> need to decide what that failure should look like, and we need to spec it. 
> Right now only setItem() can throw a QuotaExceededError exception, so per
> spec the notion of the Storage object "failing" isn't even meaningful.

From a quick test it seems that we throw a SecurityError when the user has turned off cookies, why can't we just do that? :)

Comment 33

[Anne (:annevk)]

So your argument is basically that if you disable third-party cookies, you need to disable third-party storage. That seems reasonable, but what Safari has (double key most things) seems less likely to be incompatible with content on the web. Should we not also expose that somehow? (I agree that the current mix is a little weird.)

Comment 34

[Elhem Enohpi]

The issue of "Make sessionStorage obey the third-party cookies pref" was already resolved WONTFIX in bug 1183968, wasn't it? I think the logic of that is still valid. Maybe the setting could be described in some other way; with "storage" instead of "data", or "cross-site" instead of "third party", as disabling all third party data is likely not what most users actually want to accomplish.

The purpose of the third-party cookies privacy pref is to prevent a serious problem with cross-site tracking and profiling by ad networks. Of the large number of people who disable third party cookies, practically none are worried by other things like first-party session cookies or URL-based session IDs, which usually provide a helpful function. So I don't think it's true that users are actually demanding guarantees with this pref, that all third-party site data be blocked (in that case, you should also block HTTP cache). They just want to stop cross-site tracking. Other beneficial features that don't contribute to cross-site tracking shouldn't be turned off by the same switch.

The use case is that temporary session storage is a valuable browser feature that can be used by developers who offer legitimate third-party services or embedded web apps to other pages. For example, games running in an iframe, or an infinite number of other applications. There's no reason to deny access to this feature, based on essentially non-existent privacy concerns.

From the Privacy section of the spec, https://html.spec.whatwg.org/multipage/webstorage.html#user-tracking -
"User agents may allow sites to access session storage areas in an unrestricted manner, but require the user to authorize access to local storage areas."

This is also what Safari does; by default third-party cookies are blocked, but session storage isn't restricted.

Comment 35

[Johann Hofmann [:johannh]]

Generally I'd prefer to offer this relatively cheap guarantee and not guess about what the user wants or not, but if this is indeed widely used by websites for that specific use case, I don't think there's a strong case for breaking webcompat here. It would be good find out about the webcompat situation here. I can't really imagine it breaks a lot of sites, we're talking about a _quite_ specific use case.

Comment 36

[Tanvi Vyas[:tanvi]]

Note that blocked third party cookies is not the default behavior - it is an explicit choice users make.  And it does cause breakage, though minimal.

Comment 37

[Jan Varga [:janv]]

(In reply to Tanvi Vyas[:tanvi] from comment #13)
> Both localStorage and sessionStorage should obey the third party cookie
> preferences.  If the user selects to never allow third party cookies or only
> allow third party cookies from visited, session/localstorage should obey
> that preference the same way cookies do.

Right, let's simplify the current behavior/code. Both APIs should obey the third party cookie preferences.
I also agree with what was said in comment 14 that the spec should be updated too.
The primary reason is that having simplified (storage) preferences which are actually clear and usable by most of the users is more important than covering some special use cases.

Comment 38

[Chris Mills [:cmills]]

It might be worth writing up this behavior somewhere. Setting dev-doc-needed just in case.

Comment 39

[Marion Daly [:mdaly]]

:janv, let's tackle this after we do IDB PB

Comment 40

[u310142]

https://textslashplain.com/2018/10/03/cookie-controls-revisited/

"For example, in Firefox 62, when 3rd-party site data is blocked, sessionStorage is still permitted in a 3rd-party context. In Edge RS5 and Chrome, 3rd party sessionStorage is blocked if the user blocks 3rd-party cookies."

Comment 41

[Gian-Carlo Pascutto [:gcp]]

https://bugzilla.mozilla.org/show_bug.cgi?id=1183968#c8
https://bugzilla.mozilla.org/show_bug.cgi?id=1245595#c34

Note an expert at all, but the above eems to indicate this was a well-considered (incl. privacy aspects) design decision, and so we would disagree with the claim there that "this improves privacy". The "*improves* site compatibility" angle seems to be new, and somewhat contrary to remarks/assumptions in those bugs?

Comment 42

[Andrea Marchesini [:baku]]

Because of the anti-tracking project, we took decisions about when sessionStorage should be allowed and when it should not be.
The current settings are:

sessionStorage:

1. allowed if cookieBehavior is BEHAVIOR_ACCEPT (similarly for cookie permission set to ACCESS_ALLOW).
2. disallowed if cookieBehavior set to BEHAVIOR_REJECT. Same result with cookie permission set to ACCESS_DENY.
3. allowed If cookieBehavior is BEHAVIOR_REJECT_FOREIGN or BEHAVIOR_LIMIT_FOREIGN for both first and third parties.
4. disallowed if cookieBehavior is set to BEHAVIOR_REJECT_TRACKER and the window is a 3rd party tracking context.
5. always allowed for system principal contexts

localStorage:

1. allowed if cookieBehavior is BEHAVIOR_ACCEPT (similarly for cookie permission set to ACCESS_ALLOW).
2. disallowed if cookieBehavior set to BEHAVIOR_REJECT. Same result with cookie permission set to ACCESS_DENY.
3. disallowed If cookieBehavior is BEHAVIOR_REJECT_FOREIGN or BEHAVIOR_LIMIT_FOREIGN for third parties. Allowed for first parties.
4. disallowed if cookieBehavior is set to BEHAVIOR_REJECT_TRACKER and the window is a 3rd party tracking context.
5. always allowed for system principal contexts

When I say 'disallowed' I mean that window.sessionStorage and window.localStorage getters throw SecurityError exception.

So, the only difference is that, for cookieBehavior BEHAVIOR_REJECT_FOREIGN or BEHAVIOR_LIMIT_FOREIGN, sessionStorage is allowed for 3rd party contexts. When this happens, sessionStorage will be in 'session only' mode and it will not make 'persistent' by session restore.

maybe we can close this bug.

Comment 43

[Johann Hofmann [:johannh]]

3. allowed If cookieBehavior is BEHAVIOR_REJECT_FOREIGN or BEHAVIOR_LIMIT_FOREIGN for both first and third parties.
4. disallowed if cookieBehavior is set to BEHAVIOR_REJECT_TRACKER and the window is a 3rd party tracking context.

The former part still doesn't really make sense to me but I'm not willing to die on this hill anymore :)

Comment 44

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 45

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hello Tim !
baku's comment 42 wrote the decisions from our anti-tracking project and suggested we can close it. Can you please confirm if we're good to close this bug ? Thanks!

Comment 46

[Tim Huang[:timhuang]]

I think we can close the bug, and I want to add more context regarding BEHAVIOR_REJECT_TRACKER_AND_PARTITION_FOREIGN.

sessionStorage:
allowed in a first-party context and partitioned in a third-party context. And disallowed if the window is a 3rd party tracking context.

localStorage:
allowed in a first-party context and partitioned in a third-party context. And disallowed if the window is a 3rd party tracking context.