Hi Yao,
I see that https://github.com/WICG/shared-storage/pull/152 is
still open, can that be landed before we ship this?
The PR landed just now.
Also, can you point to the tests for this change?
Yes.
cross-origin-worklet-select-url-and-verify-data-origin.tentative.https.sub.html
<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/shared-storage/cross-origin-worklet-select-url-and-verify-data-origin.tentative.https.sub.html> is
a representative one. You can find other relevant tests in the same
repository, by searching for "cross-origin".
Best,
Yao
On Wed, Apr 24, 2024 at 4:02 PM Chris Harrelson
<chris...@chromium.org> wrote:
Thanks for the further explanation! It was very helpful.
LGTM1, but please make sure to land that open PR before shipping.
On Wed, Apr 24, 2024 at 10:48 AM Josh Karlin
<jkar...@chromium.org> wrote:
Hey folks, I wanted to provide a bit more context on this
change to help clarify the intention and any associated risks.
Today, when a third-party script runs on a page and wants to
write data to shared storage, or use their shared storage data
(e.g., create an aggregate report) under its own name, the
script first needs to create a x-origin iframe and pass the
data to that frame. This is because the origin used by shared
storage is that of the context. This is cumbersome to the
developer. They have to create an iframe document to listen
for data (e.g., via name attribute, url query param, or
postMessage) and act on that data (by writing to shared
storage or starting a worklet). It's also terrible for
resource usage and performance (the browser needs to navigate,
load a document, and execute js).
The primary focus of this change is to allow a third-party on
a page to invoke its own worklet (with access to its own
storage) directly, bypassing the need to create a x-origin
iframe. This is accomplished by allowing x-origin urls to be
specified in a new API, `window.sharedStorage.createWorklet
<https://github.com/WICG/shared-storage?tab=readme-ov-file#proposed-api-surface>`.
We are not changing the behavior of addModule, and we are not
changing the capabilities of worklets. We're just making it
easier to create x-origin worklets. In `createWorklet
<https://github.com/WICG/shared-storage?tab=readme-ov-file#proposed-api-surface>`,
if a x-origin URL is specified, the response will require both
`Shared-Storage-Cross-Origin-Worklet-Allowed: ?1` and CORS
(Access-Control-Allow-Origin). That is, embedding a x-origin
worklet is strictly opt-in. This is because a shared storage
worklet has side-effects (e.g., sending reports, or selecting
a url) which also consumes budget, and the worklet's origin
may want to control who gets to use it. They should also
(always a challenge on the web) take care to ensure that the
data that they're receiving from the embedder is valid.
Another useful aspect of introducing `createWorklet`, is that
it allows a document to host multiple shared storage worklets
and call methods on them individually. This makes it easier
for pages that might have multiple teams creating them, that
don't necessarily want to coordinate their shared storage
worklet scripts.
Best,
Josh
On Wed, Apr 24, 2024 at 1:19 PM Josh Karlin
<jkar...@chromium.org> wrote:
On Wed, Apr 24, 2024 at 11:52 AM Alex Russell
<slightly...@chromium.org> wrote:
Hey Josh,
I agree that it might not be helpful to ping Gecko and
WebKit on this, but it would still be helpful to
update the TAG on how this design is evolving.
Ack. I've updated the TAG thread
<https://github.com/w3ctag/design-reviews/issues/747#issuecomment-2075450880>.
From that perspective, I would expect the TAG to
request that we improve consistency by making
cross-origin workers (not just worklets) possible.
Where are we at on that?
Regards,
Alex
On Friday, April 19, 2024 at 12:58:17 PM UTC-7 Josh
Karlin wrote:
On Fri, Apr 19, 2024 at 1:59 PM Vladimir Levin
<vmp...@chromium.org> wrote:
On Fri, Apr 19, 2024 at 12:52 PM Yao Xiao
<yao...@chromium.org> wrote:
*Contact emails*
cam...@chromium.org
jkar...@chromium.org
yao...@chromium.org
rohitgu...@google.com
ashame...@google.com
*Explainer*
https://github.com/WICG/shared-storage
*Specification*
https://wicg.github.io/shared-storage/
*Additional anticipated specification changes*
https://github.com/WICG/shared-storage/pull/152
*Blink component*
Blink>Storage>SharedStorage
<https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3EStorage%3ESharedStorage&can=2>
*Summary:*
We plan to ship the following changes to
the Shared Storage API:
* selectURL() and run() will be exposed
on the SharedStorageWorklet interface.
When calling on the default scoped
worklet (i.e.
sharedStorage.worklet.selectURL()/run()),
the behavior is equivalent to calling
sharedStorage.selectURL()/run().
* Users can create new worklets via
const worklet = await
sharedStorage.createWorklet(url,
options). This API can be used to
start multiple and potentially
cross-origin worklets from a single
document.
*Risks
*
*Interoperability and Compatibility*
The changes are fully backward compatible.
Gecko: No signal
WebKit: No signal
Web developers: No signals
Other signals:
Is it possible to file position requests?
(https://bit.ly/blink-signals)
Was there a TAG review filed for this as well?
Sorry, we should have specified that TAG, Gecko.
and Webkit are negative on shared storage as a
whole. So we did not ask for their opinion on this
particular change.
*WebView application risks*
/Does this intent deprecate or change
behavior of existing APIs, such that it
has potentially high risk for Android
WebView-based applications?
/None
*Security*
Because the worklet's context origin will
be that of the origin of the script URL,
both
"Shared-Storage-Cross-Origin-Worklet-Allowed:
?1" and CORS are required when fetching a
x-origin worklet script. Even so, it is
important that worklet script creators
understand the implications of this. Their
worklet, which accesses their origin's
Shared Storage data, can be loaded and
executed by a different party.
*Privacy*
In the case of creating or using a
cross-origin worklet, if the worklet
cannot be created because the user has
denied storage for that site, then the
promise will resolve (rather than reject)
to prevent leaking cross-site data. A
caller may still use timing attacks to
know this information, but this is a minor
privacy issue, as in reality very few
users would set such preferences, and
doing a wide search would incur a
significant performance cost spinning up
the worklets.
*Debuggability*
* Shared Storage database contents for
an origin can be viewed and modified
within DevTools.
* Shared Storage worklet can be
inspected within DevTools.
*Will this feature be supported on all six
Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)?*
All but WebView
Out of curiosity, why is WebView not supported
for this?
*Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
Yes
*Finch feature name*
SharedStorageAPIM125
*Requires code in //chrome?*
No
*Estimated milestones*
We intend to ship in M125.
*Link to entry on the Chrome Platform Status*
https://chromestatus.com/feature/5145686840705024
--
You received this message because you are
subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop
receiving emails from it, send an email to
blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/41ee180b-5822-40fe-ac15-1bb1c9715e05n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/41ee180b-5822-40fe-ac15-1bb1c9715e05n%40chromium.org?utm_medium=email&utm_source=footer>.
--
You received this message because you are
subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop
receiving emails from it, send an email to
blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2O7c2%2B%2B12PtuAS%2BSfHx0%2B8X6SuA7mr6saW%3DRVhewXkUHw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2O7c2%2B%2B12PtuAS%2BSfHx0%2B8X6SuA7mr6saW%3DRVhewXkUHw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed
to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving
emails from it, send an email to
blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/af749e5f-d3fb-4901-9427-f49efe95410cn%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/af749e5f-d3fb-4901-9427-f49efe95410cn%40chromium.org?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the
Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaPuu4frRrmLq01eAsTAb2fMnQ_rZ3OJoz9dWd%3DVfQQBhA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaPuu4frRrmLq01eAsTAb2fMnQ_rZ3OJoz9dWd%3DVfQQBhA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALYudgV0qYjc9goCzdeSBjQpy0rLTZ2rem_KCWGNBs7MzMH5pQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALYudgV0qYjc9goCzdeSBjQpy0rLTZ2rem_KCWGNBs7MzMH5pQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
