-
Notifications
You must be signed in to change notification settings - Fork 77
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
Comments
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.
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. |
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. |
[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?
The text was updated successfully, but these errors were encountered: