From fe9eb6f716aa35a82585b873f978348c6856177a Mon Sep 17 00:00:00 2001 From: Erik Taubeneck Date: Fri, 1 Mar 2024 09:07:46 -0800 Subject: [PATCH] include feedback from 20240229 patcg meeting --- third-parties/readme.md | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/third-parties/readme.md b/third-parties/readme.md index bc6d292..0b23c90 100644 --- a/third-parties/readme.md +++ b/third-parties/readme.md @@ -17,23 +17,22 @@ The proposed private measurement APIs all include some form of budgeting or rate ## Goals -We aim to achieve the following in our API designs, but also recognize there are trade offs to consider. - +We aim to achieve the following in our API designs, and will use these goals as a way to evaluate and compare proposals. We understand that some of these goals are in tension. It might be the case that no solution will be able to satisfy all of these goals at the same time. A solution might have to balance concerns or offer sites options that allow them to select how things like privacy budgets are allocated. A final solution can use these goals as a way of describing its capabilities, which might include options for sites to shift any balance to suit their needs. 1. Top-level site owners _must_ be able to delegate usage of the measurement API to _third party service providers._ 2. Top-level site owners _should_ be able to utilize multiple _third party service providers._ - a. It _may_ be reasonable to standardize an upper limit on the number of _third party service providers._ -3. The utilization of multiple _third party service providers_ _must not_ result in a reduction in the privacy afforded by the API. - a. The utilization (or general support for) multiple _third party service providers_ should not result in a reduction in the utility afforded by the API. -4. The measurement APIs _must not_ require top-level context to operate, e.g., they should be accessible within an iFrame or similarly isolated context. - a. A site _may_ restrict access to APIs for _third party service providers_ so that only their preferred providers can use the APIs. -5. It _must not_ be possible for one _third party service provider_ to actively degrade or prevent the operation of another _third party service provider_. - a. It _may_ be possible for the top-level site to configure a state that degrades or prevents the operation of some _third party service providers_, e.g., by embedding too many providers. -6. By default, it _must_ be possible for an embedded _third party service provider_ to operate the measurement APIs without requiring the top-level site to take action (beyond embedding the _third party service provider_.) - a. It _must_ be possible for sites to override these defaults (see 4a.) + 1. It _may_ be reasonable to standardize an upper limit on the number of _third party service providers._ +3. The utilization of multiple _third party service providers_ _should not_ result in a reduction in the privacy afforded by the API. + 1. The utilization (or general support for) multiple _third party service providers_ should not result in a reduction in the utility afforded by the API. +4. The measurement APIs _should not_ require top-level context to operate, e.g., they should be accessible within an iFrame or similarly isolated context. + 1. A site _may_ restrict access to APIs for _third party service providers_ so that only their preferred providers can use the APIs. +5. It _should not_ be possible for one _third party service provider_ to actively degrade or prevent the operation of another _third party service provider_. + 1. It _may_ be possible for the top-level site to configure a state that degrades or prevents the operation of some _third party service providers_, e.g., by embedding too many providers. +6. By default, it _should_ be possible for an embedded _third party service provider_ to operate the measurement APIs without requiring the top-level site to take action (beyond embedding the _third party service provider_.) + 1. It _should_ be possible for sites to override these defaults (see 4a.) 7. Whenever possible, the measurement APIs _should_ utilize reasonable defaults but _may_ allow for more precise configuration. - a. Sites that rely on defaults _should not_ receive significantly less utility from the API. + 1. Sites that rely on defaults _should not_ receive significantly less utility from the API. ## Key Issue: Privacy Budget Management