News for hackers. Stuff that matters.
Re:Requirements for DRM in HTML are confidential by girvo on Monday January 13, 2014 @09:56PM (#7055075)
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.
Re:Requirements for DRM in HTML are confidential by zanny on Monday January 13, 2014 @10:06PM (#7055107)
> 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 rendering there are, because they are destroying the platform they are supposed to advance, community backlash be damned, they got bought off.

I'm definitely looking into ways to get qml into browsers, though. I think qtquick apps as remote resources would be amazing, because they would be actual apps, not documents with scripts running on them.

Re:Requirements for DRM in HTML are confidential by fishy929 on Monday January 13, 2014 @10:23PM (#7055172)
> My problem is I have no idea what to do about the w3c.

If the W3C disappeared tomorrow, the world would be fine. (Similarly, the weather channel is not an essential service, planes can still attain flight without the TSA, and there is still life outside of the panopticon's walls...)

The W3C served a useful role a few decades ago when it focused on codifying historical standards that resulted from the early exponential growth but, like many others who took the minutes in important situations, they now seem to think they are "leaders." But documenting historical growth doesn't mean you are suddenly a source of good ideas; leading isn't something you say you will do, it's something others say you did.

I propose that everyone simply ignore the W3C whenever it's useful.

If only ignoring the TSA, the NSA, and corporate managers were as easy.

Re:Requirements for DRM in HTML are confidential by duncan_bayne on Monday January 13, 2014 @10:27PM (#7055190)
Remember that ignoring copyright 'protection' methods is in fact every bit as illegal as ignoring the TSA and the NSA (at least, in most countries).

This stuff matters.

Re:Requirements for DRM in HTML are confidential by duncan_bayne on Monday January 13, 2014 @10:08PM (#7055125)
I've been hacking around with 'websites as Racket' ... the idea that you could use Racket's documentation format for, well, documents, and the Racket GUI for everything else. Much the same idea, just Scheme instead of QT.

But I don't think it's too late for the W3C. I don't think they've been bought out in the strictest sense; rather, I think they've been subject to some very effective lobbying that has proved most persuasive ( a.k.a. 'crisis of representation; see http://boingboing.net/2013/06/06/w3c-insider-explains-whats-... ).

Re:Requirements for DRM in HTML are confidential by girvo on Monday January 13, 2014 @10:14PM (#7055146)
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.
Re:Requirements for DRM in HTML are confidential by zobzu on Tuesday January 14, 2014 @12:31AM (#7055555)
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 by duncan_bayne on Monday January 13, 2014 @10:18PM (#7055163)
If you don't frequently consume those media, then you should be doubly angry that the W3C might harm the Open Web to support it.
Re:Requirements for DRM in HTML are confidential by duncan_bayne on Monday January 13, 2014 @10:01PM (#7055094)
EME will work on Linux. The thing is, the CDMs with which it is designed to interface won't.

It is technically possible to produce a purely FOSS CDM that will compile on pretty much any platform. However that idea has been rejected by content licensees on the grounds that it won't meet requirements, as defined by licence agreements that (so far) no-one is authorised to post on the W3C discussion list.

Other ideas that have been rejected are server-side watermarking (too expensive, doesn't meet requirements) and client side watermarking (doesn't meet requirements).

So, myself and (most) others are rejecting EME on the grounds that it is inseparable from "non-user-modifiable client components" (a wonderful phrase I picked up on the list), a.k.a. closed-source, proprietary CDMs that are tied to particular OSs.

Re:Requirements for DRM in HTML are confidential by zanny on Monday January 13, 2014 @10:07PM (#7055117)
I find it somewhat awesome that this whole html drm debacle is effectively what Richard Stallman has been saying for decades versus outdated entrenched old media interests. Except in this case, the web standards consortium is giving away your freedom for you.

That is what pisses me off most, really - if big media was left to squalor in broken plugins and horrible drm, which should be horrible because its entirely anti-user, they would have to eventually adapt to the Internet and change their ways or die.

But with the power of money and apathy on the part of vast swathes of the tech community that think they don't have ground to stand on (hint: you are the consumers they want buying stuff, you hold all the cards) they are ending the open inter-operable web. It sucks.

Re:Requirements for DRM in HTML are confidential by duncan_bayne on Monday January 13, 2014 @10:12PM (#7055138)
Yes it sucks, but it's not too late.

The issue of patents in W3C standards came up a decade ago; it looked like the W3C had caved then, but a 'firestorm of public criticism' (to quote an article at the time) caused them to back down.

So, agitate. Tell people about it. Bring it up at user groups. Post to Hacker News :) If you know anyone in tech. journalism, tell them. Support the EFF.

Re:Requirements for DRM in HTML are confidential by gsnedders on Monday January 13, 2014 @10:23PM (#7055169)
Also remember it isn't the W3C as an entity that is really the problem — it's convincing a majority of member organizations of the W3C that is the problem. The W3C is just an industrial consortium, and will do what the industry wants. If that's DRM, that's DRM.

What happened with patents and what needs to happen now is to convince the majority of members who have no entrenched opinion that they should be against this work happening at the W3C (which by no means guarantees the work will stop — it may well just move to another venue, quite possibly closed, and still de-facto become part of the Web Platform), and that they should oppose this at the AC level, who ultimately control the direction of the W3C. (The AC, essentially, has one representative from each and every member organization.)

Re:Requirements for DRM in HTML are confidential by shawnz on Monday January 13, 2014 @10:31PM (#7055199)
> 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.

Re:Requirements for DRM in HTML are confidential by duncan_bayne on Monday January 13, 2014 @11:10PM (#7055314)
Why do you suppose that EME + CDMs will be a better solution than Flash? What advantages do you expect?
Re:Requirements for DRM in HTML are confidential by shawnz on Monday January 13, 2014 @11:50PM (#7055459)
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 by duncan_bayne on Tuesday January 14, 2014 @12:03AM (#7055491)
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.

Re:Requirements for DRM in HTML are confidential by shawnz on Tuesday January 14, 2014 @12:34AM (#7055563)
> 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 by Already__Taken on Tuesday January 14, 2014 @04:36AM (#7056157)
Do you want to buy and run windows 9? Because to see the new series of the game of thrones only windows 9's CDMs can read it. That is the kind web you are negotiating for.

How long do you think MS would back port these things to win7 before they bump their minimumContentPlayer=win8 and then that's it you're not seeing any of that media to you pay up.

Perhaps they'll choose to offer a binary for other open source OSs, it will just be a major version behind, 6 months late and kind of buggy.

Re:Requirements for DRM in HTML are confidential by eponeponepon on Tuesday January 14, 2014 @08:18AM (#7056801)
>Perhaps they'll choose to offer a binary for other open source OSs

Even that's a bit hopeful imho - consider how easy it is to imagine an advert declaring "Game of Thrones Season 5: Exclusive to Apple!"... Hell, it could be worse - "Only on Intel"?

Re:Requirements for DRM in HTML are confidential by shawnz on Tuesday January 14, 2014 @12:13PM (#7058195)
> That is the kind web you are negotiating for.

As discussed, that is a motivation that will exist regardless of the W3C's course of action. What I am negotiating for is the W3C being in charge of what access these "big bad companies" have over web standards, rather than allowing the development of similar technologies to continue unmoderated.

Re:Requirements for DRM in HTML are confidential by duncan_bayne on Tuesday January 14, 2014 @03:41PM (#7059560)
The fact that EME is being seriously entertained by the W3C should tell you everything you need to know about the power relationships there. I don't think there's as much 'being in charge' as you think there might be.
Re:Requirements for DRM in HTML are confidential by Nursie on Tuesday January 14, 2014 @06:06AM (#7056375)
>> Perhaps they'll choose to offer a binary for other open source OSs, it will just be a major version behind, 6 months late and kind of buggy.

And only supported on 32 bit intel machines!

Re:Requirements for DRM in HTML are confidential by ericd on Tuesday January 14, 2014 @12:48AM (#7055591)
Wouldn't another option simply be making it so that Netflix et al are in a position that they can't move forward to these new standards with their licensed stuff, but everyone else can? Them being the only ones left using Flash/Silverlight would probably give them a good incentive to push back on their contracts...
Re:Requirements for DRM in HTML are confidential by higherpurpose on Monday January 13, 2014 @11:26PM (#7055372)
So the system the way they intend it won't work, which means you won't get the content anyway.

Let's not get lost in semantics here.

Re:Requirements for DRM in HTML are confidential by zobzu on Tuesday January 14, 2014 @12:29AM (#7055549)
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 by baddox on Monday January 13, 2014 @10:00PM (#7055092)
It's pretty much baked into the definition of DRM that it may not work on all of your devices.
Re:Requirements for DRM in HTML are confidential by duncan_bayne on Monday January 13, 2014 @10:02PM (#7055098)
There is no technical reason that DRM technology can't be FOSS and use non-secret keys; this is a result of licensing agreements with content owners. I'm hoping to have those agreements made public so technical discussions surrounding EME can take place with a degree of transparency.
Re:Requirements for DRM in HTML are confidential by nly on Monday January 13, 2014 @10:07PM (#7055116)
Eh? If your DRM code is FOSS I'm just going to patch it, recompile it, dump out the keys, decrypt my media, and ignore all your constraints.

Technical DRM only 'works' when the code is an obfuscated steaming pile and the implementation/platform/hardware tries to make it an incredibly difficult process to mess subvert.

Theres never been a consumer-facing DRM technology thats made a lick of sense, and frankly I'm glad most of the FOSS success stories are in defeating it rather than proliferating a broken trust model that serves to prop up slow-moving industry monopolists who bump up costs (of many kinds) to consumers and are going to lose in the long-run anyway.

Re:Requirements for DRM in HTML are confidential by duncan_bayne on Monday January 13, 2014 @10:14PM (#7055148)
Sure - and the fact that you can do that is why 'big content' don't want a bar of FOSS DRM.

Personally, I like the idea of copyright bits that travel with content. Some way of telling the user how the creator wishes the content to be used, or not used. Not enforced, mind you (because as you say, that's impossible) but just notified. Making it easier to do the right thing.

That would go well with watermarking to identify paid content, and a good system for processing micropayments.

But of course it's easier just to lobby the W3C and break the Open Web :(

Re:Requirements for DRM in HTML are confidential by nly on Monday January 13, 2014 @10:29PM (#7055195)
I agree. I think if we promoted Creative Commons and generally made people more aware of how copyright law can be used to promote creativity, fair use and empower indy content creators that we'd become more sympathetic to the case made by Hollywood and the music industry, and maybe eventually get out of this rut of seeing it as a weapon for big media.

I wouldn't oppose any standard that made it mandatory for copyright and license information to be encoded in to image, video and audio content. Nor would I oppose a requirement for browser vendors to expose that information accessibly (on demand) to users.

I'd also like to see online registries that worked like TinEye or Midomi and let me quickly identify content with an emphasis on copyright and license discovery.

Re:Requirements for DRM in HTML are confidential by pbhjpbhj on Tuesday January 14, 2014 @03:08PM (#7059345)
DRM destroys the possibility that the contract of copyright can be upheld.

The contract is that we, the people, give - through our respective states - content producers a limited monopoly on reproduction [and modification, etc.] of artistic works in exchange for them being release in to the public domain at the end of that limited term.

With DRM a content producer (or at least the rights holder) destroys the ability of the work to pass in to the public domain [effectively].

In other words applying DRM breaks the contract. This means that we, the people, should be under no obligation to provide the state enforcement to their monopolistic rights gained via that contract.

There are ways the contract could be maintained under DRM [deposit an unblemished copy that can be released to all copy holders on expiry of the term] but I've never seen anything to suggest rights holders are acting to avoid breaching the central contract.

This is pertinent because it's not just linux that will be cut out of being able to present this data [DRM protected works] but also the OS of those in the future who're supposed to get access to copyright works which are currently being locked for good by DRM techniques.

Re:Requirements for DRM in HTML are confidential by shmerl on Tuesday January 14, 2014 @12:26AM (#7055542)
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 by krasin on Monday January 13, 2014 @10:01PM (#7055095)
you should not be okay with DRM. It's as simple as it's: DRM is the form of slavery.
Re:Requirements for DRM in HTML are confidential by markdown on Monday January 13, 2014 @10:06PM (#7055110)
> DRM is the form of slavery.

I dislike DRM as much as the next guy, but really? Slavery?

Re:Requirements for DRM in HTML are confidential by cycrutchfield on Monday January 13, 2014 @10:12PM (#7055137)
Captain Hyperbole to the rescue!
Re:Requirements for DRM in HTML are confidential by hbags on Monday January 13, 2014 @10:12PM (#7055139)
> you should not be okay with DRM. It's as simple as it's: DRM is the form of slavery.

Sorry Ivan, but voluntarily agreeing to access encrypted content is not comparable to slavery.

Re:Requirements for DRM in HTML are confidential by krasin on Monday January 13, 2014 @11:15PM (#7055334)
first of all, I agree that my message was too short and didn't have any arguments to positively contribute to the thread. Sorry about that.

Now, let me explain how did I come to this comparison (even if it seems rogue). To make it more specific, let's consider Raspberry Pi, which is one of the most open ARM boards and, at the same time, practices DRM. For example, its hardware video decoding capabilities might be unlocked, if a separate digital license is acquired in the store [1].

I am perfectly fine when people voluntarily agree to access encrypted content or "premium" functionality. The problem is that the need to put this DRM to the chip, has led to the decision of the manufacturer to make its GPU core a supervisor. GPU starts to work ahead of CPU, initializes its firmware and starts CPU at some point later ([2]). Additional GPU firmware (provided by a binary blob) may be loaded to support OpenGL and other related stuff [3].

Effectively, even if the user does not want to access an encrypted content or use the "premium" functionality, he is being kept in a jail to make sure this premium stuff is not used. Moreover, the supervisor capability of the GPU chip combined with a binary blob updates, makes it possible for the manufacturer to reduce the amount of allowed to the user.

The user of the device is treated as a customer, and it's the manufacturer who is the owner of the device, not the user.

Given these capabilities of the manufacturer over this aspect of the user life, we may start looking at the definition of slavery [4]:

"""Slavery is a system under which people are treated as property to be bought and sold, and are forced to work. Slaves can be held against their will from the time of their capture, purchase or birth, and deprived of the right to leave, to refuse to work, or to demand compensation."""

At least half of the definition applies:

1. The customers are treated as property to be sold or rented. There're video dongles/boxes on the market which stream content to the TV. They would often allow only a subset of the video services to be used, even if these services are freely available on the internet. The manufacturers of this devices may actually sell the access to the users of this device to the content providers.

2. The customers may be shown ads against their will and their user experience may be altered by the manufacturer w/o their consent or right to refuse.

Again, that does not happen to the people, it happens to the customers, which appear as a virtual entity applied to the devices, but I really see some similarities.

[1] http://www.raspberrypi.com/mpeg-2-license-key/

[2] http://stackoverflow.com/questions/16317623/how-does-raspber...

[3] https://github.com/raspberrypi/firmware/tree/master/boot

[4] http://en.wikipedia.org/wiki/Slavery

Re:Requirements for DRM in HTML are confidential by IanCal on Tuesday January 14, 2014 @03:23AM (#7055984)
> For example, its hardware video decoding capabilities might be unlocked, if a separate digital license is acquired in the store [1].

One particular format. It'll do h264 fine, it's only MPEG-2 that it won't do in hardware unless you buy a license.

> Effectively, even if the user does not want to access an encrypted content or use the "premium" functionality, he is being kept in a jail to make sure this premium stuff is not used.

Effectively kept in a jail? I've got a raspberry pi in the corner of the room, I still seem to be able to leave. This is identical to any service with a premium.

> 1. The customers are treated as property to be sold or rented.

With slavery, people are actually bought and sold. They then belong to someone else. When you watch a video with DRM you just can't copy it.

> 1. The customers are treated as property to be sold or rented. There're video dongles/boxes on the market which stream content to the TV.

Wait, are you saying that it's slavery for the dongles?

> The manufacturers of this devices may actually sell the access to the users of this device to the content providers.

In the same way that the newspapers do, but I wouldn't say when I'm reading the paper I'm being sold into slavery.

> 2. The customers may be shown ads against their will

In return for watching the programme. That part is key. If we were being held down and forced to watch it, then I'd agree more but you aren't. It's just part of the transaction.

Re:Requirements for DRM in HTML are confidential by codezero on Tuesday January 14, 2014 @01:52PM (#7058898)
Slightly off-topic, in addition to the DRM, the Raspberry Pi has a proprietary firmware that is not open source, so it's difficult to bake your own bootloader.
Re:Requirements for DRM in HTML are confidential by hbags on Wednesday January 15, 2014 @07:05PM (#7067150)
DRM is not slavery.
Re:Requirements for DRM in HTML are confidential by code_duck on Monday January 13, 2014 @09:59PM (#7055090)
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.
Re:Requirements for DRM in HTML are confidential by duncan_bayne on Monday January 13, 2014 @10:05PM (#7055104)
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 '<happy>', that displays a smiling face. Anyone who wishes (Firefox, Mozilla, you, me) could implement that feature and start properly displaying content that contains <happy> tags.

This is not true of encrypted content that requires a proprietary, closed-source CDM and / or a secret key to operate.

That is why EME should be rejected by the W3C. Lack of Linux support is a consequence of the problem, not the problem itself.

Re:Requirements for DRM in HTML are confidential by gbhn on Tuesday January 14, 2014 @12:35AM (#7055565)
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 by Rizz on Tuesday January 14, 2014 @02:14AM (#7055817)
One difference is that with embed you can still support most existing platforms by implementing NSAPI.
Re:Requirements for DRM in HTML are confidential by gbhn on Tuesday January 14, 2014 @01:00PM (#7058559)
My reading is that ESE is intended to work in much the same way -- the main work is done by the Content Decryption Module, which is more plugin-like. And indeed, the way existing DRM-using systems work in the browser is with the embed tag.

The spec says "The Content Decryption Module (CDM) is a generic term for a part of or add-on to the user agent that provides functionality for one or more Key Systems."

Re:Requirements for DRM in HTML are confidential by wmf on Monday January 13, 2014 @10:10PM (#7055130)
What they'll do is created CDMs that work on restricted subsets of Linux (Android and ChromeOS already support DRM and many media player devices have Linux buried inside) and tell you that if you want "Linux" you can use the supported subset (which is totally Tivoized so it's no more open than Windows).
Re:Requirements for DRM in HTML are confidential by betterunix on Monday January 13, 2014 @10:47PM (#7055242)
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.

Re:Requirements for DRM in HTML are confidential by duncan_bayne on Monday January 13, 2014 @10:50PM (#7055251)
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.
Re:Requirements for DRM in HTML are confidential by hsivonen on Wednesday January 15, 2014 @02:41AM (#7062134)
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.

Re:Requirements for DRM in HTML are confidential by ppergame on Tuesday January 14, 2014 @01:03AM (#7055637)
Turns out, Chrome on Linux shipped with a Widevine CDM before any other browser (including Chrome on Windows).
Re:Requirements for DRM in HTML are confidential by hsivonen on Wednesday January 15, 2014 @02:46AM (#7062144)
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 by Touche on Monday January 13, 2014 @09:58PM (#7055087)
It will work under Google Chrome (not Chromium) on Linux most likely, as Google is a DRM vendor.
Re:Requirements for DRM in HTML are confidential by wmf on Monday January 13, 2014 @10:25PM (#7055181)
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.
Re:Requirements for DRM in HTML are confidential by bzbarsky on Monday January 13, 2014 @11:41PM (#7055420)
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 by cpeterso on Monday January 13, 2014 @10:06PM (#7055113)
And Google will presumably have a Linux CDM for Chrome OS, so they could release it for Linux desktop, too.
Re:Requirements for DRM in HTML are confidential by duncan_bayne on Monday January 13, 2014 @10:10PM (#7055127)
But it doesn't matter. Google could release their CDM for any operating system they choose; it doesn't alter the fact that EME and CDM are inimical to the Open Web and should be rejected by the W3C.