Intent to Ship: Private Aggregation API: per-context contribution limits for Shared Storage callers

[Dan McArdle]

Contact emails

dmca...@chromium.org

Explainer

https://github.com/patcg-individual-drafts/private-aggregation-api#limiting-the-number-of-contributions-per-report

Specification

https://github.com/patcg-individual-drafts/private-aggregation-api/pull/164/files

Summary

Enables Shared Storage callers to customize the number of contributions per Private Aggregation report. This feature enables Shared Storage callers to configure per-context contribution limits via a new field, `maxContributions`. Callers set this field to override the default number of contributions per report — larger and smaller numbers will both be permitted. Chrome will accept values of `maxContributions` between 1 and 1000 inclusive; larger values will be interpreted as 1000. Due to padding, the size of each report's payload will be roughly proportional to the chosen number of contributions per report. We expect that opting into larger reports will increase the cost of operating the Aggregation Service. Protected Audience callers will not be affected by this feature. However, we are planning to add support for customizing the number of contributions for Protected Audience reports in future features.

Blink component

Blink>PrivateAggregation

TAG review

https://github.com/w3ctag/design-reviews/issues/846

TAG review status

Declined

Risks

Interoperability and Compatibility

None

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/805)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/189)

Web developers: Positive (https://github.com/patcg-individual-drafts/private-aggregation-api/issues/81)

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

Debuggability

No new debug capabilities beyond the existing internals page (chrome://private-aggregation-internals) and debug mode. These capabilities will reflect the variable number of contributions across payloads.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

All but WebView

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

Yes

Flag name on about://flags

None

Finch feature name

PrivateAggregationApiMaxContributions

Requires code in //chrome?

False

Tracking bug

https://crbug.com/376707230

Launch bug

https://launch.corp.google.com/launch/4357940

Estimated milestones

Shipping on desktop	134
Shipping on Android	134

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5189366316793856?gate=5179705727385600

This intent message was generated by Chrome Platform Status.

[Yoav Weiss (@Shopify)]

On Tuesday, February 4, 2025 at 9:20:37 PM UTC+1 Dan McArdle wrote:

Contact emailsdmca...@chromium.org

Explainerhttps://github.com/patcg-individual-drafts/private-aggregation-api#limiting-the-number-of-contributions-per-report

Specificationhttps://github.com/patcg-individual-drafts/private-aggregation-api/pull/164/files

Summary

Enables Shared Storage callers to customize the number of contributions per Private Aggregation report. This feature enables Shared Storage callers to configure per-context contribution limits via a new field, `maxContributions`. Callers set this field to override the default number of contributions per report — larger and smaller numbers will both be permitted. Chrome will accept values of `maxContributions` between 1 and 1000 inclusive; larger values will be interpreted as 1000.

Can you expand a bit on what this limit is protecting against, and why it's fine to remove it? What are the tradeoffs here?
Also, why would developers want to reduce the limit?
 

Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5189366316793856?gate=5179705727385600

[Dan McArdle]

Thanks for the questions, Yoav.

First, a little background. Sites make contributions to Private Aggregation histograms from within isolated contexts that have access to cross-site data. The browser sends these contributions back to the site that made them via the encrypted payload of an aggregatable report. Although the reporting endpoint cannot decrypt incoming payloads (that is the Aggregation Service’s job), it can still see each payload's length.

Can you expand a bit on what this limit is protecting against, and why it's fine to remove it?

For privacy, we cannot let the payload length depend on cross-site data. To that end, the browser limits the number of contributions per report, without any input from the isolated context. It also pads the payload with null contributions up to the limit to achieve a fixed length prior to encryption.

Today, the limit is based solely on the identity of the calling API. This I2S proposes a more flexible way to select the limit. We’d like to enable Shared Storage callers to configure their operations with `maxContributions`, an optional field that pre-declares the maximum number of contributions the operation can make. This scheme enables sites to customize the number of contributions per report without letting isolated contexts leak cross-site data.

What are the tradeoffs here?

The primary tradeoff is that larger reports cost more to process on the Aggregation Service in terms of computation and storage. Secondly, processing each report has a fixed computational overhead independent of its size; we expect that it’s always more efficient to send N contributions in one report than N contributions across multiple reports.

Also, why would developers want to reduce the limit?

The default limit for Shared Storage is currently 20 contributions per report. This one size may not fit all use cases.

Sites that send more than 20 contributions across multiple reports by triggering multiple Shared Storage operations could leverage `maxContributions` to send fewer, larger reports. This should reduce the cost of processing these contributions on the Aggregation Service.

On the other hand, sites that make fewer than 20 contributions per Shared Storage operation could reduce costs by setting `maxContributions` to a smaller number, since it would reduce the payload length.

Thanks!

Dan

[Chris Harrelson]

LGTM1

--
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+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGmnN44pgvBDymyiaJNpX%2BREGR2pw8yOPBeAugAnBa-O%2B7%2BFaA%40mail.gmail.com.

[Mike Taylor]

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8K%2B4pHF9OxtGsjSTCgcEg79f3RQHZHxagX4ZJV-ST7AA%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

LGTM3

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGmnN44pgvBDymyiaJNpX%2BREGR2pw8yOPBeAugAnBa-O%2B7%2BFaA%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 from it, send an email to blink-dev+unsubscribe@chromium.org.