This is all true, but what has it got to do with the W3C approving the standard or not?
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.
> DRM will be there anyway. Be it Flash, be it something else.
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.
There aren't going to be a hundred competing standards, because the production tool ecosystem has its own working groups who will settle on a small set of standards, with or without the input of the browser vendors. The browser vendors only have a say in DRM formats insofar as providing universal support for a format entices the production-tool ecosystem to provide export-compatibility for it. If the browser-vendors refuse to provide such a standard, they're really just refusing to sit at the table where the standard is decided.
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.
Designed. Many designs fail to achieve their goals. Has there been much research into 0-days in the GPU firmware itself? Or the closed blobs that get loaded into kernel space?
Yes, quite a bit actually, and you also need to understand that you aren't hitting the GPU directly by any means you are going through several layers of API's each with it's own security controls, then hitting a restricted end point in a usermode driver.
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.
What does that mean in regards to parent's comment? If it renders, it went through both a graphics driver and GPU. Therefore they're in attack surface for malicious data designed to take over privileged code and/or DMA engines.
Except that's not what's going to happen. This problem is not going away. And if you create more "work", they'll just do what they need to to capture the majority of the market and leave a lot of users in the cold.
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.
> Except that's not what's going to happen. This problem is not going away. And if you create more "work", they'll just do what they need to to capture the majority of the market and leave a lot of users in the cold.
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.
It's not going to be Flash precisely because Flash is dying. It doesn't matter whether the W3C is involved or not, the companies that want this are going to make it happen. The idea that stopping a W3C standard is somehow going to stop the entire media industry getting its way on this is nothing but a fantasy.
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.
We don't even need to pretend Firefox has any relevance
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.
I wouldn't say those people were "ignorant". Things like YouTube, Google Docs, most Google properties work better in Chrome. This isn't always intentional, even.
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?
> Things like [Google] YouTube, Google Docs, most Google [projects] work better in Chrome.
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".
I suppose you might be right. I actually realized after posting that there is probably something somewhere in my phone that still contains some kind of DRM. Assuming this is still in Cyanogenmod, you're probably right.
Then again, I'm not sure I have any apps that use this.
I use Firefox over any other browser precisely because I can "hack" it. I've changed so much under about:config that I have to document it for the next install. Firefox allows so many useful hacks that are truly in favor of the user. Chrome not so much. I don't use anything other than macOS or *nix, so I cannot speak to IE or other platforms.
> 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.
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.
Say in the YouTube app you perform a search for a song. The results come back very quickly and the first result is what you want so you tap it. An ad starts to play. Except its not an ad. Its a video from the advertised spot above your search results - wait a minute you didn't click that. So you go back and realize, it loads 1 second after your search results and pushes them downwards, so your tap ends up on the advertisement that wasn't even rendered yet. Hm.
That might drive short term revenue but would drive down their CPM/CPC rates and user engagement longer term. I don't think Google's culture is conducive to playing those sorts of tricks.
> Things like YouTube, Google Docs, most Google properties work better in Chrome.
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 Docs is more responsive and faster in Chrome (it improves in Firefox if you fake the Chrome UA, hah). YouTube relied on Flash much longer in Firefox, while Mozilla was working to make their MSE implementation compatible with Chrome.
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.
For more backstory, here's the Firefox bug report with the fix for Google Inbox being "too slow" due to JS array slice being faster in Chrome than Firefox due to a V8 bug:
When you change the user agent in Docs, the JS app tries to use a webkit-specific selection API and just crashes. The timing results for that test seem bogus.
Google deployed SPDY on Google sites when only Chrome supports it. YouTube deployed streaming with QUIC when only Chrome supports it. I'm not saying Google sites are sabotaging other browsers, just that these are examples of Google sites the work best in Chrome because Google teams can work closely together.
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.
Is this classical or quantum prisoner's dilemma? Which variation?
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.
Or it could be that FF is perceptibly slower and currently has very weak dev tools. I personally use Chromium, which IMO, is the best of both worlds and actually, the only one of the three browsers that doesn't have EME (so you could argue it's better than FF in this regard). You also get a clear picture of the sites that stream with DRM (looking at you Vimeo).
I don't think the person you're arguing with is even necessarily denying this. He is pointing out that the trade-off of using the "perceptibly" faster browser has very bad long term consequences.
The W3C standard is not about whether the DRM will exist - to some extent it will exist regardless of what decisions the W3C makes.
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.
That's why I wrote 'feature complete standards'. Anybody can come up with half finished standards that are only there to serve some proprietary technology.
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.
Which means you can't actually ship any useful implementation, since it won't have a backend to talk to. And an Open Source implementation would inherently be non-functional.
You can implement EME in open source (the part that W3C standardized), and then throw a closed source CDM module on top of it. You don't even have to provide the CDM, third parties can provide multiple ones.
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.
> You can implement EME in open source (the part that W3C standardized), and then throw a closed source CDM module on top of it.
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.)
>>>The W3C exists as place for these companies to work out interoperability standards.
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.
> We don't even need to pretend Firefox has any relevance in this particular space.
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. :)
Openness is not something one actor decrees. It is something promoted by a whole ecosystem. If W3C is the only opponent to DRMs, yes, it won't amount to enough resistance. If Firefox alone refuses to implement W3C-approved DRM standards, yes, it won't amount to enough resistance.
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.
We should make DRM as expensive, difficult, and unwieldy to use as possible. We need not and should not standardize the use of things that are detrimental.
"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."
Then only big medias companies will be the only ones able to reach as many users as possible. You have no idea of how expensive it's right now to target just browsers. Small producers will be constrained to only publishing trough their channels/platforms.
You're talking about the very people who build the systems here, not hackers. Standards bodies facilitate the work of implementers, they are not regulatory agencies.
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.