Mozilla Removes 23 Firefox Add-Ons That Snooped On Users (bleepingcomputer.com) 79
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.
Hey lets remove the old addons. (Score:4, Insightful)
Re:Hey lets remove the old addons. (Score:4, Insightful)
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: (Score:2, Interesting)
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: (Score:1)
Newer is bad when it is larger, slower, and less useful than what came before.
Re: (Score:3)
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 yo
Re: (Score:3)
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.
List (Score:5, Informative)
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: (Score:2)
Re: (Score:2)
How would they have been able to choose when the behavior was purposefully hidden from the users?
Re: (Score:2)
Pretty sure most users disagree and are perfectly fine with malware being disabled on their computers.
Re: (Score:2)
Are they not able to enable it again? The summary said the addons were disabled not removed.
Re: (Score:1)
And probably none will once the true purpose of the add-on has been exposed.
Is one of the addons Pocket? (Score:5, Interesting)
Re: (Score:2)
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?
Implications (Score:2)
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 [ghacks.net] 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
Re: (Score:3)
Re: (Score:2)
And only pay with cash instead of credit if it's not your credit card reader!
Re: (Score:2)
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
OK But What About Going Forward? (Score:2)
Re: (Score:2)
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 pla
Re: (Score:2)
Software freedom combats proprietary malware (Score:2)
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.
We know of no perfect defense against malware. As this essay [gnu.org] points out, "We who present free software as a defense against malware do not say it is a perfect defense. No perfect def
We need an app (Score:2)
Re: (Score:2)
Re: (Score:2)
what about (Score:1)
Misleading summary (Score:2)
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 [googleusercontent.com] 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 func
Re: (Score:2)
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, profil
Re: (Score:2)
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
Re: (Score:2)
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,
Re: (Score:2)
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
Re: (Score:1)
How do you think? The browser was told to disable the add-ons by the Mozilla Add-On site.
Re: (Score:2)
There's an addon blacklist file. Just like there's a URL blacklist file. Former: http://kb.mozillazine.org/Bloc... [mozillazine.org] Latter: http://kb.mozillazine.org/Urlc... [mozillazine.org]
Fuck you (Score:1)
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!