LGTM2 On 2/11/25 1:52 PM, Chris Harrelson wrote:
LGTM1On 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 <https://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 <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. 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 <https://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 <https://github.com/mozilla/standards-positions/issues/805>) /WebKit/: No signal (https://github.com/WebKit/standards-positions/issues/189 <https://github.com/WebKit/standards-positions/issues/189>) /Web developers/: Positive (https://github.com/patcg-individual-drafts/private-aggregation-api/issues/81 <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 <https://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 <https://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 GoogleGroups "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 <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8K%2B4pHF9OxtGsjSTCgcEg79f3RQHZHxagX4ZJV-ST7AA%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/bd17c967-f5ee-4a8d-a73c-ce2d4a881a1f%40chromium.org.
