- Apr - Flashback trojan using Java applets found
- Jun - Apple and Oracle release update to patch Flashback
- Aug - News story that Oracle were alerted to critical bugs in April
- Aug - Oracle patches critical security bugs
- Aug - Critical Java flaw in latest Java (7u7) prompts calls to disable Java
- Oct - Apple removes Java from all web browsers
- Jan - US Dept of Homeland Security recommends users to disable Java
- Jan - Apple blacklists Java on OSX to prevent latest critical exploits
- Jan - Critical vulnerabilities confirmed in 7u11
- Jan - Java's 'very high' security mode released in 7u10 fails to protect from exploits
- Jan - Firefox blocks content based on Java, Reader and Sliverlight
- Jan - Apple blacklists Java on OSX to prevent "critical" exploits (twice in one month)
- Jan - Critical vulnerabilities in the latest Java version
- Feb - Facebook, Twitter, Apple compromised by Java exploit
- Feb - Microsoft finds computers compromised by Java
- Feb - More vulnerabilities delivered by security researchers to Oracle
- Mar - Java exploit being actively used to attack targets
- Mar - Apple blacklists older versions of Flash plugin
- Mar - Oracle releases a new patch to address severe security bug
- Mar - Flash, Java, AIR and Reader take 4 out of 5 top spots for causes of PC security problems
- Mar - Apple fixes an issue which allowed JWS to start even if the plugin was disabled
- Apr - 39 exploitable bugs fixed (7u21)
- Apr - Oracle say they are prioritizing security
- Apr - More exploits found for the latest fixed version (7u21)
What we see here is primarily Java applets (and webstart) consistently having security issues over the past year and eventually being disabled and blocked by browsers (and various antivirus software).
Oracle has recently begun to put more effort into patching these bugs but there are a couple of issues with this. Firstly either Oracle isn't doing a great job on this or its just plain very hard for them to get it secure - even with the latest update in April it wasn't long before more exploits were found - and secondly at this point for applets and JWS to be really viable and widespread Oracle doesn't just have to get people to trust them again, now that its been disabled so much over the past year they have to get end users, browser and AV software to actively take the risk of explicitly allowing it again.
This will take a gargantuan effort on Oracles part and so far it just doesn't look like they are up to the job.
A lesser trend that we can maybe pick out though is that not just Applets but Flash, Silverlight and other similar software is undergoing similar treatment - as serious vulnerabilities appear the viability of these are reviewed weighing up their usefulness versus the security risk of having them enabled. Each time this happens more users, browsers and AVs disable or avoid the plugins and the technology itself becomes less widespread, therefore less useful and less attractive for developers.
Over time this is a circular trend that feeds itself:
- Security exploit, users weigh up how necessary the plugin is, some disable it
- Developers weigh up how widespread and accepted the plugin is, some avoid it
- Plugin is now less widespread and used in fewer services online, meaning that on the next security exploit the scales will be tipped further towards more users disabling it
But some sites need access to your local filesystem and need a greater degree of freedom to run on your computer. What are they to do? We believe that these sites will ultimately have to transition to full downloadable apps that are closely tied to the online service.
Fundamentally the idea that web content loaded in your browser should have access to your computer and be able to run as arbitrary code with the level of access of any normal app is going away. Mechanisms for restricting even full downloaded applications are coming into force such as Apple's Gatekeeper allowing only signed apps to run by default and Windows 8's SmartScreen enforcing similar restrictions.
This is the way we think things are going and we've tried to make JWrapper cater for this really well. Signing isn't an optional nicety any more, its a requirement so JWrapper supports signing your apps as a fundamental, cross platform and simple part of your build. Applets, JWS and similar technologies conferred a host of important benefits to app developers:
- Cross platform
- No need to worry about proxy detection
- Can be parameterised for the individual web session or page they were launched from
In a standard desktop app these are very hard things to replicate but JWrapper does replicate all of them:
- Java has always been cross platform but the deployment of a Java app has not. JWrapper makes both the build and the deployable app cross platform. It also makes it trivial to embed the app into a website, just like Flash or Applets.
- JWrapper detects a valid proxy based on the end user OS preferred mechanisms, then sets it up for the app so the developer simply doesn't have to worry about it - just like with Applets or Flash.
- Finally, parameterisation has always been a big roadblock for downloaded desktop apps. If you sign your app then it can't be modified which means the only place you can put parameters is in the app name. This though is very restrictive, nobody wants to see an app with a name thousands of characters long! The only option for passing a lot of parameters to the app is to store them on the server and have the app request them based on a key passed in in the app name. However, by implementing signing inside JWrapper rather than pointing the dev to a 3rd party, we can embed parameters into the downloaded app itself. So your server side code has the opportunity to (easily) customise each download for each user and provide them with a desktop app that is set up to provide them with an experience specific to them. This is the final important link that makes the downloaded app an extension of the web page (which is fully accepted by the OS, Browser and AV software) rather than a separate, disjointed app where the user has to first download the app, then manually link it back to their session in the website somehow.