yes -- browser permission model needs to be much more granular

would be great if something like ublock is only able to disable dom elements, not insert them, for example, and has strong guarantees about not doing IO

permissions need to be 'shaped like' APIs -- users are much more able to audit permissions than to audit changing code

It should start with access permissions being limited to user-specified (even if prefilled) list of sites/domains. There are extensions clearly meant for a single page (e.g. improving the UX), or a class of pages. I never install them, because even if those pages are not critical, the permission request is always scoped to "all data, every site", which means that e.g. this nice plugin decluttering YouTube could also exfil data from my bank's webapp.

pretty sure chrome provides this? or at least whatever build of chromium I am on, at least for local-unbundled extensions

> This is just basically everyone using Slack, as Firefox, Chrome, and Safari support web extensions API

~Basically my point. I made allowances for people who use neither, but they’re a vanishingly small user share.

> I would bet that most people who use Chrome or Firefox install extensions that can run arbitrary JS on every page, like ad blockers, full page screenshot, or “nifty” discount-coupon-code extensions.

Pretty much my point. Along with the former point, the Venn diagram is roughly all Slack users.