Default to off for high risk contexts

[dmarti]

Publishers will need to check pages for level of user risk before activating. Set the permission policy to default off, so that high risk tracking is less likely to happen accidentally before this review.

See patcg/private-measurement#6

[csharrison]

This proposed change has severe consequences for the feature. In particular, sites which currently serve ads will have to make server side changes in order to enable the API and "unbreak" themselves in the face of 3pc deprecation.

This hurts adoptability of the API, as many publishers are not tech-savvy and may struggle with something like this, especially without a third party able to help them.

Note that currently, the API is already disabled by default in cross-origin iframes, so the feature will only be used by default on a publisher if code in the publisher's frame / security context uses the API.

[dmarti]

The problem is sites that have limited ability to change their HTTP headers (because of time, skills, or hosting plan) but have both high-risk contexts (such as health or financial support forum archives) and third-party scripts.

The maintainer of such a site has 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.

Easier for the sites that need conversion tracking to turn it on. Presumably those sites are commercial, with more development skills and hosting budget. And a site maintainer who is expecting conversion 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.

[csharrison]

The problem is sites that have limited ability to change their HTTP headers (because of time, skills, or hosting plan) but have both high-risk contexts (such as health or financial support forum archives) and third-party scripts.

The problem is that there is another set of sites with limited ability to change their HTTP headers, and if the API is disabled by default on those sites then they lose all their monetization. There is a real adoptability trade-off here.

Easier for the sites that need conversion tracking to turn it on. Presumably those sites are commercial, with more development skills and hosting budget. And a site maintainer who is expecting conversion 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.

This is definitely not true for publisher sites which are often not commercial sites. It is trivial, and imo should be trivial for a non-technical person to monetize a personal site with ads.

I think there is an important point missing here which is that if a high risk site is embedding untrusted 3p scripts, they have already lost the security game in some sense. An untrusted script can do far, far worse to a site than just register a conversion. It could completely change the contents of the site, exfiltrate passwords with a keylogger, fingerprint the user to learn conversion data, etc. It doesn't seem desirable to introduce a new security boundary of "making untrusted 3p scripts running in 1p context completely safe". This goal will be very hard to defend.

[dmarti]

I agree that a totally untrusted script can do more and can't usefully be protected against.

In typical cases, though, the site wouldn't be embedding completely untrusted third-party scripts, but typical third-party scripts from known companies, that are basically legal and designed to be fine in normal contexts -- but inappropriate for particular sites with high-risk contexts.

Hosting providers will figure out that they can use the permissions policy as a difference between "business" plans and "personal" plans. So web authors on the cheapest plans who want to participate in conversion tracking will be able to upgrade, and the high-risk sites will be able to protect their users by staying on the cheap plan. Defaulting the permission to off will mostly help with doing the right thing in the adoption time between browsers starting to do conversion tracking and hosting providers all setting the header appropriately.

[csharrison]

Defaulting the permission to off will mostly help with doing the right thing in the adoption time between browsers starting to do conversion tracking and hosting providers all setting the header appropriately.

On the contrary, I think that this will cause a huge shock to the entire web advertising ecosystem and will add years to the migration effort to adopt these APIs. Maybe I am wrong but this makes me nervous. Would you be up to discussing this in a future meeting?

[dmarti]

Yes, happy to discuss further.

[csharrison]

Thanks, I added to the agenda at bit.ly/ara-meeting-notes

[kayyyy44441]

• [ ]