Re: [blink-dev] Intent to Ship: Support Cross-Origin Shared Storage Worklets

[Yao Xiao]

Hi Harley,

This is a demo site for the cross-origin worklet:
https://shared-storage-cross-origin-worklet-demo.glitch.me

Yao


On Tue, May 14, 2024 at 12:20 PM Harley Li  wrote:

> Hello - wondering whether this cross-origin feature reflected in the demo
> website https://shared-storage-demo.web.app/ ? That is, not
> cross-origin-worklet-select-url-and-verify-data-origin.tentative.https.sub.html
> 
>  because
> it still depends on Chromium's testing framework - currently we've run into
> problems when testing the API in DevTools Console, and we think the demo
> website could be of greater assistance. Thanks!
>
> On Monday, April 29, 2024 at 4:43:33 AM UTC-4 Yoav Weiss (@Shopify) wrote:
>
>> LGTM3
>>
>> On Thu, Apr 25, 2024 at 5:57 PM Mike Taylor  wrote:
>>
>>> LGTM2.
>>> On 4/24/24 5:45 PM, Yao Xiao wrote:
>>>
>>> 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
>>> 
>>>  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 
>>> 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 
 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
> `.
> 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
> `,
> 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 
> wrote:
>
>>
>>
>> On Wed, Apr 24, 2024 at 11:52 AM Alex Russell 
>> 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.
>>>
>>
>> 

Re: [blink-dev] Intent to Ship: Support Cross-Origin Shared Storage Worklets

['Harley Li' via blink-dev]

Hello - wondering whether this cross-origin feature reflected in the demo 
website https://shared-storage-demo.web.app/ ? That is, not 
cross-origin-worklet-select-url-and-verify-data-origin.tentative.https.sub.html 

 because 
it still depends on Chromium's testing framework - currently we've run into 
problems when testing the API in DevTools Console, and we think the demo 
website could be of greater assistance. Thanks!

On Monday, April 29, 2024 at 4:43:33 AM UTC-4 Yoav Weiss (@Shopify) wrote:

> LGTM3
>
> On Thu, Apr 25, 2024 at 5:57 PM Mike Taylor  wrote:
>
>> LGTM2.
>> On 4/24/24 5:45 PM, Yao Xiao wrote:
>>
>> 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
>>  
>> 
>>  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  
>> 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  
>>> 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 
 `.
  
 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 
 `,
  
 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  
 wrote:

>
>
> On Wed, Apr 24, 2024 at 11:52 AM Alex Russell  
> 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 
> 
> .
>  
>
>>
>> From that perspective, I would expect the TAG to request that we 
>> improve 

Re: [blink-dev] Intent to Ship: Support Cross-Origin Shared Storage Worklets

[Yoav Weiss (@Shopify)]

LGTM3

On Thu, Apr 25, 2024 at 5:57 PM Mike Taylor  wrote:

> LGTM2.
> On 4/24/24 5:45 PM, Yao Xiao wrote:
>
> 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
> 
>  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 
> 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 
>> 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
>>> `.
>>> 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
>>> `,
>>> 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 
>>> wrote:
>>>


 On Wed, Apr 24, 2024 at 11:52 AM Alex Russell 
 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
 
 .


>
> 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 
>> wrote:
>>
>>>
>>>
>>> On Fri, Apr 19, 2024 at 12:52 PM Yao Xiao 
>>> 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*
 

Re: [blink-dev] Intent to Ship: Support Cross-Origin Shared Storage Worklets

[Mike Taylor]

LGTM2.

On 4/24/24 5:45 PM, Yao Xiao wrote:


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 
 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 
 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
 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

`.
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

`,
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
 wrote:



On Wed, Apr 24, 2024 at 11:52 AM Alex Russell
 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

.


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
 wrote:



On Fri, Apr 19, 2024 at 12:52 PM Yao Xiao
 wrote:

*Contact emails*
cam...@chromium.org
jkar...@chromium.org
yao...@chromium.org
rohitgu...@google.com
ashame...@google.com

Re: [blink-dev] Intent to Ship: Support Cross-Origin Shared Storage Worklets

[Yao Xiao]

>
> 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

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 
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  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
>> `.
>> 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
>> `,
>> 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  wrote:
>>
>>>
>>>
>>> On Wed, Apr 24, 2024 at 11:52 AM Alex Russell 
>>> 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
>>> 
>>> .
>>>
>>>

 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 
> wrote:
>
>>
>>
>> On Fri, Apr 19, 2024 at 12:52 PM Yao Xiao 
>> 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
>>> 
>>>
>>> *Summary:*
>>> We plan to ship the following changes to the Shared Storage API:
>>>
>>>- selectURL() and run() 

Re: [blink-dev] Intent to Ship: Support Cross-Origin Shared Storage Worklets

[Chris Harrelson]

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  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
> `.
> 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
> `,
> 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  wrote:
>
>>
>>
>> On Wed, Apr 24, 2024 at 11:52 AM Alex Russell 
>> 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
>> 
>> .
>>
>>
>>>
>>> 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 
 wrote:

>
>
> On Fri, Apr 19, 2024 at 12:52 PM Yao Xiao  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
>> 
>>
>> *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 

Re: [blink-dev] Intent to Ship: Support Cross-Origin Shared Storage Worklets

[Josh Karlin]

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
`.
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
`,
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  wrote:

>
>
> On Wed, Apr 24, 2024 at 11:52 AM Alex Russell 
> 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
> 
> .
>
>
>>
>> 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 
>>> wrote:
>>>


 On Fri, Apr 19, 2024 at 12:52 PM Yao Xiao  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
> 
>
> *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 

Re: [blink-dev] Intent to Ship: Support Cross-Origin Shared Storage Worklets

[Josh Karlin]

On Wed, Apr 24, 2024 at 11:52 AM Alex Russell 
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

.


>
> 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 
>> wrote:
>>
>>>
>>>
>>> On Fri, Apr 19, 2024 at 12:52 PM Yao Xiao  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
 

 *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
 ?*
 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
 

Re: [blink-dev] Intent to Ship: Support Cross-Origin Shared Storage Worklets

[Alex Russell]

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.

>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  
> wrote:
>
>>
>>
>> On Fri, Apr 19, 2024 at 12:52 PM Yao Xiao  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 
>>> 
>>>
>>> *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 
>>> ?*
>>> 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
>>>  
>>> 
>>> .
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "blink-dev" group.
>> To unsubscribe from this group and 

Re: [blink-dev] Intent to Ship: Support Cross-Origin Shared Storage Worklets

[Chris Harrelson]

On Fri, Apr 19, 2024 at 9:52 AM Yao Xiao  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
> 
>
> *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.
>
> Hi, is it correct to say that these changes are purely ergonomic and don't
expose any new capabilities?


>
>
> *Risks*
> *Interoperability and Compatibility*
> The changes are fully backward compatible.
>
> Gecko: No signal
> WebKit: No signal
> Web developers: No signals
> Other signals:
>
> *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
>
> *Is this feature fully tested by web-platform-tests
> ?*
> 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
> 
> .
>

-- 
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/CAOMQ%2Bw_cs5OWxyw-chqDQpxM4MOQfggrPv1jSkxQiwXoeAGR8A%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Support Cross-Origin Shared Storage Worklets

[Philip Jägenstedt]

Hi Yao,

I see that https://github.com/WICG/shared-storage/pull/152 is still open,
can that be landed before we ship this?

Also, can you point to the tests for this change?

Best regards,
Philip

On Fri, Apr 19, 2024 at 9:58 PM Josh Karlin  wrote:

>
>
> On Fri, Apr 19, 2024 at 1:59 PM Vladimir Levin 
> wrote:
>
>>
>>
>> On Fri, Apr 19, 2024 at 12:52 PM Yao Xiao  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
>>> 
>>>
>>> *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
>>> ?*
>>> 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
>>> 
>>> .
>>>
>> --
>> 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
>> 

Re: [blink-dev] Intent to Ship: Support Cross-Origin Shared Storage Worklets

[Josh Karlin]

On Fri, Apr 19, 2024 at 1:59 PM Vladimir Levin  wrote:

>
>
> On Fri, Apr 19, 2024 at 12:52 PM Yao Xiao  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
>> 
>>
>> *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
>> ?*
>> 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
>> 
>> .
>>
> --
> 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
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails 

Re: [blink-dev] Intent to Ship: Support Cross-Origin Shared Storage Worklets

[Josh Karlin]

On Fri, Apr 19, 2024 at 3:49 PM Mike Taylor  wrote:

> On 4/19/24 12:52 PM, Yao Xiao 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
>
> Would it be possible to write a paragraph on this specific change, i.e.,
> what are the use cases this change addresses, and how does this help
> developers, etc.? Here in the thread is fine.
>

Sure thing. Shared Storage worklets are often run as third-party to a page.
It's cumbersome to have to first create a x-origin iframe for the
third-party, load a document, and only *then* get to start the worklet.
This uses unnecessary resources and time. The primary purpose of this
change is to make it possible to invoke a cross-origin worklet directly
from the main frame of a page. It requires CORS and an additional opt-in
header on the response header of the worklet script to do so.



>
> *Specification*
> https://wicg.github.io/shared-storage/
>
> *Additional anticipated specification changes*
> https://github.com/WICG/shared-storage/pull/152
>
> *Blink component*
> Blink>Storage>SharedStorage
> 
>
> *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:
>
> *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
>
> *Is this feature fully tested by web-platform-tests
> ?*
> 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
> 
> .
>
> --
> 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/bf885085-5e5c-44f2-ae6f-9ae7daf3bc22%40chromium.org
> 
> .
>

-- 
You received 

Re: [blink-dev] Intent to Ship: Support Cross-Origin Shared Storage Worklets

[Mike Taylor]

On 4/19/24 12:52 PM, Yao Xiao 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


Would it be possible to write a paragraph on this specific change, i.e., 
what are the use cases this change addresses, and how does this help 
developers, etc.? Here in the thread is fine.




*Specification*
https://wicg.github.io/shared-storage/

*Additional anticipated specification changes*
https://github.com/WICG/shared-storage/pull/152

*Blink component*
Blink>Storage>SharedStorage 



*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:

*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

*Is this feature fully tested by web-platform-tests 
?*

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 
.


--
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/bf885085-5e5c-44f2-ae6f-9ae7daf3bc22%40chromium.org.

Re: [blink-dev] Intent to Ship: Support Cross-Origin Shared Storage Worklets

[Vladimir Levin]

On Fri, Apr 19, 2024 at 12:52 PM Yao Xiao  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
> 
>
> *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?


>
> *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
> ?*
> 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
> 
> .
>

-- 
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.

[blink-dev] Intent to Ship: Support Cross-Origin Shared Storage Worklets

[Yao Xiao]

*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 


*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:

*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

*Is this feature fully tested by web-platform-tests 
?*
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.