title: HTTP live streaming with encryption
body: <p>I am trying to understand how the HTTP Live Streaming protocol that Apple supports on their iOS devices as well as on Safari protects the key that unlocks the content.</p>
  
  <p>The way I understand it, the .m3u8 file holds the whole thing together and references the content (in MPEG2 TS container, AES 128 encrypted) and the key to the TS file. </p>
  
  <p>Like in this example:</p>
  
  <pre><code>   #EXTM3U
     #EXT-X-MEDIA-SEQUENCE:7794
     #EXT-X-TARGETDURATION:15
  
     #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=52"
  
     #EXTINF:15,
     http://media.example.com/fileSequence52-1.ts
     #EXTINF:15,
     http://media.example.com/fileSequence52-2.ts
     #EXTINF:15,
     http://media.example.com/fileSequence52-3.ts
  
     #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=53"
  
     #EXTINF:15,
     http://media.example.com/fileSequence53-1.ts
  </code></pre>
  
  <p>Assuming a browser based playback where the <code>&lt;video&gt;</code> element is fed a m3u8 file in the "src" attribute. In this case, even if the key is delivered via https, how can I make sure that the user does not simply enter the https URL in his browser and saves the key to his hard drive? The way I understand the mechanism, the key download is done by the <code>&lt;video&gt;</code> tag as it plays the m3u8 source using the browser's https stack -- how is the legitimate client inside the browser distinguished from the user just typing it into the address bar? This must be really obvious, but I just don't see it...</p>
  
  <p>All the best,</p>
  
  <p>dansch</p>