]> Mozilla

mt@lowentropy.net

Security Privacy Preserving Measurement decibels replay This defines extensions to the DAP protocol that support the Attribution API. These extensions provide support for differentially-private aggregation and the operating modes that the Attribution API depends on. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Privacy Preserving Measurement Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Attribution API is a web platform feature that provides sites that use advertising with the ability to measure the effectiveness of that advertising. Measurements that the API produce are aggregated using the Distributed Aggregation Protocol (DAP) . This document defines extensions to DAP that support the use of DAP by the Attribution API. These extensions fall into two categories:

• Support for the differential privacy model used in the Attribution API.
• Support for the operational modes that better fit the deployment model that the Attribution API uses.

These extensions are not narrowly defined such that they can only be used by the Attribution API. Other applications might be able to use them, but any effort to make them fully generic stops short of making the extensions more complex that is required for Attribution. For example, privacy budget extensions are defined to use the epsilon definition from (ε, 0)-differential privacy or (ε, δ)-differential privacy with a fixed δ value. This is simpler than a design that might allow for multiple budget metrics. These extensions all assume the use of DAP task provisioning . However, only the collector identity extension () concretely depends on , as it uses the task configuration extensions. All other extensions apply to the core DAP protocol .

Differential Privacy in Attribution The Attribution API provides information to websites based on user activity on other websites, which is ordinarily prohibited for privacy reasons . To protect privacy, the Attribution API uses differential privacy in a combination of the central and individual models . The privacy architecture of the Attribution API allocates responsibility for managing sensitivity and privacy budgets to browser instances (DAP Clients) and for the addition of noise to an aggregation service (DAP Aggregators, collectively). To this end, reports that are submitted for aggregation need to be bound to the privacy budget that was expended at a Client when the report was generated. This ensures that Aggregators can apply noise with sufficient amplitude to maintain the intended differential privacy guarantee. An extension that reports the amount of privacy budget that was consumed in the generation of a report is described in .

Attribution Operating Mode Extensions The Attribution API is expected to operate in a mode that differs somewhat from the way that DAP is architected. Several extensions are defined to support this operating mode. In DAP, a task is a long-running context that Clients continuously contribute to. Reports are directly uploaded by Clients to the Leader as they are generated. The DAP batch mode determines how reports are grouped for aggregation. A new collection job is initiated by the Collector when an aggregate is needed, though this might fail if the requirements for the task -- the batch mode and minimum batch size, primary -- are not met. A simple representation of the DAP architecture is illustrated in .

Simplified DAP Architecture +--------+ Collection +-----------+ +-+ Clients | ----------> | Leader | <----------- | Collector | +---------+ ----------> +--------+ -----------> +-----------+ Result ]]>

In the Attribution API, reports are delivered to the website that requests them. The site is expected to gather a bundle of reports and submit them for aggregation when they have a sufficiently large set. An important feature of this design is that the website (as a DAP Collector) chooses which reports to aggregate. This gives the site an opportunity to review the circumstances in which reports were generated and filter reports according to their needs. A secondary reason for Clients to deliver reports to the website, rather than submit them directly to the Leader, is that this removes a real-time dependency on the Leader. A Leader can therefore be less available than the sites that depend on its services. A simple representation of the architecture used by the Attribution API is illustrated in .

Attribution API Architecture +-----------+ Batched v +-+ | Clients | ----------> | Collector | Reports +--------+ +-+ (Browsers) | ----------> | (Website) | =============> | Leader | +------------+ ----------> +-----------+ <------------- +--------+ Result ]]>

To support this mode of operation, a new batch mode for DAP is defined called "collector-selected"; see . For other batch modes, the Leader has sufficient information to select reports for inclusion in a collection job. In comparison, this batch mode requires that reports carry an annotation set by the Collector at the time that each report is uploaded.

Other Extensions Two other extensions are defined in this document. The minimum privacy budget collection job extension () added to collection job initialization places guardrails around what reports can be included in a collection job. Reports that lack a privacy budget extension or those with a value below the indicated threshold must be rejected by Aggregators. For the Attribution API, setting a minimum privacy budget is roughly equivalent to capping the noise that is added to an aggregate. Without this extension, noise could be determined from the privacy budget values bound to each report. This ensures that reports that do not match expectations can be dropped efficiently, rather than having Aggregators add unexpectedly large amounts of noise. The collector identity task extension () binds the identity of the Collector to tasks. This extension fixes the entity can request collection of reports. For the Attribution API, each Collector receives their own source of privacy budget. Binding tasks to a single Collector ensures that the privacy guarantees that the per-Collector privacy budget provide cannot be circumvented by Collectors pooling reports into a single aggregate.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document relies on the definitions in DAP for protocol roles and functions. Some reference is made to the terms and concepts in the Attribution API , though familiarity with these should not be necessary to understand how the extensions interact with DAP.

Differential Privacy Budget Report Extension The privacy budget report extension (codepoint 0xTBD) encodes the amount of privacy budget that might have been expended by a Client as a result of producing a report. The value of the codepoint is an integer encoding of the number of micro-epsilons of budget that are expended. That is, each unit is a one-millionth of an epsilon (ε) as used in (ε, δ)-differential privacy. The micro-epsilon value is encoded as a 32-bit integer in network byte order. This permits expenditure of up to ε=4294.967295 to be encoded. The delta (δ) parameter is not directly bound to reports. This parameter is rarely used in privacy budgeting. A maximum value for δ might be fixed as part of the configuration in a specific deployment. Setting a value for δ is necessary when selecting a differential privacy mechanism. In setting a value for δ, a deployment needs to consider the total report volume and the total number of tasks that each client might contribute to.

Privacy Budgeting A privacy budget ensures that the total information release can be bounded while providing more flexibility to the recipients of the noisy results. Recipients are able to adjust how budget is used to control how noise is distributed across multiple information releases. The amount of noise added to aggregates is based on the expended budget. In general, spending more privacy budget means that less noise is needed to maintain the same level of privacy; conversely, spending less budget means more noise. A budget might be specified in terms of a metric (like the epsilon parameter in (ε, δ)-differential privacy) that is expended with each information release. As noted, this extension uses the ε metric. For example, for an overall budget of ε=10 might be split four ways: (0.5, 1.5, 2, 6). Noise might then be added, drawing from a distribution with a width inversely proportional to the budget spent; that is, a distribution with a standard deviation proportional to 2, 2/3, 1/2, and 1/6 respectively.

Applicability to Differential Privacy Models When used in the Attribution API, the privacy budget report extension does not always encode the exact amount of privacy budget that was expended. The individual DP model used in Attribution (see ), allows a Client to expend less of its budget than this value for several reasons. This introduces some complexity, because any reduction in the budget spent is based on private information. Consequently, any reduced expenditure needs to be kept secret. In that setting, the extension reports the maximum possible expenditure. This extension gives users of the Attribution API the ability to manage privacy budget expenditure on a per-report basis. By binding the amount of budget spent to each report, the Client can transfer responsibility for applying noise to Aggregators. The addition of noise in the one place, can ensure a better trade-off between the amount of added noise and privacy parameters. The Attribution API differs from some other uses of DAP. which instead involve Clients adding noise to reports at the time they are generated. To maintain the usefulness of aggregates, the amount of noise added by each Client is kept low. To maintain strong privacy, Clients partly rely on DAP mixing their contributions with the contributions of other Clients, following the shuffle DP approach . Such uses depend on attaining a certain minimum batch size in order to meet their differential privacy targets. Applying noise during aggregation reduces the importance of the minimum batch size parameter in task configuration. However, it adds to the work that Clients need to trust Aggregators to perform. To maintain consistency with the DAP threat model for privacy (see ), this can mean either performing noise addition in an MPC protocol or having Aggregators each independently apply the requisite amount of noise. A number of MPC protocols for adding noise exist, but these are often not efficient in the two-party setting relative to the VDAF protocols typically used. On the other hand, the redundant addition of noise by Aggregators results in more noise when both Aggregators are honest. Even so, adding two amounts of noise often results in less overall noise than other approaches.

Collector-Selected Batch Mode The collector-selected batch mode (codepoint 0xTBD) give the Collector control over which reports are included in collection job. In this batch mode the Leader is not able to determine the associated batch for a report based on the contents of each report alone. This differs from the existing leader-selected () or time interval () batch modes. To that end, uploads of reports use a different URL template from the usual location for report uploads; see . This arrangement prevents the Leader from accepting reports until a collection job is created. A Leader MAY accept hold requests to upload reports for a short period prior to the creation of a collection job. Accepting reports would be on the expectation that a request to create the indicated collection job is imminent or still being processed, so it could reduce latency. However, the Leader MUST limit the reports it accepts prior to accepting the corresponding collection job. Without a limit, the Leader gives malicious actors the unrestricted capability to exhaust its resources. A Leader that does not accept reports MUST reject the request, and can respond with an indication to try later. This response could use a 404 status code and the Retry-After response field; see Sections and of . A Leader MUST reject attempts to upload reports to the regular report upload resource (as defined in ) when the collector-selected batch mode is configured for a task.

Report Upload URL Template Reports in the collector-selected batch mode are uploaded to a URL that follows the template: The inclusion of the collection job ID (see ) differs from other batch modes where the Collector does not need to provide any additional information to a Leader.

Batch Mode Parameters This batch mode uses the same parameters as the leader-selected batch mode (). That is, the payload Query.config is empty. Both the PartialBatchSelector.config and the BatchSelector.config contains a batch ID that is assigned by the Leader.

Minimum Privacy Budget Collection Job Extension The minimum privacy budget collection job extension (codepoint 0xTBD) allows a Collector to inform Aggregators of a minimum value for the privacy budget report extension (see ) that it expects to be included in the collection job. The format of this extension is a 32-bit network-endian encoding of an integer in units of micro-epsilon. This is identical to the format of the privacy budget report extension (). This extension is defined primarily as a safeguard. In the absence of this extension, Aggregators could determine the amount of privacy budget that was expended by every report and generate noise based on the minimum value across all reports. That approach is potentially error prone. If a Collector accidentally includes a report with a much lower budget, the Aggregate it receives would have more noise added than expected. The collection job extension effectively sets a cap on the noise that might be added. Aggregators can use this extension in one of two ways:

• The value in the collection job extension directly determines the magnitude of the noise that is added to the aggregate.
• The value is only used to filter reports and the minimum value of the privacy budget report extension across all accepted reports determines the magnitude of added noise.

The latter provides for lower noise in the case that the Collector provides a low value, but is more complex to implement. There is also no way provided to indicate to the Collector that less noise was added than they might have planned.

Collector Identity Task Extension The collector identity task extension (codepoint 0xTBD) binds the task -- and all reports submitted to that task -- to a single Collector. This extension does not specify how to encode the identity of the Collector. Different uses of DAP can choose an encoding that best suits the situation. The Attribution API has its own understanding of how to encode the identity of the Collector. The value is a UTF-8-encoded string of the registrable domain from the conversion site tuple.

Collector Identity and HPKE Configuration Regardless of how the Collector is identified, if an identity is included, the Leader and Helper MUST have a process for validating the HPKE configuration they use to encrypt aggregate shares for the Collector. That process MUST provide confirmation that the identified entity authorizes the HPKE configuration. This does not depend on active proof of possession for the corresponding private key but rather an affirmation that the public key is approved by the identified entity. One option for Collector identification is to use a URL, following the pattern used for the Leader and Helper (. If the URL uses an authenticated protocol, such as HTTP with the "https" scheme , retrieving an HPKE configuration from that URL (or similarly authenticated resources that are referenced from the response) provides the necessary authorization for the included key. The Attribution API does not define a process for authorizing a Collector HPKE configuration based on the encoded Collector identity.

Security Considerations Security factors specific to each extension are covered in the respective sections. Use of DAP is subject to the security considerations of DAP () and the VDAF that is in use (.

IANA Considerations TODO - update this for the collection job extension. ...and the change in where task configuration is likely to go. This document registers report extensions in the "Report Extension Identifiers" registry established in . New report extension registrations are tabulated in . DAP Extensions

Value	Name	Reference
TBD	privacy_budget

This document registers a new batch mode in the "Batch Modes Identifiers" registry established in . New report extension registrations are tabulated in . DAP Match Mode

Value	Name	Reference
TBD	collector_selected

This document registers task configuration extensions in the "Taskbind Extensions" registry established in . New task provisioning extensions are tabulated in . Task Configuration Extensions

Value	Name	Reference
TBD	collector_identity

References Normative References ISRG Cloudflare ISRG Independent Cloudflare There are many situations in which it is desirable to take measurements of data which people consider sensitive. In these cases, the entity taking the measurement is usually not interested in people's individual responses but rather in aggregated data. Conventional methods require collecting individual responses and then aggregating them on some server, thus representing a threat to user privacy and rendering many such measurements difficult and impractical. This document describes a multi-party Distributed Aggregation Protocol (DAP) for privacy preserving measurement which can be used to collect aggregate data without revealing any individual contributor's data. Apple Inc. Cloudflare An extension for the Distributed Aggregation Protocol (DAP) is specified that cryptographically binds the parameters of a task to the task's execution. In particular, when a client includes this extension with its report, the servers will only aggregate the report if all parties agree on the task parameters. This document also specifies an optional mechanism for in-band task provisioning that builds on the report extension. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Cisco ISRG Cloudflare Google This document describes Verifiable Distributed Aggregation Functions (VDAFs), a family of multi-party protocols for computing aggregate statistics over user measurements. These protocols are designed to ensure that, as long as at least one aggregation server executes the protocol honestly, individual measurements are never seen by any server in the clear. At the same time, VDAFs allow the servers to detect if a malicious or misconfigured client submitted an invalid measurement. Two concrete VDAFs are specified, one for general- purpose aggregation (Prio3) and another for heavy hitters (Poplar1). Informative References WHATWG Microsoft Research University of Pennsylvania Emerald The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. Springer Berlin Heidelberg The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.

Acknowledgments Roxana Geambesu noted that a binding to site identity () was an important component of a robust differential privacy system design for the Attribution API. David Cook provided useful feedback about the design and document. Chris Patton provided helpful input on how to integrate with the DAP architecture.