Feature Discussion: High Risk Contexts

[dmarti]

A related proposal from the Anti-Fraud CG is Anti-Fraud Safelist.

A site would be able to request that a page be treated as a "high-risk context" for purposes of fraud countermeasures.

If a page is a high-risk context, user acfions on that page would not be subject to conversion tracking.

[AramZS]

Making note here to sync with Anti-Fraud group.

[michaelkleber]

It seems like there are probably multiple incompatible notions of "high-risk" at play.

For example, consider the page on which a person enters their credit card number and clicks "Purchase". That event surely high-risk on the fraud side, since it involves a financial transaction. But it is surely an event that advertisers would want to consider a conversion, since it involves a financial transaction.

[dmarti]

@michaelkleber Some purchase pages would be "high-risk" while others might not. If the user had sufficient time and skills to do conversion reporting manually, would they choose to report the activity?

[bmayd]

When working with clients with conversion page constraints similar to those imposed by the high-risk contexts proposal (i.e., no pixels on the conversion page) we would move the pixels to an adjacent context, usually a thank you page. I assume there are various similar means of isolating high-risk contexts that could be employed.

[csharrison]

My strong preference is that we don't introduce a vague notion of "high risk" into the platform that bleeds out into a bunch of different behaviors across many APIs. Each API should have the proper controls such that pages that identity as "high risk" can configure to get the behavior they desire. This avoids a layer of indirection where everyone needs to remember that "high risk" implies a laundry list of auxiliary behaviors.

It turns out that individual feature controls and configuration is an existing thing on the web platform, called Permissions Policy. In particular, here is one of the motivations:

The developer may want to selectively disable access to certain browser features and APIs to "lock down" their application, as a security or performance precaution, to prevent own and third-party content executing within their application from introducing unwanted or unexpected behaviors within their application.

It sounds like high risk pages could just use Permissions Policy to lock down certain behaviors manually. In fact, the Attribution Reporting API already proposes to use Permissions Policy for this purpose: https://github.com/WICG/conversion-measurement-api/blob/main/EVENT.md#publisher-side-controls-for-attribution-source-declaration

[dmarti]

@csharrison Thank you -- this is helpful. It looks like the permissions policy text in the proposal is most of the way there. See linked pull request.