Web Inspector: BackendResourceDataStore for Site Isolation response bodies

JSC kept engine-internal scope metadata inside the Primitive Gigacage — the region designed to confine attacker-corruptible user buffers.

ccf6c82

Source/WebKit/WebProcess/Inspector/WebInspectorBackend.messages.in

+ GetResponseBody(String requestId) -> (String body, bool base64Encoded, String errorMessage) Async

Source/WebCore/inspector/InspectorIdentifierRegistry.h

+ std::optional<DeterministicRequestId> parseDeterministicRequestId(const String&);

Source/JavaScriptCore/inspector/protocol/Network.json

- { "name": "getResponseBody", ... }

+ { "name": "getResponseBody", "async": true, ... }

Under WebKit's Site Isolation, cross-origin iframes run in separate WebContent processes. Web Inspector's UIProcess hosts ProxyingNetworkAgent which proxies CDP-style commands to per-frame agents in the appropriate WebProcess. Previously, Network.getResponseBody was synchronous and relied on CachedResource references in NetworkResourcesData — a structure that does not cross process boundaries.

This commit adds BackendResourceDataStore, a WebProcess-side buffer for HTTP response metadata and content that lives in each WebProcess, copies response data at instrumentation time (decoupled from CachedResource lifetime), and is owned by WebInspectorBackend. Network.getResponseBody is converted from synchronous to asynchronous. ProxyingNetworkAgent parses frontend-provided requestId strings via parseDeterministicRequestId to extract the target WebProcess identifier, then sends an async GetResponseBody IPC message to that process.

Significance

This commit extends Web Inspector's reach across Site Isolation process boundaries by introducing a new IPC path and requestId-based routing mechanism — any trust or validation bugs here could allow the inspector frontend to exfiltrate response bodies from WebProcesses it should not reach.

Audit directions

parseDeterministicRequestId parses an attacker-controlled string from the inspector frontend to determine which WebProcess receives an IPC message. Insufficient validation could enable confused-deputy attacks or misrouted IPC, potentially directing GetResponseBody at a WebProcess the inspector frontend should not control.
WebProcess GetResponseBody handler. Verify that the requestId belongs to a resource the WebProcess actually loaded; if the lookup is purely string-keyed without origin or frame validation, a crafted requestId could exfiltrate bodies from unintended frame contexts.
BackendResourceDataStore LRU eviction is decoupled from CachedResource lifetime. Verify there are no use-after-free or double-callback hazards in the async IPC completion path, particularly around page teardown racing with in-flight GetResponseBody replies.
The commit explicitly acknowledges the routing design is a known-weak FIXME, making this a flagged technical debt path before the "proper" mapping-based fix lands.