Intent to Implement: Conversion Measurement API

[Charles Harrison]

Contact emails

cshar...@chromium.org,kle...@google.com,john...@chromium.org,cam...@chromium.org

Explainer

https://github.com/csharrison/conversion-measurement-api

Design docs/spec

N/A

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]

It seems the minutes from the Improving Web Advertising Business Group are gated on a W3C login, my apologies.

[Steven Englehardt]

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 <cshar...@chromium.org> wrote:

Contact emails

cshar...@chromium.org,kleber@google.com,john...@chromium.org,cam...@chromium.org

[Ehsan Akhgari]

To add to what Steven mentioned below, I should also mention that we're aware that a separate explainer [1] published in this repository acknowledges the privacy issues in the main proposal and goes over a number of potential techniques for exposing only aggregate data to the reporting endpoints, but we believe none of these ideas are yet detailed enough to be relied on as a solution.  We are disappointed to see this intent being sent out before a solution to the issue of the publisher learning about the user's cross-site activity has been explored.

Best regards,

Ehsan

[1] https://github.com/csharrison/conversion-measurement-api/blob/master/AGGREGATE.md

On Thu, Oct 17, 2019 at 7:06 PM Steven Englehardt <sengl...@mozilla.com> wrote:

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 <cshar...@chromium.org> wrote:

Contact emails

cshar...@chromium.org,kle...@google.com,john...@chromium.org,cam...@chromium.org

--

Ehsan

[Charles Harrison]

Thanks for the feedback, Steven. The high entropy (event-level) identifier on the publisher-side here is a big risk, but we hoped we could mitigate it by highly constraining (and noising) information that the advertiser can join with it.

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 blink-dev+...@chromium.org.
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.

[john.w...@gmail.com]

John Wilander from Apple WebKit here. We’d like to flesh out our “public skepticism” of this feature. We’re not just skeptical, we’re opposed to it.

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.

[1] https://wicg.github.io/ad-click-attribution/index.html

[2] https://webkit.org/tracking-prevention-policy/

[3] https://github.com/WICG/trust-token-api

[jsec...@brave.com]

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.

1. 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.

2. 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.

3. 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.

4. 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]

On Fri, Nov 1, 2019 at 5:04 PM jsecretan via blink-dev <blin...@chromium.org> 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.

1. 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

[jsec...@brave.com]

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.

[Charles Harrison]

Thanks for the feedback everyone! We're looking into additional mitigations that could alleviate the "publisher learns about an individual user’s activity on a large number of destination sites" type of attack, as well as concrete parameters for rate-limiting the API. When we have an initial proposal for those points I'll update the explainer and ping this thread.

Some quick responses to a couple other points of feedback:

Setting up reporting domains: Our main requirement here was to minimize the need for publishers (and advertisers) to do significant amounts of work to monetize their sites while also maintaining the privacy properties of the API. Alternatives designs like forcing all reports to be sent directly to the publisher in our opinion place too high a burden on publishers that wish to just forward reports directly to their ad-tech provider(s).

Multiple conversions for the same impression: We agree that a priority system for multiple conversions is better for privacy in that it collapses multiple reports into a single one. However, it is not ideal for utility. One of the key questions the API wants to answer is "how many conversions are attributed to a click", and for many campaigns they want to count subsequent conversions (i.e. two separate purchases) as two conversions, not one. A priority system isn't as helpful for these cases. A rate-limiting budget should help prevent abuse of this feature.

On Wed, Nov 6, 2019 at 1:13 PM jsecretan via blink-dev <blin...@chromium.org> wrote:

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.

I'm not sure I follow some of these points. In terms of linking a publisher visit and an advertiser visit, observing the link click alone is sufficient to learn this information (user on publisher.com visited advertiser.com). The API doesn't unlock this new capability.

I'm also not sure how the API could be used to re-sync lost cookies,  can you explain how that would work?

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 <blin...@chromium.org> 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.

1. 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 blink-dev+...@chromium.org.

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.