Disable the installation of Ask Toolbar by Java

2 Replies

I absolutely deplore companies that bundle toolbars with their products in an attempt to monetize them.  I can’t tell you how many times I will be asked to help someone with their computer and I’ll find a browser that has 4 or 5 toolbars installed on it.

I’ll tolerate this behavior from little companies that are maybe trying to get their foot in the door and survive while giving their products away. But when large companies, like Adobe bundle McAfee with Flash or Oracle bundle the Ask toolbar with Java I just find it absolutely disgusting.

For a long time, Mac users were spared this garbage by Oracle but they’ve recently decided that we’ve had it too good for too long so as of Java 8 Update 40 the ask toolbar has come to Mac too.  Check out more coverage over at Zdnet which is where I originally saw the story.

Disable Sponsored Offers via Terminal

If you want to prevent this from happening run these two Terminal Commands prior to updating to Java 8 Update 40.

defaults write com.oracle.javadeployment.plist "/com/oracle/javadeployment/" -dict-add install.disable.sponsor.offers true
defaults write ~/Library/Application\ Support/JREInstaller/ThirdParty SPONSORS -string "0"

This should prevent the update, and all future updates, from installing the toolbar.  Remember to always check those installation prompts and options just in case.

Disable via Java Control Panel

If you’ve already installed Java 8 Update 40 they expose the option in the Java Control Panel, which is accessible Under System Preferences. Java

 

The option is exposed under the Advanced tab and is all the way at the bottom.

Disable Java Sponsor Offers Ask Toolbar

A screen shot demonstrating how to suppress sponsor offers

If you’d like similar directions for windows check out this post over at How-to Geek.

This post was updated to add an additional command.

What is a Valid Email Address?

Leave a reply

I’m working on a side project and needed to validate if an email address format was valid.   I started doing searches and found a very interesting article by Ross Kendall.   His javascript implementation strictly implements RFC822, which although out of date [RFC2821 & RFC2822] is better than most alternatives that I came across.

My biggest issue with his script was that it didn’t require the domain to be at least two parts.  This meets spec and is certainly not a bug, however for all practical purposes online it would allow unsuitable email addresses.  I know just enough about regular expressions to realize it was a simple fix to make multiple domain parts required.  So I made the following modifications

I added an optional requiredFQDN parameter that’s intended to be a boolean value.

function isRFC822ValidEmail(sEmail, requireFQDN) {
   if(typeof(requireFQDN) == “undefined”)
      requireFQDN = false;

And then I changed the 0 to many identifier, * to the 1 to many identifier +.

if(requireFQDN)
    sDomain = sDomain.substr(0,sDomain.length-1) + ‘+’;

You can download the entire file here.