924231 - DOM storage becomes disabled when cookie permissions are allow_first_party_only

Status: RESOLVED DUPLICATE of bug 1356277

(Core :: DOM: Core & HTML, defect)

Description

[Ian Nartowicz]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20100101 Firefox/17.0 (Beta/Release)
Build ID: 20130911042038

Steps to reproduce:

1. Set global cookie permissions to block all cookies
2. Navigate to a site that sets DOM storage items, eg. http://trippingthebits.com/webstorage/test.html
3. Set an exception for the site to allow cookies for first party only
4. Reload the site if necessary to check if DOM storage is allowed
4. Attempt to set a storage item


Actual results:

DOM storage is reported as not allowed.  No storage items are set.


Expected results:

Storage item should have been set.  The exception corresponds to the site shown in the location bar, hence is first party.

Comment 1

[Josh Matthews [:jdm]]

I think this is probably covered by bug 365772.

Comment 2

[Ian Nartowicz]

(In reply to Josh Matthews [:jdm] from comment #1)
> I think this is probably covered by bug 365772.

If you like (or if Honza likes).  However, the cause and the likely fix are entirely different for the two cases.  I can't even see why first-party-only permission checks should fail.  Because they uses principals perhaps?  It is obvious why the ask case doesn't workw the way it does, because it was intentionally written that way, and the fixes are complex requiring additional UI.

It may make more sense to link this to bug 536509.  For now, DOM storage doesn't have any concept of third party, so the fix for this bug is just to treat first_party_only as allow, but depending on the fix for 536509 this may need to be more complex to recognise different behaviour.

Comment 3

[Ian Nartowicz]

I wrote a content script to see what was actually happening, and window.localStorage is actually undefined in this situation.  It still exists and I could get access to it using getLocalStorageForPrincipal() from an addon, but the content javascript couldn't see it.

Comment 4

[Josh Matthews [:jdm]]

Interesting; that's not what I would expect from reading nsDOMStorage::CanUseStorage (http://mxr.mozilla.org/mozilla-central/source/dom/src/storage/DOMStorage.cpp#225).

Comment 5

[Ian Nartowicz]

I think I see it.  testPermission() returns 9 (ACCESS_ALLOW_FIRST_PARTY_ONLY).  This does not match any of the checks in canUseStorage() so it is assumed (wrongly) that it is ACCESS_DEFAULT.  Then the checks fall through to looking at global cookie permissions which are blocked and canUseStorage() assumes that there is no access.

I think undefined is the expected value when access to localStorage is denied.

Comment 6

[Josh Matthews [:jdm]]

I suspect we would take a patch to make it explicitly check that the permission is ACCESS_DEFAULT.

Comment 7

[Ian Nartowicz]

It needs to explicitly detect ACCESS_ALLOW_FIRST_PARTY_ONLY.  Letting that fall out at the end of the if/else chain is only going to be correct if you explicitly set the right conditions for ACCESS_ALLOW_FIRST_PARTY_ONLY, so it may as well be checked for.  Currently DOM storage is third-party-agnostic so ALLOW_FIRST_PARTY_ONLY is exactly the same as ALLOW.

Ideally, ACCESS_DEFAULT should also be checked for before assuming the global permissions.  We're lucky this time that DOM storage should be allowed but gets blocked.  The next new exception type might be one that should block and we end up allowing it, which I feel is worse.  Then we would be left with a catch-all of an unexpected permission type, perhaps always make that denied just to be safe, and probably throw too.

Comment 8

[Ian Nartowicz]

I suspect that bug 1356277 has fixed this, so essentially a duplicate.