[foms] Proceedings to FOMS

[Jeroen Wijering]

Just a plain copy - linked to from the community goals:

http://www.foms-workshop.org/foms2010OVC/pmwiki.php/Main/SecureVideos

Feel free to update or amend to...

- Jeroen


On Oct 11, 2010, at 11:01 AM, Silvia Pfeiffer wrote:

> Do go ahead - password is "secretFoms" as always.
> 
> I have no idea at all what Apple does for encryption, sorry.
> 
> Cheers,
> Silvia.
> 
> 
> On Mon, Oct 11, 2010 at 7:16 PM, Jeroen Wijering <jeroen at longtailvideo.com> wrote:
> Hey Silvia, all,
> 
> No problem on putting this into the wiki. Do you want to, or shall I?
> 
> I also think we focussed mostly on option 2b - which I believe is a good content security solution.
> 
> 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?
> 
> Kind regards,
> 
> Jeroen
> 
> 
> 
> 
> 
> > On Sun, Oct 10, 2010 at 10:28 PM, Jeroen Wijering <jeroen at longtailvideo.com> wrote:
> > Hey everyone,
> >
> > I have a question on the "DRM" community goal:
> >
> > *) Show a demo of how to use DRM with WebM
> >
> > I think supporting "real" DRM is not required per se. It might be more about offering publishers different ways to protect video content. In the end there's a tradeoff between decent content protection ánd a decent way for users to legidly access the content (cross-platform, fair prices, etc).
> >
> > That said, there seem to be three general mechanisms for content protection:
> >
> > *) URL signing (all CDNs / Flumotion): The URL to a video is signed with an MD5/SHA1 digest that includes geo, ip, time, referrer or user-agent restrictions. Protects good against leeching but not really against downloading. Implementation is easy (small module / script) and solely serverside.
> > *) Data encryption ( Apple HLS / RTMPE): Blocks of video data are encrypted on the server and decrypted inside the client. Protects good against both leeching and downloading. Both serverside and Client-side work is needed though. This can be both in-browser (e.g. by adopting Apple's AES-128 encryption), but it can also be done in javascript: get video data using websockets » decrypt data » use something like videoTag.append(videoData).
> > *) Rights management (PlayReady, FlashAccess): Individual client access to individual files is centrally managed. Protects good against both leeching and downloading; access can even be revoked. Client-side work is needed, probably inside the UA since the JS layer can be easily compromised. Serverside work is needed too, since there's no "open DRM" server available (contradictio in terminis?).
> >
> > Is this a decent overview; are there content protection schemes missing? What is already possible with currently available tools; and what would be interesting to implement?
> >
> >
> > Hi Jeroen,
> >
> > I'm not even sure it's a goal of this community to show how to use DRM-like mechanisms - I just had it in my notes from the discussions and there was talk of it, probably motivated by your company's experiences actually. So, I didn't want to lose sight of it.
> >
> > I think what you have listed is a good summary and I wouldn't mind having that published somewhere - if you don't mind it can go into the FOMS wiki. My impression was that there was a focus on the second mechanism and there on a JavaScript implementation. I would be most keen to see implementations of all three, actually!
> >
> > Cheers,
> > Silvia.
> >
> > _______________________________________________
> > foms mailing list
> > foms at lists.annodex.net
> > http://lists.annodex.net/cgi-bin/mailman/listinfo/foms
> 
> _______________________________________________
> foms mailing list
> foms at lists.annodex.net
> http://lists.annodex.net/cgi-bin/mailman/listinfo/foms
> 
> _______________________________________________
> foms mailing list
> foms at lists.annodex.net
> http://lists.annodex.net/cgi-bin/mailman/listinfo/foms