3 ms·

Something I just thought of... if these changes are presumably meant to keep malware addons out of the browser, then it's necessarily operating in an infected e

Something I just thought of... if these changes are presumably meant to keep malware addons out of the browser, then it's necessarily operating in an infected environment. (I.e. something already had the ability to do things in the context of the user without that user's permission, and we're just preventing it from doing this one thing via restricting what the user can do) In what way does this meaningfully secure the browser from malware, with that in mind? If I've got code running in the user's account, I don't need to hook into the browser engine to direct the user at popup ads, phishing sites, harvest their keystrokes, or do any number of other evil things. Hooking into the browser is one of the least interesting things that evil me could be doing. I've got access to the browser's memory, the TCP stream, the ability to launch whatever programs the user does, and am probably traveling along with a payload to allow for privilege escalation. So, WTF?

mschuster91 11y ago
The problem these days is established extensions that get legitimately sold or their access data hacked, and malware rolled out to the users. Or extensions which actually do their job, but after a delay, e.g. a month, deploy the malware payload. Enforcing someone from Mozilla to take a look at the actual APIs used in the extension is a pretty reasonable way to prevent a lot of this. Also, disallowing local installs of unsigned stuff is usually a good practice - lots of "download managers" is bundled with "premium" "extensions" turning out to be toolbars collecting and shipping off your data, replacing your ads etc.
- mook 11y ago
  > The problem these days is established extensions that get legitimately sold or their access data hacked, and malware rolled out to the users. Published extensions on addons.mozilla.org (i.e. the built-in extension distribution channel) already go through a review for every update. Someone from Mozilla _already_ has to take a look. Of course, the addon review queue is currently ~ 10 weeks (according to their blog, from Aug 12). Relative to the 6 week Firefox release cycle, it's like saying if Apple enforced application signing for OSX where you need to submit your app, wait a year and a half, then get a signed version back.

mschuster91 11y ago

The problem these days is established extensions that get legitimately sold or their access data hacked, and malware rolled out to the users. Or extensions which actually do their job, but after a delay, e.g. a month, deploy the malware payload. Enforcing someone from Mozilla to take a look at the actual APIs used in the extension is a pretty reasonable way to prevent a lot of this. Also, disallowing local installs of unsigned stuff is usually a good practice - lots of "download managers" is bundled with "premium" "extensions" turning out to be toolbars collecting and shipping off your data, replacing your ads etc.

mook 11y ago
> The problem these days is established extensions that get legitimately sold or their access data hacked, and malware rolled out to the users. Published extensions on addons.mozilla.org (i.e. the built-in extension distribution channel) already go through a review for every update. Someone from Mozilla _already_ has to take a look. Of course, the addon review queue is currently ~ 10 weeks (according to their blog, from Aug 12). Relative to the 6 week Firefox release cycle, it's like saying if Apple enforced application signing for OSX where you need to submit your app, wait a year and a half, then get a signed version back.