fsuk-manchester
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fsuk-manchester] DRM proposed for HTML5 with BBC support


From: Chris Warburton
Subject: Re: [Fsuk-manchester] DRM proposed for HTML5 with BBC support
Date: Mon, 18 Mar 2013 10:32:31 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

Robert Burrell Donkin <address@hidden> writes:
> I think there's a strong argument for a more nuanced approach...
>
> In general, free implementations of a future encrypted media standard
> may bring some potentially useful privacy applications - think, for
> example, of being able to carry a key and a browser on a USB drive
> that would allow you to safely unlock encrypted streaming content of
> your kids or your friends from any computer whilst you're travelling
> the world. Historically, closed cryptography has a very poor track
> record. So an open, fully analysed protocol is likely to be more
> credible and secure than proprietary alternatives.
>
> So IMO the problem isn't a standard for encrypted media extensions but
> that this one seems entangled with the toxic politics of DRM and the
> unjust laws passed around it. For me, the key question is whether the
> standard is going to be capable of implementation as free software
> without the threat of legal action against developers, distributors or
> users.
>
> Robert

The problem is, the proposed standard doesn't actually specify any
encryption system, it only specifies how such systems can be
incorporated into Web documents.

It is similar to how HTML specifies "img" elements, but doesn't specify
any image format. This lead to widespread use of the patent-encumbered
GIF and lots of patent-trolling.

More recently, it is also similar to how HTML specifies "video" and
"audio" elements, but doesn't specify formats. This lead to a battle
between Theora and (patent-encumbered) H.264 and the emergence of
WebM. On the audio front, Internet Explorer still only supports
(patent-encumbered) MP3[1].

As explained in [2], the proposed standard simply allows DRM "plugins"
to be specified. I have absolutely no doubt that there will be a
proliferation of incompatible proprietary plugins. Perhaps there will be
a couple of Free Software ones too; one as a hobby project that is
quickly abandoned[3], one as a marketing scheme for an otherwise failed
product[4].

Also, DRM is obfuscation rather than encryption. The point of encryption
is for Alice to communicate with Bob without Chuck understanding the
messages. With obfuscation, Bob and Chuck are the same person; Alice
wants to restrict what Bob can do with the messages.

For example, if I want to send you a video without someone else being
able to use it, I could use a standard format like WebM and encrypt the
contents using a shared secret. If I want to send you a video without
*you* being able to use it, for example so it is 'only playable' and not
copyable, I could use a nonsense format, along with a program for a
virtual machine which will play it[5], but you will have to
reverse-engineer the program in order to do anything else.

I say 'only playable' because, of course, you could always film the
output[6].

[1] http://www.w3schools.com/html/html5_audio.asp
[2] http://manu.sporny.org/2013/drm-in-html5/
[3] http://sourceforge.net/directory/?q=drm
[4] http://en.wikipedia.org/wiki/Project_DReaM
[5] http://en.wikipedia.org/wiki/BD%2B
[6] http://en.wikipedia.org/wiki/Analog_hole

Cheers,
Chris



reply via email to

[Prev in Thread] Current Thread [Next in Thread]