Live data from Hacker News

Requirements for DRM in HTML are confidential

lists.w3.org

81–90 of 424 posts

Re: Requirements for DRM in HTML are confidential

#81

Can't we just fork the w3? Start using Firefox and forget about these people. Oh I'm sorry your browser is a little slower, but at least it's not Google made.

If you can get people to stop using Chrome, Safari, and IE en masse over this issue that might have the effect you describe. Anything else won't, because the problem here is not the W3C per se but that those three browsers are very happily implementing this stuff (already shipping it in releases in the case of Chrome on ChromeOS and IE 11) whether the W3C actually specs it or not.

Oddly enough, the people producing those three browsers just happen to all be DRM system vendors (WideVine, FairPlay, and PlayReady). Who would think they're want to build their own DRM systems into their browsers, eh?

Re: Requirements for DRM in HTML are confidential

#82

Earlier quoted context omitted.

(Disclaimer: I haven't read the lists actively in quite a while, and no longer have access to Member-Only lists.) There have been votes about whether this is in-scope of the AC. As you can tell by work continuing, the vote passed. How many abstained (explicitly or by not voting)? I cannot remember, and cannot check. The requirement to merely make it more difficult, but not impossible, has been stated on several occas…

We (EFF) raised a formal objection to whether content protection was in-scope for the new HTML WG charter; our objection was overruled by the Director, but there was no vote of the AC.

Hmmm. I think a vote would be a good start, but as an interested third party I don't think I have any way of encouraging that short of advocacy.

Re: Requirements for DRM in HTML are confidential

#83
post #38

Earlier quoted context omitted.

Free software people aren't willing to negotiate about the right to read and modify code but non-modifiable code is the only way that DRM can work.

Even leaving that issue[1] aside, if the W3C were to endorse EME, then for the first time in its history the Open Web would not be implementable by anyone who chose to do so. That is the real problem here, not incompatibility with any particular software license. [1] which is pretty much the reason for the existence of the FOSS movement, so I'm sure you'll understand the inflexibility there :)

What do you mean by "Open Web"? AFAICT the term "Open Web Platform" is only 3 years old, and before that "open web" (not capitalized) just meant all the freely implementable standards, which makes your first sentence circular.

We've had non-free things in the web since GIFs, and flash is currently used for a lot of the things that EME will be used for.

I don't endorse EME on principle, but it is inevitable at this point, whether or not the W3C endorses it.

Re: Requirements for DRM in HTML are confidential

#84

Email the W3C. Tell them what you think of this bullshit (in reasonably polite manners). I've done it. I've gotten a non-canned response. But clearly they need more people at the gates bitching. This needs to be stopped.

To their credit, the W3C are handling the level of interest in this very well indeed. Especially as many (myself included) have only passing familiarity with W3C process & protocol.

But yeah, the more voices making clear, well-reasoned objections to this, the better. Especially if that might actually result in it going to a vote.

Re: Requirements for DRM in HTML are confidential

#85
post #36
post #5

Earlier quoted context omitted.

It will work under Google Chrome (not Chromium) on Linux most likely, as Google is a DRM vendor.

AFAIK ChromeOS supports Widevine EME and Chrome does not. Why is it enabled on one platform and not the other? Make of that what you will.

Because they haven't got it locked down enough yet, presumably.

Chrome on Android doesn't support it either, yet, but http://code.google.com/p/chromium/issues/detail?id=275989 is targeted for Chrome 32...

Re: Requirements for DRM in HTML are confidential

#86
post #38

Earlier quoted context omitted.

Free software people aren't willing to negotiate about the right to read and modify code but non-modifiable code is the only way that DRM can work.

Can you even name any other class of software that cannot work unless people are somehow forbidden to modify or even read the code? It sounds like this is a problem with DRM, not with the free software movement.

As a class, just about any program that depends on security through obscurity has this trait.

Re: Requirements for DRM in HTML are confidential

#87

What's the problem? Don't support companies that distribute any DRM content. Standardizing DRM and propogating DRM aren't the same thing.

It sure helps propagating it, once you have a standard all the vendors can use.

But all this standardises is the interop between the browser and the non-user-modifiable client component, the CDM.

Re: Requirements for DRM in HTML are confidential

#88
post #40

Earlier quoted context omitted.

> they are ending the open inter-operable web. It sucks. I don't know what web you have been browsing, but as far as I can see, HTML5 is just now starting to replace flash for online video and audio. I am much sooner ready to support EME over flash, if it helps that transition, despite the ridiculous ineffectiveness and inconvenience of DRM.

Why do you suppose that EME + CDMs will be a better solution than Flash? What advantages do you expect?

I see EME as a way of reducing the area which DRM can affect. It is a sanely designed box around an insane (but persistent) concept. Whereas flash applies usage restrictions to the whole environment, EME is strictly for streaming video and audio, and encourages the rest of the system to be developed with open technologies (HTML5 and JS). It is the minimum evil necessary to meet the requirements of the existing contractual obligations that cause DRM to exist.

Re: Requirements for DRM in HTML are confidential

#89
post #60

Earlier quoted context omitted.

There are several technical reasons why EME is superior to the existing solutions; in particular, usability and ease of implementation are two. However that doesn't address the fundamental problem that EME breaks the Open Web.

I could sort of get "ease of implementation" but would trade that on behalf of the implementers to keep their secret bullshit out of standards. Have they got an actual case that says it's easier versus plug-in implementations that would, in real world cases, rely on libraries the content publishers agree to use?

Yes, malware. EME creates a nice standard compatible way for bidirectional communication with arbitrary servers, for native code run with the privileges of the user. ( By now there is at least a security considerations section in their standard... what could possibly go wrong.)
Post reply on HN