Requirements for DRM in HTML are confidential • Hacker News Board

Re: Requirements for DRM in HTML are confidential

#101

Post by zobzu » Tue, Jan 14, 2014, 5:26 AM UTC

mcot2 wrote: post #68

rlx0x wrote: post #41

This is all so ridiculous, rtmp for instance is as secure a DRM as its ever gonna get and that never stopped me from downloading a stream. Even things like HDMI/HDCP is broken beyond repair. And all of this should justify damaging the w3c reputation forever, what are they thinking?! This whole concept of DRM is just idiotic, its enough if one guy breaks the DRM and releases it. Why should I even bother booting a prop…

I don't care how it gets done, but if we need this to finally kill off flash than I am for it. This problem is solved technically so let's just get it done. Yes, every DRM will eventually be broken, but at least it satisfies the executives enough, so what's the problem? I don't understand why purists on the email list end up holding up something that will ultimately be a positive thing from a number of perspectives.…

note that, flash playback is still the default at most websites because HTML5 video playback generally sucks. its less efficient and provides a lesser experience in all major browsers.

Eventually this will change, but still.

That and of course, that NO single benefit is worth giving way to DRM. NONE. DRMs are a terrible invention from all points of view.

Re: Requirements for DRM in HTML are confidential

#102

Post by shmerl » Tue, Jan 14, 2014, 5:26 AM UTC

girvo wrote: post #4

Sigh. Look, I'm okay with DRM, as long as it works on all my devices. EME won't, under linux, I guarantee the DRM Vendors won't bother releasing Linux binaries. That annoys me.

No one should be OK with DRM if we want this garbage to be gone. If we are OK with it, how can we expect brain dead publishers to understand that it's not needed ever?

Re: Requirements for DRM in HTML are confidential

#103

Post by zobzu » Tue, Jan 14, 2014, 5:28 AM UTC

duncan_bayne wrote: post #33

wmf wrote: post #30

Earlier quoted context omitted.

There are versions that are public and I doubt the "secret" studio requirements are much different: http://www.microsoft.com/playready/licensing/compliance/ http://www.aacsla.com/license/AACS_Adopter_Agrmt_090605.pdf (see Exhibit E on p. 90) In reality these requirements are not set in stone; they are a business negotiation. The first version of iTMS did not meet the record labels' DRM "requirements", but Jobs convin…

Why do you say that Free Software people aren't willing to negotiate? We are very willing to; it's just that every suggestion we've made has been shot down. I think it's very clear who is unwilling to negotiate here. It's true, though, that there's one point on which we aren't willing to negotiate: any W3C-endorsed standard must be implementable by anyone who chooses, without paying royalties or licensing patents. EM…

TBH I think "free software people" (whatever that means, really..) would have every right to refuse to negotiate and just refuse DRMs.

I don't see any pride is finding a middle ground for the sake of saying "look, we're trying to be helpful!"

But then, that's just me.

Re: Requirements for DRM in HTML are confidential

#104

Post by zobzu » Tue, Jan 14, 2014, 5:29 AM UTC

girvo wrote: post #4

Sigh. Look, I'm okay with DRM, as long as it works on all my devices. EME won't, under linux, I guarantee the DRM Vendors won't bother releasing Linux binaries. That annoys me.

I'm not okay with DRM.

It will never work on all devices. It will never work with all software. That's the nature of DRM. It's made to block playback on non-approved devices/software (and generally is a PITA even with approved stuff).

There is an alternative which works on all devices and with any software. its called "not using DRMs".

Re: Requirements for DRM in HTML are confidential

#105

Post by shmerl » Tue, Jan 14, 2014, 5:30 AM UTC

dreamdu5t wrote: post #63

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

Standardizing DRM is bad because it prolongs its usage and makes it easier to apply. DRM shouldn't be helped in any way. It should be made harder to use for those with bad intentions who wish to proliferate it, not easier.

The problem with avoiding is, that many don't understand why they should vote with their wallets and boycott Netflix, Steam and other similar services which proliferate DRM. Many readily and gladly use them. Either because they don't understand the unethical nature of it, or because they are getting used to the police state mentality, which they accept for the price of getting some service. Unfortunately, the later seems to be the case more and more.

Re: Requirements for DRM in HTML are confidential

#106

Post by zobzu » Tue, Jan 14, 2014, 5:31 AM UTC

girvo wrote: post #24

zanny wrote: post #12

Earlier quoted context omitted.

> I'm okay with DRM It seems really defeatist to say this. You are a consumer. You have the ultimate vote on everything, with your wallet, with the only exceptions really being what you need to survive and whatever your government takes. And I don't think netflix is on par with eating. My problem is I have no idea what to do about the w3c. I'd really like to know what alternative network protocols for document render…

I'll be honest, I can say that I don't mind it as I rarely consume media that we're discussing. If I do, it's one show rented on my Apple TV, and that's it, maybe once every six months.

Well, this very push for DRM on the web is to change exactly that. It's to force you to use DRM-only content.

So - yeah.

Re: Requirements for DRM in HTML are confidential

#107

Post by simonsarris » Tue, Jan 14, 2014, 5:32 AM UTC

I suppose that the title assertion is to be expected. DRM only works if you don't know how it works.

~~~

I'm not sure I see anything wrong with DRM per se (this could be my fever talking), there are probably good uses I'm too dim to think about, but I do think it's unnecessary as part of the HTML specification.

There's no industry or company that has switched to DRM-free content, that I know of, that has failed or suffered because of it:

* Music is largely available DRM-free now, thanks to Amazon's MP3 store (at the least, I'm sure there are others)

* For games, Steam makes it easy to avoid SecuROM Hell

* Despite DRM, all of Netflix's original series House of Cards was available on The Pirate Bay within hours of release. This doesn't seem to hurt Netflix's wish to create more content, or police it more heavy-handedly. (Maybe they would if they could)

For that matter, I think in the modern case every single time a business went DRM free it turned out OK. Isn't that right? In all modern cases, maybe after 2006-ish, DRM-free businesses were accompanied with an easy way to get the content online, and sales did not seem to suffer because at the end of the day piracy can appear (or be) shady and people (rightfully) don't trust shady websites, even The Pirate Bay with all of its popups.

I wish we had better numbers. I would like to see a real analysis on all the reasons people don't pirate and instead buy on Steam. I wish there was a good way to convince media businesses at large.

But I guess this is all water under the bridge, and I'm preaching to the choir.

Re: Requirements for DRM in HTML are confidential

#108

Post by shawnz » Tue, Jan 14, 2014, 5:34 AM UTC

duncan_bayne wrote: post #96

shawnz wrote: post #88

Earlier quoted context omitted.

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 contra…

Why do you assume that EME is strictly for streaming video and audio? Others have documented an interest in extending it to other media types. Also, you're assuming that it is necessary. We don't know, as long as the requirements are secret. Finally, there's no reason that, in order for work on EME to proceed, the W3C has to compromise itself or the Open Web. It'll happen regardless of the W3C.

> Others have documented an interest in extending it to other media types.

Sorry, I guess "strictly" was the wrong word. Rather, it is designed particularly for the streaming video use case.

> We don't know, as long as the requirements are secret.

True. But I think a pretty good idea can be had just by looking at the current state of the industry.

> It'll happen regardless of the W3C.

Exactly. Having the W3C head the initiative is the best thing that could happen to it, short of it not existing (which as you say is impossible). Not compromising on ideals is nice, but not when it stands in the way of what is best for the user (or in this case, least bad).

Re: Requirements for DRM in HTML are confidential

#109

Post by gbhn » Tue, Jan 14, 2014, 5:35 AM UTC

duncan_bayne wrote: post #11

code_duck wrote: post #6

Earlier quoted context omitted.

They're going to have to create ways to play their media on Linux, with the growing popularity of the OS for appliances such as living room video players and products like the Steam Machine.

Playing on Linux is not the issue. The issue is that EME + CDM introduces an 'Open Web' standard that cannot in fact be implemented by anyone who chooses. Say the W3C decided to add a new tag to HTML, called ' ', that displays a smiling face. Anyone who wishes (Firefox, Mozilla, you, me) could implement that feature and start properly displaying content that contains tags. This is not true of encrypted content that r…

How about the embed tag? What big differences do you see between implementing EME vs the embed tag?

Re: Requirements for DRM in HTML are confidential

#110

Post by shmerl » Tue, Jan 14, 2014, 5:42 AM UTC

duncan_bayne wrote: post #87

higherpurpose wrote: post #78

Earlier quoted context omitted.

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.

Any standard makes it less messy and gives them more excuses to continue pushing it instead of admitting that it should be dropped. It's absurd to promote standards for unethical practices.