3 ms·

The article does make a good point regarding warning fatigue, which was one of the main reasons why Android is moving towards a permission system similar to wha

by pfg 10y ago

The article does make a good point regarding warning fatigue, which was one of the main reasons why Android is moving towards a permission system similar to what iOS does, i.e. ask for permission only when needed, and degrade gracefully if the permission is not granted. The previous system of showing a gigantic list of required permissions probably caused most users to a) blindly accept the permissions or b) not install some apps out of fear. That model is probably not that good a fit for browser extensions. There might be a couple of permissions where this would work, but the biggest issue is definitely the "Read and change all your data on the websites you visit." permission, and that's not really something you could work around with using on-demand prompts. The idea of combining code reviews with an explanation of the required permissions provided by the developer and vetted by the reviewers sounds interesting, but it's not clear to me whether a model like that would work in practice.

zeta0134 10y ago
I think the biggest trouble is that the vast majority of useful browser extensions need to read and/or modify the content of web pages. Often both. So the ability to "Read and change all your data on the websites you visit" is a really common use case for extensions in general. I'd love to see some user controls on extensions. A great many ad blockers have a feature built in that allows you to disable them on particular websites to work around cases where the blocker has broken the site inadvertently. I want to see this in reverse: I'd like to be able to very easily say to my browser, "OK, this youtube extension can run on youtube.com, and also on *.tumbler.com to make some change to embedded youtube players on people's blogs, but nowhere else." This isn't even particularly advanced to implement: the extension can simply be disabled by default, and either prompt to activate through some browser-controlled trigger, or wait until the user turns the extension on. I think that would stand a fair, usable middle ground between the more common all-or-nothing approach to that particular permission.
- pfg 10y ago
  That's a great idea. The implementation could look similar to how Firefox handles plugins today, offering the option to "Always activate", "Ask to activate", and a way to say "Always allow for this domain". Other permissions could still be handled with the iOS or Android approach.
  - carussell 10y ago
    It's also old news. This kind of URL-based whitelisting approach is exactly what Greasemonkey does. The problems with Greasemonkey come down to the same answer you'll find any time you're discussing extensions: the Firefox team is seriously underinvested in the ecosystem. Greasemonkey today is about as rough to use as it was years ago and almost has the smell of an unmaintained/abandoned project. The point is: this isn't exactly an unsolved problem so much as it is nobody taking up the effort or interest to apply a solution.
    - pfg 10y ago
      My understanding is that user scripts allow you to match based on the URL. It would still be a predefined set of URLs (or URL patterns) with a binary option for the user (install and accept everything, or don't). That's essentially what extensions do today. zeta0134's approach would be to put the user in charge of building this white- or blacklist. Following the way plugins are currently implemented, this would allow you to say "I always trust this extension", "I don't trust this by default, ask me every time" and "I trust this extension for example.com". This would definitely need some security UX testing, but it seems like a reasonable approach to me.
      - carussell 10y ago
        > My understanding is that user scripts allow you to match based on the URL. Yes. > It would still be a predefined set of URLs (or URL patterns) with a binary option for the user (install and accept everything, or don't). No. > zeta0134's approach would be to put the user in charge of building this white- or blacklist. As I said before, this is what Greasemonkey gives you.
- deleted 10y ago
  [deleted]

by pfg 10y ago

zeta0134 10y ago

I think the biggest trouble is that the vast majority of useful browser extensions need to read and/or modify the content of web pages. Often both. So the ability to "Read and change all your data on the websites you visit" is a really common use case for extensions in general. I'd love to see some user controls on extensions. A great many ad blockers have a feature built in that allows you to disable them on particular websites to work around cases where the blocker has broken the site inadvertently. I want to see this in reverse: I'd like to be able to very easily say to my browser, "OK, this youtube extension can run on youtube.com, and also on *.tumbler.com to make some change to embedded youtube players on people's blogs, but nowhere else." This isn't even particularly advanced to implement: the extension can simply be disabled by default, and either prompt to activate through some browser-controlled trigger, or wait until the user turns the extension on. I think that would stand a fair, usable middle ground between the more common all-or-nothing approach to that particular permission.

pfg 10y ago
That's a great idea. The implementation could look similar to how Firefox handles plugins today, offering the option to "Always activate", "Ask to activate", and a way to say "Always allow for this domain". Other permissions could still be handled with the iOS or Android approach.
- carussell 10y ago
  It's also old news. This kind of URL-based whitelisting approach is exactly what Greasemonkey does. The problems with Greasemonkey come down to the same answer you'll find any time you're discussing extensions: the Firefox team is seriously underinvested in the ecosystem. Greasemonkey today is about as rough to use as it was years ago and almost has the smell of an unmaintained/abandoned project. The point is: this isn't exactly an unsolved problem so much as it is nobody taking up the effort or interest to apply a solution.
  - pfg 10y ago
    My understanding is that user scripts allow you to match based on the URL. It would still be a predefined set of URLs (or URL patterns) with a binary option for the user (install and accept everything, or don't). That's essentially what extensions do today. zeta0134's approach would be to put the user in charge of building this white- or blacklist. Following the way plugins are currently implemented, this would allow you to say "I always trust this extension", "I don't trust this by default, ask me every time" and "I trust this extension for example.com". This would definitely need some security UX testing, but it seems like a reasonable approach to me.
    - carussell 10y ago
      > My understanding is that user scripts allow you to match based on the URL. Yes. > It would still be a predefined set of URLs (or URL patterns) with a binary option for the user (install and accept everything, or don't). No. > zeta0134's approach would be to put the user in charge of building this white- or blacklist. As I said before, this is what Greasemonkey gives you.
deleted 10y ago
[deleted]