New service for a private, secure aggregation mechanism

[Alex Turner]

Hi all,

We're working on implementing the client-side infrastructure for a private, secure aggregation mechanism (confusingly currently named the "aggregation service"), as described in this explainer. We plan to use this mechanism for multiple proposed web APIs, the first of which will be the Aggregate Attribution Reporting API (previously known as the Aggregate Conversion Measurement API). 

To avoid duplication, joint functionality for these different proposed APIs such as constructing aggregatable reports, including generation of secret shares, fetching helper server public keys and encryption will be implemented in this shared client-side infrastructure.

More details are available here: crbug.com/1225434.

This code was originally planned for //content/browser, but it appears to satisfy the requirements of a service (i.e., functionally related code that could logically run in an isolated process). However, note that we do not currently plan to run it in a different process. As this code is solely used to implement certain web APIs, we felt that //content/services/aggregation-service was likely a more appropriate place than //services//aggregation-service, but we'd appreciate your feedback on the best place for this code.

Thanks,

Alex

[Colin Blundell]

Hi Alex,

Thanks! +1 to having this code live in //content rather than //services for the reason that you mentioned.

Can you elaborate further on the motivations for making this code into a service given that it will be running in the browser process? Where do its consumers live (e.g., browser process, Blink, both, ...)?

Thanks,

Colin

--
You received this message because you are subscribed to the Google Groups "services-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to services-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/services-dev/CAA%2BBiFn%2BLHj5a5OmACjUM03Qy7har1Dvz01tXy3oWBCM_6K3qQ%40mail.gmail.com.

[Alex Turner]

Hi Colin,

The consumers will all live on the browser process as well and should also be content (e.g. the attribution API is currently hosted in //content/browser/conversions). So, there's no big practical motivation here, it's mainly just 'conceptual'. But, it would be nice to make the external interface very clear and avoid internals being accidentally used externally. That being said, I'm not super familiar with servicification, so it's also totally fine with me if you feel this doesn't need to be made a service.

Thanks!

Alex

[Colin Blundell]

On Thu, Jul 1, 2021 at 7:00 PM Alex Turner <ale...@chromium.org> wrote:

Hi Colin,

The consumers will all live on the browser process as well and should also be content (e.g. the attribution API is currently hosted in //content/browser/conversions). So, there's no big practical motivation here, it's mainly just 'conceptual'. But, it would be nice to make the external interface very clear and avoid internals being accidentally used externally. That being said, I'm not super familiar with servicification, so it's also totally fine with me if you feel this doesn't need to be made a service.

Thanks for the info! My instinct is that you'll have greater flexibility and ease by just having the aggregration code live in //content/browser as well: then you can use C++ APIs instead of Mojo, any APIs that would be useful to be synchronous can easily be so, and you don't have the overhead of managing the C++/Mojo state representations. This of course doesn't preclude making a very clean and focused API surface between that code and its consumers!

Best,

Colin

[Alex Turner]

Great, that makes sense. Thanks for the help!

Alex