Exciting times for elearning standards. Lots of discussion about two unrelated events. First, SCORM “cheats” are published and the community rallies to address the issues. Secondly, and coincidentally, the IMS recently withdrew the QTI spec from further work by IMS membership. I’ll follow-up on the IMS QTI issue in a subsequent post (likely linking to more detailed information from others).
What is SCORM Cheatlet?
I coined “cheatlet” as a portmanteau of cheat and bookmarklet (itself a portmanteau of bookmark and applet). A bookmarklet is a browser bookmark that uses the javascript: protocol prefix instead of the typical http: prefix used for web pages. This allows one to create a bookmark that runs JavaScript code in the browser.
I dove into bookmarklets when developing my iPastelet utility for iPhone in the summer of 2008. It immediately occurred to me that this technique could be an interesting way to hack/cheat the SCORM JavaScript API. Thus was born my implementation of the cheatlet. It worked easily and nearly immediately. By clicking a bookmark, I could send a score to an LMS. I tuned it to send a time, a status, and in a sinister turn, close and then nullify the API object handle to prevent any legitimate data from overwriting the hacked score.
Cheatlet Concept goes Public
In late August 2008, with a working demo of this code in hand, I sent it to major players in the SCORM world, including a major ADL contract agency, major LMS vendors, SCORM code suppliers of various types, and tool vendors. Many vendors responded that it was simply an instantiation of a hack to a known issue. One indicated they were well aware of this and raised the issue early on to discourage the AICC from deprecating HACP for the JavaScript API, that vendor was Questionmark (Disclosure, I started work for Questionmark in January 2009).
I seemed to be more concerned than others. In late August, I submitted a paper on the issue to the LETSI SCORM 2.0 Workshop, without disclosing precisely how to implement or code the exploit. The paper, Security Before Features was discussed online and at the Pensacola meeting in October 2008, but little seemed to happen as a result. Work continued on SCORM 2004 4th Edition without any API changes.
Cheatlet Example/Running Code Goes Public
Flash forward to a few weeks ago. Working completely independently, Phillip Hutchison had a similar moment of inspiration and crafts his own SCORM “cheatlet” bookmark. The big difference was this included a working cheat as a link right in the blog post (chealet linked since removed, but code is still available by request to Phillip). Soon this issue received broader attention. Reaction and opinions flew about the internet. Plateau proactively sent a letter to its US government LMS customers about this issue to help calms their fears. Ironically, I think this also drew further attention and discussion.
Defense Approaches, Work-arounds, Opinions
Soon after the example code hit the internet, opinions flew between experts on twitter, email and blogs. I posted a overview of the issues on the Questionmark blog, along with a follow-up post on general defensive strategies, including some specific solutions to support those approaches.
- The Importance of Security and Integrity of Performance Data
- Defense in Depth: Security for SCORM and Beyond
The ADL posted workarounds for some aspects of the vulnerability. Both are more clearly aimed and HTML/JavaScript coders, but that may be exactly who read this blog.
- SCORM Content Vulnerability Workarounds by Jonathan Poltrack
- Securing Your Assessments, Excerpt from Carnegie Mellon Best Practices Guide for the Design and Development of SCORM Assessments (means to make “View source” more challenging)
Some feel quite strongly that SCORM has never been suited for more than the lowest-stakes elearning events. I feel that stakes must always be viewed as a continuum. Furthermore, I believe it is far easier to consider the high stakes end of the spectrum first and back-down as necessary. In any environment, is incredibly difficult to start with little or no security and patch your way up to a secure system.
Others may see it differently. I’m sure there will be plenty of opinions. I’d say my views on this issue tend to align with Phillip Hutchison (whom I’ve never met, but respect) more than Mike Rustici (whom I’ve known & respected for many years). I’ll come back and update this post as they emerge. Other opinions include:
- SCORM security (two kinds of SCORM people), Phillip Hutchison, Pipwerks
- SCORM Security – Some Perspective, Mike Rustici, Rustici Software
