Live data from Hacker News

Requirements for DRM in HTML are confidential

lists.w3.org

361–370 of 424 posts

Re: Requirements for DRM in HTML are confidential

#361
post #291

Earlier quoted context omitted.

You are NEVER forced to steal things that aren't essential to survival. Starving on the street and steal a loaf a bread, that's one thing. Don't want to participate in many varied ways of listen to music for free legally and so choosing to steal the next big album you want to hear, not ok, ever.

Ok. I agree forced may be a bit of a strong word since i can always choose not to pirate it. However what about books or scientific papers which are hidden behind pay walls or just incredibly expensive. The price of a good programming book is about £20. But when your monthly income is £300 that is a lot of money. Not to mention you have to pay electricity, gas, etc. and the prices for the utilities are not that much…

"The price of a good programming book is about £20. "

If only we had a global computer network by which you could find a much cheaper used copy. Or even a free loaner copy.

Re: Requirements for DRM in HTML are confidential

#362

Earlier quoted context omitted.

Wait, are you implying that the UN has declared that stealing the results of someone's labor is justified because it's a "right"? We might as well declare anarchy and get it over with. I also fail to see how copyright laws are preventing anyone from enjoying their culture.

It's sad times we live in when creating culture is labeled "labor", "work" and so forth... About the "stealing" part - http://www.huffingtonpost.com/2012/02/06/lady-gaga-jack-whit... artists are more than happy to let anyone experience their art, it's the producers that have a problem with it. I guess this is what you get when you allow business-minded people to define what being human is all about...

"It's sad times we live in when creating culture is labeled "labor", "work" and so forth."

It's sad when idle consumers come to believe they are entitled to the product of another's labor for free.

Re: Requirements for DRM in HTML are confidential

#363
post #319

Earlier quoted context omitted.

For example GOG is a successful DRM free distributor - they only accept DRM free games from various publishers. There are others as well (for music, e-books and etc.). It's mostly video industry which lacks DRM-free distribution options (services like this are virtually non existent worldwide: https://www.headweb.com/en/ See their DRM-free terms of purchase: https://www.headweb.com/en/100237/purchase-terms ). Support…

Unless I'm mistaken (I may be) GOG is primarily in the business of selling old games, which is why the publishers are willing to forgo DRM on the titles. Publishers of new games (especially expensively developed new games) are more likely to fear a loss of revenue, especially in the crucial early period after release, without DRM.

GOG sells new games from those who have common sense. As I said elsewhere in this thread, it's mostly innovative, forward thinking self published studios or crowdfunded projects. GOG isn't focused on old games exclusively anymore. They are focused on DRM free games though.

I'm not really sure why bigger size of the budget should reduce the common sense of the publisher. Legacy publishers are obsessed with DRM, but DRM has nothing to do with revenue whatsoever. It doesn't reduce any piracy, and only cripples the experience for legitimate users. It's stupid from common sense business perspective, and there is an increasing amount of big budget games which come out DRM free. I view it as simply mentality issue. Legacy publishers can't understand that they should start being customer focused. New ones have no issues understanding it, therefore they don't use any DRM.

Re: Requirements for DRM in HTML are confidential

#364

Earlier quoted context omitted.

W3C's reputation went out the window in the minds of all serious software developers with the concept of HTML5's "living standard" aka, no standard. This is the kind of standards we can expect from a standards body in the industry. The only solution is to start again from scratch, maybe on top of TCP/IP only.

Standards matter only as much as the implementations adhere to them. Making HTML living standard thas the right thing to do, because only this really reflects the reality: browser vendors implementing differnt bits of the functionality described. Feel free to start from the scrach.

and now they are changing HTML5 to "HTML," the purpose is clear, to sew more confusion into the so called standard and hide the debacle that is w3c.

"this reality reflect the reality"

please... why have a standard at all then. What a joke and perversion of terms. Orwell would be proud.

Re: Requirements for DRM in HTML are confidential

#366
post #159

Earlier quoted context omitted.

i don't follow sony because i don't consume from companies with lock in tactics (betamax, laserdisc, md, memory stick, etc, etc) but thank you for that. it was awesomely entertaining.

So, your current living quarters has hardly any modern entertainment to speak of? Good thing libraries still exist.

I can garantee you i don't miss blueray as i did not miss laser disc.

Also it's much more convenient that my camera and phones use sd cards instead of memory sick..

You're point?

Re: Requirements for DRM in HTML are confidential

#367
post #95

> So, the DRM vendors have solved the problem of creating solutions that meet studio requirements and what we are trying to do with EME is provide a clean API to integrate these solutions with the HTML Media Element. Which reads as: studios have nonsensical requirements, which are implemented and soon broken. And "we" (i.e. W3C) need to oblige this insanity for the sake of . Put your own reason, but I bet it won't be…

I just posted to the list, trying to explain that EME is not a requirement, it is an implementation.

I understand. My point is, it's an implementation of an absurd requirement which simply should be ignored, rather than obliged as in providing an implementation.

Re: Requirements for DRM in HTML are confidential

#368
post #353

Earlier quoted context omitted.

Shipping binary software for Linux is like playing a never-ending game of Space Invaders. GOG's position is totally understandable.

No, it's not. Their position is (at least from their last status update): "we are trying to come up with a long term support methodology, and didn't find one yet". It takes them more than a year to design it. It doesn't sound reasonable to me.

Shipping binaries on Linux is nearly impossible on a long term support basis.

FatELF would of addressed at least some of these problems, but was largely rejected by the larger community of people not shipping proprietary products on Linux: https://icculus.org/fatelf/

Re: Requirements for DRM in HTML are confidential

#369

Earlier quoted context omitted.

But you can't get a pure HTML5 DRM experience! All the HTML5 bit is, is a Javascript API to a CDM decryptor that is every bit as crappy, proprietary, closed-source, insecure and buggy as Flash or Silverlight.

I'm still unclear as to how users are supposed to get the CDM decryptors. Are they installed like browser plugins? Or are OS vendors going to provide built-in ones for other companies to use? Either way, the actual user experience is going to be a pure HTML5 player. If I have to install something first, that's unfortunate, but once it's installed I'll never have to think about it again, unlike the current situation w…

None of the ones that have shipped already are installed like browser plug-ins. The ones Netflix deploys (PlayReady on Windows 8.1 with IE11 and Widevine on Chrome OS with Chrome) are bundled with operating systems and work with the browsers (one per OS) bundled with those operating systems.

Re: Requirements for DRM in HTML are confidential

#370

Earlier quoted context omitted.

Netflix already works on Linux: Android devices. What, you were talking about GNU /Linux? See, that is not going to happen. Instead, you'll see the Linux kernel, some GPLv2 userspace, and a hardware-enforced lockdown that renders the GPL useless. There will be jailbreaks but only a minority of people will even be aware of them, let alone care enough to actually make use of then.

Which is why it's so important that the W3C doesn't endorse this technology. It's not, in itself, the fact that it's incompatible with GPL3 etc. It's that for the first time in the history of the Open Web, the Open Web will not be implementable by anyone with a general purpose computer. That is the problem here.

You seem to think that "the Open Web" doesn't mean the part of the Web that's freely implementable but the part of the Web that uses W3C-specified tech. What makes you think that?

Wouldn't it be more logical to say something like, for the first time in the history of the W3C, the W3C publishes a non-Open Web spec? Or something like that.

Post reply on HN