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.

[othermaciej]

In WebKit, we'd probably want to disable BroadcastChannel in frames that don't have access to their origin's first-party storage, or at least partition/double-key it in the same way we do for cache, cookies and other storage mechanisms in a third-party context. We don't currently implement BroadcastChannel but we'd have to look at this when/if we do. Tagging @johnwilander

[othermaciej]

WebKit has a feature called Intelligent Tracking Prevention (ITP). ITP aims to prevent third parties from tracking a user's browsing around the web using client-side state. Though our first version was imperfect, we are committed to closing evasion techniques and not creating new ones. For example, we recently blocked the use of HSTS state as a tracking vector.

Our primary technique for this is partitioning, (AKA double-keying). You can see the details in the blog post I linked.

BroadcastChannel would create an evasion technique by bridging partitioned third-party contexts and first-party contexts, thus allowing third-party contexts to read the first-party storage and track you.

(BTW, if you think of other possible evasion techniques with future or existing web technologies, bugs at http://bugs.webkit.org/ will be welcome.)

[annevk]

Currently the <!--INSERT FINGERPRINT--> mechanism (to highlight privacy issues) is used for localStorage as well as things like navigator.languages. It seems reasonable to use it here too, but perhaps we should rename/reframe it somehow.

[othermaciej]

It would be nice to align with broader industry use of privacy-related terms, though maybe not super important if it’s only in spec comments. “Tracking” or “web tracking” is the usual term for the category of things that include state-based tracking, fingerprinting, IP address based tracking, etc. That’s the terminology the EFF uses, for sample. Tracking methods using client-side state are sometimes called “super cookies”. Fingerprinting includes browser fingerprinting and behavioral fingerprinting.

Navigator.languages is useful for browser fingerprinting (a type of tracking), while the risk from LocalStorage is a kind of tracking (state-based tracking, aka super cookies), but technically not fingerprinting.

There are also sometimes privacy concerns other than tracking in the web platform. For example, an API to expose the user’s golocation would have a privacy risk that is not about web tracking.

[andymatuschak]

This issue is dormant for the moment, but in case it revives:

Per @othermaciej, it's true that BroadcastChannel can be used as part of a strategy to defeat ITP's partitioning! But a partitioned BroadcastChannel is still useful. I'm using it (in Firefox and Chrome) to communicate between same-origin sibling iframes embedded in a third-party context. This allows me to propagate user state across these embedded interfaces when the user has disabled third-party storage (which also disables sessionStorage in those browsers). This use case would still work fine if BroadcastChannel were partitioned—but not if it were disabled completely in this storage-less context.

[rniwa]

See #5803 for partitioning BroadcastChannel. Apparently Gecko does this already.

[domenic]

Should we close this issue, and roll things into the general storage-partitioning effort? Or is there still merit in disabling BroadcastChannel in some cases, when storage is explicitly disabled?

I guess the first question is, in our partitioned-storage future, do we ever expect storage to be disabled?

[rniwa]

I think closing this issue and do the partitioning in #5803 makes sense. If it turns out that there are some other cases where we want to disable BroadcastChannel, we can reopen this issue then.

[domenic]

Thanks @andymatuschak for pinging this thread and helping us consolidate our thinking!

[annevk]

As discussed in whatwg/storage#93 and issues referenced from there I think HTML needs to invoke obtain a storage key for this API.

data:text/html,<script> console.log(new BroadcastChannel("test")) </script> is a simple test for this unrelated to partitioning; it constructs something in Firefox, but throws in Chrome.