Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default to off for high risk contexts #390

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

dmarti
Copy link

@dmarti dmarti commented Apr 28, 2022

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

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
Copy link
Collaborator

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
Copy link
Author

dmarti commented Apr 28, 2022

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.

EVENT.md Outdated Show resolved Hide resolved
@csharrison
Copy link
Collaborator

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.

Co-authored-by: Andrew Paseltiner <[email protected]>
@dmarti
Copy link
Author

dmarti commented Apr 28, 2022

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
Copy link
Collaborator

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
Copy link
Author

dmarti commented Apr 28, 2022

Yes, happy to discuss further.

@csharrison
Copy link
Collaborator

csharrison commented Apr 28, 2022

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

Copy link

@kayyyy44441 kayyyy44441 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • [ ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants