Comment by jackfranklyn
2 days ago
The permissions model for browser extensions has always been backwards. You grant full access at install time, then cross your fingers that nothing changes in an update.
What we actually need is runtime permissions that fire when the extension tries to do something suspicious - like exfiltrating data to domains that aren't related to its stated function. iOS does this reasonably well for apps. Extensions should too.
The "Recommended" badge helps but it's a bandaid. If an extension needs "read and change all data on all websites" to work, maybe it shouldn't work.
We actually have this with the permissions API. The issue is everyone just opts for longer approval times and less intrusive UX with manifest level permissions.
I agree though, runtime permissions should be the default
A big problem is also that you can pretty much only grant permission for one specific site or all sites and this very much depends on which of those two options the extension uses.
For example there's no need for the "inject custom JS or CSS into websites" extensions to need permission to read and write data on every single website you visit. If you only want to use them to make a few specific sites more accessible to you that doesn't mean you're okay with them touching your online banking. Especially when most of these already let you define specific URLs or patterns each rule/script should apply to.
I understand that there are still vectors for data exfiltration when the same extension has permissions on two different sites and that "code injection as a service" is inherently risky (although cross-origin policies can already lock this down somewhat) but in 2025 I'd hope we could have a more granular permission model for browser extensions that actually supports sandboxing.
You can grant access to a few specific sites (in chrome at least), it's just hidden in settings and you need to configure it manually.