Monkey patch for non-cookie storage access #47
Conversation
Co-authored-by: Jeffrey Yasskin <[email protected]>
| [=bounce tracking record/storage access set=]. | ||
|
|
||
| </div> | ||
| 1. Run [=process a navigation storage access for bounce tracking mitigations=] given <var ignore>request</var>. |
There was a problem hiding this comment.
For some reason github is not showing me the steps for this algorithm anywhere, but I can see them in the preview.
The preview says that we are looking at the request's client. I think for this case we actually want reserved client instead:
https://fetch.spec.whatwg.org/#concept-request-reserved-client
The reserved client is the target container for the new document. The client is the container of the document that initiated the navigation. Sometimes they are the same (click a link in a tab to navigate the tab), but sometimes they are different (click a link that opens a new tab).
There was a problem hiding this comment.
This algorithm was already written in the previous PR, it replaces "process a network cookie access for bounce tracking mitigations" since it looks like they're identical.
Makes sense, does that mean we want the same fix for cookie writes as well? It sounds like we should always use the request's "reserved client" when checking the destination navigable.
There was a problem hiding this comment.
"reserved client" is only used for document and iframe requests. Its confusing.
So maybe the cookie access thing needs to check one or the other depending on destination.
SHA: bec418a Reason: push, by wanderview Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
We still need to confirm that "obtain a storage key" and its neighbors are the correct place to patch, which I will follow up on with WHATWG. Pushing this as a description of the algorithm's behavior, while the Storage spec patch location is being finalized.
Preview | Diff