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

Can we extend the manifest file so that extensions can extend the permissions API? #383

Closed
kdenhartog opened this issue Sep 7, 2022 · 3 comments

Comments

@kdenhartog
Copy link
Member

I've recently been looking at the Permissions API in the context of extensions being able to extend them. One use case that's come up recently is that cryptocurrency wallets have an interest in being able to leverage the permissions API to be able to allow the user to determine with the wallet provider should be injected into a window.

For example, in Brave's cryptocurrency wallet, we have the ability to extend the Permissions API directly to prevent the wallet from being injected in third party iframes unless the user explicitly allows the permission and the main window uses the allow attribute set by this policy. However, because most other wallets are not built directly into the browser and instead are just extensions they aren't able to leverage these additional permissions. Because of this difference there arises web compatibility considerations where some wallets like Opera and Brave can support these capabilities, but many others cannot.

Ideally, it would be best to be able to allow the permissions API to be extensible by extensions as well such that they can register the native APIs as well as the allow attribute. While the main focus of my request is related to cryptocurrency wallets, I can imagine this being used by various other extensions as well. For example, it's well known that due to the way that password managers inject their JS objects into the window they open up additional attack vectors if the website has a XSS vulnerability to syphon passwords from the password manager. However, if a password manager is able to leverage the permissions API to limit where the objects are injected.

With this in mind, I've got two main questions:

  1. Is this the right place to have this discussion or is there a better place for me to take it like the webappsec-permissions-policy repo?
  2. Would the Chrome team, Safari team, and Mozilla team find this useful and be interested in implementing this?

cc @jyasskin @miketaylr @marcoscaceres @jan-ivar who appear to be the most active these days on the spec and represent the different orgs.

@jyasskin
Copy link
Member

jyasskin commented Sep 7, 2022

I think this issue belongs more in the Web Extensions CG since it's about an extension API to change how the permissions API works. @dotproto could confirm that. Feel free to reopen if I'm wrong.

@jyasskin jyasskin closed this as completed Sep 7, 2022
@KOLANICH
Copy link

KOLANICH commented Sep 7, 2022

I have asked Mozilla about that, but they were against allowing everyone (even to WebExtensions experiments having access to Firefox internals, the needed stuff were wrapped in a closure and so inaccessible from outside) to create new permissions and reuse their GUI for them.

@kdenhartog
Copy link
Member Author

Thanks @jyasskin for the recommendation on the better place to discuss this. I've opened an issue there for anyone who'd like to contribute to the discussion: w3c/webextensions#271

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

No branches or pull requests

3 participants