[paulgb]

As an extension developer, I hate to say it, but you're absolutely right to feel that way. I've had people offer to pay me to put tracking or buy an extension outright, and my extensions aren't even that popular; I can only imagine what emails developers of extensions with 100k+ users get.

If anyone from Firefox is reading these, I'd love a way to link an extension to a Github repository with a particular hash, and have users be able to verify that the code in the extension actually matches what's in the repo. Currently, even if an extension "lives" on GitHub, there's no way to know that what's in the extension library matches what's on Github.

[avnfish]

That's terrifying. Is there any auditing done by Mozilla to get an extension published? Or is it a free for all?

[paulgb]

To their credit, Mozilla does have an approval process, but it's pretty opaque what actually happens during that process. They also have a "Recommended Extensions" program which does more thorough vetting, apparently. Chrome is more of a free-for-all.

[unityByFreedom]

> Chrome is more of a free-for-all

Chrome is very strict, as of the last several months, about what they allow. There's even a sticky in the support group for people whose extensions have been stuck in review for more than 3 weeks:

https://groups.google.com/a/chromium.org/forum/?utm_medium=e...

[kbenson]

This is the flip side to Google and Firefox both making their extension much more locked down by removing some APIs entirely and requiring signing and approval. There are reasons to be upset that such practices hurt useful existing extensions that people like, but there's also reason to be relieved they are doing so.

[Polylactic_acid]

The old extension system while more powerful, was pretty flaky anyway. Every browser update had a good chance of breaking extensions. At least now there is a clear api that can be kept stable over updates.

[gnicholas]

Firefox addons are reviewed, though as others note the process is a bit opaque. Interestingly, sometimes a release is approved, but then later someone comes back with issues. This is somewhat concerning as both a user and a dev. For users, it means there may be rogue extensions out there that haven't been closely reviewed yet. And for devs, it's frustrating to have a release approved and then months later to get audited.

Chrome is getting more granular in their approval process, but it seems that they're still a bit behind.

[jyr0s]

There's a dead comment that seems pretty revealing in terms of the review process:

    SmallPeePeeMan 13 hours ago [dead] [–]

    I’m an extension reviewer at adding.mozilla.org. Extensions that request certain permissions are manually reviewed. Others are automatically approved. Recommend extensions are ALWAYS manually reviewed for each update.

I'm curious what the _manual review_ process looks like. There are so many questions that come to mind: Is it a single person or multiple individuals reviewing the extension? Does it require the reviewer to be familiar with the code base of the extension? Wouldn't that be a significant burden, or are these reviews cursory? Do the reviews take 10 minutes? 30 minutes? days? Is the review documented? Can the review be public? Do they review the source code on github/gitlab/etc or are they reviewing the submitted file(s)?

[SmallPeePeeMan]

I’m an extension reviewer at adding.mozilla.org. Extensions that request certain permissions are manually reviewed. Others are automatically approved. Recommend extensions are ALWAYS manually reviewed for each update.

[davidzweig]

We have 600k users, we get an email every few weeks from shifty 'investors' looking to buy the extension.

[euid]

You can audit the code of a Firefox extension by unzipping the .xpi file in the extensions directory within your browser profile directory.

Not ideal, but it's better than nothing.

[jyr0s]

Are you proposing to do that for every update that comes in, for every extension? Far from ideal.

[euid]

Oh, yes, it's far from ideal.

I'm reminded of the ArchLinux AUR, which deals with a problem kind of like this. AUR managers show a diff of what changed in a package on each update.

Perhaps one could make extension auditing easier by scripting together a Git repository from extracted xpis, and presenting updates as patches to that repository. This is probably only viable for high-security environments - it's not with it in the common case.

Of course, the real fix would come from Firefox itself: it should provide signed extensions and a way to tie them back to Git repositories with source code, which would eliminate the need for the above automation, and allow people to crowdsource extension auditing.

[Hitton]

Since the rise of typescript and other transpilers to javascript, this isn't very feasible.

[0x262d]

That's really interesting to hear, I had always wondered how bad things can really be. I guess the answer is "as bad as money can buy" which I should have expected. Thanks.

[diego898]

Linking to a particular hash is a great idea. I encourage you to open a feature request as this could go a ways towards making users with extensions that require that kind of permission feel more secure

[LinuxBender]

I would like to see a tab in about:addons that shows how much data each addon has received and transmitted and to what names/ip's/ports. Could Firefox be modified to do something like this? Perhaps an extension of about:networking?

[6510]

User.scripts are cool for small tweaks but also for large ones with dubious access.