Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BroadcastChannel needs partitioning #5803

Open
rniwa opened this issue Aug 10, 2020 · 14 comments
Open

BroadcastChannel needs partitioning #5803

rniwa opened this issue Aug 10, 2020 · 14 comments

Comments

@rniwa
Copy link

rniwa commented Aug 10, 2020

As the feature is currently spec'ed, BroadcastChannel allows same origin contents with different top-level domains to communicate with one another. This allows scripts in those same origin contents to track users across different top-level domains.

We need to partition BroadcastChannel based on top-level domain like other storage APIs.

@rniwa
Copy link
Author

rniwa commented Aug 10, 2020

Note that given WebKit's tracking prevention policy, we would not be able to re-introduce BroadcastChannel until this issue is resolved. Furthermore, I think Mozilla has implemented this behavior in Gecko so there appear to be two implementor interests in this regard. I'm not certain if Google / Chrome has done the same. Does anyone know?

@jkarlin
Copy link

jkarlin commented Aug 10, 2020

Yep, Chrome would like to see BroadcastChannel partitioned as well.

@rniwa
Copy link
Author

rniwa commented Aug 13, 2020

It would be good if someone from Mozilla could clarify what they did to partition BroadcastChannel. @annevk ?

@annevk
Copy link
Member

annevk commented Aug 14, 2020

See also discussion in privacycg/storage-partitioning#9 (and whatwg/storage#88 for storage APIs, though how that mechanism should work with broadcast channel is a bit unclear to me still). Our current approach is that the key depends on the storage access permission. I think currently if an origin has a transition from partitioned to non-partitioned it might have channels with two different keys. We've considered closing the channel with the partitioned key at that point.

cc @bakulf

webkit-commit-queue pushed a commit to WebKit/WebKit that referenced this issue Jul 16, 2021
https://bugs.webkit.org/show_bug.cgi?id=227924

Reviewed by Sam Weinig.

LayoutTests/imported/w3c:

Rebaseline WPT tests now that more tests are running and we are passing more checks.

* web-platform-tests/FileAPI/url/url-in-tags-revoke.window-expected.txt:
* web-platform-tests/html/browsers/the-window-object/noopener-noreferrer-BarProp.window-expected.txt:
* web-platform-tests/html/browsers/the-window-object/noopener-noreferrer-sizing.window-expected.txt:
* web-platform-tests/html/browsers/the-window-object/window-open-noreferrer-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/report-only-require-corp.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/require-corp.https-expected.txt:
* web-platform-tests/html/dom/idlharness.worker-expected.txt:
* web-platform-tests/html/infrastructure/safe-passing-of-structured-data/shared-array-buffers/broadcastchannel-success.https-expected.txt:
* web-platform-tests/html/semantics/forms/form-submission-target/rel-base-target-expected.txt:
* web-platform-tests/html/semantics/forms/form-submission-target/rel-button-target-expected.txt:
* web-platform-tests/html/semantics/forms/form-submission-target/rel-form-target-expected.txt:
* web-platform-tests/html/semantics/forms/form-submission-target/rel-input-target-expected.txt:
* web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/htmlanchorelement_noopener-expected.txt:
* web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/target_blank_implicit_noopener-expected.txt:
* web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/target_blank_implicit_noopener_base-expected.txt:
* web-platform-tests/wasm/serialization/module/broadcastchannel-success-and-failure-expected.txt:
* web-platform-tests/wasm/serialization/module/broadcastchannel-success-expected.txt:
* web-platform-tests/webmessaging/MessageEvent-trusted.any-expected.txt:
* web-platform-tests/webmessaging/MessageEvent-trusted.any.worker-expected.txt:
* web-platform-tests/webmessaging/broadcastchannel/basics-expected.txt: Removed.
* web-platform-tests/webmessaging/broadcastchannel/basics.any-expected.txt:
* web-platform-tests/webmessaging/broadcastchannel/basics.any.worker-expected.txt:
* web-platform-tests/webmessaging/broadcastchannel/blobs-expected.txt:
* web-platform-tests/webmessaging/broadcastchannel/interface-expected.txt: Removed.
* web-platform-tests/webmessaging/broadcastchannel/interface.any-expected.txt:
* web-platform-tests/webmessaging/broadcastchannel/interface.any.worker-expected.txt:
* web-platform-tests/webmessaging/broadcastchannel/sandbox-expected.txt:
* web-platform-tests/webmessaging/broadcastchannel/workers-expected.txt: Added.
* web-platform-tests/webmessaging/multi-globals/broadcastchannel-current.sub-expected.txt:
* web-platform-tests/webstorage/storage_session_window_noopener.window-expected.txt:
* web-platform-tests/workers/semantics/interface-objects/001.worker-expected.txt:

Source/WebCore:

Add initial support for BroadcastChannel behind a runtime flag, off by default:
- https://html.spec.whatwg.org/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts

Both Firefox and Blink have been supporting BroadcastChannel for a long time.

The implementation is complete and spec-compliant. It works both in Window and Worker environments,
in WebKit1 and WebKit2. However, the feature is off-by-default because of privacy concerns that have
not been addresssed yet:
- whatwg/html#5803

We should be able to add partioning to address the privacy concerns and ship this later on. In the mean
time though, having a working BroadcastChannel implementation in the context of layout tests is already
very useful because a lot of Web-Platform-Tests are relying on it to test other Web features. This means
better test coverage for WebKit.

Tests:
- fast/html/broadcast-channel-between-different-sessions.html
- Rebaselined WPT tests

* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources-output.xcfilelist:
* DerivedSources.make:
* Headers.cmake:
* Sources.txt:
* WebCore.xcodeproj/project.pbxproj:
* bindings/js/WebCoreBuiltinNames.h:
* dom/BroadcastChannel.cpp: Added.
(WebCore::channelToContextIdentifier):
(WebCore::BroadcastChannel::BroadcastChannel):
(WebCore::BroadcastChannel::~BroadcastChannel):
(WebCore::BroadcastChannel::postMessage):
(WebCore::BroadcastChannel::close):
(WebCore::BroadcastChannel::dispatchMessageTo):
(WebCore::BroadcastChannel::dispatchMessage):
(WebCore::BroadcastChannel::ensureOnMainThread):
(WebCore::BroadcastChannel::activeDOMObjectName const):
(WebCore::BroadcastChannel::eventListenersDidChange):
(WebCore::BroadcastChannel::virtualHasPendingActivity const):
* dom/BroadcastChannel.h: Added.
(WebCore::BroadcastChannel::create):
(WebCore::BroadcastChannel::identifier const):
(WebCore::BroadcastChannel::name const):
* dom/BroadcastChannel.idl: Added.
* dom/BroadcastChannelIdentifier.h: Added.
* dom/BroadcastChannelRegistry.h: Added.
(WebCore::BroadcastChannelRegistry::~BroadcastChannelRegistry):
* dom/DeviceOrientationAndMotionAccessController.h:
* dom/DeviceOrientationEvent.cpp:
* dom/DeviceOrientationEvent.h:
* dom/EventTargetFactory.in:
* loader/EmptyClients.cpp:
(WebCore::pageConfigurationWithEmptyClients):
* page/Page.cpp:
(WebCore::Page::Page):
(WebCore::Page::setBroadcastChannelRegistry):
* page/Page.h:
(WebCore::Page::broadcastChannelRegistry):
* page/PageConfiguration.cpp:
(WebCore::PageConfiguration::PageConfiguration):
* page/PageConfiguration.h:

Source/WebKit:

Add initial support for BroadcastChannel behind a runtime flag, off by default:
- https://html.spec.whatwg.org/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts

Both Firefox and Blink have been supporting BroadcastChannel for a long time.

The implementation is complete and spec-compliant. It works both in Window and Worker environments,
in WebKit1 and WebKit2. However, the feature is off-by-default because of privacy concerns that have
not been addresssed yet:
- whatwg/html#5803

We should be able to add partioning to address the privacy concerns and ship this later on. In the mean
time though, having a working BroadcastChannel implementation in the context of layout tests is already
very useful because a lot of Web-Platform-Tests are relying on it to test other Web features. This means
better test coverage for WebKit.

* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources-output.xcfilelist:
* DerivedSources.make:
* NetworkProcess/Downloads/DownloadManager.cpp:
* NetworkProcess/NetworkBroadcastChannelRegistry.cpp: Added.
(WebKit::NetworkBroadcastChannelRegistry::registerChannel):
(WebKit::NetworkBroadcastChannelRegistry::unregisterChannel):
(WebKit::NetworkBroadcastChannelRegistry::postMessage):
(WebKit::NetworkBroadcastChannelRegistry::removeConnection):
* NetworkProcess/NetworkBroadcastChannelRegistry.h: Added.
(WebKit::NetworkBroadcastChannelRegistry::GlobalBroadcastChannelIdentifier::operator== const):
* NetworkProcess/NetworkBroadcastChannelRegistry.messages.in: Added.
* NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::didReceiveMessage):
(WebKit::NetworkConnectionToWebProcess::didClose):
* NetworkProcess/NetworkSession.cpp:
(WebKit::NetworkSession::NetworkSession):
* NetworkProcess/NetworkSession.h:
(WebKit::NetworkSession::broadcastChannelRegistry):
* Scripts/webkit/messages.py:
(types_that_cannot_be_forward_declared):
* Sources.txt:
* WebKit.xcodeproj/project.pbxproj:
* WebProcess/Network/NetworkProcessConnection.cpp:
(WebKit::NetworkProcessConnection::didReceiveMessage):
* WebProcess/WebCoreSupport/WebBroadcastChannelRegistry.cpp: Added.
(WebKit::networkProcessConnection):
(WebKit::WebBroadcastChannelRegistry::registerChannel):
(WebKit::WebBroadcastChannelRegistry::unregisterChannel):
(WebKit::WebBroadcastChannelRegistry::postMessage):
(WebKit::WebBroadcastChannelRegistry::postMessageToRemote):
* WebProcess/WebCoreSupport/WebBroadcastChannelRegistry.h: Added.
* WebProcess/WebCoreSupport/WebBroadcastChannelRegistry.messages.in: Added.
* WebProcess/WebPage/WebPage.cpp:
(WebKit::m_appHighlightsVisible):
* WebProcess/WebProcess.cpp:
(WebKit::WebProcess::WebProcess):
* WebProcess/WebProcess.h:
(WebKit::WebProcess::broadcastChannelRegistry):

Source/WebKitLegacy:

Add BroadcastChannelRegistry implementation for WebKitLegacy.

* Sources.txt:
* WebCoreSupport/WebBroadcastChannelRegistry.cpp: Added.
(WebBroadcastChannelRegistry::getOrCreate):
(WebBroadcastChannelRegistry::registerChannel):
(WebBroadcastChannelRegistry::unregisterChannel):
(WebBroadcastChannelRegistry::postMessage):
* WebCoreSupport/WebBroadcastChannelRegistry.h: Added.
* WebKitLegacy.xcodeproj/project.pbxproj:

Source/WebKitLegacy/mac:

* WebView/WebView.mm:
(-[WebView _commonInitializationWithFrameName:groupName:]):
(-[WebView _preferencesChanged:]):

Source/WebKitLegacy/win:

* WebView.cpp:
(WebView::initWithFrame):
(WebView::notifyPreferencesChanged):

Source/WTF:

Add experimental feature flag for BroadcastChannel, off by default.

* Scripts/Preferences/WebPreferencesExperimental.yaml:

LayoutTests:

* TestExpectations:
* fast/html/broadcast-channel-between-different-sessions-expected.txt: Added.
* fast/html/broadcast-channel-between-different-sessions.html: Added.
* fast/html/resources/broadcast-channel-between-different-sessions-window.html: Added.
Add layout test coverage to make sure that windows belonging to different session are unable to communicate
via BroadcastChannel.

* platform/ios-wk2/imported/w3c/web-platform-tests/html/browsers/the-window-object/noopener-noreferrer-sizing.window-expected.txt: Copied from LayoutTests/imported/w3c/web-platform-tests/html/browsers/the-window-object/noopener-noreferrer-sizing.window-expected.txt.
* platform/ios-wk2/imported/w3c/web-platform-tests/html/dom/idlharness.https-expected.txt:
* platform/mac-wk1/TestExpectations:
* platform/mac-wk1/imported/w3c/web-platform-tests/html/browsers/the-window-object/noopener-noreferrer-BarProp.window-expected.txt: Added.
* platform/mac-wk1/imported/w3c/web-platform-tests/html/dom/idlharness.https-expected.txt:
* platform/mac-wk1/imported/w3c/web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/htmlanchorelement_noopener-expected.txt: Added.
* platform/mac-wk2/imported/w3c/web-platform-tests/html/dom/idlharness.https-expected.txt:
* platform/win/TestExpectations:
* platform/wk2/TestExpectations:
Update test expectations now that we support BroadcastChannel.


Canonical link: https://commits.webkit.org/239714@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@279971 268f45cc-cd09-0410-ab3c-d52691b4dbfc
philn pushed a commit to philn/old-webkit that referenced this issue Jul 21, 2021
https://bugs.webkit.org/show_bug.cgi?id=227924

Reviewed by Sam Weinig.

LayoutTests/imported/w3c:

Rebaseline WPT tests now that more tests are running and we are passing more checks.

* web-platform-tests/FileAPI/url/url-in-tags-revoke.window-expected.txt:
* web-platform-tests/html/browsers/the-window-object/noopener-noreferrer-BarProp.window-expected.txt:
* web-platform-tests/html/browsers/the-window-object/noopener-noreferrer-sizing.window-expected.txt:
* web-platform-tests/html/browsers/the-window-object/window-open-noreferrer-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/report-only-require-corp.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/require-corp.https-expected.txt:
* web-platform-tests/html/dom/idlharness.worker-expected.txt:
* web-platform-tests/html/infrastructure/safe-passing-of-structured-data/shared-array-buffers/broadcastchannel-success.https-expected.txt:
* web-platform-tests/html/semantics/forms/form-submission-target/rel-base-target-expected.txt:
* web-platform-tests/html/semantics/forms/form-submission-target/rel-button-target-expected.txt:
* web-platform-tests/html/semantics/forms/form-submission-target/rel-form-target-expected.txt:
* web-platform-tests/html/semantics/forms/form-submission-target/rel-input-target-expected.txt:
* web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/htmlanchorelement_noopener-expected.txt:
* web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/target_blank_implicit_noopener-expected.txt:
* web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/target_blank_implicit_noopener_base-expected.txt:
* web-platform-tests/wasm/serialization/module/broadcastchannel-success-and-failure-expected.txt:
* web-platform-tests/wasm/serialization/module/broadcastchannel-success-expected.txt:
* web-platform-tests/webmessaging/MessageEvent-trusted.any-expected.txt:
* web-platform-tests/webmessaging/MessageEvent-trusted.any.worker-expected.txt:
* web-platform-tests/webmessaging/broadcastchannel/basics-expected.txt: Removed.
* web-platform-tests/webmessaging/broadcastchannel/basics.any-expected.txt:
* web-platform-tests/webmessaging/broadcastchannel/basics.any.worker-expected.txt:
* web-platform-tests/webmessaging/broadcastchannel/blobs-expected.txt:
* web-platform-tests/webmessaging/broadcastchannel/interface-expected.txt: Removed.
* web-platform-tests/webmessaging/broadcastchannel/interface.any-expected.txt:
* web-platform-tests/webmessaging/broadcastchannel/interface.any.worker-expected.txt:
* web-platform-tests/webmessaging/broadcastchannel/sandbox-expected.txt:
* web-platform-tests/webmessaging/broadcastchannel/workers-expected.txt: Added.
* web-platform-tests/webmessaging/multi-globals/broadcastchannel-current.sub-expected.txt:
* web-platform-tests/webstorage/storage_session_window_noopener.window-expected.txt:
* web-platform-tests/workers/semantics/interface-objects/001.worker-expected.txt:

Source/WebCore:

Add initial support for BroadcastChannel behind a runtime flag, off by default:
- https://html.spec.whatwg.org/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts

Both Firefox and Blink have been supporting BroadcastChannel for a long time.

The implementation is complete and spec-compliant. It works both in Window and Worker environments,
in WebKit1 and WebKit2. However, the feature is off-by-default because of privacy concerns that have
not been addresssed yet:
- whatwg/html#5803

We should be able to add partioning to address the privacy concerns and ship this later on. In the mean
time though, having a working BroadcastChannel implementation in the context of layout tests is already
very useful because a lot of Web-Platform-Tests are relying on it to test other Web features. This means
better test coverage for WebKit.

Tests:
- fast/html/broadcast-channel-between-different-sessions.html
- Rebaselined WPT tests

* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources-output.xcfilelist:
* DerivedSources.make:
* Headers.cmake:
* Sources.txt:
* WebCore.xcodeproj/project.pbxproj:
* bindings/js/WebCoreBuiltinNames.h:
* dom/BroadcastChannel.cpp: Added.
(WebCore::channelToContextIdentifier):
(WebCore::BroadcastChannel::BroadcastChannel):
(WebCore::BroadcastChannel::~BroadcastChannel):
(WebCore::BroadcastChannel::postMessage):
(WebCore::BroadcastChannel::close):
(WebCore::BroadcastChannel::dispatchMessageTo):
(WebCore::BroadcastChannel::dispatchMessage):
(WebCore::BroadcastChannel::ensureOnMainThread):
(WebCore::BroadcastChannel::activeDOMObjectName const):
(WebCore::BroadcastChannel::eventListenersDidChange):
(WebCore::BroadcastChannel::virtualHasPendingActivity const):
* dom/BroadcastChannel.h: Added.
(WebCore::BroadcastChannel::create):
(WebCore::BroadcastChannel::identifier const):
(WebCore::BroadcastChannel::name const):
* dom/BroadcastChannel.idl: Added.
* dom/BroadcastChannelIdentifier.h: Added.
* dom/BroadcastChannelRegistry.h: Added.
(WebCore::BroadcastChannelRegistry::~BroadcastChannelRegistry):
* dom/DeviceOrientationAndMotionAccessController.h:
* dom/DeviceOrientationEvent.cpp:
* dom/DeviceOrientationEvent.h:
* dom/EventTargetFactory.in:
* loader/EmptyClients.cpp:
(WebCore::pageConfigurationWithEmptyClients):
* page/Page.cpp:
(WebCore::Page::Page):
(WebCore::Page::setBroadcastChannelRegistry):
* page/Page.h:
(WebCore::Page::broadcastChannelRegistry):
* page/PageConfiguration.cpp:
(WebCore::PageConfiguration::PageConfiguration):
* page/PageConfiguration.h:

Source/WebKit:

Add initial support for BroadcastChannel behind a runtime flag, off by default:
- https://html.spec.whatwg.org/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts

Both Firefox and Blink have been supporting BroadcastChannel for a long time.

The implementation is complete and spec-compliant. It works both in Window and Worker environments,
in WebKit1 and WebKit2. However, the feature is off-by-default because of privacy concerns that have
not been addresssed yet:
- whatwg/html#5803

We should be able to add partioning to address the privacy concerns and ship this later on. In the mean
time though, having a working BroadcastChannel implementation in the context of layout tests is already
very useful because a lot of Web-Platform-Tests are relying on it to test other Web features. This means
better test coverage for WebKit.

* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources-output.xcfilelist:
* DerivedSources.make:
* NetworkProcess/Downloads/DownloadManager.cpp:
* NetworkProcess/NetworkBroadcastChannelRegistry.cpp: Added.
(WebKit::NetworkBroadcastChannelRegistry::registerChannel):
(WebKit::NetworkBroadcastChannelRegistry::unregisterChannel):
(WebKit::NetworkBroadcastChannelRegistry::postMessage):
(WebKit::NetworkBroadcastChannelRegistry::removeConnection):
* NetworkProcess/NetworkBroadcastChannelRegistry.h: Added.
(WebKit::NetworkBroadcastChannelRegistry::GlobalBroadcastChannelIdentifier::operator== const):
* NetworkProcess/NetworkBroadcastChannelRegistry.messages.in: Added.
* NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::didReceiveMessage):
(WebKit::NetworkConnectionToWebProcess::didClose):
* NetworkProcess/NetworkSession.cpp:
(WebKit::NetworkSession::NetworkSession):
* NetworkProcess/NetworkSession.h:
(WebKit::NetworkSession::broadcastChannelRegistry):
* Scripts/webkit/messages.py:
(types_that_cannot_be_forward_declared):
* Sources.txt:
* WebKit.xcodeproj/project.pbxproj:
* WebProcess/Network/NetworkProcessConnection.cpp:
(WebKit::NetworkProcessConnection::didReceiveMessage):
* WebProcess/WebCoreSupport/WebBroadcastChannelRegistry.cpp: Added.
(WebKit::networkProcessConnection):
(WebKit::WebBroadcastChannelRegistry::registerChannel):
(WebKit::WebBroadcastChannelRegistry::unregisterChannel):
(WebKit::WebBroadcastChannelRegistry::postMessage):
(WebKit::WebBroadcastChannelRegistry::postMessageToRemote):
* WebProcess/WebCoreSupport/WebBroadcastChannelRegistry.h: Added.
* WebProcess/WebCoreSupport/WebBroadcastChannelRegistry.messages.in: Added.
* WebProcess/WebPage/WebPage.cpp:
(WebKit::m_appHighlightsVisible):
* WebProcess/WebProcess.cpp:
(WebKit::WebProcess::WebProcess):
* WebProcess/WebProcess.h:
(WebKit::WebProcess::broadcastChannelRegistry):

Source/WebKitLegacy:

Add BroadcastChannelRegistry implementation for WebKitLegacy.

* Sources.txt:
* WebCoreSupport/WebBroadcastChannelRegistry.cpp: Added.
(WebBroadcastChannelRegistry::getOrCreate):
(WebBroadcastChannelRegistry::registerChannel):
(WebBroadcastChannelRegistry::unregisterChannel):
(WebBroadcastChannelRegistry::postMessage):
* WebCoreSupport/WebBroadcastChannelRegistry.h: Added.
* WebKitLegacy.xcodeproj/project.pbxproj:

Source/WebKitLegacy/mac:

* WebView/WebView.mm:
(-[WebView _commonInitializationWithFrameName:groupName:]):
(-[WebView _preferencesChanged:]):

Source/WebKitLegacy/win:

* WebView.cpp:
(WebView::initWithFrame):
(WebView::notifyPreferencesChanged):

Source/WTF:

Add experimental feature flag for BroadcastChannel, off by default.

* Scripts/Preferences/WebPreferencesExperimental.yaml:

LayoutTests:

* TestExpectations:
* fast/html/broadcast-channel-between-different-sessions-expected.txt: Added.
* fast/html/broadcast-channel-between-different-sessions.html: Added.
* fast/html/resources/broadcast-channel-between-different-sessions-window.html: Added.
Add layout test coverage to make sure that windows belonging to different session are unable to communicate
via BroadcastChannel.

* platform/ios-wk2/imported/w3c/web-platform-tests/html/browsers/the-window-object/noopener-noreferrer-sizing.window-expected.txt: Copied from LayoutTests/imported/w3c/web-platform-tests/html/browsers/the-window-object/noopener-noreferrer-sizing.window-expected.txt.
* platform/ios-wk2/imported/w3c/web-platform-tests/html/dom/idlharness.https-expected.txt:
* platform/mac-wk1/TestExpectations:
* platform/mac-wk1/imported/w3c/web-platform-tests/html/browsers/the-window-object/noopener-noreferrer-BarProp.window-expected.txt: Added.
* platform/mac-wk1/imported/w3c/web-platform-tests/html/dom/idlharness.https-expected.txt:
* platform/mac-wk1/imported/w3c/web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/htmlanchorelement_noopener-expected.txt: Added.
* platform/mac-wk2/imported/w3c/web-platform-tests/html/dom/idlharness.https-expected.txt:
* platform/win/TestExpectations:
* platform/wk2/TestExpectations:
Update test expectations now that we support BroadcastChannel.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@279971 268f45cc-cd09-0410-ab3c-d52691b4dbfc
webkit-commit-queue pushed a commit to WebKit/WebKit that referenced this issue Sep 7, 2021
…Channel

https://bugs.webkit.org/show_bug.cgi?id=229814

Reviewed by Alex Christensen.

Source/WebCore:

Implement origin partitioning (top-origin/frame-origin) for BroadcastChannel to address privacy
concerns, as discussed here:
- whatwg/html#5803

Test: http/tests/messaging/broadcastchannel-partitioning.html

* dom/BroadcastChannel.cpp:
(WebCore::BroadcastChannel::BroadcastChannel):
(WebCore::m_identifier):
(WebCore::BroadcastChannel::dispatchMessage):
* dom/BroadcastChannel.h:
* dom/BroadcastChannelRegistry.h:
* loader/EmptyClients.cpp:

Source/WebKit:

Implement origin partitioning (top-origin/frame-origin) for BroadcastChannel to address privacy
concerns, as discussed here:
- whatwg/html#5803

* NetworkProcess/NetworkBroadcastChannelRegistry.cpp:
(WebKit::NetworkBroadcastChannelRegistry::registerChannel):
(WebKit::NetworkBroadcastChannelRegistry::unregisterChannel):
(WebKit::NetworkBroadcastChannelRegistry::postMessage):
(WebKit::NetworkBroadcastChannelRegistry::removeConnection):
* NetworkProcess/NetworkBroadcastChannelRegistry.h:
* NetworkProcess/NetworkBroadcastChannelRegistry.messages.in:
* WebProcess/WebCoreSupport/WebBroadcastChannelRegistry.cpp:
(WebKit::WebBroadcastChannelRegistry::registerChannel):
(WebKit::WebBroadcastChannelRegistry::unregisterChannel):
(WebKit::WebBroadcastChannelRegistry::postMessage):
* WebProcess/WebCoreSupport/WebBroadcastChannelRegistry.h:

Source/WebKitLegacy:

Implement origin partitioning (top-origin/frame-origin) for BroadcastChannel to address privacy
concerns, as discussed here:
- whatwg/html#5803

* WebCoreSupport/WebBroadcastChannelRegistry.cpp:
(WebBroadcastChannelRegistry::registerChannel):
(WebBroadcastChannelRegistry::unregisterChannel):
(WebBroadcastChannelRegistry::postMessage):
* WebCoreSupport/WebBroadcastChannelRegistry.h:

Source/WTF:

Add experimental preference for BroadcastChannel origin partitioning. This is useful because we currently
disable this when running web-platform-tests in WKTR / DRT for now.

* Scripts/Preferences/WebPreferencesExperimental.yaml:

Tools:

Disable BroadcastChannel origin partitioning when running layout tests since it would cause
too many test failures in WPT tests at this point (e.g. COOP/COEP tests).

* TestRunnerShared/TestFeatures.cpp:
(WTR::shouldDisableBroadcastChannelOriginPartitioning):
(WTR::hardcodedFeaturesBasedOnPathForTest):
* WebKitTestRunner/TestController.cpp:
(WTR::TestController::resetPreferencesToConsistentValues):
* WebKitTestRunner/TestOptions.cpp:
(WTR::TestOptions::defaults):

LayoutTests:

Add layout test coverage.

* http/tests/messaging/broadcastchannel-partitioning-expected.txt: Added.
* http/tests/messaging/broadcastchannel-partitioning.html: Added.
* http/tests/messaging/resources/broadcastchannel-partitioning-iframe.html: Added.
* http/tests/messaging/resources/broadcastchannel-partitioning-popup.html: Added.


Canonical link: https://commits.webkit.org/241403@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@282105 268f45cc-cd09-0410-ab3c-d52691b4dbfc
@cdumez
Copy link

cdumez commented Sep 10, 2021

To follow-up on this, I am currently implementing origin-partitioning for BroadcastChannel in WebKit:

@domenic
Copy link
Member

domenic commented Sep 10, 2021

Would anyone be able to help with the appropriate spec changes here?

@wanderview
Copy link
Member

wanderview commented Sep 10, 2021

Chromium is also working on an implementation. Also see the design doc.

I was planning on eventually working on a PR to spec for this once our implementation was further along. Happy to have someone else tackle the spec, though.

philn pushed a commit to philn/old-webkit that referenced this issue Sep 14, 2021
…Channel

https://bugs.webkit.org/show_bug.cgi?id=229814

Reviewed by Alex Christensen.

Source/WebCore:

Implement origin partitioning (top-origin/frame-origin) for BroadcastChannel to address privacy
concerns, as discussed here:
- whatwg/html#5803

Test: http/tests/messaging/broadcastchannel-partitioning.html

* dom/BroadcastChannel.cpp:
(WebCore::BroadcastChannel::BroadcastChannel):
(WebCore::m_identifier):
(WebCore::BroadcastChannel::dispatchMessage):
* dom/BroadcastChannel.h:
* dom/BroadcastChannelRegistry.h:
* loader/EmptyClients.cpp:

Source/WebKit:

Implement origin partitioning (top-origin/frame-origin) for BroadcastChannel to address privacy
concerns, as discussed here:
- whatwg/html#5803

* NetworkProcess/NetworkBroadcastChannelRegistry.cpp:
(WebKit::NetworkBroadcastChannelRegistry::registerChannel):
(WebKit::NetworkBroadcastChannelRegistry::unregisterChannel):
(WebKit::NetworkBroadcastChannelRegistry::postMessage):
(WebKit::NetworkBroadcastChannelRegistry::removeConnection):
* NetworkProcess/NetworkBroadcastChannelRegistry.h:
* NetworkProcess/NetworkBroadcastChannelRegistry.messages.in:
* WebProcess/WebCoreSupport/WebBroadcastChannelRegistry.cpp:
(WebKit::WebBroadcastChannelRegistry::registerChannel):
(WebKit::WebBroadcastChannelRegistry::unregisterChannel):
(WebKit::WebBroadcastChannelRegistry::postMessage):
* WebProcess/WebCoreSupport/WebBroadcastChannelRegistry.h:

Source/WebKitLegacy:

Implement origin partitioning (top-origin/frame-origin) for BroadcastChannel to address privacy
concerns, as discussed here:
- whatwg/html#5803

* WebCoreSupport/WebBroadcastChannelRegistry.cpp:
(WebBroadcastChannelRegistry::registerChannel):
(WebBroadcastChannelRegistry::unregisterChannel):
(WebBroadcastChannelRegistry::postMessage):
* WebCoreSupport/WebBroadcastChannelRegistry.h:

Source/WTF:

Add experimental preference for BroadcastChannel origin partitioning. This is useful because we currently
disable this when running web-platform-tests in WKTR / DRT for now.

* Scripts/Preferences/WebPreferencesExperimental.yaml:

Tools:

Disable BroadcastChannel origin partitioning when running layout tests since it would cause
too many test failures in WPT tests at this point (e.g. COOP/COEP tests).

* TestRunnerShared/TestFeatures.cpp:
(WTR::shouldDisableBroadcastChannelOriginPartitioning):
(WTR::hardcodedFeaturesBasedOnPathForTest):
* WebKitTestRunner/TestController.cpp:
(WTR::TestController::resetPreferencesToConsistentValues):
* WebKitTestRunner/TestOptions.cpp:
(WTR::TestOptions::defaults):

LayoutTests:

Add layout test coverage.

* http/tests/messaging/broadcastchannel-partitioning-expected.txt: Added.
* http/tests/messaging/broadcastchannel-partitioning.html: Added.
* http/tests/messaging/resources/broadcastchannel-partitioning-iframe.html: Added.
* http/tests/messaging/resources/broadcastchannel-partitioning-popup.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@282105 268f45cc-cd09-0410-ab3c-d52691b4dbfc
@johannhof
Copy link
Member

Hi @cdumez, I was wondering if you can provide some context as to why you decided to unpartition BroadcastChannel based on storage access when all other storage APIs in Webkit are permanently partitioned.

On Firefox we're interested in aligning our partitioning strategy with others, which includes aligning with Safari (and potentially with Blink through Edge) on which storage is unpartitioned when storage access is granted, so this would be interesting to discuss.

Happy to have this chat as part of (or adjacent to) the TPAC Session on Storage Partitioning, if you can attend that. :)

cc @johnwilander

Thanks!

@cdumez
Copy link

cdumez commented Oct 14, 2021

Hi @cdumez, I was wondering if you can provide some context as to why you decided to unpartition BroadcastChannel based on storage access when all other storage APIs in Webkit are permanently partitioned.

On Firefox we're interested in aligning our partitioning strategy with others, which includes aligning with Safari (and potentially with Blink through Edge) on which storage is unpartitioned when storage access is granted, so this would be interesting to discuss.

Happy to have this chat as part of (or adjacent to) the TPAC Session on Storage Partitioning, if you can attend that. :)

cc @johnwilander

Thanks!

I was merely trying to match Firefox’s behavior, which seemed like the safest thing to do as it is the only browsers shipping with partitioning enabled. That said, I would be happy to change this behavior if Firefox does, given that it adds some complexity.

@wanderview
Copy link
Member

FYI for other folks working on this, we're close to having some WPTs for BroadcastChaneel partitioning done and upstreamed.

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Feb 4, 2022
This CL tests that BroadcastChannel is partitioned in third-party
contexts (tentative, pending changes to the spec).

For more info, see whatwg/html#5803

Bug: 1239274
Change-Id: I8d495ecb141847276aefd1bcc4a1af0ea1098db2
aarongable pushed a commit to chromium/chromium that referenced this issue Feb 4, 2022
This CL tests that BroadcastChannel is partitioned in third-party
contexts (tentative, pending changes to the spec).

For more info, see whatwg/html#5803

Bug: 1239274
Change-Id: I8d495ecb141847276aefd1bcc4a1af0ea1098db2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3424369
Reviewed-by: Ben Kelly <[email protected]>
Reviewed-by: Mason Freed <[email protected]>
Commit-Queue: Andrew Williams <[email protected]>
Cr-Commit-Position: refs/heads/main@{#967421}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Feb 4, 2022
This CL tests that BroadcastChannel is partitioned in third-party
contexts (tentative, pending changes to the spec).

For more info, see whatwg/html#5803

Bug: 1239274
Change-Id: I8d495ecb141847276aefd1bcc4a1af0ea1098db2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3424369
Reviewed-by: Ben Kelly <[email protected]>
Reviewed-by: Mason Freed <[email protected]>
Commit-Queue: Andrew Williams <[email protected]>
Cr-Commit-Position: refs/heads/main@{#967421}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Feb 4, 2022
This CL tests that BroadcastChannel is partitioned in third-party
contexts (tentative, pending changes to the spec).

For more info, see whatwg/html#5803

Bug: 1239274
Change-Id: I8d495ecb141847276aefd1bcc4a1af0ea1098db2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3424369
Reviewed-by: Ben Kelly <[email protected]>
Reviewed-by: Mason Freed <[email protected]>
Commit-Queue: Andrew Williams <[email protected]>
Cr-Commit-Position: refs/heads/main@{#967421}
domenic pushed a commit that referenced this issue Feb 15, 2022
This updates the BroadcastChannel specification to have storage keys be used instead of origins when determining which browsing contexts should be able to have BroadcastChannel messages sent and received from them. Today, a storage key only consists of an origin, but it will likely soon include the top-level origin as well. Only using origin enables certain forms of cross-site tracking. For more details, see https://privacycg.github.io/storage-partitioning/.

This helps with #5803, but does not yet close it since storage keys do not yet contain more than just the origin.
@domenic
Copy link
Member

domenic commented Feb 15, 2022

To give a status update, the HTML standard parts of this are probably done, via @recvfrom's great work in #7567. What remains is actually specifying storage partitioning in general, by updating the Storage Standard to have partitioned storage keys.

mattwoodrow pushed a commit to mattwoodrow/wpt that referenced this issue Feb 15, 2022
This CL tests that BroadcastChannel is partitioned in third-party
contexts (tentative, pending changes to the spec).

For more info, see whatwg/html#5803

Bug: 1239274
Change-Id: I8d495ecb141847276aefd1bcc4a1af0ea1098db2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3424369
Reviewed-by: Ben Kelly <[email protected]>
Reviewed-by: Mason Freed <[email protected]>
Commit-Queue: Andrew Williams <[email protected]>
Cr-Commit-Position: refs/heads/main@{#967421}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Feb 26, 2022
… a=testonly

Automatic update from web-platform-tests
[BroadcastChannel] Add Partitioning WPT

This CL tests that BroadcastChannel is partitioned in third-party
contexts (tentative, pending changes to the spec).

For more info, see whatwg/html#5803

Bug: 1239274
Change-Id: I8d495ecb141847276aefd1bcc4a1af0ea1098db2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3424369
Reviewed-by: Ben Kelly <[email protected]>
Reviewed-by: Mason Freed <[email protected]>
Commit-Queue: Andrew Williams <[email protected]>
Cr-Commit-Position: refs/heads/main@{#967421}

--

wpt-commits: 65d9fd570851f5446d6b1e3e6f07440f9b69a561
wpt-pr: 32690
DanielRyanSmith pushed a commit to DanielRyanSmith/wpt that referenced this issue Feb 28, 2022
This CL tests that BroadcastChannel is partitioned in third-party
contexts (tentative, pending changes to the spec).

For more info, see whatwg/html#5803

Bug: 1239274
Change-Id: I8d495ecb141847276aefd1bcc4a1af0ea1098db2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3424369
Reviewed-by: Ben Kelly <[email protected]>
Reviewed-by: Mason Freed <[email protected]>
Commit-Queue: Andrew Williams <[email protected]>
Cr-Commit-Position: refs/heads/main@{#967421}
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Mar 1, 2022
… a=testonly

Automatic update from web-platform-tests
[BroadcastChannel] Add Partitioning WPT

This CL tests that BroadcastChannel is partitioned in third-party
contexts (tentative, pending changes to the spec).

For more info, see whatwg/html#5803

Bug: 1239274
Change-Id: I8d495ecb141847276aefd1bcc4a1af0ea1098db2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3424369
Reviewed-by: Ben Kelly <[email protected]>
Reviewed-by: Mason Freed <[email protected]>
Commit-Queue: Andrew Williams <[email protected]>
Cr-Commit-Position: refs/heads/main@{#967421}

--

wpt-commits: 65d9fd570851f5446d6b1e3e6f07440f9b69a561
wpt-pr: 32690
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Mar 8, 2022
… a=testonly

Automatic update from web-platform-tests
[BroadcastChannel] Add Partitioning WPT

This CL tests that BroadcastChannel is partitioned in third-party
contexts (tentative, pending changes to the spec).

For more info, see whatwg/html#5803

Bug: 1239274
Change-Id: I8d495ecb141847276aefd1bcc4a1af0ea1098db2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3424369
Reviewed-by: Ben Kelly <[email protected]>
Reviewed-by: Mason Freed <[email protected]>
Commit-Queue: Andrew Williams <[email protected]>
Cr-Commit-Position: refs/heads/main@{#967421}

--

wpt-commits: 65d9fd570851f5446d6b1e3e6f07440f9b69a561
wpt-pr: 32690
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Mar 8, 2022
… a=testonly

Automatic update from web-platform-tests
[BroadcastChannel] Add Partitioning WPT

This CL tests that BroadcastChannel is partitioned in third-party
contexts (tentative, pending changes to the spec).

For more info, see whatwg/html#5803

Bug: 1239274
Change-Id: I8d495ecb141847276aefd1bcc4a1af0ea1098db2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3424369
Reviewed-by: Ben Kelly <[email protected]>
Reviewed-by: Mason Freed <[email protected]>
Commit-Queue: Andrew Williams <[email protected]>
Cr-Commit-Position: refs/heads/main@{#967421}

--

wpt-commits: 65d9fd570851f5446d6b1e3e6f07440f9b69a561
wpt-pr: 32690
mfreed7 pushed a commit to mfreed7/html that referenced this issue Jun 3, 2022
This updates the BroadcastChannel specification to have storage keys be used instead of origins when determining which browsing contexts should be able to have BroadcastChannel messages sent and received from them. Today, a storage key only consists of an origin, but it will likely soon include the top-level origin as well. Only using origin enables certain forms of cross-site tracking. For more details, see https://privacycg.github.io/storage-partitioning/.

This helps with whatwg#5803, but does not yet close it since storage keys do not yet contain more than just the origin.
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this issue Oct 14, 2022
This CL tests that BroadcastChannel is partitioned in third-party
contexts (tentative, pending changes to the spec).

For more info, see whatwg/html#5803

Bug: 1239274
Change-Id: I8d495ecb141847276aefd1bcc4a1af0ea1098db2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3424369
Reviewed-by: Ben Kelly <[email protected]>
Reviewed-by: Mason Freed <[email protected]>
Commit-Queue: Andrew Williams <[email protected]>
Cr-Commit-Position: refs/heads/main@{#967421}
NOKEYCHECK=True
GitOrigin-RevId: e8bbaf8fa8b41dfc7c68fd5f42cf6ea0379a67c9
@tnurmi82
Copy link

tnurmi82 commented Dec 1, 2023

This in practice broke an integration between two large enterprise products. Support tickets are starting to pour in. I'm seeing other products getting bit by this as well. Each browser should very quickly implement at least an exclusion-list feature, to allow reverting to previous behaviour for selected domains. In our case it is specifically BroadcastChannel that is no longer working between our web app instances (other one in an iframe inside a well known CRM app, other one in a separate window).

@jespertheend
Copy link

For Chrome, you should register an origin trial to disable third party storage partitioning.
You can keep an eye out for the Storage Access API proposal for future updates on this issue.

@tnurmi82
Copy link

tnurmi82 commented Dec 4, 2023

Thanks @jespertheend - That's golden advice. I have registered our domain for trial and we'll start testing soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

10 participants