Any extension that's listed on the web stores have to be reviewed for malicious code, and they must do what the listing say they do. So if your browser extension has your passwords, then that extension would be considered a password manager.
The extension probably listens to the IPs of well-known time wasting websites like HN or reddit, then adds a latency to the browsing. Same with an ad blocker -- they know every site you visit but only to compare them with their blacklist of advertising IP addresses.
Of course, you have to trust they aren't doing anything else with that info, which you can probably assume you're mostly safe if you don't need an account to use the extension.
https://support.mozilla.org/en-US/kb/recommended-extensions-...
[0] https://extensionworkshop.com/documentation/publish/submitti...
Listings which do not participate in the Recommended extensions program may also get a manual review after they were published, but immediate human review is not guaranteed.
If you're a developer, I'd recommend disabling automatic extension updates in Firefox, and configuring a script to get notified about updates, even if you only use Recommended extensions.
Extension source viewer is excellent for reviewing updates yourself before installing, and it is maintained by Rob Wu, an engineer at Mozilla.
most of the relevant code is in https://github.com/OskarDamkjaer/FirefoxDelayWebpage/blob/ma...
URL: http://some.site.tld/ [ INSECURE GET:1 POST:2]
URL: https://some.other.tld/ [ SECURE GET:3 POST:2 ]
Maybe in about:networking have a tab for logging / debugging all addons?You can literally just save them from addons.mozilla.org and look inside - it's js so it's not compiled, and obfuscated code is against Mozilla policy.
Automatic updates are optional too.
Microsoft Application Inspector might be handy for some superficial profiling - https://github.com/microsoft/ApplicationInspector
You can submit obfuscated code as long as you also upload non-obfuscated code to Mozilla. Not sure if that separate code upload is public or not...
Only reviewers have access to the source code, unless you configure the listing to make the code public.
Basically, if the addon wants to interact with any kind of urls, this message is unavoidable. Which means that even if the addon doesn't require to access any data of the websites, as long as it wants to be triggered for any websites, this message is not going to be avoidable.
https://extensionworkshop.com/documentation/develop/request-... has more information.
I do agree with you though. What is surprising is that technically, this should be fairly easy to solve:
- own the CI system (to make sure the sources match the built versions)
- make sources (the ones that went into build) clearly visible
- disable silent updates
I'm assuming this permission has no need to read the body of network responses, inject anything into the responses, read cookies etc.
However, it probably has no option than to request the "read and change all network data" permission because there is nothing weaker that will let it do what it needs to do.
Making sources available isn't a scalable option to help with this in my opinion. Who is going to be doing thorough security audits of every extension + every update?
It's a fair comment, but this extension works by injecting javascript into every page the browser loads. If this capability were removed or even changed, it would break a ton of existing extensions (and compatibility with the many extensions written for Chrome).
Given the nature of javascript and the web, once you can run a bit of javascript on a page, you can do just about anything, so the phrasing "can access data" sounds scary but it is accurate. Of course, "can" doesn't mean "does", hence all the other commenters suggesting auditing the code.
Speaking of auditing extension code, I like https://addons.mozilla.org/en-US/firefox/addon/crxviewer/
To make any headway on this, you would need to start considering how to prohibit JavaScript from transmitting page content to remote servers if it's been modified by an addon, but that would then break all JavaScript modified by adblockers, and so there's not any easy solution there either.
If you can think of a valid security model here that isn't vulnerable to today's arbitrary JavaScript execution issues, I think you'd find a willing audience. Chrome tried to solve this by nailing down what extensions can do, and the adblockers all flipped out because they won't be able to run arbitrary JavaScript in-page anymore. It remains unclear how this can ever be solved.
> Even if the extension's source code is available on GitHub, there is no guarantee that the code hosted at addons.mozilla.org corresponds to the same one found on GitHub; and even if I (or someone else) could verify that the code is indeed the same, and that there is nothing malicious in it right now, there is no guarantee this will still be the case in future (silent) updates.
> To be clear, this is more of a criticism to Mozilla Firefox's security model, not to this particular extension.
Uhhh... yeah
Even if the extension's source code is available on GitHub, there is no guarantee that the code hosted at addons.mozilla.org corresponds to the same one found on GitHub; and even if I (or someone else) could verify that the code is indeed the same, and that there is nothing malicious in it right now, there is no guarantee this will still be the case in future (silent) updates.
To be clear, this is more of a criticism to Mozilla Firefox's security model, not to this particular extension.