[madeofpalk]

> - people who use both a Web Extensions-supporting browser and Slack

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

> - people who install extensions with permissions to run arbitrary JS on every page

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.

[eyelidlessness]

> 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.

[awinter-py]

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

users are much more able to audit permissions than to audit changing code

but permissions need to be 'shaped like' APIs or else they are too broad to provide power + safety together

[TeMPOraL]

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.

[awinter-py]

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