Extension block request: {800b5000-a755-47e1-992b-48a1c1357f07} (ICQ Toolbar)




6 years ago
7 months ago


(Reporter: ttaubert, Assigned: kev)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [extension][3rd-party-bustage])

Extension name: ICQ Toolbar
Extension UUID: {800b5000-a755-47e1-992b-48a1c1357f07}
Extension versions to block: 1.4.2
Applications, versions, and platforms affected affected: All
Block severity: soft

Homepage, AMO listing, other references and contact info:



The ICQ Toolbar circumvents our mechanisms introduced in bug 476430. This is a snippet from v1.4.2 that directly writes to user.js: http://pastebin.mozilla.org/1417305

I propose that we soft block this extension until its developers remove the specific code fragment. Users must be able to opt into extensions that are installed without their consent.
This behavior got introduced with version 1.4.0. So versions 1.4.0 and 1.4.1 should also be blocked.
Unfortunately, because of the way it changes that preference (by writing directly to user.js), blocklisting won't undo the changes for anyone that has one of those versions of the addon installed.

It could potentially be solved by shipping a hotfix to undo the changes, but that ability is only available starting with Firefox 11.
Wow. That's horrific. Nice to know that it only affects Windows users, though.

The blocklist entry would still prevent further auto-installs, until they realize that they've been blocklisted and manually circumvent that. The add-on is not hosted on AMO, so presumably it's installed automatically by the ICQ installer.
This code runs as part of the extension? I.e. after it will have already been blocked until accepted by the user? Odd. I guess they wanted to get these prefs set before Firefox 8 came out.
Yes, please block this. It's unacceptable that they disable user control of add-ons.
[I also sent this comment to dev-apps-firefox]

The blocklist is also trivial to circumvent. The blocklist isn't designed to prevent any kind of malicious actions by addons and it is totally ineffective if the addon doesn't want the blocklist to block it. It is only effective for cases where the addon is accidentally bad (e.g. unintentially exploitable). I would very much like to change this. However, I have been told by several people, including by multiple people from the security team, that we leave these vulnerabilities open by design and that we have no intention to try to limit what addons can do.

The worst thing to do is to abuse the blocklist mechanism in such a way that grayware addons decide to *completely disable* the blocklist. So, I think your bug must be WONTFIXed unless/until we decide to implement security measures to protect against malicious addons.

See https://bugzilla.mozilla.org/show_bug.cgi?id=686095
and https://bugzilla.mozilla.org/show_bug.cgi?id=686134
for background.

Note that the security team has asked me to indicate that I am not under their management and that I do not speak for them.
Thanks, Brian. That sounds reasonable to me to WONTFIX this.

In the meantime ICQ has removed these specific lines of code. Not sure if they've been contacted or they just saw this bug/thread. I'll keep an eye on this.
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
FWIW I agree with comment 6 when it comes to malware add-ons but I disagree when it comes to add-ons from companies who clearly wouldn't want the associated press and user complaints that came from blocking their add-on. Blocklisting can still be an effective measure to push developers to do the right thing as has been proven in the past and had ICQ not been responsive to fixing the problems I'd be re-opening this bug.
Kev, can you do some outreach here and see what they say?
Assignee: nobody → kev
Resolution: WONTFIX → ---
Whiteboard: [extension] → [extension][3rd-party-bustage]
The about:newaddon problem has been fixed. There are still policy violation issues, though: he add-on changes the default search engine and keyword URL and does not revert them on uninstall.

This add-on has ~1M users.
I just used their support form to try to get in touch with them. I'll give them some time to respond.
Jorge, can you bring up bug 713204 while you're in contact with them?
I just received an acknowledgement of my message to them, and they are passing the information to the development team.
Given that there hasn't been any useful response from ICQ, our only options are to move forward with the block or do nothing. Given bug 713204, I think we'll need to go with the block. I run it past the release drivers group tomorrow.
(In reply to Jorge Villalobos [:jorgev] from comment #14)
> Given that there hasn't been any useful response from ICQ, our only options
> are to move forward with the block or do nothing. Given bug 713204, I think
> we'll need to go with the block. I run it past the release drivers group
> tomorrow.

I meant bug 831603.
Product: addons.mozilla.org → Toolkit

Comment 16

7 months ago
Marking wontfix, given that the events around this were several years ago, and I am assuming it's been addressed in another manner.
Last Resolved: 6 years ago7 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.