We are duty-bound to protect our edu- cators’ intellectual property and, even more importantly, to protect the privacy of our students, who may be required to produce videos as a graded activity in their course-work. Video can be an intensely personal form
of expression and a powerful weapon in the
hands of a technologically savvy school bully.
Responsible stewardship of a video-hosting service used for educational media requires state-of-the-art countermeasures against piracy.
Maintaining content security means simply
keeping the toothpaste in the tube: You limit
access to a piece of media to just those people
who are authorized to view it and to just when
they’re authorized to view it. The traditional defensive strategy relies on three features of prevention. First, keep anyone from seeing the content by password protecting access to a page
containing a piece of media. Beyond that first
line of defense, the next task is to keep people
who do have access from sharing it with others. Third, prevent the more common act of
downloading the video so it can be re-hosted
on an unprotected service.
Pre-HTML5, we offered these protections by
means of end-to-end proprietary technology,
typically a real-time messaging protocol (RTMP)
media server and a custom-compiled video player running in a Flash Player browser plug-in. All
of this was opaque to standard browser-based
debugging tools, and idiosyncrasies built into
any given RTMP host and player setup protected
it against general-purpose RTMP ripping tools.
The most likely way that the content would be
compromised is by the old-fashioned technique:
recording the screen with a video camera.
The situation is different in a standards-based
HTML5 world where content owners are largely at the mercy of whatever standards browser
venders and device manufacturers implement.
All client-side code that handles video play-
back is no longer compiled and is, at best, ob-
tended to be straightforwardly translated from
binary bytecode to source. There are current-
ly two streaming protocols competing for wide
adoption for delivering media to HTML5 video
elements: Apple’s HLS and MPEG-DASH. Both
operate by a sequence of discrete HTTP re-
quests responding with downloaded video frag-
ments. These protocols are designed for de-
ployment efficiencies at the scale of CDNs, not
for the needs of small educational media hosts.
Based on vanilla HTTP, these content delivery
methods are easily inspected and spoofed with
standard browser debugging tools. Since these
delivery protocols are “standards-based” by defi-
nition, there’s little room to carve out idiosyn-
cratic protection-by-obfuscation schemes to pro-
tect your small-potatoes host from the standard
HTTP Live Streaming (HLS)-ripping tools built to
attack the big players. In other words, if you’re
doing what everyone else is doing, then you can’t
make yourself a nuisance to those who would at-
tack those you’re imitating. Absent investment
in a DRM scheme for your school, that’s the best
we can hope for, and truthfully, what we’ve re-
lied on all along—that we can outlast the attack-
ers’ patience and keep the targets moving.
To that end, an appealing strategy is to eschew
the dominant HTTP media delivery protocols in
favor of a cross-browser, bidirectional, streaming transport mechanism, namely encrypted
websockets. We know that websockets can support the scale needed for educational media delivery, because we saw RTMP hold up well at our
predictable scales. There are at least two commercial media server platforms already offering media streaming over websockets to Media-Source objects: EvoStream and Unreal Media.
Neither promote the technology for improved
content security; they say it’s for RTMP-quality
startup latency. But using a persistent, bidirectional connection also restores RTMP’s benefits
of better QoS, faster seek-times, and opportunities to add idiosyncratic security challenges
for maintaining the connection.
Protecting Content in
a Standards-Based World
Liam Moran ( email@example.com) produces curricular digital
media and manages the servers to store, process, and deliver
it at the Center for Innovation in Teaching and Learning at the
University of Illinois–Urbana-Champaign.
Comments? Email us at firstname.lastname@example.org, or check
the masthead for other ways to contact us.