1401362 - Consider disabling BroadcastChannel in contexts where storage is disabled

Status: NEW

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

Description

[Ben Kelly [:bkelly, not reviewing]]

If a window has storage denied via nsContentUtils::StorageAllowed*() we might want to also disable BroadcastChannel.  This API would allow the window to communicate with other windows that have storage and effective bypass the anti-tracking protection.

Anne asked me to file a spec issue:

https://github.com/whatwg/html/issues/3054

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Hmm, should we have some new origin attribute for storage-denied pages? That would make the principal different and BroadcastChannel just couldn't communicate with normal pages.

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Olli Pettay [:smaug] from comment #1)
> Hmm, should we have some new origin attribute for storage-denied pages? That
> would make the principal different and BroadcastChannel just couldn't
> communicate with normal pages.

That would make a lot of this better.  Its a very similar problem to private browsing.

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

Or maybe we could just mark 3rd party iframes as private browsing principals.

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

I'm not sure if private browser is really equivalent.  There we have a session ID and try to group things together by session.  For cross-origin iframes with 3rd party cookies disabled we don't really want them to talk to each other at all.  Our first party site isolation is more like what you are suggesting I think.

Comment 5

[Tanvi Vyas[:tanvi]]

What type of breakage would we see if we did this?  With 3rd party storage blocked, this woudl essentially mean all 3rd party subrequests would not have access to BroadcastChannel.

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

BroadcastChannel is relatively new and appears to only be implemented in FF/chrome.  Not sure if we have telemetry on usage.  Seems like sites should already be featuring detecting it, though.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Web pages should be able to use BroadcastChannel within them. Whether or not support cross browsing context communication is different thing, but within a single page BC should just work, and there is no reason to break that.
So if we did this, we might just break web pages rather easily.

Comment 8

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Olli Pettay [:smaug] from comment #7)
> Web pages should be able to use BroadcastChannel within them. Whether or not
> support cross browsing context communication is different thing, but within
> a single page BC should just work, and there is no reason to break that.
> So if we did this, we might just break web pages rather easily.

By this argument we shouldn't be disabling IndexedDB, Cache API, or localstorage in 3rd party iframes with cookies disabled either.  And yet we do because the user has signaled they want to restrict these frames even if it means they don't function correctly.

Comment 9

[Ben Kelly [:bkelly, not reviewing]]

Or we should make BroadcastChannel exist, but essentially only route to event listeners within the same frame.  Maybe that's what you meant.  Sorry for my confusion.

I'm just not sure how to do that without some kind of principal uniqueness flag for each 3rd party iframe.  (Gets us closer to double-keying or first-party isolation, etc.)

Comment 10

[Ben Kelly [:bkelly, not reviewing]]

I think we should ship a block or /dev/null delivery in the short term to close the hole.  We can come up with a better solution in the long term.