Hi!
After reading this proposal, this seems to be fairly close to the FLEDGE proposal ( https://github.com/WICG/turtledove/blob/main/FLEDGE.md ) that is being currently implemented in Chromium.

Can you please shed light on how you see both proposals interacting ?
In particular, should we understand that both proposals are "compatible" ? By this I mean, would a Fledge bidding worklet be able within its own worklet to call sharedStorage.get(key) ? (this worklet would be a "fledge" auction worklet and not a "shared-storage" worklet)

This seems necessary since the caller has no idea when the worklet finishes, so how can it know when it can navigate away from the page, unless it’s confident that the worklet will continue to run after the navigation?

We’d need a timeout. How long should it be?

Currently, the run() and selectURL() steps in the spec uses the return promise resolving as the signal to maybe terminate the global scope. But, the promise is immediately resolved (to avoid leaks). So, we need a new signal to trigger this case.

In the definitions of run() and selectURL(), it says "If addModule() has not yet been called, [error]". To align with the implementation, this should probably be modified to something like "If addModule()'s returned promise has not yet resolved"? (i.e. we need to wait for the module script execution to complete first)

Currently, the method for querying the number of keys stored for an origin is called length(). Perhaps a better name would be numKeys() or keyCount().

Hello,
trying out sharedStorage.selectURL as in example:
https://github.com/WICG/shared-storage#simple-example-consistent-ab-experiments-across-sites

using resolveToConfig: true, doesn't return FencedFrameConfig but just resolves as opaque URN.

Is there anything else that needs to be enabled to test this feature?

We are excited about the shared storage API and its support of Reach measurement.

Given that Reach is a fundamental metric of brand advertising and that accurate assessment of ad campaign efficiency requires accurate and flexible reach measurement, we would like to request that shared storage API extends its functionality to support advanced scenarios of reach measurement in a privacy safe manner. In particular, it is important that the system scales to thousands of advertisers pulling interactive exploratory reports on the ongoing and finished campaigns daily. We believe high utility for Reach advertisers should be achievable with reasonable privacy budget settings.

Privacy Sandbox is critical for maintaining high quality of reach measurement. In the absence of features of the privacy sandbox discussed below the reach modeling could use domain partitioned cookies as a signal, however lack of cross-domain deduplication signal poses a huge challenge for unique user count deduplication. It is unclear when and if technology of sufficient quality using domain partitioned cookies can be developed. Furthermore development of such technology could potentially pose an extra risk on user privacy, as accurate cross-domain deduplication done in the clear context (compared to on-device nature of Chrome Privacy Sandbox) may have negative effects on user privacy.

Specifically the following functionality is critical to make sure that important reach reporting scenarios can function with high quality while being powered by the shared storage.

1. Availability of the secure report in the context of the event. The explainer states:

The report contents (e.g. key, value) are encrypted and sent after a delay.

This means that users of the system have to pre-define reporting segments before the ads are served, however, modern advertising reach reporting and optimization use cases enable interactive slicing of the traffic on various criteria directly linked to the event context, such as reporting time window, device type, time of day, location, etc.

Additionally, encoding all of these options into the key rather than creating reports on-demand would put unnecessary strain on the privacy budgets.

On the other hand, it should be possible to add sufficient levels of noise on the final aggregates on demand, to ensure high standards of privacy protection without sacrificing the flexibility of reach slicing without requiring delayed reporting, which further limits the freshness of reporting capabilities.

Therefore we would request you to kindly consider the following approach:

Allow the aggregated report entity to be available immediately in the page javascript context so that at a later time the ad tech would have an option to upload a batch of the reports for further aggregation. Since aggregated reports are returned unconditionally for each impression, its arrival does not provide any extra information for ad-tech.

Since the final aggregated report would have a differentially private noise and appropriate privacy budget tracking, this option would maintain high privacy protection standards. Meanwhile it would keep the reach slicing flexibility that modern reach reporting flows rely upon now.

Alternatively the report could still be returned with a delay, but be accompanied with an event level identifier that would allow it to be joined to the original event.

2. Enable count_distinct secure aggregation function. So far the explainer only mentions sendHistogramReport function for sending the reports.

The histogram report appears to be insufficient for implementation of Virtual People technology in the privacy sandbox. This technology is used by Google and the Cross-Media Measurement project.

Aggregating Histogram with per-bucket noise is insufficient, because each browser gets mapped to a virtual person and the count of virtual people rather than browsers is important. Histogram is good for counting unique browsers by some partitions, but is incapable of counting unique virtual people.

IAB Audience reach measurement guidelines page 4 reads: "deriving unduplicated audience reach people-based measures from digital activity and other research is the most difficult of the metrics however, it is also inherently the most valuable to users of measurement data."

Providing the count_distinct aggregation function would be enabling a natural implementation of the Virtual People technology and proper differential privacy noise is capable of ensuring high privacy protection standards.

The count_distinct can be implemented for the buckets of the histogram, so that no new type of report would be required.

To support demographic composition and frequency scenario it should be possible to filter histogram buckets based on index and on the range of the value.

3. Enable pre-aggregation of the reports for further quick combination at serving time with low latency.

Interactive reports are critical to an advertiser's ability to understand the reach of the campaigns that they are running.

To enable interactive exploration the aggregation API would need to provide the ability to pre-aggregate histograms and return an intermediate data structure result encrypted. Then such intermediate reports could be pre-aggregated for atomic reporting units and reach for a collection of reporting units extracted at real time when report is required.

4. Enable combining reports with first party reports.

Campaigns could be running with some events served on first-party sites, while others on 3rd parties. One way to get deduplicated reach of such campaign accurately would be to let the secure aggregation server to digest histogram that is constructed by the ad-tech in the clear, along with pre-aggregated encrypted histogram.

5. Secure aggregation should be scaling to impression-level reports.

Each ad impression would be emitting a reach report and secure-aggregation infrastructure should be scalable to large volumes to make sure that the reach use-case is supported.

Again, thank you very much for providing this flexible privacy safe api and thank you very much for your consideration.

Website can read their's process memory via Spectre with various bandwidth depending on crossOriginIsolation, platforms and flags.
See: https://leaky.page/

It would be nice documenting what are the measure taken to prevent communication in between:

• The worklet that can read the unpartitioned storage, but have no capabilities to exfiltrate the data, outside of the two controlled ones (opaque URLs, aggregated reporting API)
• The document/worker that can't read the unpartitioned storage, but has the capabilities to exfiltrate the data (network access).

We have filed a bug to add a setting in the Chrome Privacy Sandbox Settings (chrome://settings/privacySandbox) that would toggle whether Shared Storage was enabled or not, so that a user could disable it. But we haven't worked out exactly what it means for Shared Storage to be disabled.

Does this mean that the API is not available? Or that the API is available, but that all promises are rejected? Or that the API is available, promises are resolved and rejected almost as usual, with the caveat that resolved promises are dummy/null values undetectable to the caller?

In any case, when Shared Storage is disabled, we should not actually store data in or read data from the backend database. Probably this database shouldn't exist anymore and should be wiped at the moment that the user disables Shared Storage. We already have prototype code for clearing the Shared Storage database based on user initiation through Site Settings.

If at some point the user re-enables Shared Storage, then the database can be re-created.

Synchronization

Given that set and append are synchronous, they could create a side channel exposing if a value is currently set or not, at least if naively implemented. (e.g. if setting a value takes different times based on its presence or lack-there-of)
I think it's worthwhile to point that out (e.g. in a note), to ensure implementations are performing the actual setting/appending in an async fashion.

Some origins may want to split the Shared Storage worklet operations that they want to register into multiple module files.

Does the current design allow for calling window.sharedStorage.worklet.addModule multiple times in the same context, one for each different module? If so, do the calls get fullfilled in series or in parallel?

If the latter, are there any potential race conditions that we need to consider?

The retention policy in the explainer mentioned that data will be cleared after 30 days after creation, on a per-origin basis. This is not ideal for use cases that needs a persistent storage for longer than 30 days. I would suggest two changes:

1. Instead of per-origin retention, we should make the retention per-entry or per-key. Each origin can store many key/values for different use cases. Those key/value can be written at different time and accessed at different cadences. It doesn't make sense to make all entries to share the same retention as the very first entry which created the database. Imagine that you want to write a new entry to a database of an origin that was created 29 days ago. Even knowing that this new entry has only 1-day lifetime (you can learn it from the worklet), there is no way to extend the databased's expiration date.

2. 'touch' an existing entry with set(, { ignoreIfPresent: true }) (maybe even with sharedStorage.get()) should extend the expiration date of that entry for another 30 days. This will make sure we only clear the entries that are not actively accessed.

I assume you mean to check for failure. If you actually meant validity you need something else. (Note that implementations sometimes confuse "validity" with "can parse" so you can't really rely on them.)

I'm adding this comment in response to the conversation today in the Improving Web Advertising BG about transparency for users. I support being as transparent as possible with users - and also giving them a way to act upon the information given to them. However, I think we should consider whether the transparency would be more useful if it was more about the source of the data than it is about how it's used. In other words, more "data was collected about you when you visited site X" and less trying to say "you got this ad because you visited site X". My reason is that the logic for how particular data is used isn't necessarily going to be straight forward enough to make much sense on the surface.

For example, I know of an ad campaign for probiotic supplements that was being targeted to people who bought breakfast cereals, soups, canned fruits, or non-diet sodas. Telling a user they're receiving an ad for probiotics because they bought a bottle of coke or lucky charms might not make much sense to them. The logic, btw, is that people who eat foods with high-fructose corn syrup in them likely have a greater need for probiotics. When things like KNN clustering is used, the logic can seem even more mysterious - since it's more about correlation than causation.

In that case, it might be more useful to users if this type of disclosure followed what Amazon does with their recommendations. On the recommendations page, they don't tell you why a particular product is being listed (but you can stop the item from being recommended). Instead, they let you improve the recommendations by letting you decide which products should be used or not. That might be a better user experience than trying to tell users you were recommended this movie because you bought this particular shirt last month.

Anyway, just something to consider.

Hi,

My understanding is that FLEDGE and TURTLEDOVE include the support of contextually-targeted ads, that do not need to be rendered in a fenced frame.

A given ad campaign could then be running on contextual signals only, or on both interest-based (TURTLEDOVE/FLEDGE) and contextual data, depending on the result of each ad request. Doing A/B testing on these types of campaigns is an important use case.

How could these use cases be supported by Shared Storage, without having to render contextual ads in a fenced frame?

The Protected Audience API (aka Fledge) runAdAuction call returns null or is opaque. Similarly the selectURL call response is opaque, with both intended to be rendered in a fenced frame. Unfortunately, using both APIs together seems impractical.

Consider the frequency capping use-case. Note first that the ATPs involved need to decide ahead of time that they want to use the APIs, without knowing whether the user has any relevant interest groups or any relevant frequency capping data in sharedStorage. The outputs of the two calls correspond to ads with different bids. Since the outputs are opaque, it is not possible in general to know how the bids compare, or which opaque output should be preferred. It may be possible to know or predict in some cases; however this seems like a significant gap.

Should it be possible to feed the output of one API into the other in a way that would make selecting based on the maximum bid possible?

runURLSelectionOperation() allows the caller to choose arbitrary URLs to put into the resulting Fenced Frame. Those urls might include 1p identifiers. Which would then mean the fenced frame has a 1p identifier plus a few bits of cross-site data (from the selection operation). If the Fenced Frame has unrestricted network access, then the Fenced Frame can trivially leak the combination of the 1p identifier and those few bits of information.

So, either we don't allow the FF (fenced frame) to have unrestricted network access, or we make sure that the input data to the fenced frame isn't 1p identifying. It seems like it might be easier to make the data not be user identifying, and an approach for that would be to make sure the input is k-anonymous, as is done for FLEDGE.

Note that the notion of using k-anonymity for input urls is also discussed #14.

There are lots of ways that this API can be abused by bad actors or by competitors. This is more general that the specific issues identified in #2.

The clear() call is very destructive, because it clears all keys for all domains; a site should not be able to clear the keys registered by all other sites. In general this should only be initiated by the user themselves when the user wants to do the equivalent of clearing all third-party cookies. You could modify the API to require the add() and update() calls to include a domain. Clear() would also require a domain and only clear keys associated with that domain. This doesn't prevent a company from deleting its competitor's keys, but it at least makes it so that someone trying to clear their own keys doesn't unintentionally clear those of others.

Today, a domain cannot view/set/modify/delete the cookies of its competitors, because it does not have access to these third-party cookies. However, with this API, anybody can set/modify/delete any keys that they desire. For example, a company can mess with its competitors A/B tests simply by calling
sharedStorage.set("competitor key", non-random-value, {ignoreIfPresent: false})
With this they can assign everyone to the A side of the test or randomly switch them every time they visit a site running their code, invalidating their competitor's A/B testing.
This attack could be made more difficult if the set() call supported an option, noUpdates, which if true means that the key, once set, can never be modified. If the competitor sets the value before the owning company, they may still skew the results, but they will not be able to break any test where the user has already been assigned a value.

Another option for the A/B use case would be to only support setting the seed within the SelectURLOperation() call and require that all URLs passed to the call share the same domain. Then the seed can be tied only to that domain and only available for use in future SelectURLOperation calls for that same domain.

I just had a read through of the explainer, which standards group will it be discussed in? What’s the track for it to be discussed in the open & receive feedback from the wider web creator and browser community?

The <pre class="anchors"> section is huge and includes lots of terms whose <dfn> includes data-export. (e.g. https://html.spec.whatwg.org/multipage/webappapis.html#relevant-settings-object, https://html.spec.whatwg.org/multipage/nav-history-apis.html#window-bc, https://url.spec.whatwg.org/#concept-url-origin) You should delete those because having a custom anchor for a term prevents the term from following moves in the source document.

For non-exported terms in web specs, it's best to file an issue or PR asking to export the term. Sometimes the editor will point out a better way to integrate with their spec.

Our API surface consists of asynchronous methods. Their behavior may lead to race conditions if developers are not fully aware of what guarantees, if any, can be made about how they work.

What kinds of things can be said about the following situations, for example?

• What happens if runOperation is called after runOperation? Do they run in series? parallel? Are they guaranteed to run in the order they were called in?
• If I call set, and then call runOperation on the next line, am I guaranteed that the set will complete before the next read operation happens in the runOperation?

Since shared storage is cross-site data, just knowing the size of your origin's shared storage database could leak significant information. Therefore, Shared Storage is not quota managed, and the size of the origin's database is not web exposed.

Because it's not quota managed, we've put a cap on the size of each origin's shared storage database. But we enforced that cap by limiting the key and value lengths, and the number of possible keys. In retrospect that seems overly constraining to me, when we could instead just have a single size limit for the origin that we enforce, allowing developers to use that space as they see fit.

Any thoughts or comments on making such a change? I don't have anyone asking for this change right now so it's not high priority, but would be interested to hear from folks.

So recently our team got hit by the Storage Partitioning flag rollout in the latest Chrome versions, which broke our mechanism of cross tab communication via Local Storage events.
We have a setup where site a.example.com embeds an iframe from site b.example.com. We have a mechanism where user action on site a.example.com opens a new browser tab in the b.example.com domain. Previously we were relying on Local Storage events for communication between those two tabs, but now, due to storage partitioning, it's no longer possible.
It seems that Shared Storage is designed to have secured cross-site unpartitioned storage, but searching through documentation I haven't found if we are able to use some like Storage Events with Shared Storage. Does it sound like Shared Storage is capable of helping in my case? Thanks in advance!

An iFrame that uses its own localstorage, with a source that is different from the domain of the website it is contained, will be blocked by the 2024 third party cookies proposal by chrome, even if the iFrame do not read or use any content of the parent's storage.

My question is, will sharedstorage solve the problem and how?
From what i've understood, the shared storage API (together with fenced frames) allows this particular behaviour between sites and content frames that only requires a private storage for storing data.

The SharedStorageWorkletGlobalScope IDL should expose a readonly attribute SharedStorage sharedStorage; This might need to be a WorkletSharedStorage -- but we'd need to ensure alignment with the implementation as that currently handles the differences between windows and worklets by using [Exposed=] markers on each individual function

Hi! I'm really excited to see that this Shared Storage API proposal is trying to create a solution for cross-site experiments. However the current proposal seems best suited for experimenting on within-browser changes, such as additional filtering after an ad network has already delivered an ad. We're strongly interested in enabling user-consistent cross-site server-side experiments, such as controlling whether a new ad format type would even be included in the initial server-side auction, or changing how an ad creative is rendered before it's sent to the browser.

Are there options here to expand this design to better suit server-side experiments (or possibly even experiments with simultaneous client and server-side changes)? There's a very large number of different types of filtering and logic that happens on server-side, so we'd really appreciate a solution that can scale well to a variety of use cases.

If you're uncertain about requirements, here's a few of ours that may be helpful as you think about this:

• Experiments are about comparing aggregated metrics across groups of users, we do not need nor care about identifying individuals within the groups. This means we are happy with solutions that are k-anonymous, and we can work with relatively high sizes of k.
• We are okay with some level of noise being added to the user consistency. User bucketing signals available on the web today are already somewhat noisy.
• Needs to scale to at least O(hundreds) of experiments/groups, but we prefer O(thousands).

As a potential starting point idea for you to consider, if you're able to allow third-parties access to a k-anonymous, random bucket ID that's user-sticky and consistent across sites, this would allow us to run cross-site experiments. Each 3rd party (e.g. the ad network) would want an independent user-to-bucket grouping so they don't influence one another's metrics, and that should also benefit the user by making it harder to identify common users across different 3rd parties. It'd be nice if the number of bucket IDs available to a 3rd party was proportional to the traffic the party receives since anonymity is closely tied to the underlying population - e.g. 1 bit can be identifying if you have 2 users, but it's not identifying if it's evenly split among 1000 users. I haven't fully thought through all the attack vectors and privacy implications here so I imagine this rough idea will need improvement. Please let me know if there's further details you'd like to discuss, and thanks for your time.

@jkarlin We were talking about this spec internally and realized that a couple of us had different interpretations on what would be allowable within the stored keys and values. I'm under the impression that keys and values can be arbitrary strings, and we can run arbitrary code over those strings to produce values for the Aggregate Reporting API.

For example, let's take as a use case that advertisers wish to understand their sales cycle better, and want to measure the average time from first impression served to conversion. Could we do something like (pardon my pseudo-JS/python mix):

function getTimestamp() { … }
await window.sharedStorage.worklet.addModule("timetoconversion.js");

// At impression time
window.sharedStorage.set("conversion-timestamps", getTimestamp() + "-", {ignoreIfPresent: true});

// At conversion time
window.sharedStorage.append("time-to-conversion", getTimestamp());
await window.sharedStorage.runOperation("time-to-conversion");

With timetoconversion.js containing:

class SendTimeToConversionReportOperation {
    timestamps = await this.sharedStorage.get("conversion-timestamps");
    t1, t2 = timestamps.split("-");
    time = int(t2) - int(t1);

    this.createAndSendAggregatableReport({
      operation: "sum",  // sum all time delays so we can compute an average later
      key: "time-to-conversion",
      value: time
  }
}
registerOperation("time-to-conversion", SendTimeToConversionReportOperation);

Does this make sense? Thanks in advance for any guidance!

We are soliciting feedback on the following proposal:

We propose removing the requirement that input URLs for sharedStorage.selectURL() be k-anonymous.

Given that we currently have event-level reporting, we believe a k-anonymity requirement would be of limited benefit and not worth the associated financial, performance, and utility costs.

Instead, each page load would have two entropy-bit budgets: an overall page budget and a per-origin page budget. These budgets are in addition to and separate from the daily budget for navigation.

Each time selectURL() is called during that page load, log2(num_urls) would be charged to both the overall budget and the per-origin budget for the caller's origin, as long as there is sufficient budget remaining in both. If either budget has insufficient remaining budget, then the default URL is returned for selectURL() and no budget charges are made.

We plan to use 12 bits as the page-load overall budget, and 6 bits as the page-load per-origin budget.

Handling inactive/detached documents

The spec right now unconditionally assumes that a Window's browsing context is non-null: example, example, example, more.

In order to handle the detached frame case:

const win = iframe.contentWindow;
iframe.remove();
win.SharedStorage.set()/append()/foo();

... and not crash, we have to bail-out early from algorithms that should not operate in this case. You can do this by detecting the null browsing context as you are, but then you miss the bf-cache case as well, so your best bet is to try and detect non-fully active documents as described by https://w3ctag.github.io/design-principles/#support-non-fully-active. Here is a good example usage: https://w3c.github.io/permissions/#dom-permissions-query of this.

Nothing defines how the shared storage interface is exposed

At least I don't think anything defines this. The examples in the Introduction show usage of window.sharedStorage, but I don't see the sharedStorage member actually being defined on the Window interface (if I'm just missing it, forgive me). The closes I see is in https://wicg.github.io/shared-storage/#shared-storage-interface which defines that the interfaces are "exposed" on Window, stops short of defining a name and getter. I think you can fix this by adding something similar to https://wicg.github.io/fenced-frame/#window-extension, where we define how the Fence interface is exposed via window.fence. This would clear up the many lines like this:

Let context be WindowSharedStorage's Window's browsing context.

... and this:

Let context be WorkletSharedStorage's SharedStorageWorkletGlobalScope's outside settings's target browsing context.

... which I don't think are 100% right.

(You might even want to consider doing what we (the fenced frame spec people) should probably do, which is make the getter off of Window just return null in the non-fully-active Document case. Then you don't have to keep adding the inactive checks in all of the other individual APIs.)

Indirect member references

Lines like:

Let queue be context’s associated shared storage database queue.

Are a tiny bit confusing since there is no member called "shared storage database queue" on browsing context. It might be better to make this:

Let queue be context’s associated database's shared storage database queue.

Bad promise resolution

This includes both in parallel promise resolution, as well as cross-event loop promise resolution. I noticed that in selectURL(), we resolve indexPromise in an event loop other than the other it was created in, which I don't think is allowed. The closest documentation I found for this is this example in HTML stating that you cannot resolve a promise in parallel, but I think more generally the guidance is you must resolve promises in the event loop that they were created in.

Another example of this is in https://wicg.github.io/shared-storage/#dom-workletsharedstorage-append, where while in parallel, step 8 > step 4 resolves the promise, but I don't think this is valid. This must queue a task to the outer event loop per the previous HTML link I referenced. There may be other examples (delete() seems like one) in your specification where this could be fixed.

Misc

• I noticed in https://wicg.github.io/shared-storage/#report-budget, we define a new member on each "top-level traversable". Just as an FYI, this excludes the top-level browsing context inside of a fenced frame. Is that the intention? In Chrome-implementation-speak, HTML's top-level traversable concept is 1:1 with "primary" frame in the browsing context, whereas "traversable navigable" is any main frame, including ones inside fenced frames. Just wanted to call this out to make sure we thought it through since our terminology is not super duper clear heh :/
• The https://wicg.github.io/shared-storage/#dom-windowsharedstorage-selecturl algorithm steps seem to be numerically split by the "Issue:" after step 6. Maybe the "Issue:" needs to be indented more?

Hi! I'm trying to understand how this proposal might work for cross-domain A/B experiments (e.g.trying to enable the same treatment on the same subset of users across 2 different websites). I've described below what my current understanding is of how the Shared Storage API proposal works as well as some questions on parts I'm unsure of. Could you please help clarify any parts I misunderstood?

Shared Storage

Anyone can write to the shared storage but there are limits on who and what content can be read from it.

• Question: How do you prevent domains stomping on one another's content? And what prevents a company from reading a different company's content?

Worklets

Websites can also write functions (called "worklets") that Chrome will execute in-browser based on the contents of the shared storage. The worklets can edit the shared storage, trigger the aggregated reporting workflow, or return content in an opaque URL, but not anything beyond that.

• E.g. a party could write a unique identifier (called a seed) to the shared storage, and perform different treatment based on a modulus of the identifier. Put otherwise, the user could be assigned to one of N different treatment groups but would be consistently assigned the same treatment.

  • It seems like there might be very low limits on N, but it's unclear how N is determined. Further comments show N is expected to stay under 10.

  • Question: Why does N need to be so small? Is there room to scale larger if your base population is large enough? While a small number of bits can be identifying if you have a small number of users, it's possible to have large numbers that aren't identifying if there's a large number of users, as long as the numbers are evenly distributed. Given that this proposal already requires aggregated reporting, would it be feasible for someone to run more types of treatment and just wait longer until enough users are in each treatment group to safely generate the aggregate report?

• Is there any way to support multiple independent treatments with different user splits? E.g. if one treatment coloured the website background red and another treatment changed the font, could the users be split into these experiments independently such that some arbitrary subset of users might be in both?

• Anything the function calls or loads needs to be done via opaque URL. In the long term, everything loadable via opaque URL should be a blob that's downloaded ahead of time and available offline. Put otherwise, visiting this URL wouldn't result in a server call when the user's browser actually accesses it.

  • This likely means that the content within this URL should be limited to something that could be executed in browser. Which also means that it can't pass relevant info to the serving call to trigger server-side treatment changes. Thus it doesn't enable running user-consistent A/B experiments that affect server-side behaviour.

• "Operations defined by one context are not invokable by any other contexts." -> I'm not sure what this means. Does it mean we couldn't rerun the same treatment on different domains?

• Unclear how flexible these functions/worklets are aside from letting you pick between 1 of 5 opaque URLs. Can you actually change behaviour in these functions, or does the behaviour change need to be within the URL? If the former, can you apply different worklets to different situations, so that you get behaviour changes for some situations and URLs for others?

Aggregated Reporting

The only way to get info back about your treatment is sending metrics in aggregate.

• Seems like you can write as many metrics as you want as long as it's in key-value pairs, but you can only get aggregate results returned to your servers at some time interval.

• Is there any built-in support for splitting the metrics by treatment groups, or do you have to manually write each group to a different metric key?

• Will the metrics include confidence intervals?

You can delay when the selectURL gate makes a request by delaying when the run function registered in the worklet returns. By doing this you can pass information to a server based on how quickly it receives the request relative to an earlier request, and use those delays to learn what value was stored with the API.

If you make a call to selectURL and only pass in a single URL it will not decrease the privacy budget as it is currently described since the request can only go to that one URL and log_2(1)=0, but delaying the request, based on a stored value, can still allow you to leak data that is not accounted for in the privacy budget. While the obfuscated URL or fenced frame config is returned almost immediately, the actual request can’t be made until the function returns. The simplest case involves either including a hardcoded delay or no delay before returning, although conceptually there is no reason you couldn’t use different lengths of delays to pass more information to the server (e.g., no delay, short delay, long delay) or tailor the delays to the current network conditions.

Below are links to two different websites that include the same third-party HTML in an iframe (light blue) which creates a persistent identifier that is transmitted as delays (hardcoded to be 2 seconds for this example) between requests for each of the fenced frames. The screenshots of the network waterfalls for the two sites are included below.

Website 1: https://anisenoff.github.io/sharedstorage/request.html?q=delay_header
Website 2: https://www.andrew.cmu.edu/user/anisenof/sharedstorage/request.html?q=delay_header

Note: The links above were tested in Chrome version 114.0.5735.90

Furthermore, by allowing the resources to be loaded into iframes it appears to open up the possibility of using caching attacks, to learn what resource was loaded by a call to selectURL on subsequent visits to a site without decrementing the privacy budget, and possibly other side-channel attacks.

Fenced frames recently got feedback from the TAG that shared storage seemed like an explicit dependency of the fenced frame specification due to some of the shared-storage-specific APIs appearing in that specification:

• https://wicg.github.io/fenced-frame/#fenced-frame-config-embedder-shared-storage-context
• https://wicg.github.io/fenced-frame/#dom-fencedframeconfig-setsharedstoragecontext

If fenced frames has the opportunity to ascend to something like the WHATWG before this specification, for example, then the fenced frame feature should probably not normatively include APIs that are specific to this feature. Therefore I think it's best if the bits above were specified in the shared storage spec as extensions of the fenced frame specification.

The difference between these two methods is not immediately clear to me upon reading through the explainer. It seems worthwhile to point that out.

Hi,

As discussed Tuesday, It would be great to be able to have this shared storage available in the buyer or seller worklet in fledge (themselves opaque).

Indeed, in the current set up, the ABtest can only be performed once the winner has been chosen (as you can query with only 5 urls who are therefore related to the winning campaign only) .
It is therefore impossible to do bidding ABtest for instance (where you bid more or less , or differently on a given set of users).

This is a very important use case for online advertising.

Many thanks,
Basile

The explainer states that "The chosen URL represents up to log2(num urls) bits of cross-site information", but it's not immediately obvious (to me) why that's the case. Expanding on it (inline in the explainer, or in a separate document) would be appreciated! :)

While crawling Shared Storage API, the following links to other specifications were detected as pointing to non-existing anchors:

• https://html.spec.whatwg.org/multipage/browsers.html#concept-opaque-origin

_{This issue was detected and reported semi-automatically by Strudy based on data collected in webref.}

This would be stored in browser, will there be a restriction on how much data can be stored per partition?

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?

Currently, Fenced Frames disallow all Permission policies for privacy reasons.

Shared Storage is going to add its permissions policy as well. The following Shared Storage use cases will benefit from being allowed from inside the Fenced Frame:

• A/B Experiments - Shared storage allows for assigning experiment groups to users and selecting between up to 8 different urls to display to a user. The URL selection is done from a javascript worklet, and the selected URL is rendered by a fenced frame. However, to measure the effectiveness of the experiment, the organization needs to be able to send a report to an aggregation service. It is important to send the report from within the fenced frame, and not from within the JS worklet, as orgs will want to confirm the content successfully loaded prior to sending a report, which is particularly important if the content is an ad a brand is paying for. 
• Multiple, nested url selection calls - while likely a future use case, there is a potential need to allow multiple organizations to utilize shared storage to prevent one entity further upstream (say for example in an ad decision chain) from preventing other organizations from utilizing shared storage (we will need to ensure we are “budgeting” properly for entropy leakage, hence why it is a future/under consideration use case). It is likely that if an SSP uses some information from shared storage to then render a URL within a fenced frame pointing to a DSP, that the DSP would be unable to reference information in its own shared storage to further refine the ad decision. 

How does the per-origin budget mentioned in https://github.com/WICG/shared-storage#short-term-budgets tie to the 'budget' referred in the enrollment which is per-site?

I'm trying to envision how an established ad server could utilize shared storage to implement frequency capping, a/b testing, remarketing, and rotating creatives in a sequence at the user-level. A few questions:

• Is the limit of 5 URLs set in stone? For campaigns that select a creative based on a combination of frequency-capping, a/b testing, and remarketing, we can easily run into the 5 URL limit. One of these 5 URLs will be used as a default in case the user does not fit into any of the specified categories. We would like the maximum flexibility possible, while preserving the user’s privacy.
• I found this part of the explainer hard to understand:

However, a leak of up to log(n) bits (where n is the size of the list) is possible when the fenced frame is clicked, as a navigation that embeds the selected URL may occur.

Can you describe the idea further?

• Will we be getting temporary “Event-level reporting” that FLEDGE currently has (e.g. https://github.com/WICG/turtledove/blob/main/FLEDGE.md#5-event-level-reporting-for-now)?

For utility and adoptability, prior to the deprecation of third-party cookies, we will need to support event-level reporting for sharedStorage.selectURL() in a manner that is roughly equivalent to what the FLEDGE API has implemented in their registerAdBeacon().

We propose updating the urls parameter, which is currently an array of URLs, to an array of dictionaries where the metadata can be omitted, e.g. in the following example:

var opaqueURL = await window.sharedStorage.selectURL(
  "select-url-for-experiment",
  [{url: "blob:https://a.example/123…", report_event: "click", report_url: "https://report.example/1..."},
   {url: "blob:https://b.example/abc…", report_event: "click", report_url: "https://report.example/a..."},
   {url: "blob:https://c.example/789…"}],
  {data: {name: "experimentA"}});

We would then use this metadata to hook up to window.fence.reportEvent().

In the long term, however, we will not be able to support this type of reporting, as it can be used to leak the index simply by using a distinct report_url for each candidate Fenced Frame url.

We welcome feedback on this proposal.

Shared Storage API offers interesting primitives that can potentially be useful for selecting ads based on criteria that needs some cross-site information, for example, to enable browser-level frequency capping, while protecting users from tracking across sites. The current proposal includes a selectURL function, which allows an embedded third-party origin to select one of a small number of URLs to render, delegating the choice to a snippet of JavaScript logic running inside an isolated worklet. The feature can help serve ads that are targeted mainly based on contextual, single-site criteria server-side, but need an additional post-filtering step applied based on cross-site knowledge.

That said, the current programmatic ads ecosystem typically involves not one but multiple participants working together to select and serve the best ad. Often, this includes at least a buyer (such as a DSP), who represents an advertiser or an agency, and a seller (such as an SSP), who represents a publisher.

Can there be a practical way to adapt the Shared Storage API and, specifically, its URL selection feature, to the ad selection process that involves the roles of buyers and sellers working together to select the best (for example, highest-paying) ad?

These two roles can translate into different requirements.

Buyers may want to:

• Use the Shared Storage API to apply business logic (such as frequency caps enforcement) based on cross-site information on-device, and select a subset of eligible ads from a larger set (likely determined server-side, perhaps, based on contextual or single-site targeting).

• Extra credit: adjust bid value for an ad based on cross-site information (e.g., apply bid discounts for subsequent impressions).

• Be able to write to the Shared Storage upon rendering their ad.

Sellers may want to:

• Let buyers use the Shared Storage API within the context of their origin to select a subset of ads eligible to serve (e.g., meeting campaign frequency caps) from a larger set.

• Select a winning ad (for example, top-ranked by its publisher payout) from the set of ads that the buyers’ logic within worklets determined as eligible to be shown to an end user.

• Propagate the information buyers may need for running their on-device logic inside worklets with the Storage Access API (for example, campaign frequency caps from the contextual bid responses).

Storage Access API suggests logic operating on cross-site data should run inside isolated worklets to protect from exfiltration. Can the API support multiple worklets orchestrated in a way to support both buyer- and seller-specific URL selection logic, such that the seller logic can (a) select an ad URL to render among the ad URL(s) selected by different buyers and (b) does not have access to any buyers’ origin shared storage?

Note: some ideas here sound similar to FLEDGE and its on-device auction. I’ll raise a separate issue about the relationship between FLEDGE and Shared Storage API for ad selection use cases.

In an effort to reduce the scope of joining user ids across sites, Shared Storage will delete an origin's contents 30 days after the first entry is written. This is perhaps overly restrictive, and prohibitive, for our users. For one, outside of the worklet, the caller has no idea how long the data will persist. It may be day 29, and writing a new key on the 29th day will result in it being deleted the next day. But also, there are use cases (such as reach) that will need to extend beyond 30 days.

An alternative proposal is to reduce the scope of joining user ids across sites without further interaction with the origin. This brings it closer to what FLEDGE is doing. That is, if a FLEDGE interest group already exists, and is written to again, its expiration time is reset. We could do the same thing with Shared Storage. If a key is written to (or would be written to if it didn't already exist), its timestamp is reset. This ensures that keys persist for at least 30 days, and can be extended longer so long as the origin sees the user again and updates the value.

Thoughts welcome.

The explainer says:

"""
selectURL() returns a promise that resolves into an opaque URL for the URL selected from urls.

• urls is a list of dictionaries, each containing a candidate URL url and optional reporting metadata (a dictionary, with the key being the event type and the value being the reporting URL; identical to FLEDGE's registerAdBeacon() parameter), with a max length of 8.
  • The url of the first dictionary in the list is the default URL. This is selected if there is a script error, or if there is not enough budget remaining, or if the selected URL is not yet k-anonymous.
  • The selected URL will be checked to see if it is k-anonymous. If it is not, its k-anonymity will be incremented, but the default URL will be returned.
  • The reporting metadata will be used in the short-term to allow event-level reporting via window.fence.reportEvent() as described in the FLEDGE explainer.

"""

This design has the following flaw: The default URL is not necessarily k-anonymous and may be used to join first/third-party information. For example:

Let selectURL([url1, url2, url3]); pick url2 if some third party bit = 0 and url3 if the third party bit is 1. Let url3 be above the k-anonymity threshold, but not url1 or url2.

If the third party bit is 0 (or repeat with a different selection algorithm for 1), url1 will be loaded even though it isn't k-anonymous and joins a bit of cross-site data (e.g. the URL could be "https://evil.com?first_party_id=unique_id&third_party_bit=0"). You can repeat this process to extract arbitrarily many bits of cross-site data to the server (if the server is untrusted; otherwise you just get a single k-anonymity violation + 1-bit leak locally).

We want to ensure the following property:

• The selected URL is independent of third-party information OR The selected URL is k-anonymous.

We can achieve this with an additional check at the start, as follows:

• If the first URL (the default URL) is not k-anonymous, select it (or even return an error) and increment its k-anonymity.
• If the first URL is k-anonymous, proceed with the above design.

Good

This is currently implemented but not in the spec, but top-level accesses to sharedStorage should fail in worklet global scopes, e.g.:

class Operation {
  async run(data) {
    // ok to access sharedStorage here
  }
}
register("operation", Operation)

sharedStorage.get(...)  // This should fail

No mention is made of how long keys are persisted. The set() and append() calls should include an optional parameter that allows the lifetime to be specified. This should default to something like 30 days. If set() is called on an existing key with ignoreIfPresent true, its lifetime should still be updated. You could either always update it to the newly specified expiration or to the latest of its current expiration and its newly specified expiration.