Mozilla Removes 23 Firefox Add-Ons That Snooped On Users (bleepingcomputer.com)

An anonymous reader writes: Mozilla has removed 23 Firefox add-ons from its add-on store that snooped on users and sent data to remote servers, a Mozilla engineer told Bleeping Computer Friday. The list of blocked add-ons includes "Web Security," a security-centric Firefox add-on with over 220,000 users, which was at the center of a controversy this week after it was caught sending users' browsing histories to a server located in Germany. "The mentioned add-on has been taken down, together with others after I conducted a thorough audit of [the] add-ons," Rob Wu, a Mozilla Browser Engineer and Add-on review, told Bleeping Computer via email. "These add-ons are no longer available at AMO and [have been] disabled in the browsers of users who installed them," Wu said.

Comments

Hey lets remove the old addons.

[DarkRookie]

Cuz, you know, the new stuff is definitely secure and this is just an illusion,

Re:Hey lets remove the old addons.

[slack_justyb]

Cuz, you know, the new stuff is definitely secure and this is just an illusion,

The old system was removed because:

One, the old system no one wanted to maintain it. Hard to keep a system secure when literally zero people want to work on it, Palemoon has some of the relics from the old system which means a lot of your addons should work there, but be warned that even they haven't kept 100% the old ways because...

Two, the old system sucked really bad. The old addon system is crap because it required way more tightly coupled pieces then should ever be needed. Yes, it was bad code, that should be said, Mozilla in the early days shipped bad code. By the time FF24 ESR came around, folks saw it as a good time to start breaking away from the old bad code because...

Three, you couldn't please everyone and new features took forever. All that super tightly coupled code meant that as soon as you changed that over there, person C's addon would break, fix it, and now person R over there has a broken issue related to feature ABC, fix that an now person Q is complaining about devs breaking feature XYZ. This was literally the norm with addons all of the time Bad code meant that the entire base was fragile and making sure addons worked between versions was becoming a nightmare, not only for FF devs but also for addon devs. Addon devs would just ask FF devs to just fix things and that led to...

Four, at some point the FF devs said screw fixing this crap. Palemoon devs I guess are more apt to fix old code than the FF devs were, but basically the FF devs looked at the task at hand and just said screw it. With no one else wanting to jump on board, they began putting together what would become the next version of FF.

Now here's the thing. These plugins were sipping data under the old system and they went undetected because the FF devs are busy trying to fix ABC that multitab dev over there is crying about. Now that the FF devs don't have to worry about that crap, yeah, they've got more time to carefully look at addons to see what's going on within. Addon security is indeed there, but only to a point. Addons aren't going to start grabbing files outside the sandbox and sending them to remote host, at least as far as anyone knows at the moment but bugs happen all the time. But all addons, even the old system, allowed your current URL request to be sent to remote host. If you use Palemoon, Chrome, Edge, or whatever, pretty much all addon systems allow to some degree the ability to ship your current URL to the addon for additional processing. The only way they can be made secure is to have eyeballs on the addons or if you just don't use addons at all, but you will not ever have an addon system that doesn't give the URL to the addon and trust them to not be malicious with it, unless you/yourself write said system. At some point, the end user needs to educate themselves about what the heck they're doing on their system. All addon systems are leaks of your data within your browser's sandbox. Using addons opens you up to a lot. If that's not kosher with you, then you ought not to use addons.

Re:Hey lets remove the old addons.

[Anonymous Coward]

That's a long comment to say "things have changed at FF and not for the better". Every (and I mean every) change that has come out of Mozilla lately has been horrible. The browser is larger than before, slower than before, has less useful extenstions, and has less configuration options exposed. Definitely not on the right track anymore.

Re:Hey lets remove the old addons.

[Anonymous Coward]

Newer is bad when it is larger, slower, and less useful than what came before.

Re:Hey lets remove the old addons.

[EzInKy]

Okay, but the main thing I want is a status bar on my desktop computer, the ability to easily add bookmarks with just a click or two, and I certainly don't need a "pocket" connecting to websites I want nothing to do with.

Re:Hey lets remove the old addons.

[slack_justyb]

That's a long comment to say "things have changed at FF and not for the better".

Depends on your definition of better. The code base is a lot cleaner and a lot of the underlying components no longer have crazy interactions with each other. They aren't quite to the point of easily being replaced in and out (loosely coupled) but they are a whole hell of a lot simpler to make changes in one without completely breaking the others. I'll side step multiple threads and what not. But compared to where the code base was, the browser's code is a whole hell of a lot better.

The browser is larger than before, slower than before

I don't know what you mean in size, pure size, RAM usage?? I'm going to go with RAM since that usually what most people point a finger to. Memory usage is an issue in all browsers, and that's not an excuse. However, memory issues have plagued Firefox for quite some time now, here's one example for starters. RAM usage in browsers is a complex topic that's not just a "Mozilla, Google, Microsoft" changed something and now everything breaks. Browsers are being asked very complex things by JavaScript frameworks, video decoding, complex style sheets, web fonts, and so on. I'll say, I don't have a clear answer for you on that. The web is increasing in complexity and pretty much a Browsers is being asked to be a small self contained VM. Firefox specifically has had to make shifts in what to prioritize for what goes on in the browser. So at one point there was a massive outcry of freezing and slowness, trade off for dealing with that to some extent is more RAM usage. There's a balance to be struck for sure, but even all high and mighty Google engineers have yet to really tackle that well. I will say this, that Palemoon has off and on change with this. Some releases will focus on CPU enhancements and other will focus on RAM enhancements and you can tell which one is which by looking at htop. The web is astoundingly complex and perhaps it shouldn't be that way, or maybe it should be that way and browser devs have just yet to crack a meaningful balance between CPU/memory. As for the slower than before, I've not noticed that, but it really depends on your setup. Again, that has a lot to do with, "can the browser offload tasks to something else?" Which it's still insane to me that we've gotten to a point where webpages are so complex that we need to have offloading workers, but I guess I'm just an old fart.

has less useful extenstions[sic]

Yeah, you might want to read the article you are posting to for that. Devs can do one of two things. One, go ahead hack together an API for that and watch as it is slowly abused to death and we go right back to bad code in the code base. Two, actually put together a well thought out API and stress test it over time to develop a model that is one that will work well without a million hacks. By all means, if there's some contribution you'd like to add, the devs are all ears. But by no means, should the devs hack something together, just so your purple hug bear bar multi-tab manager addon will work. Want to speed that process up? Feel free to send anyone worth their salt who won't duct-tape their API up to make it work over.

has less configuration options exposed

Fun thing, Chrome has a ton of options exposed. Number one complaint I hear from that team is the fact they had to implement a search bar for the configuration since there are so many dang options. Is there a balance? Oh you betcha! No arguments there, but it's literally, "you will always be burned by someone" type thing. about:config and just deal. If there's something you really, really want to see. Put it up on Bugzilla, make a strong argument for it. I'm not saying you are wrong on this, but it's just a such a touchy thing that devs really want a strong argument for

List

[bill_mcgonigle]

read TFA for methods and BMO link.

Popup-Blocker
Facebook Bookmark Manager
Facebook Video Downloader
YouTube MP3 Converter & Download
Simply Search
Smarttube - Extreme
Self Destroying Cookies
Popup Blocker Pro
YouTube - Adblock
Auto Destroy Cookies
Amazon Quick Search
YouTube Adblocker
Video Downloader
Google NoTrack
Quick AMZ

Re:List

[kaizendojo]

Wow, absolutely no surprises in that list. Except for maybe that FB only appears twice.

Re:OPTIONAL

[Desler]

How would they have been able to choose when the behavior was purposefully hidden from the users?

Is one of the addons Pocket?

[xack]

pocket, amazon and systemd, ruining your linuxperience.

Re:Is one of the addons Pocket?

[EzInKy]

I was totally flabbergasted to find my default page connected to sites I had no interest in after my last system upgrade. What brainiac thought this one up?

Re:OPTIONAL

[Desler]

Pretty sure most users disagree and are perfectly fine with malware being disabled on their computers.

Implications

[Artem S. Tashkinov]

What has become quite obvious recently is that add-ons for Firefox and Google Chrome web browsers (not sure about web browsers) should never be be trusted and if you really care about your security you should either give up on add-ons altogether or only use the ones which have a large enough user base (and this is not really a warranty of its safety).

For myself I've been using this workaround: I have a Firefox profile with all sorts of add-ons for my daily life and a I have a separate profile for banking which only has uBlock Origin installed - nothing else.

Re:Implications

[jbmartin6]

I use separate instances of Portable Firefox for the same purpose. Also true, browser extensions have to be treated like any untrusted program these days given how much we do from within the browser.

Re:Implications

[JackieBrown]

And only pay with cash instead of credit if it's not your credit card reader!

Re:Implications

[mangastudent]

What has become quite obvious recently is that add-ons for Firefox and Google Chrome web browsers (not sure about web browsers) should never be be trusted

For myself I've been using this workaround: I have a Firefox profile with all sorts of add-ons for my daily life and a I have a separate profile for banking which only has uBlock Origin installed - nothing else.

I do the same sort of thing, but I don't even trust uBlock Origin for my profile for all financial transactions, including ordering stuff. Sure, I generally trust it (plus uMatrix), but so do so many other people, and it's a very big target as a result. I don't see a great need for it, as I only launch that profile for a single site's interaction, and then exit before going to another site. But I do grant your implicit point that some financial sites out there are badly constructed and uBlock Origin might prevent a problem.

OK But What About Going Forward?

[theshowmecanuck]

What's to stop snooping add-ons going forward? Is there a mechanism in place to ensure no malware makes it into Firefox add-ons that are published on the Mozilla site? If not, who cares.

Re:OK But What About Going Forward?

[slack_justyb]

Is there a mechanism in place to ensure no malware makes it into Firefox add-ons that are published on the Mozilla site?

I think that's akin to asking the question, is there a mechanism in place to ensure that some random source tree on GitHub isn't just malware? Other than having people look over the code, the answer is no. Mozilla switched up dev priorities and theres a handful of extra devs now that can review addons. However, I would suggest that if you are going to install an addon, to review the source of it. Outside that, YMMV between 0% stopped and 99% stopped. Addons aren't good in a security context, if you place a high value on security, then you might not want to use addons for any browser/randomly clone some branch of code from GitHub/randomly install some piece of a software on your system.

Re:OK But What About Going Forward?

[AHuxley]

A browser testing to see what data flows back from the add on other than a version number update?

We need an app

[hcs_$reboot]

We need an app that snoops on apps snooping on users.

Re:We need an app

[hcs_$reboot]

You, sir, have to much free time!

Re:We need an app

[AHuxley]

A powerful software firewall?

what about

[sakono]

The honey app that's being promoted by youtubers now? It was known in the past for being spyware and some reports of it changing ads on pages to comprimised ads.

Re:OPTIONAL

[JackieBrown]

Are they not able to enable it again? The summary said the addons were disabled not removed.

Re:OPTIONAL

[Desler]

And probably none will once the true purpose of the add-on has been exposed.

Misleading summary

[mysidia]

which was at the center of a controversy this week after it was caught sending users' browsing histories to a server located in Germany.

The AddOn's description and privacy policy are very clear.... It's a cloud-based security AddOn that queries a realtime database on somebody else's server to help decide if a URL is malicious, therefore the addon naturally has to send a request to the server with the URL.

Whoever is describing the Add-On as "Spying" because of functioning as it is documented to function is being extremely disengenuous (IMO) --- Perhaps they work for another antivirus or security company and would prefer more users be infected to bolster sales?

2. Non-personally identifiable information that is collected automatically by Creative Software Solutions GmbH:

When the user opens the pages, used by Web Security, the following information gets processed to assure the successful operation of Web Security: the web pages that the user opens or the operating web server, the name of the internet service provider of the user and the website from which the user came from and the sub-pages the user opened. Otherwise, the user might not be warned of harmful sites. No personal information is collected by Creative Software Solutions GmbH automatically. The date and duration of the individual page visits will be stored by Creative Software Solutions GmbH in an anonymous form and checked against a database operated by Creative Software Solutions GmbH to alert the user about malicious sites, so that the purpose of the contract is fulfilled.

Re:Misleading summary

[higuita]

bullshit talk or they do not understand enough about security to have a security add-on!

You do not need to send user url to a remote server, you hash the full url (or HOST and URI if you want both data) and send the hash. the remote server compare if that hash is in their DB or not and report back to the user about the result.

Sending the user data directly is either laziness, ignorance or malicious. Most of the time this happens is malicious, is to gather tracking info about users (even if anonymous, profiling on what people access is valued info for marketing)

Re:Misleading summary

[mysidia]

you hash the full url ... and send the hash. the remote server compare if that hash is in their DB or not and report back to the user about the result.

No..... that is an architecture choice. A hash is pretty useless for scanning the URL if the URL is not found in their current database.
Many web filtering solutions query the full domain and URI to a remote server; (or rather, a Base64-encoded version of the same).

This is fundamentally no different than Proofpoint's method which scans all incoming e-mail and replaces URLs with an encoded version that
forwards through .URLDefense.proofpoint.com which does a 302 REDIRECT either to the original URL in the e-mail
message if nothing suspicious is found. Or else a 302 REDIRECT to a block page.

The security provider's servers check a cache if the URL is known good or known bad, and takes the proper action.
If the URL is in Neither database ---- then their servers won't know a hash for that URL, Before returning a reply to
the client, the security provider runs a scan of the URL from their servers, using their patterns and proprietary rules, possibly augmented with some 3rd party databases, and returns back either a Good or Suspicious Site response. Note that a hash is not adequate for any of this process.

Re:Misleading summary

[higuita]

Again, that is the lazy solution, you can create a blocklist rule for more complex rules and send it to the client, you can break the url in blocks and hash then and again use the hash against your internal rules. Even if really needed, the host can always be a hash (break it if needed) and send only the plain uri without query-strings. This way user site access is protected and query-string data is protected. URI without those is less critical (but still can give lot of info on what the user is doing)

Yes, protecting the user privacy make things harder, but sending the full URL is very bad and can break trust, if not even illegal, as it can catch protected info that would be hidden via https. There are checks that must never be in the server side, that must be in the client side so the user privacy and data is protected.

Re:Misleading summary

[mysidia]

Yes, protecting the user privacy make things harder, but sending the full URL is very bad and can break trust

No... Respecting that they need the information sent to them to do what they do and have a Privacy policy restricting their use of information is called
TRUSTing them. "Break"ing trust is suggesting some crazy scheme where the security provider will only have hashes based on URLs and Postdata,
because you don't personally trust them to adhere to their privacy policy regarding data they admit to collect.
Besides.... Have you considered that even if you Hash URL components, that doesn't technically assure privacy?

With enough wasted computation power: All the hashes can be reversed by brute force or dictionary scan; especially if you know that
all the names are short PostData components or DNS names --- only uncommon hostnames would be at all resilient.

Your "hashing" solution to a Non-Problem is essentially flawed at its fundamental level: The result of a hashing algorithm is not a zero-trust proof; Cryptographic hashes were not designed by any means for the application that you are proposing ------ Seems like you're basically trying to suggest security solutions providers misuse hashing algorithms and roll their own flawwed crypto, which is a big security no-no, and a waste of time and developer resources, anyways.

Even if really needed, the host can always be a hash (break it if needed) and send only the plain uri without query-strings. This way user site access is protected and query-string data is protected.

No.. You are making assumptions about the filtering methods that will be used. Despite your suggestion to the contrary, the
query-strings and other data are very necessary for the security provider to have for some of the most effective methods.
These are actually necessary for the security provider's servers to accurately simulate the URL being accessed by a client, As they are part of the environment data passed to the webpage: and if the URL data were missing -- this can tip off the Javascript code or exploit attempt that someone is running their script inside a malware detection/analysis sandbox or other dynamic evaluation environment on a headless remote server before the real browser is allowed to see it.

Again, that is the lazy solution

Not really... It is potentially the method a proper solution should use.

you can break the url in blocks and hash then and again use the hash against your internal rules

No malicious URL detection mechanism worth its salt is based solely on a fixed blacklist or whitelist that can be looked up by hashes of URL components.
Contextual information within page documents, where a link appears, the type of content, type and reputation of the HTTP referrer, whether the URL appears to contain malformed objects, obfuscated code, Or known code snippets from a large library are very relevant, and those are things the server needs to pull and find in order to return a response + optionally Update private reputation data that will be used to quickly recognize a bad URL in the future.

you can create a blocklist rule for more complex rules and send it to the client

You're referring to a specific kind of blocking system.
By their very nature different filtering solutions work by different means and have Pros and Cons.
Systems that rely on only the client to make complex "detection" decisions tend to be greatly inferior from a security
and reliability standpoint, because of the design constraints that using client-side decisionmaking imposes.

Implementing blocking logic on the server VS the client is totally a software architecture choice.
Both choices are legitimate, and server-based blocking precludes concealing information from the
server by hashing it. The server is going to do the analysis and make a decision for the whole gro

Re:The real WTF

[Desler]

How do you think? The browser was told to disable the add-ons by the Mozilla Add-On site.

Re:The real WTF

[Shikaku]

There's an addon blacklist file. Just like there's a URL blacklist file. Former: http://kb.mozillazine.org/Bloc... Latter: http://kb.mozillazine.org/Urlc...

Software freedom combats proprietary malware

[jbn-o]

What's to stop snooping add-ons going forward?

Software freedom; the freedom to run, inspect, modify, and share published computer software plus user's vigilance and not installing stuff one really doesn't need.

Is there a mechanism in place to ensure no malware makes it into Firefox add-ons that are published on the Mozilla site?

We know of no perfect defense against malware. As this essay points out, "We who present free software as a defense against malware do not say it is a perfect defense. No perfect defense is known. We don't say the community will deter malware without fail.". The best defense we have is to run only free software and to support software freedom for its own sake, as a good unto itself. This is a big part of the reason why Firefox (which can be made free) is so important a browser and why other popular browsers (regardless of their developmental claims) aren't trustworthy. Other popular browsers are nonfree, user-subjugating, proprietary software and there's a lot of proprietary malware.

Fuck you

[Mats Svensson]

We value your privacy

We and our partners use technology such as cookies on our site to personalise content and ads, provide social media features, and analyse our traffic. Click below to consent to the use of this technology across the web. You can change your mind and change your consent choices at anytime by returning to this site.

Change consent

Powered by
Quantcast - GDPR Consent Solution

Well, fuck you too!