Intent to Ship: Updated third-party iframe storage behavior

[Michael Layzell]

Summary: Currently, there are inconsistent rules about the availability
of persistent storage in third-party iframes across different types of
storage (such as caches, IndexedDB, localstorage, sessionstorage, and
cookies). We are looking to unify these behaviors into a consistent set
of rules for when persistent storage should be available. We have
modeled this after our cookie rules, and now use the cookie behavior
preference to control third party access to these forms of persistent
storage. This means that IndexedDB (which was previously unconditionally
disabled in 3rd-party iframes) is now available in 3rd party iframes
when the accept third-party cookies preference is set to "Always". As
our current definition of accepting third-party cookies from "Only
Visited" makes no sense for non-cookie storage, we currently treat this
preference for these forms of storage as though the preference was "Never".

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1184973

Link to standard: N/A.

Platform coverage: All platforms.

Target release: Firefox 43.

Preference behind which this will be implemented: None, although the
preference
"network.cookie.cookieBehavior" will be used to guide the behavior of
storage in third-party iFrames.

DevTools bug: N/A.

Do other browser engines implement this: Based on my quick testing:
Chrome uses it's third party preference to control access to
localStorage and sessionStorage, but not IndexedDB or caches. Safari
appears to use it's preference to control IndexedDB, but not
sessionStorage or localStorage. IE appears to only use its 3rd party
preference for cookies. All other browsers allow IndexedDB in 3rd party
iframes with default settings.

Security & Privacy Concerns: This changes how websites can store data on
the user's machine.

Web designer / developer use-cases: Previously, we had made IndexedDB
unavailable in 3rd-party iframes. Web developers will now be able to use
IndexedDB in 3rd party iframes when the user has the accept cookies
preference set to always.

Michael

[David Illsley]

Is this pref something that's exposed to users, or is it only
about:config (I can't seem to find any UI for it)?

If so, this seems like a step away from being able to ever expose it as
more apps will be built assuming IndexedDB will be unconditionally
available in 3rd party iframes. This change would make the 'it breaks
the web argument' against exposing it stringer. From my perspective,
this would be undesirable.

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

[Ehsan Akhgari]

On 2015-08-18 2:24 PM, David Illsley wrote:
> Is this pref something that's exposed to users, or is it only
> about:config (I can't seem to find any UI for it)?

It is. Go to Privacy, select "Use custom settings for history", and
under "Accept third-party cookies:" select Never. (We should probably
rename that to "Accept third-part cookies and data:".)

> If so, this seems like a step away from being able to ever expose it as
> more apps will be built assuming IndexedDB will be unconditionally
> available in 3rd party iframes. This change would make the 'it breaks
> the web argument' against exposing it stringer. From my perspective,
> this would be undesirable.

Toggling that setting can already result in some websites not working.
And the problem that you are talking about exists today: currently
Firefox blocks IDB in third-party iframes by default and no other
browser does that, which will result in those apps to not work in
Firefox, and work in other browsers.

The correct ay to write such apps is to expect that storage may not be
available due to any number of reasons (for example, this setting being
turned on, or the page being loaded in private browsing mode, etc.) and
this is a step in trying to improve the current situation both for users
who have that setting turned on (we currently allow some forms of
storage in such iframes but not others) and those who have that setting
turned off (we currently disallow some forms of storage in such iframes
even if you don't have that setting turned on), and as such, it is an
improvement over the current situation.

[Tanvi Vyas]

It is nice to see that we are moving towards an "Accept third party
cookies and data" setting instead of just "Allow third party cookies".
Will localstorage and sessionstorage also start honoring the users
blocking preferences soon?

[Ehsan Akhgari]

On 2015-08-18 5:37 PM, Tanvi Vyas wrote:
> It is nice to see that we are moving towards an "Accept third party
> cookies and data" setting instead of just "Allow third party cookies".
> Will localstorage and sessionstorage also start honoring the users
> blocking preferences soon?

Yes, that is part of this project.

[Jonas Sicking]

Is there a point to having sessionStorage honor this pref? Doesn't it
effectively double-key anyway since it ties the data to a given
nsIDocShell instance. So there's no way to use that for tracking any
more than global variables and URLs?

/ Jonas

[Anne van Kesteren]

On Tue, Aug 18, 2015 at 11:12 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> (We should probably rename that to "Accept third-part[y] cookies and data:".)

Should we? I was kind of hoping we could maintain the illusion that
all storage is cookies since it would keep the UI simple. Users have
enough trouble understanding cookies as it is. Though I suppose that
once we add persistent storage that might get complicated. (Though
calling that "persistent cookies" might actually be something that
users understand more than anything else. "May example.invalid store
persistent cookies? (These cookies are only removed when you
explicitly remove them.)"

Anyway, sorry to go off on a tangent, glad to see this is happening!


--
https://annevankesteren.nl/

[Ehsan Akhgari]

That's a great point! I commented on the bug.

[Ehsan Akhgari]

On 2015-08-19 2:48 AM, Anne van Kesteren wrote:
> On Tue, Aug 18, 2015 at 11:12 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>> (We should probably rename that to "Accept third-part[y] cookies and data:".)
>
> Should we? I was kind of hoping we could maintain the illusion that
> all storage is cookies since it would keep the UI simple. Users have
> enough trouble understanding cookies as it is. Though I suppose that
> once we add persistent storage that might get complicated. (Though
> calling that "persistent cookies" might actually be something that
> users understand more than anything else. "May example.invalid store
> persistent cookies? (These cookies are only removed when you
> explicitly remove them.)"

I somewhat agree, if I assume that users know what cookies mean, but I
really have no idea whether that is true. At any rate, I don't feel
strongly either way.

[tinnick]

This conversation seems quite old and I'm wondering what the current state is?
Are browsers now currently accepting a uniform way of handling user's pref.?
And are there any trustable documentation available for others to see?

In 2023, it seems localStorage is still not persisted across domains in Safari, regardless of the user's pref.