12 ms·

> I understand that there are significant security issues with browser extensions Sure, there are significant security issues. Since when is that a reason to d

> I understand that there are significant security issues with browser extensions Sure, there are significant security issues. Since when is that a reason to disable a user-originated threat vector? As long as the user in question is informed and alerted to the potential security risks shouldn't it be within the user's purview to decide what to allow and what not? Even if this line of argument cannot be said for every purpose - and I understand there is a potential for abuse and misinformation about misrepresenting any specific extension - but for instance say Tampermonkey, which the user needs to first download from the webstore then the user needs to also download the script, can't there be sufficient warning that what the user is doing is potentially harmful? Or a requirement from the webstore that Tampermonkey somehow also alert users before loading any remote scripts? If a user decides to downright download malware we let them (Given, Chrome would block it but you can override that manually) why wouldn't the user be allowed to override these risks (i.e. you can enable it only in development mode etc. with a requirement that such extensions provide sufficient warnings etc.)

xyzzy_plugh 5y ago
> As long as the user in question is informed and alerted to the potential security risks shouldn't it be within the user's purview to decide what to allow and what not? If you've been following the Epic v. Apple case, you'd know some folks like Tim Cook strongly believe the answer is no, or in his words "they shouldn't have to [decide]." The freedom-less future sure seems pretty bleak.
- simonh 5y ago
  Well I’m a user and I don’t want to have to make that choice. For example I’m not a big fan of Facebook, but I do use it occasionally to keep in contact with some friends. Suppose Facebook decided to move to a different third party store on iOS, maybe their own store, so they don’t have to list their data access and sharing policies, don’t have to go through app store review, etc. Doing that forces me to choose between rigorous app review and disclosure, and using the Facebook app. I don’t want to be put in that position. One of the reasons I use an iPhone is because of that.
  - shock 5y ago
    Regardless of whether you have the responsibility to make that choice or not, you are still responsible for dealing with the consequences of whatever choice has been made for you. How is that any better that being responsible for making the choice in the first place?
  - zajd 5y ago
    "Rigorous app review" > https://www.theverge.com/2021/4/21/22385859/apple-app-store-scams-fraud-review-enforcement-top-grossing-kosta-eleftheriou https://www.theverge.com/2021/4/21/22385859/apple-app-store-... Bad news buddy, you're already in the boat you don't want to be in.
- unknown_error 5y ago
  As both a developer and a user, a lot of the software "freedoms" we have are superfluous, duplicative, and inefficient. As technology becomes more and more commoditized and 50,000 vendors all sell roughly the same thing, decision fatigue sets in. The walled gardens provide value not because they remove freedom but because they give you back something most people value more: time. We don't all have time to sit around evaluating 1,000 similar packages, compiling and debugging them from scratch, just to get a simple app or game working. The bleeding edge will keep on bleeding, but for the rest of us, good enough is good enough. It doesn't have to be perfect, it just has to work well enough and not add to our already-overwhelmed mental loads.
toomanyducks 5y ago
> informed and alerted and here I think is the issue - it's hard for a closed source project to fully inform and alert anyone, at all. It's impossible to get a full understanding of a codebase that doesn't allow me to look at it, and I don't see why that would be different here. I can't understand security risks to Chrome (proper Chrome, not Chromium) because I'm not allowed to, therefore any extension at all could be dangerous in some way. So it is actually best to not allow the user to think about security for themself, because they can't have the necessary information. A developer can't look over every extension because they have better things to do with their time, so I think it makes sense that we end up with this incredibly restricted platform. If your strategy for security can't be having an open and audited interface and implementation, the next best thing seems to be no interface.
- cwyers 5y ago
  If you feel like the only thing preventing you from understanding the security risks of executing a piece of Javascript in Chrome is the parts of the source that are used only in Chrome and not in Chromium, you have a very high opinion of your ability to reason about that many lines of non-memory-safe code that I think is not backed up by the evidence.
  - toomanyducks 5y ago
    No, I think I have a low opinion about my abilities - I need a complete picture and all the help I can get to understand anything at all. But yes, I agree that it's not as simple as my original comment made it out to be - I definitely failed to fully acknowledge that most/some of the critical parts are open source and secured, but I think the incompleteness in any outside understanding (such as my own) is a major factor in the options Google could present about security.
- ROARosen 5y ago
  Don't forget the fact that any scripts you download are by definition open-source (you download the actual script).
shadowgovt 5y ago
> since when is that a reason to disable a user-originated threat vector? Since Google is operating at a scale where the majority of users use their browser, so a successful popular malicious extension scales extremely rapidly. This is basically a recapitulation of the decisions Microsoft had to make regarding the market dominance of Windows and the ease of attacking users via VBScript exploits. The developers of the framework have to make a trade-off between capabilities of the framework and likelihood that those capabilities will be used to attack the average user. It's a cat-and-mouse game where there are not obvious technical answers so much has move-countermove. We even have the analog to Apple Computer during the heydays of VBScript exploits in this story... With its much smaller market share, Mozilla has the luxury of worrying less about these exploit vectors because successfully deploying a malicious extension in that ecosystem only impacts a couple percent of total users of the internet. Much as Apple didn't have to worry much about malicious AppleScript exploits.
- ROARosen 5y ago
  As someone pointed out above, Tampermonkey has ~10m downloads compared to 2.5b Chrome users, I seriously doubt any one malicious Tampermonkey script can affect as many users as even a malicious AppleScript can.
  - shadowgovt 5y ago
    This design change to manifest V3 isn't about tampermonkey. It's about the capability space of manifest V2 allowing a malicious actor to make something like tampermonkey, have it grow in popularity, and then flip the script under the hood via the extension fetching an arbitrary script from a third-party source and executing it to turn every installed node into a botnet agent without changing any of the code in the extension itself. Google is trying to solve a similar problem here to the one they have to solve with App Store apps: the ability to make claims about safety an end-user can trust. They can't make those claims if the extension can modify its behavior without any way for the Web Store administrators to know.
jolux 5y ago
> As long as the user in question is informed and alerted to the potential security risks shouldn't it be within the user's purview to decide what to allow and what not? In a purely ethical sense, absolutely yes. But we're coming up on 30 years of people using the internet, and it's been clear for a while now that you simply cannot teach people what is safe and what is not in an absolute sense. Even highly technical, experienced users still make mistakes and install malware sometimes. Informing users is not effective, to a first approximation. System designers have a responsibility to protect the users of their systems. > If a user decides to downright download malware we let them (Given, Chrome would block it but you can override that manually) why wouldn't the user be allowed to override these risks (i.e. you can enable it only in development mode etc. with a requirement that such extensions provide sufficient warnings etc.) These overrides should exist, but making them too easy will just lead to malware tricking people into triggering them. And some doors are so frequently abused or fundamentally vulnerable that they probably should be closed entirely — most people don't think we should still be embedding Java and Flash in webpages these days.
- ROARosen 5y ago
  The problem with closing the API is that for even the most advanced users, it will now be impossible to get the (very useful) functionality these extensions provide.
  - deleted 5y ago
    [deleted]
  - jolux 5y ago
    I believe it was tptacek who once commented half-jokingly that the ideal thing to do would be to leave the API open to uBlock Origin exclusively and kill it for everything else. The privileges required by that extension and others like it are indeed very powerful and often abused. This is not a problem with an easy solution, your suggestions are essentially the status quo and the industry is beginning to move on from it.
    - 5y ago
canada_dry 5y ago
> wouldn't the user be allowed to override these risks It would seem like a useful compromise to have harmful features/functionality disabled by default for each new script - controlled at the individual script level. If the user wants to invoke/allow the feature, they should be able to explicitly and manually enable it. Like the android app permissions: Allow access to x? [none, this time or always?]
- dmitriid 5y ago
  > If the user wants to invoke/allow the feature And when there are hundreds of features... Scratch that. Even if there are ten features, the user will simply click "allow all" without paying attention to what's requested.
  - canada_dry 5y ago
    Yah, this is the conundrum of security vs. useability. More and more Android has been lumping disparate access permissions together with the goal seeming to be KISS.
deleted 5y ago
[deleted]
jsnell 5y ago
That's not really a solution. The average user will not read security warnings, and will just click through them. Especially if they're being actively social engineered, the attacker can easily talk them through anything they don't understand. The people who need this functionality are a very small minority. Tampermonkey has 10M installs which is phenomenal, but Chrome apparently has an estimated 2.5B active users. The tradeoff here is exposing billions of users to unnecessary risk, to save two orders of magnitude fewer of the most tech savvy users from an insignificant annoyance. I.e. just use a browser that supports the extensions you need instead.
- ROARosen 5y ago
  > The average user will not read security warnings The basic point of my comment is that deprecating the capabilities or the current API just because there can be a security risk in some cases for the average user is harmful to the more advanced users. You focus on one possible solution mentioned about warning dialogs. However, there are lots of different solutions available which would allow it to run only with knowing 100% that the user knows what they're doing aside from warnings. There can be a command line flag --developer etc. just like there is for unsafe certs. 'Use a browser that supports it' is not a solution since - as you said - Chrome has the largest user base why would a developer put in the effort to develop a solution for a minorly used browser. Since the major browser is closing this API there will be no possible use of this type of functionality for anyone - even the users who know what they're doing.
  - 9wzYQbTYsAIc 5y ago
    Product liability to the masses likely weighs much heavier as a concern to the developers of Chrome than does any harm done to “advanced users”. Beginner users often do what advanced users tell them too, anyhow.
- pandeiro 5y ago
  Wow, so you believe this is actually being done to protect users from themselves, and not to hamstring adblocking in the future? I wish I still had that kind of innocence.
SilverRed 5y ago
>shouldn't it be within the user's purview to decide what to allow and what not? Imagine it this way: The local supermarket is selling a product which claims to be food but actually contains a highly toxic poison. And then someone justifies it still being allowed because it's still up to the buyer to choose to buy and consume it. It's on the user, the should be responsible to look for trusted brands that do not disguise poison as food or they could take it down to their local lab to test it for toxicity before consuming it. It's obviously completely absurd to expect the user to protect themselves from malice like this which is rampant on browser extension stores.
- pmontra 5y ago
  > Imagine it this way: The local supermarket is selling a product which claims to be food but actually contains a highly toxic poison Basically anything on sale if had in the wrong dose. Example: a can of a sugary drink is OK, drink 6 of them per day and it's going to be bad for your health. Let's try a different metaphor.
  - stan_rogers 5y ago
    Okay. How about buying something that was legitimately food when you bought it, but updates to poison - and there's really no choice about allowing updates, since previously safe foodstuffs can become poison if left as purchased - in your cupboard?
    - 6yyyyyy 5y ago
      I can't tell if you're being sarcastic.
      - SilverRed 5y ago
        Why would it be sarcastic? Malware authors buy legitimate extensions for mountains of cash and then stick spyware in them. Users have no idea their previously good and trusted extension is now malware.

xyzzy_plugh 5y ago

> As long as the user in question is informed and alerted to the potential security risks shouldn't it be within the user's purview to decide what to allow and what not? If you've been following the Epic v. Apple case, you'd know some folks like Tim Cook strongly believe the answer is no, or in his words "they shouldn't have to [decide]." The freedom-less future sure seems pretty bleak.

simonh 5y ago
Well I’m a user and I don’t want to have to make that choice. For example I’m not a big fan of Facebook, but I do use it occasionally to keep in contact with some friends. Suppose Facebook decided to move to a different third party store on iOS, maybe their own store, so they don’t have to list their data access and sharing policies, don’t have to go through app store review, etc. Doing that forces me to choose between rigorous app review and disclosure, and using the Facebook app. I don’t want to be put in that position. One of the reasons I use an iPhone is because of that.
- shock 5y ago
  Regardless of whether you have the responsibility to make that choice or not, you are still responsible for dealing with the consequences of whatever choice has been made for you. How is that any better that being responsible for making the choice in the first place?
- zajd 5y ago
  "Rigorous app review" > https://www.theverge.com/2021/4/21/22385859/apple-app-store-scams-fraud-review-enforcement-top-grossing-kosta-eleftheriou https://www.theverge.com/2021/4/21/22385859/apple-app-store-... Bad news buddy, you're already in the boat you don't want to be in.
unknown_error 5y ago
As both a developer and a user, a lot of the software "freedoms" we have are superfluous, duplicative, and inefficient. As technology becomes more and more commoditized and 50,000 vendors all sell roughly the same thing, decision fatigue sets in. The walled gardens provide value not because they remove freedom but because they give you back something most people value more: time. We don't all have time to sit around evaluating 1,000 similar packages, compiling and debugging them from scratch, just to get a simple app or game working. The bleeding edge will keep on bleeding, but for the rest of us, good enough is good enough. It doesn't have to be perfect, it just has to work well enough and not add to our already-overwhelmed mental loads.

toomanyducks 5y ago

> informed and alerted and here I think is the issue - it's hard for a closed source project to fully inform and alert anyone, at all. It's impossible to get a full understanding of a codebase that doesn't allow me to look at it, and I don't see why that would be different here. I can't understand security risks to Chrome (proper Chrome, not Chromium) because I'm not allowed to, therefore any extension at all could be dangerous in some way. So it is actually best to not allow the user to think about security for themself, because they can't have the necessary information. A developer can't look over every extension because they have better things to do with their time, so I think it makes sense that we end up with this incredibly restricted platform. If your strategy for security can't be having an open and audited interface and implementation, the next best thing seems to be no interface.

cwyers 5y ago
If you feel like the only thing preventing you from understanding the security risks of executing a piece of Javascript in Chrome is the parts of the source that are used only in Chrome and not in Chromium, you have a very high opinion of your ability to reason about that many lines of non-memory-safe code that I think is not backed up by the evidence.
- toomanyducks 5y ago
  No, I think I have a low opinion about my abilities - I need a complete picture and all the help I can get to understand anything at all. But yes, I agree that it's not as simple as my original comment made it out to be - I definitely failed to fully acknowledge that most/some of the critical parts are open source and secured, but I think the incompleteness in any outside understanding (such as my own) is a major factor in the options Google could present about security.
ROARosen 5y ago
Don't forget the fact that any scripts you download are by definition open-source (you download the actual script).

shadowgovt 5y ago

> since when is that a reason to disable a user-originated threat vector? Since Google is operating at a scale where the majority of users use their browser, so a successful popular malicious extension scales extremely rapidly. This is basically a recapitulation of the decisions Microsoft had to make regarding the market dominance of Windows and the ease of attacking users via VBScript exploits. The developers of the framework have to make a trade-off between capabilities of the framework and likelihood that those capabilities will be used to attack the average user. It's a cat-and-mouse game where there are not obvious technical answers so much has move-countermove. We even have the analog to Apple Computer during the heydays of VBScript exploits in this story... With its much smaller market share, Mozilla has the luxury of worrying less about these exploit vectors because successfully deploying a malicious extension in that ecosystem only impacts a couple percent of total users of the internet. Much as Apple didn't have to worry much about malicious AppleScript exploits.

ROARosen 5y ago
As someone pointed out above, Tampermonkey has ~10m downloads compared to 2.5b Chrome users, I seriously doubt any one malicious Tampermonkey script can affect as many users as even a malicious AppleScript can.
- shadowgovt 5y ago
  This design change to manifest V3 isn't about tampermonkey. It's about the capability space of manifest V2 allowing a malicious actor to make something like tampermonkey, have it grow in popularity, and then flip the script under the hood via the extension fetching an arbitrary script from a third-party source and executing it to turn every installed node into a botnet agent without changing any of the code in the extension itself. Google is trying to solve a similar problem here to the one they have to solve with App Store apps: the ability to make claims about safety an end-user can trust. They can't make those claims if the extension can modify its behavior without any way for the Web Store administrators to know.

jolux 5y ago

> As long as the user in question is informed and alerted to the potential security risks shouldn't it be within the user's purview to decide what to allow and what not? In a purely ethical sense, absolutely yes. But we're coming up on 30 years of people using the internet, and it's been clear for a while now that you simply cannot teach people what is safe and what is not in an absolute sense. Even highly technical, experienced users still make mistakes and install malware sometimes. Informing users is not effective, to a first approximation. System designers have a responsibility to protect the users of their systems. > If a user decides to downright download malware we let them (Given, Chrome would block it but you can override that manually) why wouldn't the user be allowed to override these risks (i.e. you can enable it only in development mode etc. with a requirement that such extensions provide sufficient warnings etc.) These overrides should exist, but making them too easy will just lead to malware tricking people into triggering them. And some doors are so frequently abused or fundamentally vulnerable that they probably should be closed entirely — most people don't think we should still be embedding Java and Flash in webpages these days.

ROARosen 5y ago
The problem with closing the API is that for even the most advanced users, it will now be impossible to get the (very useful) functionality these extensions provide.
- deleted 5y ago
  [deleted]
- jolux 5y ago
  I believe it was tptacek who once commented half-jokingly that the ideal thing to do would be to leave the API open to uBlock Origin exclusively and kill it for everything else. The privileges required by that extension and others like it are indeed very powerful and often abused. This is not a problem with an easy solution, your suggestions are essentially the status quo and the industry is beginning to move on from it.
  - 5y ago

canada_dry 5y ago

> wouldn't the user be allowed to override these risks It would seem like a useful compromise to have harmful features/functionality disabled by default for each new script - controlled at the individual script level. If the user wants to invoke/allow the feature, they should be able to explicitly and manually enable it. Like the android app permissions: Allow access to x? [none, this time or always?]

dmitriid 5y ago
> If the user wants to invoke/allow the feature And when there are hundreds of features... Scratch that. Even if there are ten features, the user will simply click "allow all" without paying attention to what's requested.
- canada_dry 5y ago
  Yah, this is the conundrum of security vs. useability. More and more Android has been lumping disparate access permissions together with the goal seeming to be KISS.

deleted 5y ago

[deleted]

jsnell 5y ago

That's not really a solution. The average user will not read security warnings, and will just click through them. Especially if they're being actively social engineered, the attacker can easily talk them through anything they don't understand. The people who need this functionality are a very small minority. Tampermonkey has 10M installs which is phenomenal, but Chrome apparently has an estimated 2.5B active users. The tradeoff here is exposing billions of users to unnecessary risk, to save two orders of magnitude fewer of the most tech savvy users from an insignificant annoyance. I.e. just use a browser that supports the extensions you need instead.

ROARosen 5y ago
> The average user will not read security warnings The basic point of my comment is that deprecating the capabilities or the current API just because there can be a security risk in some cases for the average user is harmful to the more advanced users. You focus on one possible solution mentioned about warning dialogs. However, there are lots of different solutions available which would allow it to run only with knowing 100% that the user knows what they're doing aside from warnings. There can be a command line flag --developer etc. just like there is for unsafe certs. 'Use a browser that supports it' is not a solution since - as you said - Chrome has the largest user base why would a developer put in the effort to develop a solution for a minorly used browser. Since the major browser is closing this API there will be no possible use of this type of functionality for anyone - even the users who know what they're doing.
- 9wzYQbTYsAIc 5y ago
  Product liability to the masses likely weighs much heavier as a concern to the developers of Chrome than does any harm done to “advanced users”. Beginner users often do what advanced users tell them too, anyhow.
pandeiro 5y ago
Wow, so you believe this is actually being done to protect users from themselves, and not to hamstring adblocking in the future? I wish I still had that kind of innocence.

SilverRed 5y ago

>shouldn't it be within the user's purview to decide what to allow and what not? Imagine it this way: The local supermarket is selling a product which claims to be food but actually contains a highly toxic poison. And then someone justifies it still being allowed because it's still up to the buyer to choose to buy and consume it. It's on the user, the should be responsible to look for trusted brands that do not disguise poison as food or they could take it down to their local lab to test it for toxicity before consuming it. It's obviously completely absurd to expect the user to protect themselves from malice like this which is rampant on browser extension stores.

pmontra 5y ago
> Imagine it this way: The local supermarket is selling a product which claims to be food but actually contains a highly toxic poison Basically anything on sale if had in the wrong dose. Example: a can of a sugary drink is OK, drink 6 of them per day and it's going to be bad for your health. Let's try a different metaphor.
- stan_rogers 5y ago
  Okay. How about buying something that was legitimately food when you bought it, but updates to poison - and there's really no choice about allowing updates, since previously safe foodstuffs can become poison if left as purchased - in your cupboard?
  - 6yyyyyy 5y ago
    I can't tell if you're being sarcastic.
    - SilverRed 5y ago
      Why would it be sarcastic? Malware authors buy legitimate extensions for mountains of cash and then stick spyware in them. Users have no idea their previously good and trusted extension is now malware.