BroadcastChannel needs partitioning #5803
Labels
normative change
security/privacy
There are security or privacy implications
topic: serialize and transfer
topic: storage
Comments
domenic
added
normative change
security/privacy
|
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? |
|
Yep, Chrome would like to see BroadcastChannel partitioned as well. |
|
It would be good if someone from Mozilla could clarify what they did to partition BroadcastChannel. @annevk ? |
|
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
|
To follow-up on this, I am currently implementing origin-partitioning for BroadcastChannel in WebKit:
|
|
Would anyone be able to help with the appropriate spec changes here? |
|
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
|
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. :) 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. |
|
FYI for other folks working on this, we're close to having some WPTs for BroadcastChaneel partitioning done and upstreamed. |
3 tasks
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 <wanderview@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Andrew Williams <awillia@google.com> 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 <wanderview@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Andrew Williams <awillia@google.com> 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 <wanderview@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Andrew Williams <awillia@google.com> 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.
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 <wanderview@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Andrew Williams <awillia@google.com> 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 <wanderview@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Andrew Williams <awillia@google.com> 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 <wanderview@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Andrew Williams <awillia@google.com> 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 <wanderview@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Andrew Williams <awillia@google.com> 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 <wanderview@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Andrew Williams <awillia@google.com> 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 <wanderview@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Andrew Williams <awillia@google.com> 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 <wanderview@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Andrew Williams <awillia@google.com> Cr-Commit-Position: refs/heads/main@{#967421} NOKEYCHECK=True GitOrigin-RevId: e8bbaf8fa8b41dfc7c68fd5f42cf6ea0379a67c9
|
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). |
|
For Chrome, you should register an origin trial to disable third party storage partitioning. |
|
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
and others
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.
The text was updated successfully, but these errors were encountered: