[foms] Proceedings to FOMS

[Jeroen Wijering]

>> Does anybody know more about the implications of option 2a - and Apple's implementation of it? Is having AES encryption built-in useful, or will there simply be tools that automatically fetch the keys and decrypt on-the-fly?
> 
> I don't know anything about what they're actually doing, but I did
> read the draft specification. They've carefully separated key
> retrieval from both the media and the m3u playlist/manifest, so that
> can be handled by a separate server, presumedly we some kind of
> authentication scheme. If it's just the key that's signed,
> authenticated, etc. that might reduce the load on the 'smart' parts of
> the server infrastructure since it's only a very small amount of data
> that has to be checked/encrypted on the fly.
> 
> Encrypting the blocks provides additional obfuscation for download
> sniffers, but so does using https. I guess you can use the same key
> for everyone, instead of negotiating separate keys for each connection
> like https does, so it's a cheaper way to add that hurdle and you can
> put the blocks pre-encrypted on your cdn, Apple's scheme also allows
> one to change the keys mid-stream, for whatever that's worth.
> 
> On the other hand, Apple's scheme does not work with the byte-range
> based seeking or virtual chunking, because the cipher has to run from
> the beginning of the resource; that's a major disadvantage.
> 
> I also agree that using access-limited urls for the media itself (your
> '2a' scheme) is the best approach to controlling how your media is
> accessed. The '2b' scheme trades some of that control for cheaper
> server-side automation, i guess.

Thanks, that's a great overview. So overall, signed URLs and HTTPS already get people pretty far.

What happens with the "rightclick save as" of a video in browsers? Is that a separate request to the server, or are the videos pulled from cache? And is it still possible to browse your local cache and copy over files with certain browsers?

Kind regards,

Jeroen