Intent to Implement: Conversion Measurement API
Charles Harrison
Contact emails
[email protected],[email protected],[email protected],[email protected]
Explainer
https://github.com/csharrison/conversion-measurement-api
Design docs/spec
TAG review
Filed: https://github.com/w3ctag/design-reviews/issues/418
Summary
This is a new API for measuring conversions (e.g. purchases) and attributing them to clicked ads, without using cross-site persistent identifiers like third party cookies.
Note that this is a very early stage design, and we’re explicitly not asking for permission to ship yet. We would like to get initial feedback on the idea and start prototyping.
Motivation
Currently, the web ad industry measures conversions via identifiers they can associate across sites. These identifiers tie information about which ads were clicked to information about activity on the advertiser's site (the conversion). This allows advertisers to measure ROI, and for the entire ads ecosystem to understand how well ads perform.
Since the ads industry today uses common identifiers across advertiser and publisher sites to track conversions, these common identifiers can be used to enable other forms of cross-site tracking.
This doesn’t have to be the case, though, especially in cases where identifiers like third party cookies are either unavailable or undesirable. A new API surface can be added to the web platform to satisfy this use-case without them, in a way that provides better privacy to users.
Risks
Interoperability and Compatibility
Safari proposed a very similar API, the Privacy Preserving Ad Click Attribution
API and it is currently in experimental development. We believe that the ad click attribution API does not provide enough utility to developers, and this is an alternative. There is an interoperability risk of two competing but similar APIs on the web, but we hope to work with Safari on a joint proposal that works for all browsers.
Firefox: No public signals
Edge: No public signals
Safari: Public skepticism, especially around the 64 bit impression metadata (https://www.w3.org/2019/09/18-ad-privacy-minutes.html)
Web developers: Positive (https://www.w3.org/2019/09/04-web-adv-minutes.html)
Positive feedback from Facebook that this API can be used to train ML models
Ergonomics
N/A
Activation
This API requires multiple sites to collaborate to activate its potential, but otherwise it should be straightforward to use.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
No
We intend to test this with Web Platform Tests
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6412002824028160
This intent message was generated by Chrome Platform Status.
Charles Harrison
Steven Englehardt
The publisher site can learn information about individuals by associating the “impression data” value with a user identifier at the time of conversion registration (i.e., when the user clicks on an ad on the publisher site). Then, information revealed by the “conversion-metadata” value can be associated with that user’s account through the link created by the “impression data” value. In practice, this may be sensitive information like whether that user made a purchase on the destination site, or whether they registered for an account.
To understand the severity of the risk associated with allowing the publisher to collect activity data associated with an individual through this API, consider that the publisher may be a search engine or social network that acts as a user’s primary access point to the rest of the web. Publishers in this position are likely to learn about an individual user’s activity on a large number of destination sites, and thus build a fairly comprehensive picture of that user’s off-site purchase activity, off-site registration activity, and so on.
[0] https://wiki.mozilla.org/Security/Anti_tracking_policy
On Tuesday, October 15, 2019 at 1:24:17 PM UTC-7, Charles Harrison wrote:
It seems the minutes from the Improving Web Advertising Business Group are gated on a W3C login, my apologies.
On Tue, Oct 15, 2019 at 3:54 PM Charles Harrison <[email protected]> wrote:
Contact emails
[email protected],[email protected],[email protected],[email protected]
Ehsan Akhgari
[1] https://github.com/csharrison/conversion-measurement-api/blob/master/AGGREGATE.md
I would like to voice Mozilla’s concerns regarding the introduction of a high-entropy cross-site identifier, which I also expressed at the aforementioned TPAC meeting. The high-entropy “impression data” identifier gives the publisher site the ability to learn information about an individual user’s activity on a site other than their own. This is an explicit violation of Firefox’s anti-tracking policy [0], and we are not going to to implement an API that facilitates such a violation because it enables cross-site tracking.
The publisher site can learn information about individuals by associating the “impression data” value with a user identifier at the time of conversion registration (i.e., when the user clicks on an ad on the publisher site). Then, information revealed by the “conversion-metadata” value can be associated with that user’s account through the link created by the “impression data” value. In practice, this may be sensitive information like whether that user made a purchase on the destination site, or whether they registered for an account.
To understand the severity of the risk associated with allowing the publisher to collect activity data associated with an individual through this API, consider that the publisher may be a search engine or social network that acts as a user’s primary access point to the rest of the web. Publishers in this position are likely to learn about an individual user’s activity on a large number of destination sites, and thus build a fairly comprehensive picture of that user’s off-site purchase activity, off-site registration activity, and so on.
[0] https://wiki.mozilla.org/Security/Anti_tracking_policy
On Tuesday, October 15, 2019 at 1:24:17 PM UTC-7, Charles Harrison wrote:
It seems the minutes from the Improving Web Advertising Business Group are gated on a W3C login, my apologies.
On Tue, Oct 15, 2019 at 3:54 PM Charles Harrison <[email protected]> wrote:
Contact emails
[email protected],[email protected],[email protected],[email protected]
--
Charles Harrison
From use-cases we've heard, the critical functionality the event-level identifier has is the ability to label some ML inference (the conversion metadata being that label). In that context, the bits of conversion metadata are just icing on the cake to allow slightly more granular labels; the most valuable part is just learning that a conversion for a specific event happened in the first place, which could be achieved without any conversion metadata at all.
I understand that this still leaks some small amount of “cross site activity”, and how it violates Firefox’s tracking policy. We feel like this trade-off is worth it due to the critical functionality it unlocks for ads without the need for third party cookies or other stable, cross site identifiers.
As Ehsan says, we are iterating on a variant of this proposal that uses some server side smarts to provide even stronger guarantees on privacy and aggregation. Unfortunately, those solutions still don’t allow for this “labeling” functionality, though we hope to share something more in that space soon. Our intention is to provide both aggregate and event-level variants of the API simultaneously.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANTur_7NdgKxbPA3n1YZa1Egtt7FzzjcNr9YgxQpF-Bp00PN1A%40mail.gmail.com.
We support what Mozilla says above and we’ve shared our view of what a privacy-preserving click measurement API should look like in our Private Click Measurement proposal [1].
Proposed “conversion-metadata” Is a Case of Cross-Site Tracking
We think "classic" user tracking capabilities were never the intent of cookies or other means of storage and state on the web, rather an unfortunate side effect of them. We are actively working on reducing tracking capabilities as explained in our Tracking Prevention Policy [2].
Chrome’s proposed Conversion Measurement with its high entropy “conversion-metadata” is a case of cross-site tracking and thus violates WebKit’s Tracking Prevention Policy.
Adding Intentional User Tracking Features Legitimizes Tracking
Chrome’s proposed Conversion Measurement feature will for the first time explicitly add a feature to the web platform intended to facilitate tracking of individual user activity across websites. This would evolve the web in the wrong direction and legitimize cross-site tracking.
As an example, Chrome’s proposed 64 bit identifier allows the click source to track 2.4 billion individual clicks per human on earth. We don’t think the web platform should support such tracking.
The Threat Model Needs To Cover Misuse
Our Private Click Measurement proposal [1] takes into account bad website behavior and Chrome’s Conversion Measurement proposal needs to do so too. Click source websites may add high entropy click tracking info to arbitrary links, not just ad links.
Regarding Fraud Prevention
The argument that the click source needs high entropy tracking info to fight fraud should take into account Chrome’s other proposal called Trust Tokens [3]. The better way to fight fraud is with privacy-sparing techniques like this and remove any user identifying tracking info.
Interoperability Is Still A Goal
Finally, regardless of whether Chrome moves ahead with Conversion Measurement or not, we still hope web browsers can agree on a shared syntax between our proposed Private Click Measurement and Chrome’s proposed Conversion Measurement so that websites can add meta data to ad links and have measurement work across browsers.
[3] https://github.com/WICG/trust-token-api
At Brave, we have been examining and discussing the proposed conversion measurement API detailed here: https://github.com/csharrison/conversion-measurement-api. While we applaud efforts to build privacy safe mechanisms for ad supported revenue models, we do not believe that this proposal comes close to being sufficient. We agree with many of the points brought up by our colleagues at Mozilla and Apple in recommending a significant overhaul to the proposal.
We agree with our colleague at Apple that, fundamentally, this proposal provides unnecessary cross-site tracking. The use of a 64-bit impression ID provides more than enough linkability across multiple uses of this conversion API, allowing a large ad-tech provider, such as Google, to build a significant longitudinal profile. While the proposal mentions provisions for throttling, it is hard to imagine how these valuable conversion events could be throttled in a way that would consistently resist overuse. Even a handful of these events in a month can allow significant linkability and it is doubtful the limits still under discussion in the proposal would be that low by default.
As mentioned by our colleague at Apple, the unique impression ID is not required to resist fraud. We are already actively making use of a blinded token setup, similar to the Chrome Trust Token proposal, to make sure requests are authenticated but not identifying.
The proposal is currently written in a way that makes it most useful within a handful of “walled gardens”. The proposal specifies that the publisher will authorize conversion reporting for an an ad tech provider. This works out fine when the ad tech provider is Google, as frequently it is leveraged by both the publisher (Google’s DFP) and the buy side (Google AdX). But the ad stack on publisher pages can be far more complex, often being served by 2 or 3 partners downstream. To keep this running equitably, it would require the publisher to tediously setup downstream partners for reporting in iframe authorizations, or just to allow reporting from any source, which would certainly be bad for privacy. If the publisher, for instance, had Google as both provider and the only reporter, this would afford Google a significant advantage over any competitors, creating a potential antitrust issue.
Instead of what the proposal specifies for “multiple conversions for the same impression”, we recommend the more private “priority” system laid out in the Webkit proposal.
We would be happy to work with our colleagues at Google on ways to enforce real privacy while meeting marketer goals. In the meantime, we recommend that Google reconsider their proposal.
Jeffrey Yasskin
At Brave, we have been examining and discussing the proposed conversion measurement API detailed here: https://github.com/csharrison/conversion-measurement-api. While we applaud efforts to build privacy safe mechanisms for ad supported revenue models, we do not believe that this proposal comes close to being sufficient. We agree with many of the points brought up by our colleagues at Mozilla and Apple in recommending a significant overhaul to the proposal.
We agree with our colleague at Apple that, fundamentally, this proposal provides unnecessary cross-site tracking. The use of a 64-bit impression ID provides more than enough linkability across multiple uses of this conversion API, allowing a large ad-tech provider, such as Google, to build a significant longitudinal profile. While the proposal mentions provisions for throttling, it is hard to imagine how these valuable conversion events could be throttled in a way that would consistently resist overuse. Even a handful of these events in a month can allow significant linkability and it is doubtful the limits still under discussion in the proposal would be that low by default.
Charles Harrison
Thanks for the reply Jeffrey. So yes, (2) is more of the issue here, with the publisher able to receive conversion information based on how it specifies the reporting domains. Furthermore, the identifier also provides a link between a publisher visited and an advertiser visited to the adtech provider. It also provides the adtech provider an additional opportunity for re-syncing lost cookies or modified fingerprints by using that unique impression id.
On Saturday, November 2, 2019 at 11:37:17 PM UTC-4, Jeffrey Yasskin wrote:On Fri, Nov 1, 2019 at 5:04 PM jsecretan via blink-dev <[email protected]> wrote:At Brave, we have been examining and discussing the proposed conversion measurement API detailed here: https://github.com/csharrison/conversion-measurement-api. While we applaud efforts to build privacy safe mechanisms for ad supported revenue models, we do not believe that this proposal comes close to being sufficient. We agree with many of the points brought up by our colleagues at Mozilla and Apple in recommending a significant overhaul to the proposal.
We agree with our colleague at Apple that, fundamentally, this proposal provides unnecessary cross-site tracking. The use of a 64-bit impression ID provides more than enough linkability across multiple uses of this conversion API, allowing a large ad-tech provider, such as Google, to build a significant longitudinal profile. While the proposal mentions provisions for throttling, it is hard to imagine how these valuable conversion events could be throttled in a way that would consistently resist overuse. Even a handful of these events in a month can allow significant linkability and it is doubtful the limits still under discussion in the proposal would be that low by default.
Thank you for sending feedback. I haven't been involved in the design of this API, but I wanted to clarify an aspect of this feedback: What do you mean by "linkability" here?1) Are you saying that the proposal in this thread allows two websites to share their respective user IDs for a person? That is, learn that person X has user ID A on publisher.example.com and user ID B on advertiser.example.com?2) Or are you worried more about the issue Steven pointed out, that the publisher can learn facts like "the person with user ID A on publisher.example.com is signed in and bought something on advertiser.example.com"?https://github.com/csharrison/conversion-measurement-api#privacy-considerations claims (1) is impractical, so if that's what you're worried about, I'd like to hear more details of the steps in the attack.Thanks,Jeffrey
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b5c10d29-2fe1-4917-828d-13dbf412c9b5%40chromium.org.