Re: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

On Thu, Feb 23, 2012 at 3:59 PM, Mark Watson <watsonm@netflix.com> wrote:
> Tad,

Tab, but that's not a big deal.  ^_^


> To address your last point first: There is clearly a choice to be made as to
> whether the web platform should support commercial video services any time
> soon, or should wait for the DRM-free future you imagine below to arrive.
>
> This will be a long wait. During this time many millions of $$ of
> engineering effort will be invested in providing commercial video services
> on other platforms: effort which could have gone towards making the web
> platform better in many different ways. These costs are also 'unnecessary
> costs on legitimate users', because investment is fragmented, duplicated,
> instead of targeting a single common platform. And the sums involved far
> exceed the sums involved in supporting DRM.

Commercial video can be done right now. People make livings off of
Youtube, for an extreme example, doing short films.  There are
increasing numbers of examples of long-form video making good money
when distributed without DRM, such as Louis CK's most recent comedy
tour video.

If you want to assert that commercial video requires DRM, please
clarify why your argument doesn't apply to photographs, music, or
books.

Keeping DRM-laden video expensive and fragmented is a positive goal,
as it makes it harder for people to achieve bad results.  This is
similar to, say, not adding APIs to <canvas> that make it easy to make
text editors, because text editors in <canvas> are a bad thing for the
web.  There's a cheap, unified, simple solution available for
publishers if they give up the DRM requirement (just use <video>).


> DRM doesn't primarily derive the security it offers from being closed
> source: you could publish the code for most if not all DRM systems without
> making them easy to crack. I'm not saying that it's possible to have an open
> source DRM that can just be downloaded and installed on arbitrary platforms.
> Or that there are not IPR issues. But they are not based on security through
> obscurity.

Of course, DRM is based on encryption, and all good encryption is
open-sourced.  But it requires the consumer's software to have the
decryption key without giving the consumer the key.  This is obviously
impossible in open-source software.

One can link into closed-source software that *can* implement that, of
course.  We then run into more philosophical objections.  I can't
speak for Mozilla (not even Moz engineers can), but I believe many of
them, particularly ones that would be responsible for these portions
of the code base, are also philosophically opposed to DRM.


>> This is ignoring the more general concerns with the concept of DRM,
>> namely that it's technically impossible and practically useless,
>
> Of course it's not possible to make it impossible for protected content to
> be copied. Any more than a speed bump makes it impossible to break the speed
> limit. It merely makes it more difficult, uncomfortable, very obviously not
> endorsed by the owner (or the content, or the road).
>
> DRM is probably more effective at it's objective than speed bumps are at
> theirs and noone would call speed bumps "technically impossible" or
> "practically useless".

This is a pretty flawed analogy.  To fix it, you have to assume:

* that speed bumps are specifically put in places where people would
really like to go fast (rather than in places where they usually want
to go slow anyway, like parking lots),
* that your car needed a contract with each speed-bump manufacturer
and was unable to go over the bumps when the manufacturer went out of
business,
* and that each type of speed bump had a "kill switch" that was
difficult to discover, but once found out was trivial to mod your car
to send out, allowing you to ignore those speed bumps entirely and get
to work faster (as long as you pretended to go slow over them when a
cop was in sight).

~TJ

Received on Friday, 24 February 2012 00:43:06 UTC