Closed Bug 812290 Opened 12 years ago Closed 7 years ago

Blocklist Ask Toolbar add-on

Categories

(Toolkit :: Blocklist Policy Requests, defect)

Product:
Toolkit
Component:
Blocklist Policy Requests
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: kmag, Assigned: jorgev)

References

(
URL
)

Details

+++ This bug was initially created as a clone of Bug #812287 +++

+++ This bug was initially created as a clone of Bug #812283 +++

+++ This bug was initially created as a clone of Bug #812264 +++

+++ This bug was initially created as a clone of Bug #810016 +++

Next up: Silent installs of Ask Toolbar, again. Accompanying preference changes which are not reset on uninstall.

ID: toolbar@ask.com
Blocks: 812292
No longer blocks: 812292
No longer depends on: 812287
No longer depends on: 812264
No longer depends on: 810016
No longer depends on: 812283
Blocks: softonic
Sorry for the bugspam. Changing dependency chain to cut down some.
Alex has helped us with these cases in the past. Alex, what can be done to solve this problem with Softonic?
I need some more details before I can answer this.  What steps to reproduce are going on to lead to the Ask toolbar being installed?
<John-Galt> Yeah, they have a whole gamut of crap they install. You basically have to repeatedly run the installer until you get to it.
<WeirdAl> I don't have to download it again and again?
<John-Galt> Yeah, same installer. I think it downloads the crapware installers on demand.
<John-Galt> No, you have to *not* reset the machine. It basically only installs the next one if it finds evidence of the previous one.
(tl;dr) So, I tried to reproduce a silent install with the Ask toolbar through GrabIt and failed:  when it finally did get to the Ask TB, the about:newaddon page *did* show up.  The installation for the Ask toolbar was *not silent*.

I need a video of the silent Ask toolbar installation to proceed further.

Steps:
(1) Take a VM
(2) Download the installer from the URL given above
(3) Make a copy of the FF profile before running the installer
(4) Run the installer and observe what happens.
(5) Repeat steps 3 and 4 ad nauseum.

Apps installed, per pass:
1. Incredibar (crashed on install, asked user to confirm addon)
2. PC Performer with Claro toolbar (launched URL to install ClaroTB.xpi from local filesystem)
3. SweetPacks (bypassed FF addon protection!)
4. ZoneAlarm (launches FF, bypassed FF addon protection!)
5. FreeRide Games Player (launches FF)

Somewhere here we got a BrowserManager addon from Bit89.com


6. ASPCA Reminder extension (bypassed FF addon protection!)
7. ooVoo with Ask Toolbar 3.17.1.28235
	- oovooInstallingAsk has profile before launching FF
	- FF addon protection launches to validate Ask toolbar:  addon protection NOT bypassed

Unless the user uninstalls the Ask toolbar (either through uninstalling ooVoo or another path), there is no possibility of installing Ask TB again silently.  Our installer code checks for an existing toolbar and bails out if the toolbar is found.

So whatever's causing a silent Ask TB install is more complicated and/or more random than a simple "what's the next app that's not installed" list.

At no point did I notice the extensions.autoDisableScopes preference changing - it remained 15 every time I checked it.

How the bypass happened is therefore a mystery.  The preference may have changed temporarily without my noticing long enough to install an extension.
There are two possibilities:

1) The Ask installer has been fixed. I know that they had this problem in the past, and it's possible that Softonic was just using the old installer.

2) One of the previous installers changed extensions.autoDisableScopes during my tests and didn't change it back. I did check for that after each add-on, but it's possible I missed one.

Either way, I think we can call this closed for now.

Incidentally, Browser Manager is in some way associated with Babylon/Claro. We're still not sure what it does.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
On #1, our installer never, ever tried to disable Firefox's addon protections.  We did see a case several months ago where another installer bypassed it to install us (see bug 773514 comment 2 for details).
I see. Well, I don't know who is responsible for the installer that's included with Softonic downloads, only that this has happened with the Ask Toolbar in the past.
Hrm. Now "ooVoo toolbar, powered by Ask.com", with the same em:id (toolbar@ask.com) is being installed. It's *not* overriding about:newaddon, but it is modifying it: https://people.mozilla.com/~kmaglione/images/65980a385ac64086.png

Then, later, it installs Ask Shopping Toolbar (https://people.mozilla.com/~kmaglione/images/5bbf08adac65baa4.png), which does likewise: https://people.mozilla.com/~kmaglione/images/e8154edd23e80b9c.png
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
The modified about:newaddon screen has been seen/reported on by zdnet

http://www.zdnet.com/a-close-look-at-how-oracle-installs-deceptive-software-with-java-updates-7000010038/
Assignee: nobody → jorge
Jorge, Kris: if Ask doesn't restore prefs on uninstall, this is a good reason to block. Looking at this bug it doesn't look like we have a synopsis of the current issue.
I'm trying to confirm this. I think that given the multiple warnings we've given Ask about the about:newaddon modifications, a block for that would not be out of order. I apparently have to wait 10 minutes for the installer to complete before I can check the settings modifications, so we'll see about that in a bit.

For reference, the installer's opt-out page:

https://people.mozilla.com/~kmaglione/images/159e55194e2fd768.png
Modified about:newaddon: https://people.mozilla.com/~kmaglione/images/87513f150336c8dc.png https://people.mozilla.com/~kmaglione/images/8348ad5b6f6eb39f.png

The default search engine and keyword URL are not changed unless the add-on is installed, but they're not reverted when it's disabled or uninstalled either: https://people.mozilla.com/~kmaglione/images/1aec31e9493f3e69.png (search page opened via the keyword URL and changed default search engine)
OS: Linux → All
Hardware: x86_64 → All
In Firefox 19 we will be landing Bug 718088, which will help those users with keyword.URL hijacking. Just wanting to point out that if we do block it that users who had their settings taken over won't be stuck with Ask.
IMO modifying newaddon clinches it.
Some SUMO information around Ask Toolbar (which has been a long standing Support issue):

Input feedback: https://input.mozilla.org/en-US/?product=firefox&sentiment=sad&locale=en-US&date_end=&date_start=&version=--&q=%22Ask+Toolbar%22 (this is a very strict query, there are more pieces if you loosen up the query)


https://support.mozilla.org/en-US/questions/800822 - 149 Users

https://support.mozilla.org/en-US/questions/753826 - 306 Users

https://support.mozilla.org/en-US/questions/793289 - 48 users

These stretch back for years and have only recently been locked. We still get multiple newer requests.
https://input.mozilla.org/opinion/3532440

This, along with other setting hijackers is causing us to lose ADI's
I just checked with the version installed by the ooVoo installer, and it also violates our guidelines by not reverting search setting and homepage changes after being disabled or uninstalled.
Please test these installers again and see if there's any further action required. As I understand it, all about:newaddon modifications were dropped.
The ooVoo installer no longer modifies about:newaddon, but it does change the search engine and homepage before the add-on installation has been accepted, and uninstalling does not revert the changes.
It's also no longer using the same ID as the other add-ons. The current version uses toolbar_OVO2V7@apn.ask.com, but toolbar_OVO2V6@apn.ask.com also exists in the wild.
I just came across a new set of Ask add-ons with different behavior. Rather than being side-installed by an external installer, they bundle the installer with the add-on, and side-install a search hijacker/toolbar add-on from within Firefox. They do ask users to opt into changes (https://people.mozilla.com/~kmaglione/images/ddb572fdd543dac4.png) and offer to revert them on uninstall (https://people.mozilla.com/~kmaglione/images/1417dea01b063b8a.png), but the default is to not revert.

These are sort of less out of policy than the other iteration, but these behaviors are still unacceptable in my opinion:

1) The initial add-on should not silently side-install another add-on. The user should give consent for the installation of the second. In the end, users are also left with two add-ons, which seems unnecessary.

2) The default behavior on uninstall should be to revert changes. Users should need to opt into keeping the changed settings.

3) The IDs should use the same domain. Currently they follow the pattern /[a-z0-9]{2}ffxtbr@.*/

An example can be installed from http://free.marineaquariumfree.com/index.jhtml

I believe that the following IDs are all iterations of this add-on:

8hffxtbr@Allin1Convert_8h.com
4affxtbr@Astrology_4a.com
1cffxtbr@BringMeSports_1c.com
2pffxtbr@CouponAlert_2p.com
5zffxtbr@CouponXplorer_5z.com
7lffxtbr@CursorMania_7l.com
2vffxtbr@DailyBibleGuide.com
v4ffxtbr@DictionaryBoss.com
paffxtbr@FilmFanatic.com
65ffxtbr@FromDocToPDF_65.com
gtffxtbr@GamingWonderland.com
29ffxtbr@HeadlineAlley_29.com
6offxtbr@HeroicPlay_6o.com
1gffxtbr@InboxAce_1g.com
39ffxtbr@MapsGalaxy_39.com
57ffxtbr@MarineAquarium3Free_57.com
5mffxtbr@MyFunCards_5m.com
8jffxtbr@MyImageConverter_8j.com
12ffxtbr@MyScrapNook_12.com
5affxtbr@MyWebFace_5a.com
m3ffxtbr@mywebsearch.com
7iffxtbr@PopularScreensavers_7i.com
4jffxtbr@RadioRage_4j.com
6xffxtbr@ReadingFanatic_6x.com
2jffxtbr@RecipeHub_2j.com
1pffxtbr@ReferenceBoss_1p.com
4wffxtbr@Retrogamer_4w.com
89ffxtbr@SafePCRepair_89.com
64ffxtbr@TelevisionFanatic.com
14ffxtbr@TotalRecipeSearch_14.com
5effxtbr@TranslationBuddy_5e.com
49ffxtbr@UtilityChest_49.com
4zffxtbr@VideoDownloadConverter_4z.com
1effxtbr@VideoScavenger_1e.com
gcffxtbr@WeatherBlink.com
52ffxtbr@Webfetti_52.com
86ffxtbr@YourVideoChat_86.com
5qffxtbr@Zwinky_5q.com
We're in touch with the people at Mindspark regarding comment #23.
Flags: in-moztrap+
Product: addons.mozilla.org → Toolkit
Does this bug need to remain open?
Flags: needinfo?(jorge)
No, we can reopen if the problem comes up again, but I think it was resolved.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 7 years ago
Flags: needinfo?(jorge)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.