Closed Bug 1401359 Opened 2 years ago Closed 2 years ago

Disable SharedWorker in contexts where storage is not available

Categories

(Core :: DOM: Workers, enhancement, P2)

57 Branch
enhancement

Tracking

()

RESOLVED FIXED
mozilla59
Tracking Status
firefox59 --- fixed

People

(Reporter: bkelly, Assigned: bkelly)

References

(Blocks 1 open bug)

Details

(Keywords: privacy, sec-want, Whiteboard: [fxprivacy][adv-main59-])

Attachments

(1 file, 1 obsolete file)

There are a number of cases where we disable storage in a window.  For example, in 3rd party iframes when 3rd party cookies are disabled, etc.  If one of these windows attaches to a SharedWorker it could gain access to storage in the worker context or another non-restricted window attached to the same worker.

To mitigate this we should disable SharedWorker when storage is disabled.  Its better to be overly restrictive here since we can loosen the restrictions later.
Whiteboard: [fxprivacy]
Do we have an open bug on using double-keying instead for all of these APIs? That would presumably lead to less breakage and would increase parity with Safari.
(In reply to Anne (:annevk) from comment #1)
> Do we have an open bug on using double-keying instead for all of these APIs?
> That would presumably lead to less breakage and would increase parity with
> Safari.

We have work-in-progress on "first party isolation" which is what I believe our double-keying solution is called.  I don't know where we stand on being able to make it the default, though.  Its a bigger job than restricting some known problematic APIs right now.
This patch disables SharedWorker for now in windows that cannot access storage.  This is a bit heavy handed since there are some cases where its safe.  For example, if all storage is disabled then using SharedWorker should be fine.  For now, though, lets close the loop-hole that lets 3rd party iframes escape to other windows via the SharedWorker.  We can relax this later if necessary.
Attachment #8910468 - Flags: review?(amarchesini)
Comment on attachment 8910468 [details] [diff] [review]
Disable SharedWorker if in windows that cannot access storage. r=baku

Hmm, this breaks SharedWorker in private browsing mode which we explicitly verify works right now.
Attachment #8910468 - Flags: review?(amarchesini)
Priority: -- → P2
Comment on attachment 8936462 [details] [diff] [review]
Disable SharedWorker if in windows that cannot access storage. r=baku

Andrea, this patch disabled SharedWorker in contexts that cannot access storage.  It does allow it for private browsing, however, because we purposely isolate SharedWorker by private browsing session ID already.
Attachment #8936462 - Flags: review?(amarchesini)
Keywords: privacy
Keywords: sec-want
Duplicate of this bug: 1424557
Attachment #8936462 - Flags: review?(amarchesini) → review+
Pushed by bkelly@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/950d56123c67
Disable SharedWorker if in windows that cannot access storage. r=baku
https://hg.mozilla.org/mozilla-central/rev/950d56123c67
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Whiteboard: [fxprivacy] → [fxprivacy][adv-main59-]
You need to log in before you can comment on or make changes to this bug.