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.
Great stuff, but what does all that have to do with elearning standards?
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.
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."