== Background ==
blink::DocumentToken will be used for features like GPU's pipeline
caching, allowing the cache to be partitioned using storage keys. The
renderer process is considered untrustworthy, but communicates directly
with the GPU process; rather than having the untrustworthy renderer
directly specify a potentially spoofed storage key, it will send a
document token to the GPU process, which will then ask the trustworthy
browser process for the corresponding storage key.
== Implementation details ==
On the browser side, the blink::DocumentToken is bound to the
RenderFrameHostImpl's DocumentAssociatedMetadata; on the renderer side,
the token is bound to the blink::Document.
When creating a new window or child frame, the browser side allocates a
new DocumentToken and also passes that token to the renderer to plumb
through frame initialization.
When committing a new navigation, the browser side allocates a new
DocumentToken on the NavigationRequest and passes that token to the
renderer in the `CommitNavigation()` IPC.
The intended behavior is that blink::DocumentToken changes each time the
Document changes, though there are some exceptions:
- things like javascript: URLs that end up resulting in a new document
reuse the old DocumentToken: from the perspective of the browser, the
document has not really changed.
- when processing something like `window.open()`, Blink has a historical
quirk where it creates the initial empty document and then immediately
replaces it with a synchronously-completed navigation to about:blank.
Like javascript: URLs, this also reuses the old DocumentToken: this
quirk is renderer-internal and invisible to the browser.
There is also a small hack for speculative RenderFrameHosts: committing
a navigation in a speculative RenderFrameHost does not construct a new
DocumentAssociatedMetadata, instead, the DocumentAssociatedMetadata's
token is simply updated. The hope is that there will be minimal other
document-associated data prior to committing a navigation in a
speculative RenderFrameHost, so this quirk will be mostly invisible
outside the //content implementation.
One open question: when navigating away from the initial empty document
and reusing the Window object, should the DocumentToken be reused
instead of generating a new one? Reusing the token would more closely
mirror the lifetime of LocalDOMWindow and allow it to be a logical
replacement for LocalFrameToken in ExecutionContextToken; however,
reuse of the Window object is also one of the weird edge cases in the
HTML standard that would be nice to minimize if possible.
For now, the implementation chooses not to reuse the DocumentToken even
if the LocalDOMWindow would be reused for a navigation from the initial
empty document to another same-origin page (note that this is distinct
from the synchronous re-navigation to about:blank noted above).
Finally, this CL does not add the ability to look up a RenderFrameHost
by DocumentToken yet: this CL is already far too large due to the amount
of boilerplate changes required.
Bug: 1362938
Change-Id: I4431ed4a7a0739905579fd1585b2a42701d84d7d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3849601
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Nate Chapin <japhet@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Owners-Override: Nate Chapin <japhet@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1050447}
284c389485