Then let it be Flash, so it can die with Flash. Let's not perpetuate it, or make it any easier. Let a hundred competing "standards" bloom so media companies have more work to do, and might decide that DRM seems like too much trouble and decreases their target audience. Let browsers prune away support for DRM with their outdated plugin interfaces.
Don't give any one "standard" the blessing of any standards organization. And don't accept something inherently non-standard as a standard. Don't accept as a standard something completely unimplementable in a fully Open Source browser. Don't accept a standard interface to custom binary DRM implementations.
In the end, there'll be a standard DRM multimedia format whether it's "endorsed" by Open Web people or not; if browsers don't build in support for it, then it'll just build support for itself, via the APIs that do exist: WebGL, WebRTC, ASM.js, etc. Consumers will get their media; they'll just be running an opaque blob of Javascript in the browser to get it, instead of the browser doing the job—cleanly—itself.
This is not to say that there aren't vulnerabilities in the drivers, that said the only 3 PE/CE vulnerabilities in the NVIDIA driver in the past 4+ years were not exploitable through any vectors you are suggesting since they involved NVAPI, AMD doesn't discloses vulnerabilities openly IIRC.
To exploit a vulnerability in the manner you suggest you need to break through the sandboxing and security model of the browser, break the sandboxing and security model of the web API you are using e.g. WebGL break through the security model and sandboxing of the actual API e.g. DirectX on Windows, break through the sandboxing and security model of the user mode driver, and then exploit a vulnerability in a kernel mode driver that might have actual access to something you might care about.
And even then it's not that simple in WDDM for example even in pure kernel mode you'll have issues accessing memory out of the bounds of your application due to how GPU resource are managed, pinned and translated.
To put it simply every process accesses a "virtual GPU" through it's own endpoint, there is a zero-out process which is invoked on both the GPU and system memory when any buffer is allocated or accessed, and there is an out-of-bounds behaviour control running on the GPU independent of the driver, basically once you access (read or write) out of bound memory the GPU would terminate the loaded kernel which would crash your application and the driver would be cycled (restarted).
The out of bound memory is a real annoyance anyone who's worked with GPGPU especially CUDA is pretty familiar with, it's the #1 app killer (as far as code errors go) and for good reasons, even a privileged kernel running natively on the GPU is protected from abusing it's own rights.
There is a reason why the graphics driver is in user mode, and why the memory is virtualized.
The application doesn't have traditional DMA unless you load a privileged kernel which you can't do via a browser.
An application can't access the memory of another application via the display driver this is a solved issue.
Open web people can not endorse DRM, once a open web persons endorses DRM they cease to be a Open Web Person.
Claiming to be a Open Web supported while also endorsing closed items like DRM, is an objective violation of the Philosophy of the open web
People over use and misappropriate the charge of No True Scots Man
The people this hurts aren't going to be the media companies or the normal users. The people it will hurt will be us crazies that do stuff like run Unix on the desktop or try and run unlocked Chinese Android phones, because they just won't be supported because there's no financial case for it.
And then that'll leave a market for someone else to come along and serve.
If the company that owns the distribution rights to a piece of content doesn't want to support the last few percent of the market then they just won't and there's nothing anyone else can (legally) do about it unless they start further up the food chain, making their own content. And if there were enough money in those outliers for that to be profitable, then the existing content creators would probably be serving them.
DRM is going to happen one way or another, and in my mind ensuring that at the very least the DRM itself has a defined interface for everyone to work against results in a more "open" ecosystem than leaving it up to backroom deals between content creators and DRM vendors who create hacky hodge-podge software.
Unfortunately, many people who could bring some moderation to the discussions about DRM are still stuck in fantasy land where none of this is happening.
And this is a collective fault of many ignorant persons also in this forum who more than often have suggest people to use Chrome. I think that Chrome has gained much support thanks to the wide spread ignorance about the implications.
Google can control both ends of the pipe, which means whenever they make big changes Chrome users will have a better experience. They pushed ahead there with MSE, codec support (VP9), SPDY, HTTP/2, etc and other browsers had to catch up. If other browsers were ahead in some areas, it didn't matter, because the content side didn't support it. Sites are designed and optimized in Chrome first and foremost, so Chrome never risks looking slow.
Similar things apply to Safari on iOS, or Edge on Windows.
The problem in my mind is that by having the same parties sit on both ends of this story, it's inevitable the middle man (that could be a leverage against DRM) gets pushed out. It's very, very hard to explain to the majority of users that they have to accept short term pain to avoid an outcome that is much worse for them. Ask any politician.
But we don't even need to kill the web to get there (pushing out any middlemen). We have native apps! Nobody is complaining their Android or iOS phone has DRM, do they?
I wonder why that is.
> This isn't always intentional, even.
I don't think everyone at Google is evil. There are many passionate engineers and hackers like you and me. However, if a Youtube developer has an issue with something running extraordinarily slowly, it's a much shorter call to the Chrome department than it would be to Apple's Safari or Mozilla's Firefox. So while developers might not be actively hindering other browsers, they are developing for Chrome. That it technically works on other browsers is a requirement but optimizing for the competition's browsers is not something I imagine management allocates hours for.
The end result is that they are hindering competition in the browser market, and quite a few people saw that coming. Still, even more people (vastly more people) either did not care or know and recommended Chrome anyway.
> Nobody is complaining their Android or iOS phone has DRM, do they?
My Android phone does not have DRM beyond what it in the SIM and I am complaining about people whose phones do. Many friends and peers share my view on this, so it's at least not "nobody".
https://developer.android.com/reference/android/drm/package-...
"Added in API level 11". Maybe you have a custom build with this ripped out, but then we're stretching by calling it "Android".
Then again, I'm not sure I have any apps that use this.
It's like they're trying to give up every advantage.
Youtube exists to sell ads, and a slow browsing experience on any device or browser does not serve that goal. So while Chrome may be their default testing environment, there's a very strong incentive to have it work well across the board.
As someone who has never used Chrome, I'd love to understand what exactly "works better" means. I've never had problems with any of those sites using Firefox and Safari.
Google broke YouTube for Firefox users right before the last Christmas holidays. Mozilla pushed out Firefox updates over the holidays that faked the UA as a workaround.
Google Inbox didn't work on Firefox initially, because Google claimed Firefox was too slow. When reported to Mozilla, it was fixed in a few hours, and they found that Chrome's implementation of the "thing that was too slow" was actually broken and not spec compliant.
Hangouts (used to?) require a plugin in Firefox, and just uses WebRTC in Chrome.
And so on...(sigh)
https://bugzilla.mozilla.org/show_bug.cgi?id=1087963
Here's the Firefox bug report about Google Docs being 3-9% faster, in a particular performance benchmark, when Firefox spoofs the Chrome UA:
Google Hangouts uses WebRTC and NaCl without plugins in Chrome, but requires an NPAPI plugin or ActiveX Control (confusingly called the "Google Talk Plugin") in other browsers. Support for any browser other than Chrome is not listed on the Hangouts home page. You must search their KB to find the plugin installer.
Because the knowledge of the prisoner is deeply intertwined with the optimal strategy in quantum prisoner's dilemmas. And quantum prisoner's dilemmas have at times been shown to more accurately match human behavior than classical ones.
The W3C standard is not about making DRM supported by all browsers and other tools - even if included in the standard, many makers of web technology will be locked out of DRM support.
The W3C standard is simply about whether we (the "tech guys") ENDORSE the use of DRM. And it DOES make a difference: if approved, DRM will be more common than if not approved.
Or the other way around, W3C should only approve feature complete standards that can be implemented using open source.
You cannot have an open web if an essential part is governed by binary blobs.
Nothing is lost if W3C does not approve an interface to secret technology.
The problem is the CDM, which the W3C isn't standardizing.
An interface to an unspecified DRM module is not a useful web standard. And due to the nature of DRM, a fully specified DRM standard is also completely useless. DRM is just not compatible with open.
This is in fact how it works in Firefox. There's no part of Firefox that is closed source, including EME support or even the CDM sandbox. The CDM is loaded at runtime from an external server.
Focusing on the W3C and/or it's relation with open source is completely and utterly missing the point, but it's explained enough throughout this thread that I see no point in repeating it once again here.
Which means the whole thing doesn't work in a fully Open Source browser. EME is non-functional without a proprietary CDM.
It's like standardizing the <object> or <applet> tags: yes, they're a standard, but they're a standard way to talk to completely non-standard bits. But worse, because you could use <object> or <applet> to talk to an Open Source plugin, but a CDM completely loses what little function it has if open.
(That includes hardware-backed CDMs, since signed software you can't replace isn't Open Source either.)
Web for All
The social value of the Web is that it enables human communication, commerce, and opportunities to share knowledge. One of W3C's primary goals is to make these benefits available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability.
Web on Everything
The number of different kinds of devices that can access the Web has grown immensely. Mobile phones, smart phones, personal digital assistants, interactive television systems, voice response systems, kiosks and even certain domestic appliances can all access the Web.
https://www.w3.org/Consortium/mission
EME and DRM violate the Stated mission of the W3C
Browser market share changes widely depending on which capabilities browsers have. Firefox went from 0 to web dominance in a few years because it had a more compelling offering than IE. Then Chrome beat it to its own game. Then IE was kept alive on Windows in parts because Netflix' use of Silverlight. If DRM is kept at the add-on level in some browsers, then those browsers will succeed as DRM restrictions invade the web slowly, and publishers will not be able to ignore those browsers.
Even if Firefox came on board and publishers really started cracking down, I could see a DRM-free fork take hold. It could be called Firefork, actually. :)
But if Apple does a DRM tech in Safari, that it is not approved by W3C, that it is not implemented in Firefox, how do you think they will get it into Chrome and IE? Heh, they'll have to pay a lot of money to Google and MS, or to accept reciprocal agreements, segmenting their markets, complicating the development of their tech.
It will slow them down, like it has so far. And if it slows them enough that they move slower than the tech they want to regulate, we win.
So yes, the W3C is just a stone thrown in the middle of the stream, trying to slow it down. It won't make much by itself. But at least it knows it wants to be a part of the dam.
"Oh, hackers will always be able to break into systems. So instead of making them do it ad-hoc, let's just create a standardized backdoor on every system. It will be less work for everyone."
Those would be the same reasons the anti-DRM forces don't.
The content publishers and the browser makers are severely intermingled and often the same company. (Google, Apple, "Netflix HD only on Edge") We don't even need to pretend Firefox has any relevance in this particular space.
If Google wants to push SPDY or HTTP2 or a DRM technology through, they can just do so through combined browser and YouTube/Gmail/Google Play/Android/Google Docs marketshare. Similar things apply to the iOS and Windows ecosystems.
The W3C exists as place for these companies to work out interoperability standards. They have no other incentive to attend. If the W3C gets in the way of that, what does it matter? They can interoperate or not. There can be a standard or not.
DRM will be there anyway. Be it Flash, be it something else.