Re: [w3ctag/design-reviews] WG New Spec: Attribution (Issue #1229)

bkardell left a comment (w3ctag/design-reviews#1229)

Thank you for bringing the Attribution specification to the TAG. 

The explanatory material in the specification is useful, but in order to conduct a good review, we do feel that a complete Explainer covering the broader design context, alternatives considered, trust model, user-agent responsibilities, interoperability expectations, and user benefit would have been/would still be helpful.  We also believe this would aid others as well (in wide review, for example).  This [has been requested](https://github.com/w3c/attribution/issues/464#issuecomment-4969461392)

The proposal gives browsers a central role in storing impressions, performing attribution, constructing reports, and interacting with aggregation services. This is a fairly significant shift in user-agent responsibility and as such an explainer might really help explain why it is justified.

If such an expansion of responsibilities moves forward, we believe that these are good qualities it seems to currently have:
* On-device attribution with only the attributed result leaving the device (§9.1) is a real architectural improvement over off-device designs, and the spec says so precisely.
* The undetectable enabled/disabled and success/failure behaviour (§8.2, §9.2) is the correct answer to the observability-vs-privacy tension.
* Central noise (§7.3) avoids the utility collapse of local DP.

In the meantime, we do have a few immediate questions, comments and suggestions which we will open much more detailed issues on and link:

* The formal DP guarantee is conditional on assumptions the spec states cannot hold. The per-site DP claim is not unconditional, and the spec acknowledges it.

* Privacy-determining parameters are implementation-defined with weak floors 

* Small-cohort / micro-targeting inference - It would be beneficial if the spec can analyse the worst case where an adversary engineers batch composition down to min_batch_size. Either raise the minimum, tie it to ε, or document the residual inference risk explicitly.

* Aggregation-service trust and governance are out of scope, but the guarantee depends on them 

* Ad fraud / invalid traffic is acknowledged but unmitigated on-device - should be surfaced as an explicit non-goal ("this API does not provide Sybil resistance for measurement integrity") rather than left implicit in a security subsection, since advertisers may otherwise assume the numbers are trustworthy.

* Enabled by default in third-party contexts, opt-out only:  The undetectable-opt-out design is genuinely good as it prevents discrimination against users who decline. But default-on, third-party-exposed, opt-out participation in a cross-site data flow is a configuration that does not follow the Privacy Principles' consent expectations. The "collective privacy" framing argues for a policy outcome (enable for everyone) inside a technical spec; the TAG should decide whether that argument belongs in normative material. We  think it is good to justify the * default and third-party availability against Design Principles ("Design for user intent") and ("Help users make good decisions"), which themselves point to the Privacy Principles' consent principles, and separate the normative behaviour from the advocacy (Note the API is already user-activation-gated per spec §4.2.2, so the concern is the consent model and defaults, not the absence of activation.)

* matchValue (and related fields) can carry identifiers
 - suggest cross-referencing §9.5 to the budget/cohort assumptions and state the residual risk when those are configured permissively.

* Side-channel mitigation is largely delegated and hard to test - define at least one normatively checkable property?

* Wall-clock dependence (§9.8): the one-time budget-renewal risk from forward clock jumps is acknowledged; consider a normative bound on tolerated forward correction within an epoch.

* Unconfigured browsers (§9.4): the requirement to obtain aggregator config out-of-band to avoid a timing/fingerprinting leak can be interop constraint and should be a MUST, not a SHOULD, given the consequence.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1229#issuecomment-5429541069
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1229/5429541069@github.com>