-
Notifications
You must be signed in to change notification settings - Fork 6
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
Preventing fingerprinting via detecting the presence of downloaded language packs #3
Comments
As it's quite easy to get many unique sites using various free hosting services, wouldn't this be easily circumvented? |
Those sites would need to coordinate among each other within the same browsing session. I think that should not be possible if we restrict to top-level navigables with no opener. (E.g. by requiring COOP.) That's a pretty strong restriction however, in particular disallowing iframed widgets, so we might want to explore other ways of loosening it when possible... |
Can't they just navigate and include the information in the URL? |
But that doesn't allow them to join user identity; there's no way to say whether it's the same user navigating or a different user. |
That statement has a lot of underlying assumptions that don't currently hold I think. |
This issue is for discussing questions noted in the explainer about preventing fingerprinting via detecting the presence of downloaded language packs.
The Chrome team is currently investigating whether an approach such as the following would work for a "v0": each origin can see at most two languages as supported, the user's language and the site's detected language. We tell the truth about these two languages, but this should not give significant fingerprinting info, especially since it will vary across sites.
The details of making this abuse-resistant can be a bit tricky, e.g. to avoid an origin creating one invisible iframe for each language. But we think it should be doable. It might involve expanding from origin- to site-scoping.
This is quite limiting for some use cases, so we're interested in using some of the other mitigations mentioned in the explainer to expand beyond that. But we're waiting to see how much feedback we get on these limitations first.
The text was updated successfully, but these errors were encountered: