Re: Unrestricted publishing in EME? Re: DRM, EDE, CDM, W3C and the TAG:

On 2013-10 -28, at 09:25, Eric J. Bowman wrote:

> Tim Berners-Lee wrote:
>> 
>> Suppose though we could impose constraints on DRM systems
>> which were attached. One of the many criticisms of current DRM systems
>> is that they are controlled by a single bottleneck vendor,
>> in some cases the hardware vendor.
>> The system protects the content of those who distribute
>> through the channel, but the channel is a single one,
>> and so not everyone can play.  Some assume that any
>> EME system must be like that -- but does it have to be? 
>> 
> 
> Why make it easier for this hideous concept to procreate?  Not having a
> DRM framework in HTML at all would hasten the demise of DRM, which
> seems a much more desirable outcome than wasting *any* bits defining a
> framework to perpetuate such nonsense.

Whether it would hasten that demise or a question of forecasting the future
under a lot of uncertainty, and others suggest having the DRM more open 
and more standard would hasten its demise as it would whittle down the
proprietary non-open-source-able bits to a minimum.
We will never be able to know what will happen in advance for sure,
but also we can agitate rather than just sit

>  Any framework (e.g. EME) is
> guaranteed to be at the mercy of the underlying DRM, unless DRM itself
> is somehow re-engineered to be less nefarious -- which contradicts the
> business goals of those who insist on DRM in the first place.

Well, there is the business goal of preventing people copying a
stream of video, and there is a business goal of being the single gateway
bottleneck agency for everything bought/played/installed etc on a given
platform. 

You lump them together.  Suppose we separate them.
We provide a system which meets the first but not the second.
A company which says, "Well, we would have used for EME system
to stop people ripping our products but we won't because also
we want complete stranglehold on the whole device" will 
be making a choice. If it plays that card, that is a strong statement 
both to users and regulators, which they could get a lot of push back against.

Or maybe the tendency will be stronger to release the stranglehold,
and lead to an open market.

> 
>> Can we imagine or design a EME system which instead
>> as usable by anyone as a publisher? Suppose anyone could set up
>> an web serve and serve encrypted content to end users without
>> going through a bottleneck vendor.
>> 
> 
> But, why would I as a publisher want to do that?  It makes no sense to
> me, to limit (if not remove outright) fair use of any content I publish.

The live show business model, for example.
" And it’s never recorded. It’s live and then it’s gone.".
-- http://www.concertwindow.com/open_faq
to pick an arbitrary example.

Not because one wouldn't want fair use, its just that currently no one has AFAIK
designed anything which allows fair use and prevents wholesale copying.

> Having no bottleneck beats the heck out of supposing anything about
> making DRM more user-friendly, which seems to me a boondoggle if ever
> there was one.  The Open Web should require content publishers to adapt
> their business models to the reality of the Web, not cram DRM-in-HTML
> down everyone else's throats.
> 
>> 
>> (Clearly, you might think, this won't work as for a system to be so
>> highly used by both consumers and receivers it would be cracked
>> instantly. But actually DRM is cracked anyway -- you can play
>> anything over an HDMI cable and crack the HDMI cable.[1]  So we are
>> not talking about an uncrackable system anyway. Just one where people
>> will be more inclined to pay for the stream and less inclined to
>> record it.)
>> 
> 
> This makes no sense whatsoever.  Those with the wherewithal to crack
> DRM will do so.  The 99% who don't have the 1337 skillz to record from
> HDMI are the ones who are inconvenienced.

Well, a very small community who can crack it,
a quite small community who will use the crack and put it up some place,
and a community of a certain size who will pick it up from that place.
Then, different jurisdictions will give differing wight to these as offenses,
and the may be pressure to change these weights as Hollywood 
perceives the easiest place to stop this happening.

>  There is no inherent "right"
> to restrict content playback by player or region, nor to restrict the
> user's ability to skip ads and whatnot.  There is an inherent right to
> fair use, and it makes me literally sick to my stomach to imagine HTML
> providing the means to strip my actual rights, in order to grant fantasy
> rights to those producers whose business models are obsolete, who
> should get with the program.

I'm not really a fan of rights being inherent as in self-evident
and inalienable. A right is something we chose to have as a society,
because we decide that we want to live in a world where a a given right exists.
Some rights are enshrined in laws or constitutions or common expectations.

So picking rights, I would prefer to live in a world where,
- I can buy for-pay content from any supplier on any platform equally;
- If I have "bought" something I can watch it in any country any time offline or online
- If I have "bought" something I can archive it 

A solution to the archive problem could be that master keys are just handed
out to DVDs every quarter, so a year after something is released it becomes copyable.
Any other ideas?

> 
> The only users penalized by this approach are the ones who don't pirate
> content to begin with.  The amazing success of the Web was predicated
> on fair use by *everyone*, not just those capable of breaking technical
> barriers.  At least I always thought this was a strength of HTML vs.,
> say, Flash.

Yes.

Even changing default preferences is rare for normal users, they say.

>> Can you imagine a system in which there is some protected code
>> but it is is sandboxed so the open source operating system can talk
>> to it?
>> 
> 
> Yes, Flash.  HTML not having a DRM framework wouldn't prevent those
> content producers with obsolete business models from "protecting" their
> content.  Those who have seen the light are more than welcome to put
> their content on the "Open Web" without DRM, using HTML, allowing fair
> use to potentially make said content viral -- those who cannot imagine
> how to profit from such virality are free to keep tilting at the DRM
> windmill.  You know, like iTunes...  Oh, wait...
> 
>> 
>> In fact, such a system has to be directly the screen anyway.
>> Maybe the EME system should just be the screen.
>> Can you in fact just build an open source system which negotiates
>> directly between a HTMI device and the server? 
>> Maybe this doesn't work -- I am not an expert on this.
>> 
> 
> All I know about DRM handshaking, is it's a proprietary black box which
> will not function with my obsolete 4x3 monitors, and is nigh unto
> impossible to troubleshoot/fix when it doesn't work on consumer devices.
> The best solution for me to play "protected" content on my PC is to
> crack the DRM (infinitely easier than figuring out why my PC won't play
> content on my HDTV or my monitors), but most consumers lack the skills
> to work around faults inherent in the _concept_ of DRM.  Having an HTML
> framework for DRM will only proliferate such problems, for the majority
> of end-users who simply can't get DRM to work reliably.
> 
>> 
>> Can we while we are at it build a DRM system which is sandboxed so it
>> can't call home, or is prevented from reading any data bout me from
>> my system?
>> 
> 
> What bugs me the most about this entire debate, is W3C's insistence
> that declaring DRM "in scope" has nothing to do with building a DRM
> system, and that EME is only an idea.

In scope means it is up for discussion.

>  Then you go and talk about just
> that -- building a DRM system.  

That is talking.  No one is really talking about how if DRM
were linked to HTML it could be required to be better.
People just slam DRM in principle for a load of reasons at once,
missing an opportunity.


> Or, sidestepping the controversy by
> stating that EME isn't a DRM system, only middleware, when the
> arguments against EME are really arguments against the notion of a DRM
> framework in HTML outright.  

I'm not making that argument.

> Which leads me to ask, is it possible to
> engineer a DRM framework for HTML without also engineering the DRM
> mechanism itself?  And is that really "in scope"?

This is the architecture list, where it should surely be in scope to 
ask if you are going to provide some DRM then what would a fairer version?

>> One of the things I am worried about is that once we allow
>> a EME vendor to install their own unreadable code, then that code
>> could report on my media-watching activity, not to mention scrape up
>> other private data and send it back, as many phone apps do now.
>> 
> 
> Or any other number of potential horror stories, like the fact I can't
> read an e-book if I travel out of my home country -- and then have to
> re-download said content on my return.  Keeping such shenanigans out of
> HTML entirely, seems the prudent way forward to me.

Can we require of EME systems that e.g. they don't have access to location
or the network, they just juggle keys?  
Could we require as policy that it the DRM system is not allowed to call home
(for privacy, and offline working) and isn't allowed to discriminate by location?

It is an architectural decision.
Could we specify a DRM system which would be fairer than the underlying platform ones 
we sometimes see.


> Just what is the
> definition of consensus, anyway?  If 99% of the community is opposed to
> the concept of a DRM framework in HTML, does consensus amongst the 1%
> on EME or some other framework trump all opposition to the concept of
> DRM-enabling HTML itself?


Well,  consensus at W3C can be only a part of whatever deployment happens,
involving browser vendors and media channels. etc making their decisions.
W3C can design a way, but can't vote that people implement it even with 
a unanimous working group.  It takes pressure from different sides to get 
these companies to make their decisions.


>> Or can we make a DRM which doesn't have any hardware-protected code,
>> which is open to being abused, and we rely on the fact that 
>> most people don't change their computers much -- under that set of
>> assumption -- which can be used by anyone who wants to stream a video?
>> 
> 
> Again we're talking about engineering DRM, rather than just a framework
> for it.  At what point do we recognize that DRM is simply borked? Yeah,
> I don't change my computer much, but in the past year I've had my Blu-
> Ray drive, one monitor, and a graphics card bite the dust.  Each
> instance has required major effort on my part to restore "protected"
> content.  Which led to frustration with all the black-box crap where
> you can't even decipher the specs enough to figure out why the HDMI
> handshake, etc., has gone kablooey -- and I'm an expert!  So I simply
> installed crack software.  I don't see how a DRM framework in HTML
> would solve such problems?
> 


You are not the average user. 
Yes, there can be massive problems if you have licence keys on a computer
and you lose the drive.   Fine if you have a live up to date relationship with
the supplier, not fine if they are under new management.

There is an ethical argument that once you have paid for something,
you should be able to restore it from "illegal" copies whenever DRM stops
you playing it.

Note none of those problems apply to streamed data.

Maybe DRM will be tolerable by users for streaming, and  for bought content,
manufacturers will live without DRM.


>> Yes, you can argue that if DRM is bad then more [providers using] DRM
>> is worse but on the other hand one of the bad things people associate
>> with DRM is the closed market. Can we break that connection?
>> 
> 
> Yes.  Let DRM die.  

That's not separating them, which is what the mail is about.

> It's a borked solution to a non-problem for all but
> those content providers who insist on using lobbying, legalese, and DRM
> shenanigans in pursuit of denying my right to fair use while arrogating
> unto themselves various rights which don't really exist in the first
> place.  I cannot support granting fantasy rights to producers which
> destory the actual rights of end-users, there is no technical solution
> to this social problem.

"fantasy and actual" -- do you mean rights that are and are not enshrined in law?

> 
> I have the utmost respect for you, Tim, but just how much negative
> feedback is required for you to admit an error?

I put the subject in scope for discussion.  
There is discussion happening.
I'd like to see some attempt to make a fairer DRM system.

And someone to show that if we don't put EME in HTML
the browser makers won't implement a non-standard DRM anyway,
and if the browser makers don't implement a DRM, that the content distributers 
won't just switch off the web platforms onto native apps, making life a pain
for users and developers. 

You have suggested that DRM will just die if not included on the web.
It's possible but it is not obvious. 


> I delayed chiming in
> on this to keep an open mind, based on the fact that *you* were the one
> taking a position diametrically opposed to my gut instinct re: DRM, but
> IMHO you've failed to make the case for it; particularly when your
> position seems to depend on somehow fixing DRM in order to make an HTML
> framework for it palatable

Well, designing a system to have properties which we would like to have
is not crazy.     Let's stop assuming that a DRM system has to be like the ones we have now.
If by "somehow fixing" we end up with a compromise which works for everyone,
even for streaming content, it will make a system much improved 
on the current ones,  we have made a step toward openness in a different direction.

> -- seems a sisyphian task which will become
> obsolete before it's ever completed, when the movie industry follows the
> music industry to an "open" (as in DRM-free) Web experience.


It's possible but it is not obvious. 
You want to take that gamble, that there will in fact not be a non-standrad
closed-platform backlash.


> 
> Please, let content producers move forwards, instead of moving the Web
> backwards to accommodate (some of) their desire to eliminate fair use.

I would not attribute that motivation myself.
I don't imagine that any content provider wants to eliminate fair use.
They just don't know how to stop what they see as unfair use, without 
in the process eliminating fair use.

> 
> -Eric
>

Received on Tuesday, 29 October 2013 15:18:35 UTC