No, the reporting endpoint can’t infer the number of null contributions. Critically, the browser pads the payload before encrypting it with the Aggregation Service’s public key. That ciphertext is sent to the reporting endpoint, so the performance of HTTP compression won’t vary depending on the number of null contributions.
Thanks for the questions! On Friday, October 4, 2024 at 1:43:03 AM UTC-4 Yoav Weiss wrote: > On Thu, Oct 3, 2024 at 8:58 PM Dan McArdle <dmcar...@chromium.org> wrote: > >> 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.) >> > > OK, that's not awful. > One more annoying question - can the reporting endpoint distinguish > between actual payload and padding using compression? > In other words, will the lengths differ if the payload was compressed? > > >> >> >> 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/1404ffa0-e36f-4f3a-b5d4-87380ca02650n%40chromium.org.
