LGTM1 On Fri, Oct 4, 2024 at 8:48 PM Dan McArdle <dmcar...@chromium.org> wrote:
> 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/CAOmohS%2BHVK6NNkFH%2BDUgPneWqZjL9eyJ%2Bv4a8YL3eHNK7%2Bx1eg%40mail.gmail.com.
