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.
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.
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-... ).
So - yeah.
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.
This stuff matters.
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.
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.
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.
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.)
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.
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.
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).
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.
And only supported on 32 bit intel machines!
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"?
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.
Let's not get lost in semantics here.
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".
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.
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 :(
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.
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.
I dislike DRM as much as the next guy, but really? Slavery?
Sorry Ivan, but voluntarily agreeing to access encrypted content is not comparable to slavery.
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
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.
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.
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."
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.
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.
So that libwidevinecdm.so isn't particularly useful to Linux users.
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...