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

FPS as an attack surface #55

Open
dmarti opened this issue Aug 20, 2021 · 1 comment
Open

FPS as an attack surface #55

dmarti opened this issue Aug 20, 2021 · 1 comment
Labels
ua_policy Issues related to UA Policy

Comments

@dmarti
Copy link

dmarti commented Aug 20, 2021

This is an expanded version of the scenario I mentioned at the ad-hoc meeting on August 12.

  1. An independent publishing company, located in a jurisdiction where major browser vendors do not have employees or law firms, runs a controversial story about political corruption.

  2. Politicians who are named in the story hire people who familiar with the FPS governance process to challenge the publisher's FPS. They create fake public records (that might be obviously fake to a knowledgeable business person in the publisher's jurisdiction, but appear real to the browser vendor and/or FPS enforcement organization) and successfully get the publisher's FPS revoked.

  3. Browsers cease to recognize the publisher's FPS, causing them to lose ad revenue and business relationships.

A similar targeted attack on FPS could also take place against an FPS of product sites after a controversial decision to sponsor content or withdraw sponsorship.

Some FPS owners will be able to get this kind of thing fixed quickly because of the informal tech support system for policy-related web breakage. Somebody who follows you on Twitter or a back channel knows somebody, and they fix it. Or an Internet journalist decides it's worth a story. Less well-connected sites are at greater risk of having their FPSs broken, so are less likely to be confident in being able to use this feature.

dmarti added a commit to dmarti/first-party-sets that referenced this issue Aug 23, 2021
 * Remove reference to Do Not Track

 * Add a source and definition of "controller"

 * Remove language on ownership, replace with more consistent mentions of "controller"

 * Mention that common branding should apply to users of assistive technologies

Ownership verification is complex, does not add enforceable protections for users beyond the common controller requirement, and is likely to create costs and risks for some sites that would make it hard to use this feature.

Refs: WICG#14 WICG#18 WICG#20 WICG#49 WICG#55
@dmarti
Copy link
Author

dmarti commented Sep 2, 2021

Updated the description to make it clear how this is relevant to #56.

If FPS validity can depend on corporate ownership records, which are different across many different jurisdictions, then there are more opportunities for errors and deception..

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

No branches or pull requests

2 participants