Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Update references to FLEDGE in explainer (#39)
Resolves #37.
- Loading branch information
1 parent
b5c6162
commit bdbbd63
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -10,7 +10,7 @@ Author: Alex Turner ([email protected]) | |
|
|
||
| - [Introduction](#introduction) | ||
| - [Examples](#examples) | ||
| - [Protected Audience reporting](#protected-audience-reporting) | ||
| - [Measuring user demographics with cross-site information](#measuring-user-demographics-with-cross-site-information) | ||
| - [Goals](#goals) | ||
| - [Non-goals](#non-goals) | ||
|
|
@@ -47,8 +47,8 @@ Browsers are now working to prevent cross-site user tracking, including by | |
| cookies](https://blog.chromium.org/2020/01/building-more-private-web-path-towards.html). | ||
| There are a range of API proposals to continue supporting legitimate use cases | ||
| in a way that respects user privacy. Many of these proposals, including [Shared | ||
| Storage](https://github.com/WICG/shared-storage) and [Protected | ||
| Audience](https://github.com/WICG/turtledove), plan to isolate potentially | ||
| identifying cross-site data in special contexts, which ensures that the data | ||
| cannot escape the user agent. | ||
|
|
||
|
|
@@ -60,8 +60,8 @@ has been proposed to allow reporting noisy, aggregated cross-site data. This | |
| service was originally proposed for use by the [Attribution Reporting | ||
| API](https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATE.md), | ||
| but allowing more general aggregation would support additional use cases. In | ||
| particular, the [Protected Audience](https://github.com/WICG/turtledove) | ||
| and [Shared Storage](https://github.com/WICG/shared-storage) | ||
| proposals expect this functionality to become available. | ||
|
|
||
| So, to complement the Attribution Reporting API, we propose a general-purpose | ||
|
|
@@ -86,10 +86,11 @@ the reporting origin. | |
|
|
||
| ## Examples | ||
|
|
||
| ### Protected Audience reporting | ||
|
|
||
| The [Protected | ||
| Audience](https://github.com/WICG/turtledove/blob/main/FLEDGE.md#5-event-level-reporting-for-now), | ||
| API plans to run on-device ad | ||
| auctions using cross-site data as an input. This Private Aggregation API will | ||
| allow measurement of the auction results from within the isolated execution | ||
| environments. | ||
|
|
@@ -246,13 +247,14 @@ The report, including the payload, will mirror the [structure proposed for the A | |
| API](https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATE.md#aggregatable-reports). | ||
| However, a few details will change. For example, fields with no equivalent | ||
| on this API (e.g. `attribution_destination` and `source_registration_time`) | ||
| won't be present. Additionally, the `api` field will contain either | ||
| `"protected-audience"` | ||
| or `"shared-storage"` to reflect which API's context requested the report. | ||
|
|
||
| The following is an example report showing the JSON format | ||
| ```jsonc | ||
| { | ||
| "shared_info": "{\"api\":\"protected-audience\",\"report_id\":\"[UUID]\",\"reporting_origin\":\"https://reporter.example\",\"scheduled_report_time\":\"[timestamp in seconds]\",\"version\":\"[api version]\"}", | ||
|
|
||
| "aggregation_service_payloads": [ | ||
| { | ||
|
|
@@ -271,9 +273,9 @@ The following is an example report showing the JSON format | |
|
|
||
| As described earlier, these reports will be sent to the reporting origin after a | ||
| delay. The URL path used for sending the reports will be | ||
| `/.well-known/private-aggregation/report-protected-audience` and | ||
| `/.well-known/private-aggregation/report-shared-storage` for reports triggered | ||
| within a Protected Audience or Shared Storage context, respectively. | ||
|
|
||
| ### Temporary debugging mechanism | ||
|
|
||
|
|
@@ -298,8 +300,8 @@ will be disabled if third-party cookies are disabled/deprecated. | |
| #### Enabling | ||
|
|
||
| The following javascript call will then enable debug mode for all future reports | ||
| requested in that context (e.g. Shared Storage operation or Protected Audience | ||
| function call): | ||
| ``` | ||
| privateAggregation.enableDebugMode(); | ||
| ``` | ||
|
|
@@ -322,8 +324,8 @@ calls will be ignored. | |
| When debug mode is enabled, an additional, duplicate debug report will be sent | ||
| immediately (i.e. without the random delay) to a separate debug endpoint. This | ||
| endpoint will use a path like | ||
| `/.well-known/debug/private-aggregation/report-protected-audience` (and the | ||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong. |
||
| equivalent for Shared Storage). | ||
|
|
||
| The debug reports should be almost identical to the normal reports, including | ||
| the additional debug fields. However, the payload ciphertext will differ due to | ||
|
|
@@ -336,7 +338,8 @@ key. | |
| In the case of multiple calls to `sendHistogramReport()`, we can reduce report | ||
| volume by sending a single report with multiple contributions instead of | ||
| multiple reports. For this to be possible, the different calls must involve the | ||
| same reporting origin and the same API (i.e. Protected Audience or Shared | ||
| Storage). | ||
| Additionally, the calls must be made at a similar time as the reporting time | ||
| will necessarily be shared. | ||
|
|
||
|
|
@@ -345,12 +348,12 @@ will necessarily be shared. | |
| For calls within a Shared Storage worklet, calls within the same Shared Storage | ||
| operation should be batched together. | ||
|
|
||
| For calls within a Protected Audience worklet, calls using the same reporting | ||
| origin within the same auction should be batched together. This should happen | ||
| even between different interest groups or Protected Audience function calls. One | ||
| consideration in the short term is that these calls may have different | ||
| associated [debug modes or keys](#temporary-debugging-mechanism). In this case, | ||
| only calls sharing those details should be batched together. | ||
|
|
||
| #### Contributions limit | ||
|
|
||
|
|
@@ -387,7 +390,7 @@ examples of metadata that could be included, along with some potential risks: | |
| subdomains, e.g. to separate use cases. | ||
| - Which API triggered the report | ||
| - The `api` field and the endpoint path indicates which API triggered the | ||
| report (e.g. Protected Audience or Shared Storage). | ||
| - The API version | ||
| - A version string used to allow future incompatible changes to the API. This | ||
| should usually correspond to the browser version and should not change | ||
|
|
@@ -537,9 +540,9 @@ reporting origin, no matter which top-level sites are involved. For the earlier | |
| within `reportResult()` and the interest group owner within | ||
| `reportWin()`/`reportLoss()`. | ||
|
|
||
| We initially plan to have two separate budgets: one for calls within Shared | ||
| Storage worklets and one for Protected Audience worklets. However, see [shared | ||
| contribution budget](#shared-contribution-budget) below. | ||
|
|
||
| ## Future Iterations | ||
|
|
||
|
|
@@ -557,7 +560,8 @@ Framework](https://datatracker.ietf.org/doc/draft-gpew-priv-ppm/). | |
|
|
||
| ### Shared contribution budget | ||
|
|
||
| Separating contribution budgets for Shared Storage worklets and Protected | ||
| Audience worklets | ||
| provides additional flexibility; for example, some partition choices may not be | ||
| compatible (e.g. a per-interest group budget). However, we could consider | ||
| merging the two budgets in the future. | ||
|
|
||
shouldn't be
/.well-known/private-aggregation/debug/report-protected-audience ?
(based on implementation test (and real traffic))
chromium/chromium@c08a9c1#diff-040003cbc23bed76337f62c021a7adad1249f946644476fdc642bcc5f86ad5abL336