should BroadcastChannel be disabled if a window does not have access to storage?

[wanderview]

Currently we disable access to storage for a variety of reasons:

1. Third party iframe with user setting disabling third party cookies.
2. Private browsing window.

If one of these windows uses BroadcastChannel it could in theory communicate tracking information to another tab the user has open which can then write it to disk.

Also, consider an https:// iframe in an insecure http:// parent. It can BroadcastChannel to other https:// windows that may be considered secure. Should it be disabled in this situation as well?

I had thought this was an implementation detail, but @annevk asked me to write a spec issue.

[domenic]

I might be missing something, but doesn't this apply to much more than just BroadcastChannel? E.g. fetch() for server-side communication to another tab, or otherWindow.postMessage(), or more...

[annevk]

How would the server know about another tab? That would only apply if the user is logged in. postMessage() applies, but you cannot generally get handles to windows across tabs.

I think for BroadcastChannel we should point this out as a fingerprinting concern, but double-keying seems more appropriate than disabling, but maybe both should be allowed for now.

[annevk]

This also applies to SharedWorker.

[wanderview]

Also don't forget it allows insecure https-nested-under-http frames to communicate with secure top level https frames. Its a similar problem.

Edit: But maybe that is solved by double-keying as well.

[guest271314]

@annevk What is double-keying?

[guest271314]

@wanderview How is BroadcastChannel different from window.open and window.opener? Why is storage the barometer of whether or not BroadcastChannel should be disabled?

[wanderview]

window.open() creates a visible top-level window popup. If the succeeds from a 3rd party iframe then they have pretty much already interacted with the frame and opt'ed in to whatever it wants to do. (At least conceptually to me.)

I think BroadcastChannel is different. If you happen to have socialmediasite.com open in one tab, and then do some random browsing in other tabs. We should not let nested socialmediasite.com iframes in those random other tabs communicate with the top level socialmediasite.com. Or at least not if the user has asked for those nested iframes to be isolated by blocking 3rd party cookies, etc. Otherwise socialmediasite.com can track you across other, unrelated browsing you do while you have one of their tabs opened anywhere in the browser.

Double-keying or first-party isolation would help here, but may not completely solve it. AIUI some of the webkit solutions here promote any origin you have interacted with as a first party to first party status as a nested iframe. So it doesn't help with the situation I describe above.

[guest271314]

@wanderview Adding sandbox="" attribute to the <iframe> should prevent communication from <iframe> in a separate tab with window.opener when the tab is opened with <a target="_blank"> https://plnkr.co/edit/kEha0MitTDjZEdFrUnPg?p=preview.

Are you suggesting that the communication should be restricted by default?

[wanderview]

I'm not concerned about sandboxed iframes that result in an opaque origin. Those can't BroadcastChannel to other Windows because the origin won't match.

This is more about contexts like 3rd party iframes that are not sandboxed, but the user has disabled 3rd party cookies.

[guest271314]

@wanderview Not gathering what the concern is? Can you fork the linked plnkr to demonstrate?

[wanderview]

I don't know how I can describe it better than #3054 (comment) and #3054 (comment).

If a user has blocked 3rd party cookies that is a pretty strong signal they don't want these iframes to track them across different sites. Something like BroadcastChannel would let these 3rd party iframes communicate to another top level frame of the same origin and persist tracking information to disk.

Anyway, I'm happy to just fix this in gecko. @annevk wanted me to raise a spec issue, but its unclear to me how much the spec covers things like blocking 3rd party iframe cookies.

[guest271314]

Why would <iframe>'s on different tabs having the same origin be considered 3rd party? The specification does not appear to mention blocking 3rd party cookies relevant to BroadcastChannel.

It is not clear from perspective here how "access to storage" is related to the case? As mentioned at an earlier comment SharedWorker can communicate between browsing contexts having the same origin. The storage event can also be utilized to achieve comparable communication between browsing contexts as BroadcastChannel and SharedWorker.