Proposal: extend the manifest file so that extensions can extend the permissions API

[kdenhartog]

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?

[xeenon]

I'm not entirely sure I follow what you are proposing. Can you give some code examples?

This is the right place for this.

[kdenhartog]

The end goal here is for the permissions policy to be accessible to extensions to affect the behavior of the allow attribute. This is useful for having extension based wallets being able to imitate this logic would be useful for web compatibility of SPAs in web3 across a variety of wallets. As for how that's achieve I have an idea in mind (expose the permissions API to extensions so they can hook into it and add additional permissions), but I'm not necessarily certain it's the best way to approach the problem. Specifically, I'd like for this case to be achievable by extensions:

Top level https://a.com with <iframe src="https://b.com" sandbox="allow-scripts" allow="ethereum"> -> ethereum provider object (injected by an extension like metamask) can be injected in top level.

Right now, Brave wallet does this via checking the state of the permissions API which allows our wallet to detect this and inject the provider if the user consents to it. If the permission is not granted then the provider wouldn't be injected since there's a 3rd party iframe.

For more details on the logic here's the docs of how we handle this: https://wallet-docs.brave.com/provider-availability/

Here's code where our implementation was refactored a bit to enable this for both ethereum and solana wallets. brave/brave-core#12945

[bershanskiy]

The end goal here is for the permissions policy to be accessible to extensions to affect the behavior of the allow attribute. This is useful for having extension based wallets being able to imitate this logic would be useful for web compatibility of SPAs in web3 across a variety of wallets.

This sounds very niche and probably irrelevant to most browsers. One possible way to implement this would be to extend manifest.json so that content_scripts elements have an extra optional attribute called permission which can be a string. The browser could inject said content script only if said permission string is present in the iframe allow attribute or Permissions-Policy or Feature-Policy header and be integrated with Permissions API as if it was proper permission.

[Rob--W]

The feature request here is difficult to understand for people without prior context. Could you try to be more explicit about what you'd like to see? The request here asks for "extend the permission API", but that is very vague and not well defined.
It looks like you're mainly interested in querying whether your custom feature is present in an allow attribute (maybe even Feature-Policy / Permissions-Policy response header). And then there are questions on what to do in case of nested frames and/or sandboxed browsing contexts.

While the description definitely suggests the desire to query the status, it is not clear whether you're also looking for a way to modify the policy for existing documents. An example of such a use case (modifying policies rather than interpreting them) has been voiced in https://bugzilla.mozilla.org/show_bug.cgi?id=1771352.

While extensions could potentially be a vehicle to extend the permission policy, I think that we need to be very careful here. This is a web platform API, and if extensions are able to register arbitrary identifiers, there is a chance of conflicts with (future) standard keywords, or even conflicts with different extensions trying to claim a keyword. I have no interest in pursuing this feature request until there is an informed decision (approval) from the owners of this feature.

[kdenhartog]

Yup, it's similar to what you've essentially described @bershanskiy. Basically something like this added to the manifest.json

permissions: {
  "<permission name">: [
    <DOM Path to API 1>,
    <DOM Path to API 2>,
    etc,
  ]
}

Which would allow an extension to be able to register a string (via the <permission name>) that's usable with the permissions policy. I think the primary purpose for it to be able to utilize the browser's permission logic to decide when and where extensions should be used and when they can be enabled by the user via the permissions API. Right now they end up as on by default for every page unless the extension decides to limit itself or the user changes the default which is set to Enable it for every site (picture taken from UI accessed via the "manage extensions" setting available under chrome://extensions/?id=).

So for example, with the permissions API it would work in the following way if an extension registers a permission.

Ask -> If a website uses the allow property it will prompt the user to enable the extension for this origin (default)
Enabled -> It is allowed for this origin
Disabled -> It is not allowed for this origin

if extensions are able to register arbitrary identifiers, there is a chance of conflicts with (future) standard keywords, or even conflicts with different extensions trying to claim a keyword

Agreed there definitely needs to be carefully consideration here. In some cases these conflicts may be useful (e.g. it would be useful for wallets in web3 to register under the same permission so that web pages don't need to actively track every wallet created and ask for access), however in many others it may be harmful. Especially in the case where a malicious extension registers intentionally under a separate permission to trick the user into granting access that a user wouldn't want to if they were properly informed. To me this seems like the trickiest part of this, but if done right it allows for the extension model to align much better with the Principle of Least Privileges than what we have today.