That’s correct! In isolation, cleartext payloads will be ~5x larger. In terms of magnitude, typical report sizes will increase from ~1.5 KiB to ~6 KiB. (Double these estimates when debug mode is enabled.)
On Wednesday, October 2, 2024 at 10:30:28 PM UTC-4 Yoav Weiss wrote: > That's extremely useful, thanks!! > > Can you expand on the size of the payloads in question? I'm assuming we'd > now be seeing 5x larger payloads, but I'm not sure what's the order of > magnitude we're talking about here. > > On Wed, Oct 2, 2024 at 10:57 PM Dan McArdle <dmcar...@chromium.org> wrote: > >> Hi, Daniel! >> >> First, a little background. Sites make Private Aggregation contributions >> from within isolated contexts, where they have access to cross-site data. >> The browser sends these contributions back to the site that made them via a >> report’s encrypted payload. Although the site’s reporting endpoint cannot >> decrypt incoming payloads (that is the Aggregation Service’s job), it can >> still see the length of the encrypted payloads. >> >> We need the encrypted payload to have a fixed size to prevent sites from >> leaking cross-site data. To achieve a fixed size, we limit the number of >> contributions and pad >> <https://github.com/patcg-individual-drafts/private-aggregation-api#padding> >> reports with null contributions if the limit is not reached. >> >> As for the workaround that I mentioned in the first message — sending >> more contributions in a second report — only Shared Storage callers can do >> this. That’s why this I2S proposes increasing the number of contributions >> per report for Protected Audience callers alone. >> >> The increased costs come in because more contributions per report means >> larger encrypted reports, and thus more computation/storage on the >> Aggregation Service. >> >> Thanks for the questions! Hope this helps. >> >> -Dan >> >> On Wednesday, October 2, 2024 at 12:05:43 PM UTC-4 Daniel Bratell wrote: >> >>> I admit to not being the most versed in Private Aggregation, but I >>> wonder why there is a limit at all? You say it might "increase the cost of >>> operating the Aggregation Service", but that connection is not clear to me >>> when you also say that people could work around the limit already. >>> >>> /Daniel >>> On 2024-09-24 17:26, Dan McArdle wrote: >>> >>> Contact emails dmcar...@chromium.org >>> >>> Explainer >>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/138 >>> >>> Specification >>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/150 >>> >>> Summary >>> >>> Enables Protected Audience script runners to make up to 100 >>> contributions per Private Aggregation report, compared to the current limit >>> of 20. Private Aggregation limits the number of histogram contributions >>> that can be embedded in a single aggregatable report, dropping any >>> additional contributions. Shared Storage callers can work around the limit >>> by invoking another Shared Storage operation. However, Protected Audience >>> callers have no persistent storage, so they lose their excess contributions >>> at the end of their auction. Note that this change is privacy neutral as >>> the API's contributions are still limited by the same privacy budget. Due >>> to padding, each Protected Audience report will have a larger payload, even >>> if it did not need the larger contribution limit. We expect that these >>> larger reports will increase the cost of operating the Aggregation Service. >>> Please reach out with any feedback. >>> >>> >>> Blink component Blink>PrivateAggregation >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPrivateAggregation> >>> >>> TAG review https://github.com/w3ctag/design-reviews/issues/846 (We have >>> not requested a signal for these changes specifically.) >>> >>> TAG review status Declined >>> >>> Risks >>> >>> >>> Interoperability and Compatibility >>> >>> None >>> >>> >>> *Gecko*: No signal ( >>> https://github.com/mozilla/standards-positions/issues/805) We have not >>> requested a signal for this change specifically. The Gecko position on >>> Shared Storage (one of the ways Private Aggregation is exposed) is negative. >>> >>> *WebKit*: No signal ( >>> https://github.com/WebKit/standards-positions/issues/189) We have not >>> requested a signal for this change specifically. >>> >>> *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 temporary debug mode. These >>> capabilities will reflect the merged contributions. >>> >>> >>> 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 chrome://flags None >>> >>> Finch feature name >>> PrivateAggregationApi100ContributionsForProtectedAudience >>> >>> Requires code in //chrome? False >>> >>> Tracking bug https://crbug.com/360160864 >>> >>> Launch bug https://launch.corp.google.com/launch/4336057 >>> >>> Estimated milestones >>> Shipping on desktop 131 >>> Shipping on Android 131 >>> >>> 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/5114676393017344?gate=5096059924381696 >>> >>> 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 on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGmnN45m%3DJJ3ja7_zA71nOn%3DjiBw%2Br0uFQuR0hwqHxtXzuZf4g%40mail.gmail.com >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGmnN45m%3DJJ3ja7_zA71nOn%3DjiBw%2Br0uFQuR0hwqHxtXzuZf4g%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 on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1ded3947-aff7-4fd5-9b42-d11f72bc7997n%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1ded3947-aff7-4fd5-9b42-d11f72bc7997n%40chromium.org?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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e3dd02a-4a70-4186-9ce6-563a9cac6635n%40chromium.org.
