An unofficial blog that watches Google's attempts to move your operating system online since 2005. Not affiliated with Google.

Send your tips to

April 18, 2011

Java and QuickTime Require Permission in Google Chrome

Last year, Chrome's team promised to add some features that improve plug-in security. One of them is already included in the latest dev builds: "some plug-ins are widely installed but typically not required for today's Internet experience. For most users, any attempt to instantiate such a plug-in is suspicious and Google Chrome will warn on this condition."

Two of the plug-ins that require permission every time you visit a site that uses them are Oracle's Java and Apple's QuickTime. The two plug-ins are enabled by default, but you need to click "Run this time" or "Always run on this site" to load the full content of the page. You can manually whitelist domains, but there's no way to disable the infobar.

While not many sites use these plug-ins, it's surprising to see that Chrome requires permission before loading Java or QuickTime content, even if you've updated to the latest version of the plug-in. The infobar warning is annoying, some users might ignore it, while others could think that the page tries to install malicious software.

"The reason is to protect the (estimated 90% - 95%) of internet users who do not ever need to instantiate various lesser-used plug-ins. Remember that you just have to press a single button on the sites that you trust to run Java. And then you're done. In fact you're much better than done: you've limited your exposure to Java security vulnerabilities such that a drive-by malware Java ad won't automatically run. I encourage you to read about the evolution of drive-by downloads and pay particular attention to how Java is being used in a lot of current attacks, even when it is fully up to date," explains a Chrome engineer.

An article from November 2010 informs that "a Java exploit has replaced exploits of PDF file weaknesses to become the most common threat, according to G Data SecurityLabs. Java vulnerabilities offer cyber criminals a lot of potential on the technical side, said researchers, and the development and distribution of malicious code is considerably easier than other methods of infecting a system. Topping the list is Java.Trojan.Exploit.Bytverify.N, which exploits a security hole in Java's byte code verifier. Using this exploit allows the execution of malicious code which could enable an attacker to gain control over a victim's system. This trojan is typically found on hacked websites, where it attempts to infect PCs through drive-by download through a manipulated Java applet, researchers said. Just visiting an infected website with an unprotected computer will be enough to infect a system." G Data expects "a significant rise in the number of Java-based malware in the coming months".


  1. He later fixed that to "press a single button". Could you update the post ("press a single version" doesn't make much sense here).

  2. by the way, I wonder how long will it take until they start doing that with Flash :P

  3. I agree with this implementation, it's a bit geeky but of course does it implement another degree of saftety.


  4. @Waldir:

    I've changed the quote.


    Flash is bundled with Chrome and also sandboxed.

  5. It sounds very wired but I have never worked on Chrome.So never realized about its advantages and disadvantages.

  6. Fair enough in blocking Java but blocking QuickTime seems like more of an attempt to annoy Apple than a security feature.

  7. Good. Both times my computer got malware it was because of the Java plugin. Because of that I uninstalled Java (and I uninstalled QuickTime ages earlier), but this is still nice to see.

  8. A little bit annoying. It would be nice to have that "always run this plugin" button.

    Some API additions to properly implement NoScript would have been better also, then this.

  9. This is a good idea! Brian Krebs actually recommends uninstalling Java.

    I have ran into the occasional QuickTime file and even more rarely the Java file, so instead of uninstalling or turning off Java, I'd rather be prompted to run it.

  10. Didnt windows vista do something very similar and it wasn't very effective. I think the core lesson was click fatigue does not produce security.

  11. Maybe this makes sense, but it certainly has the appearance of an attack on Java and Quicktime.

    Actually, it is an attack on them, the question is whether it is justified.

    Will this apply to plug-ins like silverlight and H264? Will this turn into an attack on anything that Google doesn't like?

  12. Definitely a jab a Oracle and Apple. If you think it's anything else, you are fooling yourself.

  13. I have used a weather radar applet in my start up page for 15 years. This page auto refreshes every 10 minutes. Now I will have to give permission every time the page reloads? Why do they hate us so much? What did we do to them to warrant this crap? :(

  14. Anonymous above clearly can't read. What do you think the button "Always run on this site" means?

  15. A well-planned jab. Both plug-ins obviously pose a security risk, which gives Google the perfect excuse to 'block' them.

  16. Sounds great... but what is "a site?" I just loaded some language software with QuickTime files in multiple directories. Each subdirectory is apparently considered a "site." So, the prompt is everywhere. Further, these are on my hard disk, not some nefarious website. How about if I can approve everything recursively under a certain directory? In my mind, "site" is protocol://site, e.g. .

  17. I don't need a nanny, Google. The lack of a way to indicate that a plug-in should be run on all sites without prompting is completely unacceptable. If I can't find a way around it, Chrome will no longer be my default browser.

  18. Java applets already have a security mechanism built in. An applet runs in a sandbox and can be either a signed or unsigned applet. If it is a signed applet then a security dialog will appear to the user before the applet is allowed to run. If it is an unsigned applet then it can only run in the sandbox and cannot harm the computer. I don't like this new prompt from google chrome at all. I think that if the user has an up to date JRE then no prompt is necessary. Please reconsider this new policy.

  19. you're sad, Google. "not required for today's internet experience"? I use QT all day long on my, um, Mac. I know you're upset by Apple's relentless kicking of your ass (how'd you like that "reader" in iOS5, huh? kind of makes internet ads useless, don't it?), but basically disabling QT? guess it's time to go back to firefox...

  20. "Fair enough in blocking Java but blocking QuickTime seems like more of an attempt to annoy Apple than a security feature."

    Well, I'd argue that blocking Java is more likely retaliation against Oracle for the Android lawsuits then anything else. If they were really concerned about security, they'd be doing the same thing with Flash. There have been and are tons of flash vulnerabilities out there. They don't block Silverlight content either, which they would be doing if blocking plugins that "lots of people have installed, but do not actually use" was the real reason for doing this.

    Also, the recent Apple MacDefender infections are proof enough that making a user confirm something doesn't work anyway. It's trivial to track the average user into clicking Yes on something when they should be clicking No.

    Again, I smell a rat. And it smells like retaliation against Oracle to undermine JavaFX 2's ability to compete as an RIA technology. And I think they are doing it in response to the Android lawsuit.

  21. Flash is bundled with Chrome and Google works on sandboxing the plugin. Chrome also bundles a PDF viewer which can be used instead of Adobe Reader.

    Java and Quicktime have three characteristics: (i) they have a large user base, (ii) not many sites use them, compared to other plugins, (iii) a lot of malware uses Java/Quicktime vulnerabilities to infect computers. This is not cheap a move to annoy Oracle and Apple, it's an overly protective feature. Google can't sandbox plugins, so it tries to minimize their impact by warning you when they need to be updated or when you are about to load some objects that could be malware. These are just some of the many security features recently added by Chrome. I agree that some are annoying and they should be imoroved, but the goal is to protect users, not to attack Oracle or Apple.

  22. Alex,

    The fact that Google is all buddy buddy with Adobe and is bundling Flash only adds weight to my suspicion that Google is intentionally trying to undermine Java FX 2 and Apache Pivot as RIA platforms on Chrome.

    Also, a lot of malware uses Flash vulnerabilities to infect computers as well. So applying this double standard makes no sense unless there is an ulterior motive at work. I have already stated what that ulterior motive is. A combination of partnership with Adobe, combined with malice against Oracle because of the Android lawsuit.

    And again, Microsoft Silverlight (i) has a large user base (because it is bundled with .NET by default, which is installed with all new versions of Windows), (ii) not very many sites actually uses it compared to other plugins. (iii) it's a security vulnerability. So Silverlight would seem to fall in the same category as Java. Except Silverlight is getting a pass, and Java is not.

    It might be true that Google can't sandbox plugins, but again, why are they giving Silverlight a free pass, but not Java? Java has been singled out as the only RIA technology they are blocking. Silverlight is allowed. Flash is allowed. If Microsoft tried to pull this on Internet Explorer, you can bet that they would be back in antitrust court right now for intentionally trying to undermine Java's future as an RIA technology. But so far, Google is being allowed to get away with it. They are singling out Java for unfair treatment, while allowing flash and Silverlight to get a free pass.

    I don't consider this far or acceptable. And the decision impacts my enterprise clients that use Java applets. Because of that, I am no longer using Chrome. And I am no longer recommending Chrome to my clients, or considering it to be a supported platform. In fact, I am telling my clients that we recommend they do NOT use Chrome, because we will not support it. We support Firefox, and IE.

    I honestly never thought the day would come when I would recommend Internet Explorer over Chrome, or say that we support Internet Explorer, but not Chrome. But that is the position I am in now. Because Google has forced me into it by deciding that Java is a second class citizen in the RIA space.

  23. I would also point out that Google is censoring discussions about this on the Chromium bug forums. I brought up my concerns about the technical reasons for this not being valid, given that Flash is a major source of security vulnerabilities as well. I also raised the concern that Google was doing this to retaliate against Oracle for the Android lawsuit. My comments were censored by deleting them. And the threads were locked so I could not respond again.

    Google claims to not be evil, and claims to support freedom. But they are exactly the opposite of what they claim. They suppress free speech. They create unfair playing fields for RIA technologies. Again, if Microsoft tried this, they would be slapped with an antitrust lawsuit.

    Make no mistake. Google is evil, and should be avoided whenever possible. Try as an alternative to Google for Web searches btw. They don't track you like Google does. And they don't censor your search results based on what the think you might be interested in. I've been using it for the last few days, and am very happy with it.

  24. "Exploits of Sun Java by web malware increased in the third quarter, from 5% of all attacks in July to 7% in September, according to Cisco’s 3Q10 Global Threat Report." ( )

    "Landesman told Infosecurity that the increase in Sun Java attacks was the result of the development of a public exploit code for Java made available in the first quarter. So attackers began to focus on Java, and Java was put at the top of the exploit list.

    Many users are unaware that they have Java on their computers. Also, Sun’s security updates for Java are unpredictable. These both contributed to Java’s vulnerability to malware attacks." (same source)

    "Durham, NC—April 21, 2011— Online criminals are relying more heavily on Java security holes to distribute computer malware, according to research generated from G Data Security Labs. Not only has Java malware been on the rise since 2010, last month five of G Data’s Top 10 malware programs targeted Java or Javascript.  These unclosed security holes are playing a progressively larger role in the infection of Windows systems and have been gaining the attention of the security community." ( )

  25. " Reportedly, during Q3-2010, Java assaults rose to about 14 times the attacks identified during Q2-2010 whence two vulnerabilities within Sun (presently called Oracle) JVM namely CVE-2009-3867 and CVE-2008-5353 were exploited. " (,-Says-Microsoft-2011052314642/ )

    "Over the last few months we’ve seen a noticeable rise in the number of in-the-wild Java related exploits, some of which are pretty effective. We’ve been detecting most of these as Mal/WebStart-A. The typical scenario we see is a compromised web page hosting a malicious Java applet which downloads and executes a PE file. So why have the bad guys taken to using Java as an attack vector? Well, why not? It works. " ( )

  26. Just last week, there was another memory corruption vulnerability in Flash that allowed arbitrary code execution and was rated "Extremely Critical" by Secunia. So you can quote people claiming Java is insecure all day. And I can respond by quoting vulnerabilities in Flash that make it insecure as well. So again, why isn't Flash getting the same treatment that Java is? Because Google has an ulterior motive to undermine Java. That's why.

    Both exploits were fixed in recent versions of the JVM. Java is no longer vulnerable to those exploits. It should be enough that Chrome checks whether the plugin is outdated or not, and if it is outdated, then it will ask you to upgrade it and block execution of the applet. I'm fine with that. But blocking execution on a JVM that is 100% up to date, I am not fine with unless they apply the same standard to all RIA technologies.

  27. I agree. Blocking Java content only if you're using an outdated Java version is the best thing to do. I haven't found reports that show QuickTime malware is on the rise, so I'm not sure why it's blocked.

    Regarding Flash, I don't think Google is a big Flash fan, but their partnership with Adobe allowed them to bundle Flash and to start working on sandboxing the plugin. Flash for Chrome is already partially sandboxed in Windows and this will be improved. Chrome's auto-update makes sure that you always have the latest versionof the plugin. I don't think Oracle would allow Google to bundle a sandboxed Java plugin and I'm not sure if this would be possible. Java is rarely used on the client side today, so I don't think blocking Java content by default is such a big annoyance for users. I know a lot of people that use extensions like FlashBlock which block Flash content and lets you enable it on demand. No more Flash ads, fewer CPU cycles wasted, no more videos to play automatically. JavaBlock makes even more sense, since Java applets are used a lot to create malware.

    Google should try to better balance security benefits with user needs and only block outdated plugins.

  28. I agree that there isn't a lot of client side Java activity right now. At least not in the RIA space. But there are a few very prominent and popular sites that do use Java applets. Wikipedia is probably the best example. The embedded media player in many Wikipedia articles is a Java applet.

    But again, my concern is more about the future. There are emerging Java RIA technologies such as JavaFX 2, and Apache Pivot. There are also some commercial Java RIA technologies such as Canoo RIA Suite. And I think this undermines their ability to compete alongside Flash and Silverlight because with Java, you don't get a seamless experience anymore in Chrome. And now, if you are an RIA developer and you use Java, you have to explain to the users that yes, it's OK for them to allow the app to run because it is legitimate and all. I think this reduces the appeal of Java based RIA technologies, and thus hurts them from a competitive standpoint.

    As far as bundling a sandboxed Java plugin, that should be possible for Google to do by using OpenJDK, which is GPL licensed. There is already GPL code in Chrome, so there should not be a licensing conflict with any existing Chrome code. In fact, Google should be able to do it without even getting permission from Oracle, since the GPL'd OpenJDK should allow them to do whatever they want with the code as long as they follow the requirements of the GPL.

  29. Re: "You can manually whitelist domains..."

    Other than visiting a page with Java on the desired domain, how?

    1. Paste this in the address bar:


      and add domains like this:


      This is not limited to Java, so you whitelist domains for all plug-ins.


Note: Only a member of this blog may post a comment.