-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spec update: Support multiple & cross-origin worklets #131
Conversation
- selectURL() and run() will be exposed to the shared storage worklet object. When calling on the default scoped worklet (i.e. sharedStorage.worklet.selectURL()/run()), the behavior is equivalent to sharedStorage.selectURL()/run(). - Users can create new worklets via `const worklet = await sharedStorage.createWorklet(url, options)`. This can be used to start multiple and potentially cross-origin worklets from a single document. - User settings error won't be exposed to the caller (i.e. will be treated as success) in the case of creating or using a cross-origin worklet. This is to prevent leaking user's settings for an arbitrary site.
@pythagoraskitty: PTAL. Thanks! (After it's looking okay from your end, I will also request review from a spec mentor.) |
Suggest we move the {#reporting} and {#budgets} subsubsections of {#window} up to be subsections of the {#worklet} section instead. I have no strong preference about the ordering within that section, but you could probably just tack them on the end of it after {#scope-algo}. |
I've looked at most, except need to give a closer read to the new versions of Hopefully will get to in the next couple of days. Otherwise looks good % comments. |
Finished checking. Looks good % comments. :) |
Thanks Cammie. I did some more changes around dividing the permissions checks, as explained in the comment above. PTAL again! @domfarolino : PTAL from the spec's perspective. Thanks! |
For the sharedStorage.createWorklet() API, relax the restriction to allow cross-origin script, in which case a cross-origin worklet will be created. We leverage the existing process allocation and management logic from service workers and directly re-use SiteInstanceImpl::CreateForServiceWorker(). To keep this CL focused, renaming will occur in a separate CL, as it involves renaming other downstream components like 'UnmatchedServiceWorkerProcessTracker'. Explainer: WICG/shared-storage#130 Spec: WICG/shared-storage#131 Design doc: https://docs.google.com/document/d/1QTaaroCMeFVZVghI6JkUcDvmDQEacjvpyTfk6mpvQhA/edit?usp=sharing&resourcekey=0-dqfVkB2DJcTzHLfJkern0Q Bug: 325302836 Change-Id: I11c1fc87bc76f4400c54d9fa809349d1d1781247
For the sharedStorage.createWorklet() API, relax the restriction to allow cross-origin script, in which case a cross-origin worklet will be created. We leverage the existing process allocation and management logic from service workers and directly re-use SiteInstanceImpl::CreateForServiceWorker(). To keep this CL focused, renaming will occur in a separate CL, as it involves renaming other downstream components like 'UnmatchedServiceWorkerProcessTracker'. Explainer: WICG/shared-storage#130 Spec: WICG/shared-storage#131 Design doc: https://docs.google.com/document/d/1QTaaroCMeFVZVghI6JkUcDvmDQEacjvpyTfk6mpvQhA/edit?usp=sharing Bug: 325302836 Change-Id: I11c1fc87bc76f4400c54d9fa809349d1d1781247
For the sharedStorage.createWorklet() API, relax the same-origin restriction to allow cross-origin script, in which case a cross-origin worklet will be created. How: - Rely on CORS for the worklet to be loaded/used by the embedder. - Leverage the existing process allocation and management logic from service workers and directly re-use SiteInstanceImpl::CreateForServiceWorker(). To keep this CL focused, renaming will occur in a separate CL, as it will involve renaming other downstream components like 'UnmatchedServiceWorkerProcessTracker'. Explainer: WICG/shared-storage#130 Spec: WICG/shared-storage#131 Design doc: https://docs.google.com/document/d/1QTaaroCMeFVZVghI6JkUcDvmDQEacjvpyTfk6mpvQhA/edit?usp=sharing Bug: 325302836 Change-Id: I11c1fc87bc76f4400c54d9fa809349d1d1781247
@domfarolino : friendly ping! Also adding @wanderview as an alternative reviewer, who may be able to cover the review this week when Dominic is OOO. Thanks! The idea is to make the spec good enough to unblock launch. We can track non-blocking issues separately if applicable. |
For the sharedStorage.createWorklet() API, relax the same-origin restriction to allow cross-origin script, in which case a cross-origin worklet will be created. How: - Rely on CORS for the worklet to be loaded/used by the embedder. - Leverage the existing process allocation and management logic from service workers and directly re-use SiteInstanceImpl::CreateForServiceWorker(). To keep this CL focused, renaming will occur in a separate CL, as it will involve renaming other downstream components like 'UnmatchedServiceWorkerProcessTracker'. Explainer: WICG/shared-storage#130 Spec: WICG/shared-storage#131 Design doc: https://docs.google.com/document/d/1QTaaroCMeFVZVghI6JkUcDvmDQEacjvpyTfk6mpvQhA/edit?usp=sharing Bug: 325302836 Change-Id: I11c1fc87bc76f4400c54d9fa809349d1d1781247
For the sharedStorage.createWorklet() API, relax the same-origin restriction to allow cross-origin script, in which case a cross-origin worklet will be created. How: - Rely on CORS for the worklet to be loaded/used by the embedder. - Leverage the existing process allocation and management logic from service workers and directly re-use SiteInstanceImpl::CreateForServiceWorker(). To keep this CL focused, renaming will occur in a separate CL, as it will involve renaming other downstream components like 'UnmatchedServiceWorkerProcessTracker'. Explainer: WICG/shared-storage#130 Spec: WICG/shared-storage#131 Design doc: https://docs.google.com/document/d/1QTaaroCMeFVZVghI6JkUcDvmDQEacjvpyTfk6mpvQhA/edit?usp=sharing Bug: 325302836 Change-Id: I11c1fc87bc76f4400c54d9fa809349d1d1781247
For the sharedStorage.createWorklet() API, relax the same-origin restriction to allow cross-origin script, in which case a cross-origin worklet will be created. How: - Rely on CORS for the worklet to be loaded/used by the embedder. - Leverage the existing process allocation and management logic from service workers and directly re-use SiteInstanceImpl::CreateForServiceWorker(). To keep this CL focused, renaming will occur in a separate CL, as it will involve renaming other downstream components like 'UnmatchedServiceWorkerProcessTracker'. Explainer: WICG/shared-storage#130 Spec: WICG/shared-storage#131 Design doc: https://docs.google.com/document/d/1QTaaroCMeFVZVghI6JkUcDvmDQEacjvpyTfk6mpvQhA/edit?usp=sharing Bug: 325302836 Change-Id: I11c1fc87bc76f4400c54d9fa809349d1d1781247
@domfarolino friendly ping. Thanks! (Note also that I just updated this patch to include a "Shared-Storage-Worklet-Allowed: ?1" response header check, which was based on a security review feedback (i.e. relying solely on CORS isn't considered safe enough)). |
…e header check When creating a cross-origin worklet, require the "Shared-Storage-Worklet-Allowed: ?1" response header, or the request should fail (similar to the handling for CORS failure). Note that shared storage worklet request doesn't allow redirects, so it's sufficient to check inside `OnReceiveResponse` only. PR: WICG/shared-storage#131 Bug: 332564979 Change-Id: I6c2a07473527ede995cf4bd337d293f3168351bb
…e header check When creating a cross-origin worklet, require the "Shared-Storage-Worklet-Allowed: ?1" response header, or the request should fail (similar to the handling for CORS failure). Note that shared storage worklet request doesn't allow redirects, so it's sufficient to check inside `OnReceiveResponse` only. PR: WICG/shared-storage#131 Bug: 332564979 Change-Id: I6c2a07473527ede995cf4bd337d293f3168351bb
…lowed response header check When creating a cross-origin worklet, require the "Shared-Storage-Cross-Origin-Worklet-Allowed: ?1" response header, or the request should fail (similar to the handling for CORS failure). Note that shared storage worklet request doesn't allow redirects, so it's sufficient to check inside `OnReceiveResponse` only. PR: WICG/shared-storage#131 Bug: 332564979 Change-Id: I6c2a07473527ede995cf4bd337d293f3168351bb
Can you separate out the header code from this PR to review separately? I just want to avoid piling more things onto this CL which is already massive and difficult to review. |
Btw has #131 (comment) been address anywhere? I don't see a way to respond to it directly right now, but I can't tell if it has been addressed or commented on really. Edit: Yes it has, per #131 (comment). |
- Addressed review comments - Took out the header change, to make this patch shorter
@domfarolino I addressed the comments, and took out the header part to make this patch smaller. PTAL again. Thanks! Also, responding to your comments below that I'm unable to respond inline: For comment #131 (comment): I updated it to [=shared storage navigation budget charged=]" which I feel is more clear. For #131 (comment): Yes it's been addressed. The location is: "1. If |options|[" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nothing too major structurally-speaking, which is good. This will probably be the last substantial pass.
spec.bs
Outdated
|
||
- For each method under [[#window-setter]], |environment| is the current context, and |origin| is |environment|'s [=environment settings object/origin=]. | ||
- For creating a worklet, |environment| is the [=environment settings object=] associated with the {{Window}} that created the worklet, and |origin| is the module scirpt url's [=url/origin=]. | ||
- For initiating (from a {{Window}}) and for running (from {{SharedStorageWorkletGlobalScope}}) operations on a worklet, |environment| is the [=environment settings object=] associated with the {{Window}} that created the worklet, and |origin| is the worklet's [=global scopes=][0]'s [=global object/realm=]'s \[[HostDefined]] field's [=environment settings object/origin=]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for running (from
SharedStorageWorkletGlobalScope
)
Is this why step 6 of https://pr-preview.s3.amazonaws.com/WICG/shared-storage/pull/131.html#determine-whether-shared-storage-is-allowed-by-context asserts that the current global might be a SharedStorageWorkletGlobalScope
? I guess that confuses me a little bit: does it mean that a shared storage worklet can create new shared storage worklets? I certainly don't think so, but just want to triple check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ack that this was indeed confusing. I updated it to "For running operations on a worklet (from a {{Window}}), and for each method under [[#worklet-setter]] (from {{SharedStorageWorkletGlobalScope}}), ..."
@domfarolino I've addressed / responded to your comments. PTAL again. Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK I think we've addressed the meat of worklet internals with the previous reviews here so far, so I'm happy moving forward with this due to the urgency of this work, and thank you very much for sticking with it as well as filing the follow-up issues for the small remaining things that can be addressed separately.
Please send PRs soon to fix the following:
- [spec] "name" and "operationCtor" parameter cannot be missing during register() #151
- [spec] Move the call [=charge shared storage reporting budget=] to the fenced frame spec. #150
- [spec] Add boolean "shared storage navigation/reporting budget charged" to [=fenced frame config instance=] #149
- [spec] Move the definition of [=pending shared storage budget debit=] to [=fenced frame config instance=] #148
- [spec] Many definitions under "Entropy Budgets" section needs improving #147
- Window setter/deleter methods don't match up with any Web IDL #146
- [spec] Add "sharedstorageworklet" destination to RequestDestination #145
- Use of
function
is wrong in the operation map definition #135 - Use of
object
is wrong in theregister()
method #134
More smaller PRs would be better than larger PRs combining the issues above.
1. Let |globalScope| be [=this=]'s [=global scopes=][0]. | ||
1. Let |workletOrigin| be |globalScope|'s [=global object/realm=]'s \[[HostDefined]] field's [=environment settings object/origin=]. | ||
1. If the result of running [=Is feature enabled in document for origin?=] on "[=PermissionsPolicy/shared-storage-select-url=]", |document|, and |workletOrigin| returns false, return a [=promise rejected=] with a {{TypeError}}. | ||
1. If [=this=]'s [=global scopes=] is [=list/empty=], then return a [=promise rejected=] with a {{TypeError}}. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, you're saying selectURL() cannot be called after createWorklet() then, right?
Thanks for the thorough review @domfarolino . (For the last few comments, I think you might looked at an outdated version of the patch? The comments in question should have already been addressed.) |
…ader check This is a follow-up patch for #131. For starting a cross-origin worklet, this response header is needed.
Applies to issue #2 |
const worklet = await sharedStorage.createWorklet(url, options)
. This can be used to start multiple and potentially cross-origin worklets from a single document.Preview | Diff