LGTM1 On Thu, Feb 6, 2025 at 9:57 AM Dan McArdle <dmcar...@chromium.org> wrote:
> 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 > > On Wed, Feb 5, 2025 at 11:25 AM Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > >> >> >> On Tuesday, February 4, 2025 at 9:20:37 PM UTC+1 Dan McArdle wrote: >> >> Contact emailsdmcar...@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? >> >> >> 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 componentBlink>PrivateAggregation >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EPrivateAggregation%22> >> >> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/846 >> >> TAG review statusDeclined >> >> 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 >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ?Yes >> >> Flag name on about://flagsNone >> >> Finch feature namePrivateAggregationApiMaxContributions >> >> Requires code in //chrome?False >> >> Tracking bughttps://crbug.com/376707230 >> >> Launch bughttps://launch.corp.google.com/launch/4357940 >> >> Estimated milestonesShipping on desktop134Shipping on Android134 >> >> 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 Statushttps://chromestatus.com/ >> feature/5189366316793856?gate=5179705727385600 >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.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+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGmnN44pgvBDymyiaJNpX%2BREGR2pw8yOPBeAugAnBa-O%2B7%2BFaA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8K%2B4pHF9OxtGsjSTCgcEg79f3RQHZHxagX4ZJV-ST7AA%40mail.gmail.com.
