Enable get() in fenced frames with network access revoked.#220
Enable get() in fenced frames with network access revoked.#220wanderview merged 12 commits intoWICG:mainfrom
Conversation
After script running in a fenced frame successfully resolves a call to `window.fence.disableUntrustedNetwork()`, the fenced frame gains access to Shared Storage via `get()`. This patch refactors the `get()` algorithm to be accessible from `Window` and `SharedStorageWorklet` scopes, but the `Window` branch will fail outside of a fenced frame tree with network disabled.
Merge main into read2
VergeA
changed the title
|
Hi @xyaoinum, just wanted to follow up on this, can you give this patch a review when you get a chance? Thanks! |
|
@VergeA My apologies for the delayed review! This LGTM! |
|
Thank you! This is my first Shared Storage spec PR; is there anyone else who I should normally add as a reviewer before we merge? |
|
@wanderview Could you please take a look as well? Thanks! |
| On the other hand, methods for getting data from the [=shared storage database=] are exposed to the {{SharedStorageWorklet}} only, in order to carefully control the flow of data read from the [=shared storage database|database=]. | ||
| On the other hand, methods for getting data from the [=shared storage database=] are exposed to the {{SharedStorageWorklet}} only, in order to carefully control the flow of data read from the [=shared storage database|database=]. The only exception is that {{SharedStorage/get()}} is exposed to {{Window}}, but will only succeed if the result of the [=determine if a navigable has fully revoked network=] algorithm is true. | ||
|
|
||
| Note: The [=determine if a navigable has fully revoked network=] algorithm ensures that {{SharedStorage/get()}} only succeeds for [=fenced frames=] that have successfully resolved a call to {{Fence/disableUntrustedNetwork()}}. |
There was a problem hiding this comment.
Where is the "fully revoked" algorithm defined? I don't see it in this PR or in the existing spec.
There was a problem hiding this comment.
It's defined as a standalone algorithm in the Fenced Frames spec: https://wicg.github.io/fenced-frame/#gating-methods-on-network-revocation
I assumed since the build succeeds that the reference is being linked properly. Is there anything else I should do to clarify where this algo comes from?
There was a problem hiding this comment.
Thanks. I was looking in the shared storage spec!
|
Thanks for the review Ben! I don't have merge permissions on this repo, so could one of you (@wanderview, @xyaoinum) please press the button for me? |
SHA: a1bffbb Reason: push, by wanderview Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
3 participants
After script running in a fenced frame successfully resolves a call to
window.fence.disableUntrustedNetwork(), the fenced frame gains access to Shared Storage viaget().This patch refactors the
get()algorithm to be accessible fromWindowandSharedStorageWorkletscopes, but theWindowbranch will fail outside of a fenced frame tree with network disabled.This patch also specifies a new Permissions Policy,
fenced-unpartitioned-storage-read, which can be used to disable access toget()in fenced frames. Its default allowlist is*.Preview | Diff