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

On Feb 23, 2012, at 4:42 PM, Tab Atkins Jr. wrote:

> On Thu, Feb 23, 2012 at 3:59 PM, Mark Watson <watsonm@netflix.com> wrote:
>> Tad,
> 
> Tab, but that's not a big deal.  ^_^

Sorry!

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

You made an argument that DRM imposed 'unnecessary costs on legitimate users', and I countered that not providing any kind of content protection in HTML5 also imposes, larger, unnecessary costs - of fragmentation. You now say this is a positive. Either way the users ultimately bear the costs and either you care about those costs - and want to minimize them - or you don't.

And by the way, whether money is spent on content protection mechanisms is independent of whether we choose to adopt a proposal like this in HTML5. Whether money is wasted on fragmentation is not.

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

But that's not a solution, is it, because it doesn't meet their requirements. You're arguing that they should change their requirements. Well, maybe, but you should address that argument to them, not me.

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

I may be splitting hairs, but again the requirement is not that the software be closed-source, but that it be difficult to modify/replace the software without the server-side being aware of this. There are means to make this difficult (some, though not all, involving hardware) that are independent of whether the software you're trying to protect is open or closed source.

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

The analogy is not perfect, but you are taking it too literally below. It was just an illustration of how something does not have to be "perfect" to be effective. You can drive fast over speed bumps if you like - it just hammers your suspension and doesn't make for a comfortable ride. We do not say because of this fact that speed bumps are "impossible and practically useless".

> 
> * 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),

where *some* people would like to go fast, yes. That's exactly where speed bumps can be found. I'm missing your point here.

> * 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,

You don't need a contract with anyone but Netflix to watch Netflix. And if Netflix goes out of business, well, then you do have to stop watching, but I'm not sure you'd expect any different. So I'm missing this point too. 

> * 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 03:59:54 UTC