Furthermore, the Java installation goes as far as to actually recommend installing this useless junk, meaning that any non IT-savvy person is more than likely to leave it checked and install it (after all, it was enabled by default and the friendly Java installed did recommend it, right?).
To add insult to injury, even if you remove the Ask Toolbar, you can be sure to see it again soon, when the next Java update hits you (which seem to happen quite often lately, due to loads of security fixes for Java, but that's another story).
Seeing the damn thing pop-up on several family members' and friends' computer I support, I found a simple way of removing it silently (in case you want to do it via scripting), but more importantly: Prevent future installations of Ask Toolbar!
Update: Since I made the script to prevent the installation of Ask with Java, a much nicer and more elegant solution has been found by Danilo Roascio on the question I posted to SuperUser.com: How can I prevent Ask.com Toolbar from being installed every time Java is updated?
I've kept the original post intact below for reference, but you should really consider the simple registry fix first.
Uninstalling Ask Toolbar from command line
If you do not want to simply uninstall the toolbar from Add/Remove Programs, here's how to do it from the command line.
From an elevated command prompt, run:
MsiExec.exe /X{86D4B82A-ABED-442A-BE86-96357B70F4FE} /q
The GUID between the brackets is the product code for the Ask.com Toolbar and is at least valid for versions 1.15.9.0 and 1.15.15.0.
Preventing future installations of Ask Toolbar
The simplest way to prevent Ask Toolbar from being installed again I could think of, was to create the folder Ask Toolbar install into and modify the permissions, so no one can write to it.First, make sure that the Ask Toolbar has been removed. Then copy the following code to Notepad, save it as a .cmd file and run it in an elevated command prompt:
REM Detect processor architecture
set proc_arch=x64
if "%PROCESSOR_ARCHITECTURE%" == "x86" (
if not defined PROCESSOR_ARCHITEW6432 set proc_arch=x86
)
REM Define Ask Toolbar path
if "%proc_arch%" == "x86" set AskPath=C:\Program Files\Ask.com
if "%proc_arch%" == "x64" set AskPath=C:\Program Files (x86)\Ask.com
set AskReadme=%AskPath%\..\Ask.com_ReadMe.txt
set AskRevert=%AskPath%\..\Ask.com_RestorePermissions.cmd
REM Create dummy Ask Toolbar folder
md "%AskPath%"
REM Add explanatory text file, as to why the dummy folder is there
echo The 'Ask.com' folder is has been created and write protected,> "%AskReadme%"
echo in order to prevent Ask.com Toolbar from being 'accidentally'>> "%AskReadme%"
echo installed, e.g. by Java.>> "%AskPath%\readme.txt">> "%AskReadme%"
echo.>> "%AskReadme%"
echo This has been done using ICACLS by denying write access to the>> "%AskReadme%"
echo EVERYONE security group.>> "%AskReadme%"
echo.>> "%AskReadme%"
echo To revert permissions run:>> "%AskReadme%"
echo %AskRevert%>> "%AskReadme%"
REM Create script to remove restrictions
echo icacls "%AskPath%" /remove:d *S-1-1-0> "%AskRevert%"
REM Deny everyone (SID: S-1-1-0) write access
icacls "%AskPath%" /deny *S-1-1-0:(OI)(CI)W
Please note: ICACLS is included in Windows Vista and later. You can download ICACLS for Windows XP/Server 2003 through Microsoft KB919240, or an updated version through KB943043 (but the latter must first be requested, after which you will receive a link to download it). For this purpose, both versions should work equally well.
I have verified with the installer for Java 1.7 update 13, that the Ask Toolbar indeed does not install, even if I leave the checkbox checked.
This doesn't happen if you simply only have been assigned read access in the first place, but it seems to happen when you have been assigned read/write permission to the folder and then been denied write access.
Windows Explorer quirk: Access denied
Windows Explorer behaves a little strange if you try to open the folder. Even though you still have read access to the folder, Windows Explorer will tell you that access is denied, even though only write access has been denied.This doesn't happen if you simply only have been assigned read access in the first place, but it seems to happen when you have been assigned read/write permission to the folder and then been denied write access.