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

Expanding technical checks specific for subset types #95

Open
helenyc opened this issue Aug 2, 2022 · 2 comments
Open

Expanding technical checks specific for subset types #95

helenyc opened this issue Aug 2, 2022 · 2 comments

Comments

@helenyc
Copy link

helenyc commented Aug 2, 2022

[Note: This issue captures an open question related to the changes proposed in PR #91 and summarized on issue #92]

Chrome hopes to mitigate abuse of set formation through a transparent assertion process, which will increase accountability by facilitating awareness for users, developers, and interested parties.

We are also proposing some technical measures to prevent the scope of abuse (e.g., limit on associated domains). We may consider expanding the technical checks, where possible, involved in mitigating abuse (e.g., to validate the ccTLD and common eTLD subset categories). What are possible technical checks we should consider?

@dmarti
Copy link

dmarti commented Aug 2, 2022

service sets: There should be several automatically checkable attributes of service domains. For example a service domain would not needs its own ads.txt, and would not be intended to show up in search results, so should be able to block general-interest web search crawlers in its robots.txt. The more that service domains can be required to limit their own functionality with web-standard or industry-standard configuration, the less incentive to abuse this subset of FPS.

associated sets: It looks like the process for reviewing "associated" sets are at risk of moderation and participation issues.

  • public participants who comment that a proposed set is invalid may be harassed or worse by proponents of that set who anticipate being able to make money from it

  • companies that propose a set may receive hostile comments or requests for disapproval based on unrelated complaints

The big challenge for technical checks for associated sets will be how to improve the community review process for all participants. I added a suggestion in a review of #92 -- require some user research when proposing a set, to show that the real members of the set's audience are already seeing the domains as a "party". The discussion of set validity should be based on research, not on subjective evaluations by reviewers.

The requirement to attach research could be automatically checked (but it would be hard to automatically check the content of the research)

Another way to lower the burden on set reviewers would be an automatically enforced delay between the rejection of a set and the earliest date when a domain from the rejected set could be submitted as part of a new set.

@jdcauley
Copy link

Branding Check:

Common and consistent brand association provides a much more meaningful indication of association to users.

Brand association could be consistently determined via reliable DOM Node defined in a way the browser can infer and validate reliably.

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

No branches or pull requests

4 participants