Proposal: Url Denylist. A basic feature with massive security benefits.

[Caleb Sparks]

The problem:

Chrome extensions frequently request the ability to access any site [1]. Users may either not recognize the significance of that or simply trust the developers to not abuse the power. Developers may not be trustworthy or their extension may be taken over by untrustworthy parties. Once the user is hacked (it only takes one extension!) the “any site” privilege gives access to sites where security is essential, like banking and financial institutions.

Current Protection Measures:

• Automated review of extension code

• Ability to allowlist allowed sites

• Isolation of extension code

• Opening sensitive sites in incognito mode

Why they are not enough:

• Automated review of extension code

  • Does not catch everything. Some extensions pass through filter - examples

• Ability to allowlist allowed sites

  • Does not apply to extensions that realistically need access to all sites. For example, https://darkreader.org

  • Does not apply to extensions that apply to a dynamic, changing set of sites.

• Isolation of extension code with access to chrome API’s

  • Protects extensions from websites but not the other way around

• Opening sensitive sites in incognito mode

  • Effective in terms of security but practically speaking an annoyance

Proposal: A global denylist to limit “any site” access

A global denylist would restrict extension access from all sites listed by the user. It would let a person use a “any site” extension while still being confident that it will not access their personal or financial records in the sites denylisted. It’s simple, straightforward, and a relatively easy addition to Chrome. Once the global denylist is put in place, the concept could be expanded upon further. There could be extension-specific denylists. There could also be a default denylist of the top 10 major financial institutions. For example, Tampermonkey comes with the following defaults in it’s denylist:

*example.org/*
*paypal.tld/*
*stripe.com/*
https://*deutsche-bank-24.tld/*
https://*bankofamerica.tld/*
/^.*:\/\/apis\.google\.com\/((?!render)([^\/]+)\/)+([^\/]+)?$/
*://www.facebook.com/plugins/*
*://platform.twitter.com/widgets/*

Footnotes

[1]: You can also verify this empirically by picking random extensions on the Chrome web store. Many of them request read/write access to all websites, like Google translate, Honey, Redux Devtools, Guru, and more.

[Stefan Van Damme]

Hi there,

Whether you know it or not, there is the "activeTab" permission that only works if you click the button (on the currently open tab). That should reduce broad host permissions.

https://developer.chrome.com/docs/extensions/mv3/manifest/activeTab/

https://groups.google.com/a/chromium.org/g/chromium-extensions/c/FtHQ8e9V7ag/m/szKkfW6cEgAJ

Proposal of WebExtension (= all web browsers) can be submitted here:

https://github.com/w3c/webextensions

Note: The Chrome Web Store team reviews each updated Chrome extension and also checks for unused permissions. And can block Chrome extension update.

Thanks,

Stefan vd

[wOxxOm]

A new UI for site access and denial is being developed by Chrome team for quite some time, there's even a flag to enable the current half-implemented feature, I didn't try it myself but I suppose it's not yet ready to be used, which might be one of the major underlying reasons why ManifestV2 was given some breathing space in the web store until the next summer.

Technically this has been already implemented long time ago via ExtensionSettings Chrome policy's runtime_blocked_hosts, which can be specified for all extensions and then re-allowed an a per-extension basis via runtime_allowed_hosts. It's widely used in managed environments. It can be also used by an individual, although it's pretty inconvenient. I use it myself to protect accounts.google.com and other sensitive sites so that I don't have to use a separate browser profile just to read an email.

[Caleb Sparks]

> Proposal of WebExtension (= all web browsers) can be submitted here:

https://github.com/w3c/webextensions

I see, thanks for the link!

> A new UI for site access and denial is being developed by Chrome team for quite some time, there's even a flag to enable the current half-implemented feature, I didn't try it myself but I suppose it's not yet ready to be used, which might be one of the major underlying reasons why ManifestV2 was given some breathing space in the web store until the next summer. Technically this has been already implemented long time ago via ExtensionSettings Chrome policy's runtime_blocked_hosts, which can be specified for all extensions and then re-allowed an a per-extension basis via runtime_allowed_hosts. It's widely used in managed environments. It can be also used by an individual, although it's pretty inconvenient. I use it myself to protect accounts.google.com and other sensitive sites so that I don't have to use a separate browser profile just to read an email.

Interesting. I'm glad to hear there's some work on it already.

[Stefan Van Damme]

Hi there,

|| > Proposal of WebExtension (= all web browsers) can be submitted here:

|| https://github.com/w3c/webextensions

|| I see, thanks for the link!

You are welcome.

Thanks,

Stefan vd