Use Shared Storage

The Shared Storage proposal intends to create a general purpose cross-site storage API which supports many possible use cases. In this document, you'll find code samples to help you get started.

The following features are available to test in Chrome 104:

• Frequency control: run a worklet script to select a URL from a provided list, based on the stored data, and then render that URL in a fenced frame. This has many possible uses, such as selecting new content when a frequency cap is reached.
• A/B testing: You can assign a user to an experiment group, then store that group in Shared Storage to be accessed cross-site.
• Creative rotation: You can store the creative rotation mode, and other metadata, to rotate the creatives across different sites.
• Known customer for payment provider: You can store whether the user has registered on your site into Shared Storage, then render a different element based on that stored status.

The following use case isn't available for testing in Chrome Beta, but we intend to support it in the future:

• Noisy aggregation of cross-site data: you will be able to run a worklet script to aggregate your data with the Private Aggregation API which returns a privacy-preserving report.

These are only some of the possible use cases for Shared Storage. We'll continue to add examples as we receive feedback and discover new use cases.

# Try the Shared Storage API

Shared Storage API with Fenced Frames can be tested in Chrome 104 (version 104.0.5086.0 or later) by enabling the Privacy Sandbox Ads APIs experiment flag at chrome://flags/#privacy-sandbox-ads-apis.

You can also enable Shared Storage with the --enable-features=PrivacySandboxAdsAPIsOverride,OverridePrivacySandboxSettingsLocalTesting,SharedStorageAPI,FencedFrames flag in the command line.

# Use the demo

The demo can be accessed at goo.gle/shared-storage-demo, and the code is available on GitHub.

The demo is constructed from the perspective of an advertiser/DSP that wants to store information across different publishers. Think of the advertiser as a shoe company, and the publishers as news companies. In the demo, the same advertiser code will run on both Publisher A and Publisher B sites for each use case. Visit both publishers to see how the data is shared between two sites.

The demo contains frequency capping, creative rotation, known customer, and A/B testing use cases.

# Not recommended: user consent status

Ad tech companies often have cross-site consent statuses that they need to keep track of. For example, an ad tech company may want to store if a user consents to an ad tech's terms or service or policies related to regulations, such as GDPR.

Shared storage is not recommended for this use case. This is because:

1. A user might opt-out of using the privacy sandbox apis, which would prevent organizations from using shared storage at all.
2. The current output gates will require k-anonymity or additional noise sometime after the Origin Trial, which would mean there is a non-zero chance the consent status would not be 100% accurately represented in all cases.

# Engage and share feedback

The Shared Storage proposal is under active discussion and subject to change in the future. If you try this API and have feedback, we'd love to hear it.

• GitHub: Read the proposal, raise questions and participate in discussion.
• Developer support: Ask questions and join discussions on the Privacy Sandbox Developer Support repo.