3 ms·

Naturally this required the "Access your data for all web sites" permission -- most powerful/useful extensions need this permission. But I've been pretty conser

by morsch 4y ago

Naturally this required the "Access your data for all web sites" permission -- most powerful/useful extensions need this permission. But I've been pretty conservative in adding extensions with it (as in, just two, including the obligatory UBO). Why isn't there a permission where the add-on doesn't get to access anything until I activate it for a specific tab, and then it only gets to access to that specific tab? Unclutter would be most useful on websites where I'm not particularly worried about misuse, but I don't want it to be able to read my emails. This is not meant as a dig at this add-on or its author, I have no reason to believe he's not trustworthy, I think it's a limitation of the add-on permission model.

simcop2387 4y ago
I'd also love it if there was one that allowed for additional sandboxing. i.e. it can read anything but can never store or talk to the network or cause a network call to happen. I know that'd be harder to do but it'd also allow for a lot of nice add-ons to be made.
cxr 4y ago
"Access your data[...] for a specific tab" basically describes what a bookmarklet does (where by "specific tab", you mean "a given page—the one loaded in the focused tab when you activate the bookmarklet").
phgn 4y ago
It's possible for extensions to only get access when you activate it for a specific tab. If you want Unclutter to work this way you can manually set "Site access" to "On click" in the Chrome extension settings (this doesn't work on Firefox unfortunately). The reason I enabled "all sites" by default is to make the automatic activation feature work, which used to be more powerful. Possibly it can be done with an optional permission now, I'll look into it: https://github.com/lindylearn/unclutter/issues/527 https://github.com/lindylearn/unclutter/issues/527 Thanks for the feedback! Also, if you don't like something you can always submit a PR ;)
- morsch 4y ago
  Sorry, I should have been more specific, I'm on Firefox. Nice that it's already possible in Chrome. It was intended to be a comment about the limited power of the permission model in Firefox, though I have now learned from the sibling comment that Firefox actually has the permission I was thinking of.
  - phgn 4y ago
    Yep, but extensions still have to adopt the more restrictive permissions.
k1m 4y ago
There is an activeTab permission which does this (limits access). Mozilla: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#activetab_permission https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web... Chrome: https://developer.chrome.com/docs/extensions/mv3/manifest/activeTab/ https://developer.chrome.com/docs/extensions/mv3/manifest/ac...
- morsch 4y ago
  That sounds like it's exactly what I want, thanks, very interesting.
dredmorbius 4y ago
There's also a tremendous difference between: 1. "Extension sees data on pages for which it's activated, and might modify that all kept locally", and 2. "Extension sends all page information to The Cloud^W^W Somebody Else's Computer where it is probably being shared with umpteen third parties, advertising^W behavioural manipulation and surveillance organisations, and will be preserved in crystal until the Heat Death Of The Universe. Why desktop, and most especially mobile platforms / operating systems fail to either distinguish or permit control between these two scenarios is ... utterly beyond me. There is Steve Krenzel's recent account of being pressured, by both a Twitter marketing exec and the phone company requesting the feature, to track "when users leave their house, their commute to work, and everywhere they go throughout the day". This should not even be possible, let alone invisible to the device owner. <https://news.ycombinator.com/item?id=33511016 https://news.ycombinator.com/item?id=33511016> <https://threadreaderapp.com/thread/1589700721121058817.html https://threadreaderapp.com/thread/1589700721121058817.html> The reputational harm that this does to the company, to mobile computing, to Web 2.0, to the start-up sector, and to the infotech sector as a whole really cannot be overstated. Burn it down.
- wolfgang42 4y ago
  There’s no practical way to distinguish between these two options for web extensions: once the extension can fiddle with the HTML on the page, it can use that power to make network requests (trivially, by inserting <img> tags onto the page).
  - dredmorbius 4y ago
    Hrm... That does make things more complicated. The dynamic nature of HTML as a whole means that 1) page contents can change interactively and 2) follow-up network requests can be made. Limiting that would be difficult, and might require something like, spitballing here: - Limiting extension functionality to subtractive network requests, or specifically permitted requests. Given that I've just installed LibRedirect, which points surveillanceware sites (Twitter, YT, Reddit, Instagram, etc.) to open, less-surveilled alternatives, I'm already contradicting myself here. - Limiting extension functionality to changing displayed content after an initial pre-render has been achieved. sort of: { Web } <-> { Unmodified fetch } <-> { Extension } <-> { Displayed content } That ... obviously ... fails to work for any number of content blocking or tracker-blocking tools (uMatrix, Ghostery, amongst others). This leaves us with the option of tools which are audited and certified as to behaviour, have some specifically limited sets of requests, and require those back-ends to treat any such requests in specific manners which preserve privacy and confidentiality. That's a lot more cumbersome, and doesn't work off simple allow/deny rules on-device. Thanks for the reality slap.

by morsch 4y ago

simcop2387 4y ago

I'd also love it if there was one that allowed for additional sandboxing. i.e. it can read anything but can never store or talk to the network or cause a network call to happen. I know that'd be harder to do but it'd also allow for a lot of nice add-ons to be made.

cxr 4y ago

"Access your data[...] for a specific tab" basically describes what a bookmarklet does (where by "specific tab", you mean "a given page—the one loaded in the focused tab when you activate the bookmarklet").

phgn 4y ago

It's possible for extensions to only get access when you activate it for a specific tab. If you want Unclutter to work this way you can manually set "Site access" to "On click" in the Chrome extension settings (this doesn't work on Firefox unfortunately). The reason I enabled "all sites" by default is to make the automatic activation feature work, which used to be more powerful. Possibly it can be done with an optional permission now, I'll look into it: https://github.com/lindylearn/unclutter/issues/527 https://github.com/lindylearn/unclutter/issues/527 Thanks for the feedback! Also, if you don't like something you can always submit a PR ;)

morsch 4y ago
Sorry, I should have been more specific, I'm on Firefox. Nice that it's already possible in Chrome. It was intended to be a comment about the limited power of the permission model in Firefox, though I have now learned from the sibling comment that Firefox actually has the permission I was thinking of.
- phgn 4y ago
  Yep, but extensions still have to adopt the more restrictive permissions.

k1m 4y ago

There is an activeTab permission which does this (limits access). Mozilla: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#activetab_permission https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web... Chrome: https://developer.chrome.com/docs/extensions/mv3/manifest/activeTab/ https://developer.chrome.com/docs/extensions/mv3/manifest/ac...

morsch 4y ago
That sounds like it's exactly what I want, thanks, very interesting.

dredmorbius 4y ago

There's also a tremendous difference between: 1. "Extension sees data on pages for which it's activated, and might modify that all kept locally", and 2. "Extension sends all page information to The Cloud^W^W Somebody Else's Computer where it is probably being shared with umpteen third parties, advertising^W behavioural manipulation and surveillance organisations, and will be preserved in crystal until the Heat Death Of The Universe. Why desktop, and most especially mobile platforms / operating systems fail to either distinguish or permit control between these two scenarios is ... utterly beyond me. There is Steve Krenzel's recent account of being pressured, by both a Twitter marketing exec and the phone company requesting the feature, to track "when users leave their house, their commute to work, and everywhere they go throughout the day". This should not even be possible, let alone invisible to the device owner. <https://news.ycombinator.com/item?id=33511016 https://news.ycombinator.com/item?id=33511016> <https://threadreaderapp.com/thread/1589700721121058817.html https://threadreaderapp.com/thread/1589700721121058817.html> The reputational harm that this does to the company, to mobile computing, to Web 2.0, to the start-up sector, and to the infotech sector as a whole really cannot be overstated. Burn it down.

wolfgang42 4y ago
There’s no practical way to distinguish between these two options for web extensions: once the extension can fiddle with the HTML on the page, it can use that power to make network requests (trivially, by inserting <img> tags onto the page).
- dredmorbius 4y ago
  Hrm... That does make things more complicated. The dynamic nature of HTML as a whole means that 1) page contents can change interactively and 2) follow-up network requests can be made. Limiting that would be difficult, and might require something like, spitballing here: - Limiting extension functionality to subtractive network requests, or specifically permitted requests. Given that I've just installed LibRedirect, which points surveillanceware sites (Twitter, YT, Reddit, Instagram, etc.) to open, less-surveilled alternatives, I'm already contradicting myself here. - Limiting extension functionality to changing displayed content after an initial pre-render has been achieved. sort of: { Web } <-> { Unmodified fetch } <-> { Extension } <-> { Displayed content } That ... obviously ... fails to work for any number of content blocking or tracker-blocking tools (uMatrix, Ghostery, amongst others). This leaves us with the option of tools which are audited and certified as to behaviour, have some specifically limited sets of requests, and require those back-ends to treat any such requests in specific manners which preserve privacy and confidentiality. That's a lot more cumbersome, and doesn't work off simple allow/deny rules on-device. Thanks for the reality slap.