Looks like our 10.6.8 systems running 1.6.0_37 are disabled as well.

This is bad…

Yes, all of our Macs have had this issue. We have Java 6 on 10.6 and Java 7 on 10.7/10.8. On users' Macs that needed urgent access to Java in a web browser I pushed out a modified XProtect.meta.plist file which is located in /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/

I changed the JavaWebComponentVersionMinimum key to 1.6.0_37_b06-434 and the MinimumPlugInBundleVersion key to 1.7.11.21

After you deploy the updated file to the Mac the user just needs to restart their browser and Java will be enabled again.

I did the same thing and got mine back working. I am going to create a policy that I can put in Self Service.

The problem is that Apple will simply change this file back.

I think if you uncheck the 'Automatically update safe downloads list' (System Preferences > Security & Privacy > Advanced) that this will disable this file from being updated?

Can anyone clarify this?

Thanks for the heads up on this! I can understand Apple pushing a new XProtect min version list IF the new Java plug-in version is out there already, but this is just stupid. At least wait until the new version is out before you start blanket disabling it for your entire user base.
So there are going to be a bunch of Mac users out there that suddenly won't be able to connect to a Webex session and will be wondering what the heck happened. Nice one Apple!

They should pop up a warning "Hey, your version of java exposes you to a risk that we don't think you should accept. However, Click here to continue at your own risk…"

Instead, Apple shuts it down with no path to an upgrade and the workaround a hack like the one mentioned above.

We have critical connections with our vendors that depend on Java.

Yup. Now my remote users could be completely screwed as the java plugin is blocked.

THANKS APPLE

I've got a post up now about this issue:

http://derflounder.wordpress.com/2013/01/31/java-blocked-in-safari-on-10-6-x-10-8-x/

It looks like the workaround for now is Firefox.

I found that running Firefox on a 10.6 Mac this morning disabled Java and wouldn't run until I modified the XProtect.meta.plist file.

Anyone sort out how to programmatically disable the safe downloads list updating??

defaults write /System/Library/LaunchDaemons/com.apple.xprotectupdater Disabled -bool yes

brilliant. i arrived there the same time you answered :)

We downloaded and wrapped both of these earlier this week, they deploy and launch fine on Mountain Lion:

Apple-Java-1.6.0_37
Oracle-Java-1.7.0_11

defaults write /System/Library/LaunchDaemons/com.apple.xprotectupdater Disabled -bool yes

This isn't working for me.

sudo def...

@don check the xprotect file on your machine. Some of our users haven't gotten one, but the ones with JAVA issues have a file from this morning on them.

Well duh. The issue is that it's not clearing the checkbox for "Automatically update safe downloads list" and the file is still being pulled down from Apple. I've found that the /var/db/launchd.db/com.apple.launchd/overrides.plist file is where the setting is changed when you manually check/uncheck the box and I've been able to change the flag manually in the file and see the box clear.

So, I think I'm looking at plistbuddy to manually change the flag.

defaults write /System/Library/LaunchDaemons/com.apple.xprotectupdater Disabled -bool yes

@jared - above worked for me but didn't see the change in GUI until I rebooted.

Reboot hasn't changed the flag for me... hrm.

UPDATE: I used plistbuddy to change it, rebooted, flag cleared in GUI.

UPDATE: Or not. This is completely inconsistent for me.

OK, I clicked the company SSL link in Safari, and got "Your Java is out of date - install".
I click the install button, and it takes me to the Oracle Java DL page, and it's Java 7, update 11.
What gives? I already have Java 7_11 installed.

Working on this along with the great collective here... But does anyone see the ironic humor in the fact that when Apple was releasing Java updates we'd go 6-8 months sometimes following critical vulnerabilities, where as now that they've dumped it back to Oracle they're expecting zero-day fixes? Just thought that's interesting....

I'm also seeing inconsistencies like Jared is so far...

Apple is doing better, but yes, it's kinda funny - well, except that it causes admin's more grief than Windows :)

Yes @john_wetter, I definitely noticed the irony there too.

Ok I've found some consistencies. The reason it's unreliable is because we need to unload the launchdaemon instead of just setting it to disabled and rebooting. Let's all think about launchd 101 here.... This appears to be reliable in initial testing. No reboot needed, checkbox is cleared in the GUI.

#!/bin/sh



#Filename: xprotectDisable.sh

#Purpose: Disable XProtect and delete it's settings file

#Author: Jared F. Nichols



# Disable XProtect

launchctl unload -w /System/Library/LaunchDaemons/com.apple.xprotectupdater.plist



# Kill the xprotect meta file

rm -f /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist

Apple is doing better, but yes, it's kinda funny - well, except that it causes admin's more grief than Windows :)

I've always said that Apple doesn't royally screw up often, but when they do it's spectacular.