w3c / webextensions

Charter and administrivia for the WebExtensions Community Group (WECG)
Other
580 stars 50 forks source link

Proposal: add `disallow_host_permissions` #123

Open carlosjeurissen opened 2 years ago

carlosjeurissen commented 2 years ago

Related to the 2021-10-28 meeting about host permissions. As a developer, it can be helpful to determine a set of host_permissions which should not be granted to the extension.

An example could be granting permission for *.google.com yet excluding accounts.google.com due to security concerns. In this case it would basically have the same effect as having the user go to accounts.google.com and then remove host permissions from there.

Status

Apple Safari: In favor, only implemented for legacy extensions for now. Mozilla Firefox: in favor, not yet implemented. Google Chrome: awaiting response.

xeenon commented 2 years ago

This sounds good. I support this for Apple.

carlosjeurissen commented 2 years ago

This issue has been mentioned in Publish minutes of 2022-02-03 meeting.

Apple Safari and Mozilla Firefox seem to be in favor. @dotproto mentioned he will share Google's view async.

rdcronin commented 10 months ago

I'm supportive of this in Chrome. Allowing extensions to opt into reduced permissions always sounds good to me.

Jack-Works commented 10 months ago

what will happen if the extension programmatically & explicitly requests permission for the disallowed host?

e.g. in the case above, it's account.google.com

carlosjeurissen commented 8 months ago

@Jack-Works There are a few paths to take. 1) Raise an exception when requesting this permission / give an error when manifest host permissions colide. 2) Return as permission not granted 3) Just granting it yet have another layer in which the disallowed_host_permissions are subtracted.

@Jack-Works What do you think would be most logical here?

Jack-Works commented 8 months ago

@carlosjeurissen I believe it should be rejected.

carlosjeurissen commented 8 months ago

@Jack-Works So basically you are saying, when an extension author requests permissions for host X, Y, and for permission Z. Say host X is a disallowed_host_permission. The whole request should be rejected and no permission request should be displayed to the user?

There are some edge cases, like what if a more specific host_permission is requested. Say https://*.example.com/ is in disallowed_host_permission, and permission for https://accounts.example.com/ is requested. Should this be rejected as well?

Not sure there is a concept of partially granted permissions after / during a permission prompt. This could potentially be helpful.

ameshkov commented 3 months ago

I'd like to express support to this proposal, but I'd also like it to be extended -- the user also needs control over disallowed host permissions.

Currently, the host permissions only allow developers to include a list of websites where the extension is supposed to work on, but don't allow excluding them.

We often end up having extensions with <all_urls> host permissions and it's sometimes justified, but the problem is that users may need to be able to prevent extensions access to certain websites and currently the only way is to disable the extension completely.

The simple examples are websites with sensitive information: banking, medical records, etc. I would like to prevent extensions installed in my browser from accessing those. Instead of that I have to use a different browser to access these websites.

This proposal may in the future open a way to some new API that would allow websites to indicate that the information on the website is sensitive and extensions access to it may be undesirable (and then let the user decide how to deal with it).

xeenon commented 3 months ago

Safari already supports the user denying host permissions in the UI.

carlosjeurissen commented 3 months ago

This proposal may in the future open a way to some new API that would allow websites to indicate that the information on the website is sensitive and extensions access to it may be undesirable (and then let the user decide how to deal with it).

Seems the opposite can be useful as well. A website indicating it is of a certain type, for example, a shopping website. It could volunteer to work with a coupon extension. A lot can be done to improve the/any contract between websites and extensions in this regard. Think about opting in/out to password managers, cosmetic extensions, text writing companions and so on.

Potential downsides have briefly been discussed during TPAC 2023. The concern raised was the potential of abuse by non-bank websites. Say some evil actor has a website filled with ads. It pretends to be a bank and thus could avoid the ads from being blocked. So some form of user override might be welcome.

tophf commented 3 months ago

What about naming it exclude_host_permissions to match exclude_matches for content scripts?