-
Notifications
You must be signed in to change notification settings - Fork 262
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
API for browser extensions? #25
Comments
Thanks for the question. In terms of disabling topics, that's certainly possible with extensions. In terms of modifying topics via javascript, that's something extensions (save for manifest v3) have the capability to do since they can inject arbitrary script. Which means that topics returned via js may have been modified by an extension (or some other script on the document). Topics sent via request headers are unmodified (due to the sec- prefix) so those should be preferred. |
Preferred by who? Why enable users to filter topics passed by one method but not another? |
It's not that we're "enabling" it in the javascript case, it's that javascript isn't 100% trustworthy when there are extensions involved. |
A user would want to be able to use a trusted extension to filter topics (as they can do with cookie manager extensions), but would not want an untrusted extension to modify topics to track them. But an untrusted extension could modify other headers to conceal a tracking identifier, so just preventing extensions from modifying topics doesn't seem like it provides any extra protection. |
As a browser user, I might choose to install an extension that will
It looks like the extension API should prevent extensions from seeing the user's topics or deducing any information about them, to limit incentives to submit malicious extensions.
Related: #78
The text was updated successfully, but these errors were encountered: