skip to main page content CETIS: Click here to return to the homepage
the centre for educational technology interoperability standards

skip over the long navigation bar
Home
News
Features
Events
Forums
Reference
Briefings
Press centre

Inside Cetis
what is Cetis?
Contact us
Cetis staff
Jobs at CETIS


 




Syndication
XML: Click here to get the news as an RSS XML file XML: Click here to get the news as an Atom XML file iCAL: Click here to get the events as an iCalendar file

Background
what are learning technology standards?
who's involved?
who's doing what?

CETIS Groups
what are cetis groups?
what difference can they make?
Assessment SIG
Educational Content SIG
Enterprise SIG
Metadata SIG
Life Long Learning Group
Portfolio SIG
Accessibility Group
Pedagogy Forum
Developer's forum

Subjects
Accessibility (310)
Assessment (74)
Content (283)
Metadata (195)
Pedagogy (34)
Profile (138)
Tools (197)
For Developers (569)
For Educators (344)
For Managers (339)
For Members (584)
SCORM (118)
AICC (18)
CEN (34)
DCMI (36)
EML (47)
IEEE (79)
IMS (302)
ISO (21)
OAI (24)
OKI (20)
PROMETEUS (12)
W3C (37)

print this article (opens in new window) view printer-friendly version (opens in new window)

A feature or a bug; SCORM and cross domain scripting

People trying to deploy SCORM across several sites have been agonising over the problems associated with playing SCORM content from one domain in a VLE in another domain. We asked SCORM luminaries Dan Rehak, Claude Ostyn, Wayne Hodgins and Schawn Thropp about their views on the nature of the problem, what sorts of solutions might work and what SCORM's makers -ADL- intend to do about it.

An issue more useally discussed in internet security circles has been affecting SCORM deployment in distributed environments for some time now: cross domain scripting, or the ability to control a web page from one site with code from another site. As a rule, you wouldn't want that to be possible, because it makes it very easy to surreptitiously do all sorts of nasty things to unsuspecting surfers- as some well known exploits on, for example, hotmail have already demonstrated.

For that reason, any half-decent browser such as Mozilla 1.x, Netscape 7 or Internet Explorer 6 will either ask permission or else simply not allow code from one internet domain to control content from another internet domain. The underlying idea is that the best way to make sure that no crackers are able manipulate content from a trusted site, is to look at the domains encoded in the URLs. So javascript code from www.hisdodgysite.net can manipulate another page from www.hisdodgysite.net, but not a page from my www.mytrustedsite.com.

Great stuff, but what does all that have to do with elearning standards?

As, among others, Jeffrey C. Engelbrecht in an article in the E-Learning Developers Journal made clear, the browser block on cross-domain scripting also prevents you from playing SCORM content from one domain on a VLE in another domain. The first thing a SCO does when it gets played is to execute a bit of JavaScript code from within itself that looks for another bit of JavaScript code --the API-- that is put out to the user's browser by the VLE. Once found, the SCO will happily allow itself to be manipulated by that VLE, via the API.

Not a problem when both content and VLE come to the user from the same, trusted domain. But when they come from different domains, a browser can't tell that both domains are trusted- it can only tell that the domains are different, and therefore block the communication, and scupper interoperability between systems.

There's a number of reasons why you would want to have content in one place, and a VLE in another. Ironically, in the situation Engelbrecht was describing it was partically to facilitate re-use of content, partially to comply with US Department of Defence network security policy. This states that certain active content types can't come to a user's browser from beyond a network's firewall. So it's hosted locally, even though the VLE that plays it is somewhere else entirely.

This does have wider implications; quite a few organisations will have set-ups where content is obtained from a variety of content management systems spread across the 'net. Sometimes because of network capacity issues, sometimes because the providers want to only serve their content from their own machines.

So, with a considerable amount of SCORM people busy standardising the crucial parts of SCORM at the IEEE LTSC quarterly meeting in Chicago, we asked what their thoughts were on the issue and what was being done about it.

According to Schawn Thropp, ADL considers the whole problem endemic to any browser-based content delivery system on the web, not just SCORM. Rehak and Ostyn concur, and Hodgins even considers the block on cross-domain scripting a (security) feature, not a bug.

Which is all very well in theory, but it still is a serious problem for larger institutions who try to deploy SCORM.

For that reason, ADL is busy compiling a white paper that lists all known solutions to the cross-domain scripting problem, with some pros and cons of each. Since the requirements of different SCORM deploying institutions are different, it is unlikely that one solution will fit all, hence the variety. Also, to ensure that hese solutions actually work, they are being gathered from SCORM vendors themselves.

The solutions have been solicited since plugfest 7 in December last year, and, according to Thropp, "We definitely plan on producing this paper along with the final version of the SCORM 1.3 but we are working hard to get this done before then. It really depends on the amount of support and solutions provided by the ADL Community." The document will be freely available from ADL.

As to possible solutions that the SCORM people themselves are thinking of, Dan Rehak had no specific preference, but warned against some solutions that solve the interoperability bug essentially by breaking the security feature. An example of this would be reverting to the older, AICC derived, http-based HACP protocol. This protocol relies entirely on encoding content-to-VLE communication in the URL rather than a JavaScript API, and is therefore wide open to interception and manipulation.

One other solution that has been doing the rounds on the web is also out: VLE vendor Centra had a solution that involved tweaking some JavaScript calls. Unfortunately, this relied on what was essentially a backdoor in Internet Explorer 6, which was closed, the re-opened, then closed again in the usual welter of Microsoft patches.

Of the solutions that might work, Claude Ostyn thought that the best approach probably involves tweaking the network infrastructure of a particular organisation. For example, rewriting rules (as opposed to redirection rules) might be worth exploring. This is a fairly regular feature on, for example, the widely-used Apache webserver that rewrites a request on a specific URL into a different URL. Simplified greatly, it means that all URLs handled by the user's browser look as if they come from one domain, even if the content on the back end actually comes from a different one. A proven public recipe for this is not yet available.

So while people are trying their hacks, and hopefully submitting them to ADL, it is worth reflecting on ADL's assertion that the cross-domain scripting problem "It is not a problem created by, or as a result of SCORM per se, but the delivery environment [the web] we presently live in."

This is not entirely true; there are architectures conceivable that do not involve either JavaScript or plain URL encoding for communication. By relying on properly encypted webservices, for example. Problem with those is that it would almost certainly break backward compatibility with existing content and delivery systems, and make much more specific demands on the platform capabilities of compliant VLEs. All of which is exactly what SCORM was designed to avoid.

Related items:

Comments:

copyright cetis.ac.uk
Creative Commons License This work is licensed under a Creative Commons License.

syndication |publisher's statement |contact us |privacy policy

 go to start of page content