[foms] Proceedings to FOMS

[Silvia Pfeiffer]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.annodex.net/cgi-bin/mailman/private/foms/attachments/20101011/a4c1130a/attachment.htm