Closed Bug 744466 Opened 13 years ago Closed 8 years ago

Isolate DOM Storage to first party domain (Tor 6564)

Categories

(Core :: DOM: Security, defect, P2)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1260931
Tracking Status
e10s - ---

People

(Reporter: mayhemer, Assigned: timhuang)

References

(Blocks 1 open bug, )

Details

(Keywords: privacy, Whiteboard: [tor][ETA 10/10][domsecurity-active])

+++ This bug was initially created as a clone of Bug #536509 +++ http://scarybeastsecurity.blogspot.com/2009/12/bypassing-intent-of-blocking-third.html claims localStorage does not obey the third-party cookies pref. After bug 536509 gets fixed, we need to update DOMStorageImpl::CacheStoragePermissions to work with the third-party flag as well. (Currently we pass false so despite the 3th-party-session-only pref we still persist in multi-process). My first idea: - move the mThirdParty flag to DOMStorageBase (a base class for DOMStorageChild and DOMStorageImpl) - carry it from DOMStorageChild to DOMStorageParent (PStorage at PStorage.ipdl, Init() event, SendInit and RecvInit methods in C++) - DOMStorageParent sets the flag on its DOMStorageImpl and we are done
We have a patch that is not tied to any pref to isolate DOM storage to the first party URL bar domain (ie "double-key) it. This might be more complex than what you're talking about, but we went with this option to still enable third party DOM storage functionality without the associated cross-site tracking. We prefer this approach for all types of third party identifiers (cache, cookies, DOM storage, etc). You can have a look at the patch at: https://gitweb.torproject.org/tor-browser.git/commitdiff/fc3f828978e8ec2347055e276bd6281de72629a8 Let me know if that sounds like something that is worth pursuing instead of simply disabling DOM storage for third parties, or if this approach should have a separate bug and pref.
Whiteboard: [tor]
(In reply to Mike Perry from comment #1) > You can have a look at the patch at: > https://gitweb.torproject.org/tor-browser.git/commitdiff/ > fc3f828978e8ec2347055e276bd6281de72629a8 This link was invalidated due to the hash chain invalidation from the Mozilla git mirror switchover. Here's a working link: https://gitweb.torproject.org/tor-browser.git/commitdiff/1b3c110a29ae11b50ce2bf56d5954773262e67c0
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Here's a link that tracks the latest version of the Tor Browser patch: https://torpat.ch/6564 and here are the regression tests: https://torpat.ch/13749
I'm reopening this bug, to track work on isolating DOM storage to the URL bar domain (the approach taken by Tor Browser). This approach can break fewer sites than simply banning third-party DOM storage altogether.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: e10s: localStorage does not obey "third-party cookies" pref → Isolate DOM Storage to first party domain
bug 536509 seems sufficient for what we needed in e10s, so untracking for e10s
Priority: -- → P1
Assignee: nobody → tihuang
Whiteboard: [tor] → [tor][ETA 10/10]
Component: DOM → DOM: Security
Priority: P1 → P2
Whiteboard: [tor][ETA 10/10] → [tor][ETA 10/10][domsecurity-active]
Summary: Isolate DOM Storage to first party domain → Isolate DOM Storage to first party domain (Tor 6564)
LocalStorage respects origin attributes and bug 1260931 added first party domain to origin attributes, so it should alread be isolated by first party domain. We also have a test for that in bug 1264567. As for session storage, it is already isolated per tabs by design. I think there's nothing to do in this bug, so I'm closing it.
Status: REOPENED → RESOLVED
Closed: 10 years ago8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.