Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Requirements for DRM in HTML are confidential

lists.w3.org

Post reply on HN
Print view View original

371–380 of 424 posts

Re: Requirements for DRM in HTML are confidential

#371

Post by hsivonen »

ppergame wrote: post #122
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.

Turns out, Chrome on Linux shipped with a Widevine CDM before any other browser (including Chrome on Windows).

Chrome for Linux indeed comes with libwidevinecdm.so, but still, Netflix is not letting the Chrome on desktop Linux play content even though Netflix allows Chrome OS to play content.

So that libwidevinecdm.so isn't particularly useful to Linux users.

Re: Requirements for DRM in HTML are confidential

#372

Post by hsivonen »

robmcm wrote: post #194
Zigurd wrote: post #45

Why should DRM be part of a standard? Aren't plug-ins sufficient?

The problem is a normal plugin doesn't allow a browser vendor to write their own version. (iPhone + Flash for example). Perhaps a plugin standard and API would solve it, then a vendor can build their own plugin (Apple) and allow others to use a non shipped third party (Firefox).

If Apple wanted to, they could write their own implementation of the non-DRM parts of swf. Mozilla is doing this in Shumway. Apple did this for PDF.

Of course, just like you aren't allowed to interoperate with an EME CDM without permission, you aren't allowed to interoperate with the DRM part of Flash (called Adobe Access) without permission. (Or the DRM part Silverlight called PlayReady, which, unsurprisingly, Moonlight does not clone.)

Re: Requirements for DRM in HTML are confidential

#373

Post by hsivonen »

xyjztr wrote: post #153

Hey Guys, can somebody create a simple guide, FAQ or something similar for non-tech people to understand what is going on with HTML and DRM? It will help to spread the word.

https://hsivonen.fi/eme/ explains what EME is. Granted, it might not explain "what is going on".

Re: Requirements for DRM in HTML are confidential

#374

Post by hsivonen »

jlebrech wrote: post #178

why can't they just build it in NaCl and leave the open standard alone.

In that case, the site providing DRMed video and the NaCl player would have distribute an H.264 decoder (and potentially other encumbered stuff) to end users as part of a NaCl executable. It's much more convenient for a company like Netflix not to have to distribute the DRM component when companies like Microsoft and Google are willing to do it instead. Also, NaCl doesn't integrate with the HTML media elements, you'd need to implement the whole media stack in NaCl instead of just the DRM part.

Furthermore, since NaCl is sandboxed by the browser (and the browser is untrusted by Hollywood in the DRM trust model), it can't conspire with the GPU on low enough a level to hide pixels from the browser and the operating system.

Re: Requirements for DRM in HTML are confidential

#375

Post by Nursie »

talmand wrote: post #342
psionski wrote: post #290

Earlier quoted context omitted.

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...

Well, I was talking mostly about food. But if I use my culture as a basis for a song that I write and I wish to sell it to make money, then you're dang right I see it as stealing if someone takes it without my permission. If an artist wants to share it openly, then that's excellent. But if the artist wishes to make money from their effort why is it your "right" to demand otherwise? It's not about being business-minde…

Because mostly it's not the artists who want to lock it up, and it's not the artists that stand to gain most from locking it up, it's the suits.

Re: Requirements for DRM in HTML are confidential

#376

Post by Nursie »

talmand wrote: post #284
RexRollman wrote: post #216

Earlier quoted context omitted.

Well, my question is does HTML even need to encompass everything it does. It seems to me that we have an ever expanding monster. HTML does not have to be everything for everyone.

I thought that was more-or-less what was being discussed. My understanding was that the media element being accessed would not play the stream unless a specified DRM component was available, most often due to a plugin installed to the browser. It wasn't that they wanted DRM in the open web, they wanted the open web to have the ability to communicate with a third-party DRM. A third-party solution that an individual ca…

>> A third-party solution that an individual can decline to install and not participate.

A third party solution that they can't get hold of because the 'official' one only runs on windows and intel, and the ps4.

Re: Requirements for DRM in HTML are confidential

#377

Post by robmcm »

hsivonen wrote: post #372
robmcm wrote: post #194

Earlier quoted context omitted.

The problem is a normal plugin doesn't allow a browser vendor to write their own version. (iPhone + Flash for example). Perhaps a plugin standard and API would solve it, then a vendor can build their own plugin (Apple) and allow others to use a non shipped third party (Firefox).

If Apple wanted to, they could write their own implementation of the non-DRM parts of swf. Mozilla is doing this in Shumway. Apple did this for PDF. Of course, just like you aren't allowed to interoperate with an EME CDM without permission, you aren't allowed to interoperate with the DRM part of Flash (called Adobe Access) without permission. (Or the DRM part Silverlight called PlayReady, which, unsurprisingly, Moonl…

Sure, but I believe that Adobe didn't really want anyone to clone flash (at least not in the early days).

If this was the goal from the outset the DRM parts could be described in the same way the HTML5 ones are being.

Re: Requirements for DRM in HTML are confidential

#378

Post by ZoFreX »

simonsarris wrote: post #107

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

> DRM only works if you don't know how it works.

That's not entirely true, I don't think? What about AACS, which uses a very clever master key / sub key + key revocation mechanism. People figured out exactly how it worked well before it was actually "broken" - and it was broken by stealing private keys from devices.

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

Steam is DRM. Sure, it's fairly nice as DRM goes, but it is still DRM.

Re: Requirements for DRM in HTML are confidential

#379

Post by derefr »

pquerna wrote: post #368
shmerl wrote: post #353

Earlier quoted context omitted.

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/

Might Docker containers be a valid solution to this? Shipping old games is a sorta-kinda-similar problem to shipping frozen versions of web-apps.

Re: Requirements for DRM in HTML are confidential

#380

Post by alkonaut »

fafner wrote: post #330
alkonaut wrote: post #327

Earlier quoted context omitted.

You misunderstood me, I think if there should be standardization of some kind of platform indepndent "plugin" it should address what flash, applets, ActiveX and Silverlight does but in a standardized way.

It is - by definition - not possible to have an open standard or libre implementation for DRM. You could simply implement it to dump the stream instead of displaying it. If you mean the features besides DRM then we don't need a plugin because HTML5 and JavaScript are perfectly fine for replacing those plugins and they can be openly implemented and distributed.

I mean a standard way of distributing binary executables where anything the plugin author wants can be done (within a sandbox). For example the decoding and display of protected data. Much like flash, but with some form of standardized bytecode vm. I understand that the implementation if the actual DRM will probably be closed, but the plugin standard that hosts the DRM code should not have to be.

Apart from allowing closed binary applications it should of course offer some other benefit over javascript, such as offering good hardware support (true multithreading with shared data, access to all peripherals, and so on). Javascript even with WebGL+WebWorkers+similar frameworks isn't it.

Post reply on HN