Some of us prefer having complete integration with the OS. Plus, I haven't experienced any show stopping bugs while using Safari.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Updates Anti-Malware Software to Block Older Versions of Adobe Flash Player Plug-in
- Thread starter MacRumors
- Start date
- Sort by reaction score
Some of us prefer having complete integration with the OS. Plus, I haven't experienced any show stopping bugs while using Safari.
I ask sincerely (esp since I don't think I even have the VERY latest installed) - what aspects of integration with the OS does Safari offer that another browser doesn't?
CrashPlan does not, by any means, require that the java browser plugin be enabled. There is a difference between having a java runtime installed and having the browser plugin additionally enabled. The browser plugin is the common attack vector.
CrashPlan agent and server require a java runtime present. That is all.
Does the CrashPlan management GUI require the browser plugin?
I have a number of million+ dollar EMC RAID arrays that are managed by the Navisphere Java web GUI.
Fortunately, I use Windows systems to manage them - so I get a "potential security issue" popup that I can click "ignore" on, instead of having millions of dollars of disk arrays that I can't manage.
AAPL hit a 52 week low today. Connection?
Apple simply doesn't understand the enterprise, and stunts like disabling Java without warning help ensure that the enterprise will never trust Apple.
Sorry, try this link: http://www.java.com/en/download/installed.jsp
If it says it can't determine, then either you didn't installed it, or Apple is now automatically blocking it to protect your MAC.
The problem isn't Java; the problem is Java in the browser.
You are confused between a standalone Java app and Java in the browser, and your CrashPlan Pro. Look at http://crashplan.com/blog/consumer_backup/crashplan-users-java-safe-and-sound : The vulnerability only affects the Java browser plug-in, which CrashPlan doesn’t use (or need)
Apple has had the malware-disabling preference since snow leopard and there is definitely a way to opt out. What's NOT OK is griping about things that you clearly don't understand.
Last edited:
people just amase me
People just amaze me because they will spend time back in forth in forums like this one (and it does not matter the info or title) and claim they are the only one who has it correct! But that cannot be further from the truth, people need to understand that weather it is apple, MS or whoever it is a much bigger issue or thing then what ONE person thinks they know!!
Stop yelling at one another and start listening, as for the issue with JAVA it is a HUGE platform that is not going away anytime soon, just the same with Flash, both of these platforms are used by more people than not, it is much larger than apple!
People just amaze me because they will spend time back in forth in forums like this one (and it does not matter the info or title) and claim they are the only one who has it correct! But that cannot be further from the truth, people need to understand that weather it is apple, MS or whoever it is a much bigger issue or thing then what ONE person thinks they know!!
Stop yelling at one another and start listening, as for the issue with JAVA it is a HUGE platform that is not going away anytime soon, just the same with Flash, both of these platforms are used by more people than not, it is much larger than apple!
Nobody should come in this weekend, Tigres. What you should be asking is why you tolerate having your suppliers using a platform -- Java in the browser -- that has had zero-day exploits for at least a year and a half?
What exactly is it going to take before your vendors -- and you -- get a wake-up call? Do you need to get a widespread zero-day spear phishing attack costing your company millions of dollars? Do you need a deadline from the DHS telling you that you must stop using Java in the browser? What will it take?
How does your company deal with providing solutions for the iPhone, iPad, Windows RT, and other platforms that do not support Java and Flash in the browser? Companies are delivering solutions via the app store on these platforms; WTF can't you do the same on the Mac platform?
Exactly. It's mind-boggling why someone would be managing a million+ dollar product with a platform that continues to be vulnerable to zero day attacks. Why doesn't EMC package their solution through app stores? Why aren't their customers insisting on it?
Zero. But why are you asking us? Why don't you just use a JVM search-engine (or perhaps just google) to see if you can find one analyst -- anywhere -- who said that?
Here's a different cut: some employees managing million+ dollar equipment are oblivious to the clear and present risk of behavioral profiling to introduce exploits into the enterprise. They know that employees have programmed themselves to click "ignore" when a "potential security issue" warning pops up. Apple is looking for comprehensive solutions to these problems -- using the App Store for managing these custom apps rather than the risk of running unverified software in the browser.
Is there some good reason that EMC couldn't package the Java GUI and deliver it through the App Store?
@Aiden: EMC hit their 52-week low on Friday -- the same day you told us they use platforms that are constantly being attacked by new zero-day exploits. Connection?
Last edited:
Probably because:
- EMC isn't cracking into their customer's computers through the exploits
- Java lets EMC support lots of different clients with one code base
- "Best practices" for data centers with million dollar disk arrays puts the management network in a separate out-of-band subnet firewalled from all other networks.
In other words, I have to remote desktop into a proxy system inside the firewalled network, and run the browser Java app inside the protected domain. The protected domain is unable to access "the interwebs" - so there is no risk.
Enterprises don't run browsers on their servers, except for specific well-known apps - such as browser-based software update apps or hardware control apps (such as RAID configuration utilities) which are often local disk-based "websites". Other than encrypted, signed access to the manufacturers' software repositories network access is not needed.
These practices are necessary regardless of the software used - even without Java one would never allow a system with full "interweb" access to run management software on the servers/controllers.
When you say things like
It's terribly difficult to take you seriously in the discussion.
A spear-phishing threat wouldn't come from EMC; the threat would come from an entity that knows you use Java in the browser. They'd know you were vulnerable to a Java-browser-based zero-day exploit. If EMC delivered their Java management tool through the App Store, you would not have that risk.
What led you to presume anyone was claiming the zero-day exploit would come from EMC?
Again, I don't think you understand what's being discussed. The malware threat isn't from Java per se; it's the fact that Java is enabled in the browser. EMC could deliver their Java code to computers some other way than through dynamic loading and execution in the browser. It is not an issue of having multiple code bases!
By your own account the "potential security issue" popup pops up every single time you invoke the Navisphere GUI. Wouldn't "best practices" say that it's rather dangerous to have to click the "ignore" button every time you fire up the software? Training operators to regularly click an "ignore" button is asking for trouble.
Nope. You're not getting it at all. This system trains the operators to regularly "ignore" a "potential security issue". The risk is behavioral conditioning -- pressing "ignore" when you have a real security issue. In other words, requiring ops to regularly click "ignore" qualifies as a worst practice.
Not exactly.
The dubious practice is forcing the operators to click "ignore" every time they fire up the software. The alternative is to have the vendor package the code and have it installed on the machine -- no need to press "ignore" every time it's used.
If you eliminate the JVM from the browser you eliminate the possibility that you'll ever get a zero-day exploit coming in through that path.
Now: why did you try to imply that AAPL's stock price had anything to do with this discussion?
It's terribly difficult to take you seriously in the discussion.
A spear-phishing threat wouldn't come from EMC; the threat would come from an entity that knows you use Java in the browser. They'd know you were vulnerable to a Java-browser-based zero-day exploit. If EMC delivered their Java management tool through the App Store, you would not have that risk.
What led you to presume anyone was claiming the zero-day exploit would come from EMC?
Again, I don't think you understand what's being discussed. The malware threat isn't from Java per se; it's the fact that Java is enabled in the browser. EMC could deliver their Java code to computers some other way than through dynamic loading and execution in the browser. It is not an issue of having multiple code bases!
By your own account the "potential security issue" popup pops up every single time you invoke the Navisphere GUI. Wouldn't "best practices" say that it's rather dangerous to have to click the "ignore" button every time you fire up the software? Training operators to regularly click an "ignore" button is asking for trouble.
Nope. You're not getting it at all. This system trains the operators to regularly "ignore" a "potential security issue". The risk is behavioral conditioning -- pressing "ignore" when you have a real security issue. In other words, requiring ops to regularly click "ignore" qualifies as a worst practice.
Not exactly.
The dubious practice is forcing the operators to click "ignore" every time they fire up the software. The alternative is to have the vendor package the code and have it installed on the machine -- no need to press "ignore" every time it's used.
If you eliminate the JVM from the browser you eliminate the possibility that you'll ever get a zero-day exploit coming in through that path.
Now: why did you try to imply that AAPL's stock price had anything to do with this discussion?
Last edited:
What i'm seeing is java being used as a tool for installing stand alone apps. The app can be java or not. Examples are SAP GUI and AnyConnect. Oracle and Cisco should not be requiring java in the browser considering how easy it is to create an OS X install package.
And why should there be any java app running within a web browser in the first place?
And why should there be any java app running within a web browser in the first place?
Bingo. Several here have been insisting that there's no way to deploy a common code base without the risk of zero-day Flash/Java browser exploits. They are wrong.
Adobe has hit a home run with their Flash Builder software. It creates packaging of Flash software for iOS, Android, BlackBerry Tablet OS, Windows, Mac OS, and Linux. I'm confident that Windows RT (ARM mobile platform) will be added to the fold. Machnarium is one of the great cross-platform Flash success stories. The Flash app was the #1 paid iPad game in the App Store for several weeks.
Does the packaging of Java work as well? I can't say; I've never done it. JAR files were certainly intended to be used this way. AFAICT, Oracle hasn't bothered to promote the cross-platform deployment of Java apps nearly as thoroughly as Adobe has done with Flash.
It's a most excellent question. Steve Gibson noted on his Security Now! podcast that Java was never ever designed with the intention of running it in the browser. It reminds me of one of my favorite quotes in all of computerdom: something that goes back to pre-PC days. TECO madness:
Java (and Flash) implemented within the browser are the equivalent of GMO Foods on our PCs: just say no!
-If Apple changes the UI for OSX, Safari's UI is changed to match it. See: FireFox scroll bars compared to the ones used with Apple's stock OSX applications on 10.8.
-Gesture animations match those present on stock applications. Ex. Google Chrome swipe gestures are different.
-Integration with iOS bookmarks and cloud tabs.
-Files downloaded by Safari are screened by the OS for malware.
To name a few..
Clearly, you don't understand the enterprise any more than Apple does.
It's nice to have blue sky notions of an idyllic world - but reality often sucks.
You propose what you say is a better way - but should I have to trash-can millions of dollars of enterprise class Fibre Channel hardware and buy new stuff that follows your idea?
The EMC arrays that I have were in fact EOL'd in 2010. No software/firmware updates. No chance of any fixes. The Navisphere in question actually requires Java 6 - it won't run (even in the browser) with Java 7. Do I need to spend more millions on Java 7 compatible arrays?
And your "spear-pfishing" comment shows that you didn't read or understand what I said. No "spear-pfishing" or other exploit is possible in our setup, even while running Java 6 in the browser.
Apple seems to think that forcing everyone to replace equipment every few years is a good business model. That model works for iToys, but it doesn't work for businesses that have much longer lifecycles for multi-million dollar systems and software.
When I need to replace the FC arrays because they've reached the end of their useful life (or, more likely, we upgrade the applications using them - since TiB don't really have a "useful life"), I'll certainly consider security issues with the management software when I buy. But until then, the systems, arrays and applications "ain't broke" - and the adage "don't fix what ain't broke" is gospel.
Also, you latched onto a relatively minor point in my explanation - the security popup. It is not "every time" you run the software. There are a couple of places (for example, when you drill down into Domain->ArrayController->RAIDgroup-NN->LUN-MMM->devices->bus0.enclosure4.disk13->properties and click on the "advanced" tab) where a popup warns that the applet for that function isn't correctly signed.
We're not telling untrained operators to click "ignore" on every warning. Only highly skilled admins configure the RAID arrays, and it's a pretty clearly defined issue that some deep menus have a signage warning. And it's also clear that there is zero risk in clicking "run anyway" on an applet that the RAID array itself sends to the browser that's running in a sandbox.
Please turn down the theatrics - we live and work in the real world, not some idyllic perfect world.
Last edited:
Apple disabling flash whenever the hell they feel like it is a pain in the ass if a person runs a lab that needs access to flash. It throws lesson plans into a loop of pain if using flash is an important part of the day, and about 20 minutes into class kids hands start going up and the "blocked plugin" warning becomes a headache and obstacle to getting work done.
And yes, some of us still use safari. There are districts who require it. Nope. We cannot use Firefox. Feel for the windows labs.....they HAVE yo use IE.
And yes, some of us still use safari. There are districts who require it. Nope. We cannot use Firefox. Feel for the windows labs.....they HAVE yo use IE.