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

On 3/2/12 3:30 PM, Charles Pritchard wrote:
> On 3/2/2012 12:18 PM, Boris Zbarsky wrote:
>> On 3/2/12 3:11 PM, Mark Watson wrote:
>>> That you can use the service on any device that supports it and not
>>> on others is also obvious (even tautological).
>>
>> Why? It's not obvious to me, and seems broken at first glance. Why
>> shouldn't any device be able to support any service, a priori?
>
> I'd think that would defeat the purpose of trusted computing.

I thought we were talking about personal media consumption here, for the 
most part.

> If a contractor is required to use a particular device; short of reverse
> engineering, the purpose of a trusted service is to require secure and
> accepted device in order to view confidential materials.

Again, we're mostly talking about media consumption by actual consumers.

Aka the "I bought this tablet, why can't I view this video on it?" problem.

> This proposal encourages outfits to use HTML, instead of getting stuck
> in Flash/Silverlight. That's a good thing, isn't it?

If we're going to get all good-vs-bad here... Bit of a rant coming.

The answer to your question is "It depends".  If it just leads to 
getting stuck in some other binary blob with worse licensing terms than 
Flash/Silverlight and worse availability on actual hardware (which might 
take some work, of course, given all the places Flash is not nowadays), 
we're no better off.  If we get into such a stuck state and it's 
perceived as The Right Thing Because The Standard Says So as opposed to 
damage to route around, we may be worse off.

Just to be clear, I think there's not much inherently good about HTML 
per se.  It and CSS, even with recent changes, are pretty terrible 
languages so far for what many people are using them for (user interface 
layout, books, real-time games, and so on).  Its strengths are that 
anyone can write it, anyone else can consume it, people can build on top 
of it without having to license it or any related technologies and all 
that other "feel-good" open-standards stuff.  Oh, and a large install base.

Keeping the bad part (HTML per se) while throwing out the advantages is 
... not a good thing.  Creating standards which keep to the letter but 
not the spirit of the policies that made HTML what it is now, likewise 
not a good thing.  In my opinion.  This is the same reason some working 
groups in the W3C have felt that focusing on "standardization" for 
walled gardens is not necessarily a good thing.

Now I don't think the proposal in question is _necessarily_ throwing 
away the advantages of HTML while paying lip service to openness and 
interoperability, but I think it could easily end up there even if 
that's not the intent.  Hence the questions trying to pin down exactly 
how all this will work in practice.

-Boris

Received on Friday, 2 March 2012 20:53:50 UTC