[foms] Proceedings to FOMS

[Ralph Giles]

On 11 October 2010 01:16, Jeroen Wijering <jeroen at longtailvideo.com> wrote:

> 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.

 -r