[pull] main from WICG:main

AGGREGATE.md

@@ -315,7 +315,9 @@ encoded. The map will have the following structure:
   "operation": "histogram",  // Allows for the service to support other operations in the future
   "data": [{
     "bucket": <bucket, encoded as a 16-byte (i.e. 128-bit) big-endian bytestring>,
-    "value": <value, encoded as a 4-byte (i.e. 32-bit) big-endian bytestring> 
+    "value": <value, encoded as a 4-byte (i.e. 32-bit) big-endian bytestring>,
+    // k is equal to the value `aggregatable_filtering_id_max_bytes`, defaults to 1 (i.e. 8-bit).
+    "id": <filtering ID, encoded as a k-byte big-endian bytestring, defaults to 0>
   }, ...]
 }
 ```
@@ -507,6 +509,47 @@ A similar design was proposed for the
 [Private Aggregation API](https://github.com/patcg-individual-drafts/private-aggregation-api/blob/main/report_verification.md#shared-storage)
 for the purpose of report verification.
 
+### Optional: flexible contribution filtering with filtering IDs
+
+Trigger registration's `aggregatable_values`'s values can be integers or
+dictionaries with an optional `filtering_id` field. 
+
+```jsonc
+{
+  ..., // existing fields
+  "aggregatable_filtering_id_max_bytes": 2, // defaults to 1
+  "aggregatable_values": {
+    "campaignCounts": 32768,
+    "geoValue": {
+      "value": 1664,
+      "filtering_id": "23" // must fit within <aggregatable_filtering_id_max_bytes> bytes
+    }
+  }
+}
+```
+
+These IDs will be included in the encrypted aggregatable report payload
+contributions.
+
+Queries to the aggregation service can provide a list of allowed filtering IDs
+and all contributions with non-allowed IDs will be filtered out.
+
+The filtering IDs need to be unsigned integers limited to a small number of
+bytes, (1 byte = 8 bits) by default. We limit the size of the ID space to
+prevent unnecessarily increasing the payload size and thus storage and
+processing costs.
+
+This size can be increased via the `aggregatable_filtering_id_max_bytes` field.
+To avoid amplifying a counting attack due to the resulting different payload
+size, the browser will unconditionally send an aggregatable report on every
+trigger registration with a non-default (greater than 1) max bytes. A null report
+will be sent in the case that the trigger registration did not generate an
+attribution report. The source registration time will always be excluded from
+the aggregatable report with a non-default max bytes. This behavior is the same
+as when a trigger context ID is set.
+
+See [flexible_filtering.md](https://github.com/patcg-individual-drafts/private-aggregation-api/blob/main/flexible_filtering.md) for more details.
+
 ## Data processing through a Secure Aggregation Service
 
 The exact design of the service is not specified here. We expect to have more

EVENT.md

@@ -1114,9 +1114,27 @@ trying to measure user visits on, the browser can limit the number `destination`
 sites represented by unexpired sources for a source-site.
 
 The browser can place a limit on the number of a source site's unexpired source's
-unique `destination` sites. When an attribution source is registered for a site
-that is not already in the unexpired sources and a source site is at its limit,
-the browser will drop the new source.
+unique `destination` sites. Source registrations will accept an optional field
+`destination_limit_priority` to allow developers to prioritize the destinations
+registered with this source with respect to other destinations for the purpose
+of source deactivation.
+
+```jsonc
+{
+  ..., // existing fields
+  "destination_limit_priority": "[64-bit signed integer]" // defaults to 0 if not present
+}
+```
+
+When an attribution source is registered for a site that is not already in the
+unexpired sources and a source site is at its limit, the browser will sort the
+`destination` sites registered by unexpired sources, including the new source,
+by `destination_limit_priority` in descending order and by the registration
+time in descending order. The browser will then select the first few
+`destination` sites within this limit, and delete pending sources and
+aggregatable reports associated with the unselected `destination` sites. Any
+event-level reports are not deleted, as the leak of user's browsing history is
+mitigated by fake reports within differential privacy.
 
 The lower this value, the harder it is for a reporting origin to use the API to
 try and measure user browsing activity not associated with ads being shown.
@@ -1129,6 +1147,9 @@ the [denial of service](#denial-of-service) for more details. To prevent this
 attack, the browser should maintain these limits per reporting site. This
 effectively limits the number of unique sites covered per {source site, reporting site} applied to all unexpired sources regardless of type at source time.
 
+The browser can also limit the number of `destination` sites per {source site, reporting site, 1 day}
+to mitigate the history reconstruction attack.
+
 #### Limiting the number of unique destinations per source site
 
 To further reduce the possibility of a history reconstruction attack, the browser can also limit the number of `destination` sites registered per {source-site, 1 minute}.