Should the domain of the shared storage script be restricted?

[jkarlin]

Can A.com load a shared storage worklet from a domain other than A.com? This seems to come down to how much you trust the entities on your page. E.g., if the top frame embeds untrusted script, that untrusted script might create worklets that report bogus aggregate data to poison the site's aggregate data.

Generally, the web does not protect documents from embedding scripts that could do terrible things. Should that same precedent apply here?

[jkarlin]

The decision is that the shared storage script's origin must match that of the context that created it. Due to concerns of poisoning and using up the origin's budget. Can revisit later if necessary.

[alexmturner]

Would Access-Control-Allow-Origin be sufficient here to allow servers to control embedding?

[jkarlin]

Thanks for bringing this back up Alex. I do think that header or a similar one to specify that this document is allowed to write to this origin's shared storage or run worklets on its behalf (perhaps separate controls) would provide for significant performance gains (e.g., not having to create an iframe just to write to shared storage).

[xottabut]

Hi Alex, Josh,

I juse tested the next setup:
domain1.com: html page, imitating iframe that requests ad from ad server

... creative html here ...
<script src="domain2.com/register_module.js"></script> // could be just inlined js, same result in the end
... creative html here ...

domain2.com/register_module.js script that registers module to shared storage worklet
...sharedStorage.worklet.addModule("domain2.com/module.js");

This gives an error that same origin expected. Both registration and module itself have configured CORS headers.

So, looks like it is not allowed to host js module under different domain. Which means that it should be always same origin as ad server, which also means reporting origin will be the same as ad server origin.

This is not very convinient for clients as ad serving infrastructure might be controlled by different teams/organisations/departments than reporting infrastructure. Devinding by domain would make sense here.

Would you have any suggestions here?

Thanks,
Anatolii

[alexmturner]

Hi Anatolii,

We appreciate the feedback. Currently, the shared storage worklet script has to be same-origin as the frame it's embedded in. So, you have to create an iframe to run this script on the different origin. However, as Josh said above, we are considering changing this requirement to avoid the performance issue of creating that iframe.

Best,
Alex

[xottabut]

Hi Alex,

thanks for answering. I probably misunderstood the way how it should be setup. I thought when Josh said "e.g., not having to create an iframe just to write to shared storage" it was about iframe on publisher side, but Josh was probably saying about iframe from ad-tech side in iframe from publisher (nested iframe)? Just want to share how I made it work, and probably get some feedback from you and Josh whether this makes sense.

How ad is served now:

1. Publisher (i.e. news.com) have iframe on the page:

<div id="ad..." ...>
  <iframe src="https://ad-exchange-server.com/getAd....." .....>
</div>

2. Ad tech serves the ad from "https://ad-exchange-server.com" so the origin of iframe is https://ad-exchange-server.com

Initially I tried to add registration and run script to html part of the response from https://ad-exchange-server.com. I.e.:

...
await window.sharedStorage.worklet.addModule("https://ads-reports-server.com/module.js");
await window.sharedStorage.run('my-module', {data: input});
...

this was failing because I tried to add js module from https://ads-reports-server.com origin while running it on https://ad-exchange-server.com origin. I also setup a header for ads-reports-server.com/module.js resource:

access-control-allow-origin: https://ads-reports-server.com

hoping that this will solve "same-origin" issue, but as I mentioned in my previous message it didn't.

So when I read through the message from Josh again I added iframe to the response from https://ads-reports-server.com instead of the js code.
Response from https://ads-reports-server.com will look like this now:

<html>
  Ad content here....
  <iframe src="https://ads-reports-server.com/register_module.html" style="display:none;></iframe>
</html>

register_module.html is something like this:

<html>
...
    <script>
      ...
      await window.sharedStorage.worklet.addModule("https://ads-reports-server.com/module.js");
      await window.sharedStorage.run('my-module', {data: input});
      ...
    </script>
...
</html>

Now when inner iframe has same origin as worklet module code - this is working and generates reports with desired reporting origin:

https://ads-reports-server.com/.well-known/private-aggregation/report-shared-storage

For us it is important that we separate reporting and ad serving infrastructure so this approach kind of solves our issues.
Does this make sense? Is this the way it is supposed to be used?
If so, it would be nice to have this in the documentation explaining how to make the setup so script location and reporting origin for the aggregatable reports can be any and should not be limited to ad serving origin (https://ad-exchange-server.com in my example)

Thanks,
Anatolii

[jkarlin]

As noted in the references above, the explainer and spec have been updated with a new capability to create cross-origin worklets directly, without having to first create a x-origin iframe. The worklet script response headers script will need to opt into this with both CORS and a Shared-Storage-Worklet-Allowed: ?1 header. Be careful with this, as it's not your document that is requesting this worklet to run.