Set the default Permissions-Policy

[dmarti]

Setting the Permission-Policy will require some sites to make an administrative change, with impact on either:

• If the default was off: Small publishers and retailers that want attribution tracking but do not have a lot of development skills would have to do some work in order to change the policy.

• If the default was on: Non-commercial sensitive or high-risk sites, that do not run ads or commerce, but have previously included a general-purpose third-party script that is later modified to call the API, would need to do some work to prevent the script from using the API.

The maintainers of sensitive non-commercial sites have limited options in the event a third-party script on such a site begins sending events from a high-risk context. If they even notice it they would have to remove the whole script (possibly breaking site functionality) switch hosting, or take the site down.

Sites that intend to participate in attribution tracking have more options. Because these sites are commercial, they have access to development skills and hosting support. Web hosts providing services to these commercial sites could turn the Permissions-Policy on for "business plan" customers, and leave it off for "basic" or "non-commercial" plans -- which would give both groups of site maintainers the right thing. Web CMSs and retail software could also in many cases set the header appropriately for contexts where the site maintainer chooses to do attribution tracking.

A site maintainer who is expecting attribution tracking and sees it not happening is more likely to figure out what's going on and fix it than a site maintainer who has not heard of this proposal.

• Feature Discussion: High Risk Contexts · Issue #6 · patcg/private-measurement

• Default to off for high risk contexts by dmarti · Pull Request #390 · WICG/conversion-measurement-api

(edited to make it clear that the second category of sites includes non-commercial)

[alextcone]

The maintainers of sensitive non-commercial sites have limited options in the event a third-party script on such a site begins sending events from a high-risk context. If they even notice it they would have to remove the whole script (possibly breaking site functionality) switch hosting, or take the site down.

Am I understanding correctly the scope of the "high-risk context" threat you're looking to address? Reading this issue and the linked documentation I understand you're concerned about these cases:

• "sensitive, non-commercial sites" that show ads containing code from advertisers (and their tech) which defines source events in the context of the Attribution Reporting API
• "sensitive, non-commercial sites" not wishing to set trigger events in the context of the Attribution Reporting API

Is this understanding of high-risk contexts correct?

[dmarti]

Updated issue description.

A good example of a high-risk context is a non-commercial health-related support forum or educational site.

These sites do not run ads, but often include third-party resources such as image embed widgets.

[alextcone]

These sites do not run ads, but often include third-party resources such as image embed widgets.

And your concern is that the third-party resources will make use of the Attribution Reporting API features, without the property owner's knowledge while on page (in app)?

[dmarti]

Technically it will be with the web site maintainer's knowledge, because they will send out a long "important updates to our terms of service", but many web site maintainers will not read it, or the email will go to someone who originally set up the third-party widget but doesn't work on the site any more.

[alextcone]

Ok, so if I update my question to read:

And your concern is that the third-party resources will make use of the Attribution Reporting API features, without the property owner's web site maintainer's (or someone who original set up the third-party widgets) knowledge while on page (in app)?

...is this a fair understanding of the concern you're raising with this Issue? Yes or no?

[dmarti]

@alextcone Yes, that's fair, thank you. The problem is what happens when third parties that didn't previously do something switch over to doing it.

Possibly related: https://www.w3.org/TR/SRI/ (Maybe if all 3rd party scripts on a page have SRI it would be fine to have the API on, since it's a signal that the site maintainer has checked/approved a certain version)

[chandan-giri]

The choice of default value of permission policy will very likely impact the adoption and effectiveness of Attribution Reporting API. Setting the value to off by default will require both publishers and advertisers to make server side changes to enable the APIs. This would require large scale advertiser and publisher outreach to enable the APIs. Furthermore, Publishers would likely no longer be able to accurately measure the impact of their media due to some advertisers not having turned this on which might limit the effectiveness of the APIs for the ecosystem.
Google ads proposes the default value to be set to on for both publishers and advertisers to simplify and streamline adoption of the Attribution Reporting APIs. We also believe that easy opt outs for those who don't want to participate strikes the right balance between building an effective privacy preserving APIs and giving partners the right choice of controls over the API usage.

[lbdvt]

And your concern is that the third-party resources will make use of the Attribution Reporting API features, without the property owner's web site maintainer's (or someone who original set up the third-party widgets) knowledge while on page (in app)?

What would third-party resources get from such a use?

[csharrison]

In #558 we decided to default the API to be enabled by default, for the sake of feasibility. That issue and many of our meetings on this (1,2,3) have more context for this decision. Closing this out for now, although like I said in #558 we are interested in continuing to explore changes to Permissions Policy that have greater chances at widespread adoption.