Redo BroadcastChannel partitioning using channel name altering approach.

Chromium change:

https://chromium.googlesource.com/chromium/src.git/+/61e816d489f1f574b609435922de3a48334c7b8d

commit 61e816d489f1f574b609435922de3a48334c7b8d
Author: Andrew Williams <awillia@google.com>
Date:   Mon Nov 1 04:41:04 2021 +0000

    BroadcastChannel: Partition using StorageKey instead of Origin

    This CL updates the BroadcastChannel implementation so that partitioning
    is done by StorageKey instead of Origin. To facilitate this, it also
    changes the way in which Mojo messages are sent to preserve per-thread
    message ordering (as required by the BroadcastChannel specification).

    Previously, a shared, per-thread Remote was used to send messages from
    the renderer to RenderProcessHost on the browser side. This message would
    contain the origin, which the browser code would verify was accurate, and
    would then be used to establish the channel connection. This approach
    presents a challenge when switching to StorageKey, in that there's not a
    way to have the renderer send the StorageKey and have the browser verify
    it at the process level.

    This CL removes the origin from the message definition and replaces the
    RenderProcessHost handler (BroadcastChannelProvider instance) with
    separate ones for RenderFrameHostImpl, DedicatedWorkerHost,
    SharedWorkerHost, and ServiceWorkerHost instances. These new handles
    associate incoming connection attempts with their StorageKeys, allowing
    partitioning to be done without any information directly provided by the
    renderer. Shared per-thread Remotes are still used for workers to send
    messages to their corresponding host instance's BroadcastChannelProvider,
    and for frames a channel-associated interface is used to ensure that
    renderer messages are received in-order by the corresponding
    RenderFrameHostImpl.

    For more details, see the "Partitioned BroadcastChannel Design" document:

    https://docs.google.com/document/d/1CchMLU8QmDEx_tA0y57qLyQWvaTT3dlWF-4P_ncc06E/edit?usp=sharing

    Bug: 1239274
This commit is contained in:
Aleksey Khoroshilov
2021-12-07 14:45:50 -05:00
committed by mkarolin
parent fa39c93443
commit 43ba430268
@@ -3,26 +3,22 @@
* License, v. 2.0. If a copy of the MPL was not distributed with this file,
* You can obtain one at http://mozilla.org/MPL/2.0/. */
#include "third_party/blink/public/mojom/broadcastchannel/broadcast_channel.mojom-blink.h"
#include "third_party/blink/renderer/core/frame/local_frame.h"
#include "third_party/blink/renderer/modules/storage/brave_dom_window_storage.h"
#include "third_party/blink/renderer/platform/weborigin/security_origin_hash.h"
// Ephemeral origin substitution is applied only to frame-based
// Ephemeral origin channel name altering is applied only to frame-based
// ExecutionContexts. This is fine because any Worker-based context still
// wouldn't be able to communicate with a frame in both directions because a
// frame-based BroadcastChannel will use an ephemeral origin instead of the one
// the worker is using.
#define ConnectToChannel \
Version_; \
{ \
LocalDOMWindow* window = DynamicTo<LocalDOMWindow>(execution_context); \
if (window) { \
if (auto* origin = GetEphemeralStorageOrigin(window)) { \
origin_ = origin; \
} \
} \
} \
provider->ConnectToChannel
#define GetRemoteNavigationAssociatedInterfaces \
should_send_resource_timing_info_to_parent(); /* no-op */ \
if (auto* origin = GetEphemeralStorageOrigin(window)) { \
name_ = name_ + String::Number(SecurityOriginHash::GetHash(origin)); \
} \
frame->GetRemoteNavigationAssociatedInterfaces
#include "../../../../../../../third_party/blink/renderer/modules/broadcastchannel/broadcast_channel.cc"
#undef ConnectToChannel
#undef GetRemoteNavigationAssociatedInterfaces