Skip to content
September 7, 2010 / ftth

Can HTML5 videos be protected against downloading ?

Downloading: the HTML5 Taboo

Never wondered why there is no easy “download” link or button on HTML5-experimenting video platforms ? Downloading content may well be the taboo part of the HTML5 crusade (yes, google dares it for the sake of ubiquity on devices — but not on featured videos — and Vimeo requires an account) and possibly it’s weakest point against Flash streaming from the broadcast industry’s point of view.

I remember seeing a “download video” button when right clicking video players on early Firefox releases proof of concepts, but this kind of convenience subrepticely disappeared when big players started doing real life HTML5 deployments — especially mp4/h264 ones.

Video Downloading Uses

Common cases :

  • piracy
  • offline use
  • browser performance limitations (the initial reason of this post)

I recently tried watching a video on vimeo, but my computer is too slow to render h264 with Flash (damn Linux binary uses OpenGL but can’t even do hw colorspace conversion … or, on the other side of the mirror,, could it be because of the Linux Video Acceleration APIs ?), and it was also too slow to play it using google chrome’s integrated HTML5 codecs (or Firefox’s).

On one hand, i could’nt find an obvious download link or right-click option, on another one this short movie would have looked so much better in all it’s HD-ness inside mplayer (and at 30 fps)…

With HTML5 and it’s <video> tag coming, one could expect downloading videos do get easier, or security strategies to emerge in the faster-moving (now that’s going http-centric) CDN field. Let’s take a look at major video websites which offer HTML5 deployments and still manage to attract high quality content providers by implementing downloading prevention strategies. Downloading videos can’t be this simple, can it ? Short answear could be, sometimes.

Mp4/h264 desktop playback


HTML5’s all about the source, right luke ? Let’s check it out, there should be an obvious http link pointing to an mp4 or webm (or ogg?) file.

Well, you’ll only find an empty <video> tag:

<div id=”vimeo_clip_14654242″ style=”height:312px;width:560px”>
<video width=”0″ height=”0″ src=””></video>

No link, no fancy mp4 extension. Just sadness (and hiccups, and low framerate). There might well be javascript voodoo behind this.

However, let’s rejoice, there are useful tools built right into google chrome’s core which hopefully can help. The resource tracker (right click -> inspect element -> resources tab) is a small wonder, because it shows you http requests with loading time and file size of elements.

Thanks to the nature of html, http GETs are everywhere, especially when there’s downloading involved (although it might be possible to send video over HTML5 websocketsimage transfer example).

Enabling resource tracking, then hitting play will let us find the redirecting url call which will let the embedded (and hungry) video player access the right file:

It seems not to be the only method experimented by Vimeo, since other (older) pages will show you a large url whose resource tracking shows a continuously growing size item over time (in fact an mp4 file):

Even if the url suggests some form of referrer-based tracking, you can still download this using wget or curl.


After activating experimental HTML5 support, some of Youtube’s featured (== protected) videos are available with an HTML5 player, and you will find a more scary “videoplayback” request, which ends up in a 403 Forbidden http error (when trying it on the command line using e.g. wget) quickly after the browser starts downloading. You can even find the Flash player’s file download request (and it’s exactly the same type) on a regular non-HTML5 page using chrome’s resource tracker.,expire,ip,ipbits,itag,ratebypass,oc:U0dXSFhOUF9FSkNNN19QSFRB&fexp=90521-2,902905&itag=18&ipbits=0&sver=3&ratebypass=yes&expire=1283832000&key=yt1&signature=639F-8ABDFAD2C18EC8780A89C3887311A3748842-.4017464C6937B8C843C9EB866DA6C26F46021E86&id=517739d2107d2a5c

There is an epoch format timestamp in the ‘expire’ variable, an associated (unique?) signature, and the url design clearly suggests that per-ip limiting could be implemented in a close future. In short, this makes it much harder to save it out of the browser, and it looks like it’s only the beginning. Youtube is investing heavily on this field.

The loner Ogg/Theora example: Dailymotion

Chrome clearly not being big fans of Ogg, since Dailymotion still uses ogg/theora/vorbis, native playback requires using another browser such as Firefox ; you’ll find the media URL in the source code of their openvideodemo webpage. [edit : now this page has been replaced by a shining h264-powered html5 support]×240/video/x99gp5_transformers640_creation.ogg?auth=1283987647-58790b5e8607a7464ed6bd47d6cc7b63

There seems to be some kind of authentication involved, although it did not restrict me from downloading the file using wget even after waiting a few minutes and several transfer completions.

Corporate video: HTML5 means mobile devices ?


From their HTML5 demo page source code,

Well, unsecured like, … unsecured. Looks like the only real-life deployments of Brightcove html5 video are inside iPhone/iPad apps. I could not find any brighcove HTML5-enabled (desktop-oriented) websites. Coincidence ?


Ooyala’s home page show the player getter URL:;callback=onPlayerLoad&amp;width=432&amp;height=242&amp;-embedCode=5tZjhoMToQ_42jg_5j_ES7AqaAZXQTQ4

It’s response contents shows the mobile player getter URL:

… which contains the iphone playlist url:

… itself containing the list of of playlist qualities, themself leading to the .ts fragments urls:

This was downloadable without even without faking the user agent to the iPhone/iPad Safaris’ at any step. There seems to be some expiration timestamp, but it did not restrict the download after some minutes.

However, their blog clearly claims nothing different:

“Promotional Content: The HTML5 video tag doesn’t have DRM (Microsoft Play Ready or Flash Token-based Authentication), so even if you have an encrypted m3u8, any user who downloads the video will have an unencrypted version of it on their hard drive. This is why we think HTML5 should be used only for promotional content where content protection is not a requirement.”

So, can it be secure even without encryption ?

Offering no encryption (yet?), none of these strategies could resist Wireshark (that’s what the follow tcp stream feature can do) or other network sniffers, but some software editors already provide implementations of DRM over http streaming (Apple, Adobe, Microsoft). If the HTML5 standard did specify a standard/open securing scheme, HTML5 video could start being called “secure” but currently available encryption implementations are too vendor -specific to spread into the browsers themselves. Meaning, just regular token and/or expiration-based CDN security can be used until then for HTML5 video. Of course, expiration tokens will only be useful if the webserver properly restricts downloading after their expiration.

On the desktop side, again, Youtube leads the way by exposing real HTML5 technology without sacrificing security too much. Large corporate players prefer not to get exposed and stick to traditional DRM security (Flash, Silverlight).

In other terms, there’s still time for some mplayer (or any other excellent standalone player) happiness on most others HTML5-capable video websites 🙂



Leave a Comment
  1. Anita / Jul 18 2012 1:34 am

    is there any way to download the videos played with ooyala ?

  2. Russianspi / Mar 27 2013 4:26 am

    Thanks! This was exactly what I needed for liberating some video from Ooyala. I was on the right track (I was spoofing iPhone user agent in Firefox, and planning to watch it while running Wireshark), but only the first video (not the playlist) wanted to run. I dug into the source a bit, but I had neither the time nor the knowhow to go dredging through javascript files looking for the playlist. Once I found it, I just had to modify it a bit and use the list of URLs that it contained to feed to a bulk downloader program. I’m on chunk 12 of 180, but they seem to play just fine. (Each chunk is 1.8ish mb.) I don’t think I’d have ever gotten this done without your help. Thanks again! (Even if this isn’t exactly what you intended to do with this blog post.)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: