Testing ... Testing ... Java Sucks

By John Butcher 

I tried the other day to look at some of the practice SOL questions and could not because they require Java, which is disabled in all my browsers. 

Java Sucks

Microsoft reports that, as of Q2, 2013, attempted Java exploits were the second most numerous kind detected, following only HTML/Javascript (i.e., other kinds of browser exploits). 

Following a series of discoveries of Java security holes, the Department of Homeland Security in 2013 encouraged users to disable or uninstall Java: 

This and previous Java vulnerabilities have been widely targeted by attackers, and new Java vulnerabilities are likely to be discovered. To defend against this and future Java vulnerabilities, consider disabling Java in web browsers until adequate updates are available. As with any software, unnecessary features should be disabled or removed as appropriate for your environment. 

Security expert Brian Krebs reports that the "huge install base — combined with a hit parade of security bugs and a component that plugs straight into the Web browser — makes Java software a perennial favorite target of malware and malcontents alike." 

 Pearson Is Using Java for the SOL Testing

My experience with the practice questions suggested that VDOE's contractor is using (indeed requiring) this problematic software for the SOL testing. So I did a Freedom of Information Act request for

all public records of the Department or Board that (1) discuss security implications of using Java for the testing, (2) discuss why Pearson has elected to require Virginia's school computers to be exposed to the risks of running Java, and/or (3) discuss alternatives to the use of Java in the testing.

 The response was some 5.6 MB of PDFs. The contents are disheartening. (Shout if you'd like a copy.) 


In February, 2014, following a series of disruptions caused by Java updates, VDOE produced "talking points" that discuss the situation (emphasis supplied): 

Because Java is so widely used in Internet applications, it is often the target of cyber attacks. 

Oracle has been under greater scrutiny (including by the Department of Homeland Security) to increase the security of Java and to eliminate vulnerabilities in the Java software code that could be exploited by hackers. This has resulted in increased number of Java patches and software updates.

* * *

In October and January when Oracle released its security updates, a significant amount of online testing was scheduled to happen statewide – October was the fall writing window and January was the fall non-writing window and the 2nd opportunity writing window. The java update published by Oracle caused the current version of Java that most school divisions had installed to expire. 

With the current version of Java expired, the web browser was able to launch but TestNav could not be started successfully to reach the student login screen. 
The error messages that appeared on the screen for students included text such as: 

• An update to Java must be installed to run TestNav.
• Java is required to run TestNav, please install Java. 
• TestNav cannot launch because the current version of Java is not available. 

* * *

Pearson and DOE fielded calls from school divisions on both dates. Some school divisions started testing late after installing Java, some postponed testing altogether, and a handful of divisions were not affected for various reasons (automatically accepted the Java update, the version of Java installed was not recent enough to be disabled by Oracle, etc). DOE hosted a webinar to explain the situation to school divisions on the afternoon of the October incident. 

 The "talking points" propose "next steps": 

• Pearson must do a "better job" communicating about Java updates; 
•  Pearson must "maximize their involvement with Oracle"; and 
•  School technology staff should be "aware" of Java issues.

What's absent here and throughout the 5.6 MB of DOE documents is any recognition that Pearson's use of Java (and browsers and Adobe Flash and the Internet) opens an attack vector that exposes Virginia's testing program to unnecessary disruption and danger. 

Why Java? 

 Pearson's February 11, 2014 Technical Bulletin poses the question, "Why is browser-based TestNav dependent on Java?" Their non-responsive answer: "TestNav uses the Java plugin within a browser to ensure that the browser runs in secure mode for high-stakes assessments." 

Wikipedia has the real answer: 

Java applications are typically compiled to bytecode (class file) that can run on any Java virtual machine (JVM) regardless of computer architecture. Java is, as of 2014, one of the most popular programming languages in use, particularly for client-server web applications, with a reported 9 million developers. 

That is, Java is hugely popular because it is write-once, use-anywhere. Doubtless, Pearson uses it (and Internet connected machines and browsers and Flash) because that is cheaper and easier than writing stand-alone software. 

 Why Do We Pay for This?  

Last I heard, Pearson was getting about $110 million over three years from VDOE to administer the SOL tests. Do you think that somewhere in the penumbra of all that money they could have spotted a secure testing regime? Do you think that, for that kind of money, somebody at VDOE (where they know about the DHS recommendation!) would have sense enough to demand a secure testing regime? Do you think that pigs can fly? 

Your tax money at "work."