Going back to HACP? I think not. Not secure.
Posted on November 09 2004 by Claude Ostyn
in reponse to A feature or a bug; SCORM and cross domain scripting
A number of people have suggested solving this problem by going back to AICC "HACP" instead of the SCORM API. That is ignoring the security issues with that approach, unless you are willing to give up significant functionality.
If you want to use HACP to *get* data from the LMS when the content is served by a different server, then you only have those choices:
(c) Use an ActiveX object. Works the same as a Java Applet, must be signed in any case, grave sandbox issues.
The bottom line is that in order to use HACP for two way communication (get data as well as set) you have to compromise security at the browser level by making the user accept a signed applet from the content server.
There is another HACP security issue, which is that it exposes the LMS server to Cross-Site Posting exploits, one of the oldest Web security issues; it is possible to lock the server down, for example by securing the server to accept postings only from applets served by known remote content servers, but that may be difficult to maintain.
No, the real solution is not in cheating security at the client or browser level. If cross domain communication takes place, it should be in a managed, logged, auditable way, i.e. on the server side. In the meantime, Click2learn does ship a proprietary signed applet solution that works with any SCORM content when that content must be run from another server; something like that may be the only solution if, like many implementers of elearning, you have no control over the network infrastructure.
Replies to this post: