jkarlin
commented
1 year ago Thanks for the question! And sorry for the slow response. I think allowing cross-origin communication within the shared storage worklet ecosystem makes sense. Here are two possible ways I could see that happening:
ACLs
In this mode, an origin can specify which origins are allowed to read/write to which of its keys. Something like sharedStorage.setACL(‘read’, <key name>, <list of origins>); This would declare that the given origins could read this key from within their worklets.
In this scenario SSPs and DSPs would need to agree on a set of key names and how to interpret them. DSPs would need to set the ACLs on their keys to allow read (and possibly write) by each SSP that they work with. The primary advantage to this solution is that it doesn't incur the creation of any new worklets. It's as fast as making any other shared storage database request.
Multiple Worklets
This is what you proposed. Here, a selectURL() worklet owned by the SSP could create a DSP worklet and communicate with it (perhaps with postMessage) to ask it questions. The advantage here is that the interface between the SSP and DSP is relatively minima. Just pass a dict with all of the options/params and let the DSP decide what to do with it and return a response (perhaps a bid). The downside is the cost of creating more worklets and the added latency (we can hide much of this latency by declaring which worklets will be needed on the selectURL() call).
I'm curious on your thoughts of which is preferable. Again, ACLs are easy to implement (for Chrome) and run super fast. Worklets are more flexible but slower performance.
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.