You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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?
Would the Chrome team, Safari team, and Mozilla team find this useful and be interested in implementing this?
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.
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.
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
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:
cc @jyasskin @miketaylr @marcoscaceres @jan-ivar who appear to be the most active these days on the spec and represent the different orgs.
The text was updated successfully, but these errors were encountered: