Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Tim Berners-Lee approves Web DRM, but W3C members have two weeks to appeal (defectivebydesign.org)
249 points by acabal on July 7, 2017 | hide | past | favorite | 215 comments


W3C takes advantage of the ambiguity of what the EME spec and "standard" DRM is. People unfamiliar with the spec may think it's the end of plug-ins and a spec for a DRM that is somehow open, implementable and cross-browser.

It's nothing like it. It's a small JS API that launches the same old, fully closed, proprietary DRM solutions. The NPAPI has been replaced with DMCA-protected interface, and previously separate DRM plug-ins are now called "modules" and shipped with the browser.

It's as if Chrome, which ships with Flash bundled-in, created a "HTML Multimedia Extensions" spec with just `navigator.launch("com.adobe.flash")` for launching "Multimedia Modules" (details of which are out of scope of the spec), and hailed it as the end of the non-standard Flash and plug-ins.


I think that is a bit of an exaggeration. First, for some browsers, the DRM scheme is built in, not any kind of plugin architecture.

Second, without EME, the state of the art for DRM video was to run the whole playback path through a plugin. Now, only the DRM bit is generally going to be hidden in binary blob (whether plugin or not.)

This has some important advantages:

* Web content authors can build video players using the same technology stack (HTML5 video+JS) for DRM-ful video as for DRM-free video. No need to learn a whole different plugin environment for this case.

* Video playback only has one code path, instead of totally separate browser and plugin video pipelines. Video codecs are complex, so this means less security attack surface.

* The browser's built-in playback is generally much more power-efficient, meaning more video viewing time on battery for your Netflix/Amazon/Hulu/etc video content.

* Even if the DRM scheme is some form of plugin, it needs far fewer capabilities than a plugin that has full video playback, live streaming, a scripting environment, etc. So it's less of a security risk

* Flash and Silverlight especially were common sources of critical security vulnerabilities and they'll be out of the picture.

* With approaches like MPEG Common Encryption[1], a single encrypted media resource can be used with multiple DRM schemes. This helps content hosts save on storage, and it makes it materially easier for new browsers to enter the market, since they don't have to ask content providers to host a whole separate copy of the video.

The continuing existence of DRM is admittedly not ideal. But supporting it in the browser instead of solely in the separate world of plugins has major user and developer benefits, as described above.

[1] https://en.wikipedia.org/wiki/MPEG_Common_Encryption


> same technology stack (HTML5 video+JS) for DRM-ful video as for DRM-free video

this isn't a pro in my books - i want DRM to be a difficult and cumbersome stack to use. More specifically, i want the end user to go through hassle to obtain the proprietary plugins, so that the end user feels the hurt from DRM. This makes a non-DRM version much more simple to view (just click and play), so that users would vote with their wallet, and use the non-DRM version (and avoid the DRM version).

If making DRM video easy to play for end users is the goal, then yes, web-DRM is doing it. But it will make DRM more prevailent, as end users will have no reason to try avoid DRM, thus, making web less open.


This already happened. We had Flash and Silverlight. This didn't make the Netflixes of the world drop DRM, and it didn't make customers flee for DRM-free solutions. All it did was decrease security for all of us.

But yes, you do have a point that making DRM easier will likely make more content producers consider and implement DRM than before. I'm not sure there is a good solution to this right now, and yours is just vindictive and actively harmful.


> We had Flash and Silverlight.

and when apple decides to drop flash support, what happened? Did netflix or any other video content producer suddenly decide to stop supporting those devices? No, they went with html5 video (and at that time, free of DRM). That was a great step forward for DRM free content for the web.

By making the web standard include a mechnism to include DRM natively, this means content producers once again will have a hassle free way to include DRM. The end user won't care as long as they can get their content, but the slippery slope is there, and one day, the web will only contain content that is DRM'ed (and there would be no way of format shifting, or saving the video for offline viewing or sharing). That is not the web I want to see in 5/10 year's time, and the way to stop that is to prevent the cracks from appearing.

It's actively harmful to consumers of content producing companies, but only if those companies do not move to DRM free platforms. But because companies ultimately have to make the user experience smooth, forcing them off DRM like this to make a smooth user experience is worth it in my books.


Did Netflix ever support iOS devices without an app or DRM? Since iOS 6, there’s been FairPlay DRM available in Safari – and it added support for time-limited (expiring) keys in iOS 9. In many ways, I’m less worried about DRM and more worried about the value of content as expectations change to prefer free stuff from YouTube etc. Making things easy to watch/share is one of the only ways to compete...


No, Netflix always used DRM (either via an app or via FairPlay).

The argument has a tiny issue in that it's not actually true. At all.


> and when apple decides to drop flash support, what happened? Did netflix or any other video content producer suddenly decide to stop supporting those devices? No, they went with html5 video (and at that time, free of DRM). That was a great step forward for DRM free content for the web.

That's a figment of your imagination. They used DRM in an app store app.


The answer after Apple dropped Flash support was for everyone to use native iOS apps. This is not a good thing in any way, shape or form.

Imagine if Netflix, Hulu etc. could have used the browser, complete with Chromecast/Airplay support. It would save us all so much wasted phone storage and app downloads.


Maybe, just _maybe_ that would have been a viable pressure point to favour non-DRM content* if we were all running Firefox.

As it is, too many people decided they are OK with a google browser. The answer to: "It's cumbersome to use DRM" is to tell your consumers to use Chrome.

* I find this highly questionable. We have an abundance of examples of media companies favouring DRM over user experience. Clearly they think a less smooth experience is a price worth paying.


> abundance of examples of media companies favouring DRM over user experience.

I don't think media companies particularly care about user experience. They care about control.

Once you have a piece of content (which you didn't produce) in your hands, and an exclusive distribution contract to guarantee the content producer can't go elsewhere - you have a monopoly over the content in question. DRM is an abhorrent, if natural, extension of this control-freakery. After all, you don't want to provide consumers control over how they view YOUR[0] precious content.

The ingrateful bastards might find a way to enjoy the content without going through the hoops you've carefully put in place. What good would a monopoly be? As the sole content distributor, the last thing you want is competition.

0: Nope, you still didn't produce it. Someone else did. But now you own it.

EDIT: grammar fix in footnote


> and when apple decides to drop flash support, what happened? Did netflix or any other video content producer suddenly decide to stop supporting those devices? No, they went with html5 video (and at that time, free of DRM). That was a great step forward for DRM free content for the web.

Unambiguously, no, they didn't.

They used applications that had Playready or Adobe Access or Widevine built in, or a little bit later they used Apple FairPlay inside the browser. Some also used root level Apple certificates to limit streams to iOS devices only.

Unambiguously, this argument is factually false.


Flash and Silverlight were low friction. And both are deprecated or unavailable on a lot of players now.

Making DRM harder for the end user is the only effective push-back. It worked for music. It's working for e-Books. It would have worked for movies... if it wasn't for this.


> It's working for e-Books.

How is it working for ebooks, when the leading vendor has introduced more severe DRM?


It didn't work for music either. The industry is now majority distribution via DRM subscription streaming.


Unfortunately, "Get the browser that makes it harder to watch Netflix! On purpose!" is not a winning marketing message.


or, if DRM-free streaming is there, "get netflix on all your devices with a browser, no plugin or installation needed! Netflix everywhere, on your fridge, on your car's video player etc"


> i want DRM to be a difficult and cumbersome stack to use

Exactly. Even flash plugins are too easy, really, so long as flash is ubiquitous. NOW would be the time to hit it, as flash is less common (almost completely absent on mobile) and silverlight is deprecated.

Imagine if Apple and Microsoft and Real had agreed on an easy and ubiquitous plugin framework for music DRM.

We would still be dealing with near-universal DRM for music today.


That's a very principled position but it should not surprise you that any position with 'make things shittier for users' as a key component is unlikely to be well-received by any and all of: standards bodies, browser vendors, content providers, website developers, users, sane people and many others.


Content providers have happily made experience utterly shitty by adding DRM with no regards to users. I don't think they care about your experience a lot.


They seem to care quite a bit. For instance, browser-based DRM and constrained devices have made the experience vastly better than it was just a few years ago. No plugins, you can download content for offline viewing, etc. So I'm not really seeing how they're making it utterly shitty.


How is not being able to download files at all, not being able to just move them to another device and being forced to have a n internet connection to watch HDR Blu-Rays a better experience than just double clicking a mp4 file?


You're not forced the have an internet connection to watch UHD Blu-rays.

The spec allows a disc to require it, but it not a single disc has ever turned it on. It was also in the blu-ray spec, and not a single disc ever turned it on there either.


Only if you use a Popular Platform like Android or Windows.

If you use less popular platforms (Linux, Ubuntu Phone, etc) DRM makes it impossible to access content you paid for.

Also if you Root Android, or modify the "approved" platforms in anyway... BAM the DRM kicks you out of your paid for content as well


Sure, but for the vast majority of users, the experience is much better. You can certainly argue that they should care more about minority users such as yourself (and me, Linux desktop user here), but it's a hard sell when the cost of the development and maintenance effort exceeds the revenue brought in.

I don't think there's a great solution here. Content producers believe that DRM reduces copyright infringement to a level that they're at least somewhat comfortable with. Whether that's true or not is irrelevant; it's how they feel about it that matters. Making playback harder for the average customer isn't in anyone's best interests.


>>it's how they feel about it that matters

Yes and that is how a Technical Standards body should be making decisions, based on people/companies feelings ....

That is filling me with Confidence that the open web is in good hands with the w3c...


This started with someone claiming what should happen is DRM'ed video streaming should be made a difficult and unpleasant experience. Standards bodies and implementors aren't going to do that. What's more, their collective efforts have made the usability better, the availability of content better and as a free bonus, the security is better. That's all.


> DRM'ed video streaming should be made a difficult and unpleasant experience.

why can't DRM'ed video be difficult and unpleasant, but DRM-free videos be made much easier to implement, and have smooth experience for end users?

Why is DRM-free a non-starter? The whole point i wanted to make is that by making DRM'ed video easier to deploy (and consume), it normalizes the fact that _it's DRM_. Why are standards bodies putting in standards that consumers wouldn't ordinarily chooses, and is only meant to appease businesses? Why couldn't they be more socially oriented, such that anti-consumer mechanisms aren't added to an open standard?

Imagine if it weren't DRM, but anti-adblocking? What if the web standards bodies were attempting to prevent adblocking in a browser, in such a way that to be a compliant browser, you can't possibly intercept content? How is that any different to this DRM standard?


it normalizes the fact that _it's DRM_

That ship has long, long sailed and, despite all predictions to the contrary, has actually been pretty good for users. Again, it's you who suggested everyone should stop and shittify the existing user experience that most people like. That's neither realistic nor constructive.


Earlier this year I downloaded a season of a TV show I wanted to catch up on, into Google Play on my tablet. A few weeks later I was on a plane, and finally had a chance to watch them. Google Play had blithely decided to save space (possibly prompted by the OS) and had removed my downloads.

If they weren't DRMed I would have just downloaded them into space I control and there would have been none of this "oh he's not interested" BS guessing.

I deal with this kind of bovine exhaust regularly.

So, hell, no, DRM has NOT IN ANY WAY been good for me. ANYTHING that makes DRM less viable is an absolute good. Period.


If the file wasn't DRMed I'm not seeing why the app or OS wouldn't have decided to do exactly the same thing.


> i want DRM to be a difficult and cumbersome stack to use. More specifically, i want the end user to go through hassle to obtain the proprietary plugins, so that the end user feels the hurt from DRM.

so you want to make stuff like netflix as much of a PITA as possible? why? why be this vindictive?


No, we want to make Netflix pushing DRM as PITA as possible. Video streaming without DRM works just fine.

(And please don't come back with "Netflix has no choice BS", they're happily doing all the nasty DRM crap for their own production as well.)


i agree with netflix, straight up. they invest quite a lot in infrastructure and production to provide these videos, and making it simpler for average folks to get their protected videos in a profitable manner is a win for everyone except idealistic pirates. i don't get why i'd care about the needs of the people who want to ruin a fertile ecosystem for some abstract principle.


With DRM+streaming as default the world will be relying on rights holders and streaming services to preserve an archive of cultural works. A situation that invariably will result in loss of a lot of those works once they stop caring or go out of business.

Consider f.ex. the situation with the missing Dr. Who episodes. BBC is still hopping it can recover copies from the public. Had they'd been aired with DRM at the time they would be lost without hope, now at least there is hope.


> you want to make stuff like netflix as much of a PITA as possible?

Not op but yes, using DRM in a browser should be hard.

Netflix should just make a native app, like everyone else who needs drm do.

This clearly scopes what is open and webby and what is closed and DRMy.

Nobody has issues installing Spotify to stream music. What makes Netflix special?


> Netflix should just make a native app, like everyone else who needs drm do.

The native app security model on desktop (i.e. can do anything) doesn't make the notion of letting streaming services run native apps look so great.

Do you really prefer giving streaming services (not just Netflix but others too) fully-privileged code execution instead of having an operating system or browser vendors exercise some oversight?


Nobody has issues installing Spotify to stream music.

Spotify does have a web player using web DRM (Widevine) and a lot of people use it exclusively.


Netflix chooses to use DRM. That's completely on them.


If you read the EME spec, unless they've changed you're not guaranteed to be able to overlay anything over the EME-provided video rectangle using HTML. The only cross-platform approach is to treat it as an opaque, untouchable area that does not interact with the HTML side of things in any way, like the bad old early days of plugins. Also, at least on Android the playback chain goes through TrustZone code that's effectively running at a higher privilege level than the kernel.


>Video playback only has one code path, instead of totally separate browser and plugin video pipelines. Video codecs are complex, so this means less security attack surface.

Nope. For any effective DRM (aka what all browsers use) the video codec decoding happens inside the DRM module. Otherwise anyone could just patch the open source browser and grab the decrypted compressed content coming out of the module. In reality, they can only grab the decrypted decompressed content.


In the browser I'm most familiar with the internals of: most of the playback logic is done by shared software, and the decode of the video track is done in hardware in the common case, for both encrypted and unencrypted videos. There are some forks in the path but a lot of commonality.


Plus having a single blob responsible for, and only for, the DRM part means that hackers will have an easier time crack that, instead of a whole player. So we should get workarounds quite quickly.


Note that part of standard DRM schemes is also "Computer verification" - e.g. that they refuse to work if your PC doesn't have the correct kernel, drivers or software installed. If you need special drivers to fix compatibility, want to customize your Android or do anything but leave your system full untouched and bloated, might be that you'll be prevented from watching online videos.


To some extend perhaps...

One of the key arguments when Mozilla decided to implement EME was that the crappy-proprietary-code could be sandboxed by firefox to ensure that it doesn't infect a system with malware, spy on users, etc.

From a security perspective it's light years better than flash and other crappy plugins.


I wrote a bug asking Mozilla not to implement HTML5 DRM. It was closed as RESOLVED WONTFIX.

https://bugzilla.mozilla.org/show_bug.cgi?id=923590


And when they did that, the Content providers responded by saying "Ok then we will only allow you access to low quality content" i.e you can only stream upto 1280x720 resolution on firefox, no 1080 content, and no 4K content..

Today that has low impact, in a few years that situation will be untenable for FF and they will be "forced" to cave once again in order to appease users that do not care about privacy or security


But we life to fight another day.

Don't forget that vendors like Netflix aren't proponents of DRM, it complicates their streaming architecture and costs a lot of money.

In a future where Netflix and other streaming services makes up a large part of the profit for content owners, we might see DRM disappearing.

Look at how Apple was able to sell DRM free music because their volume was high.


Before DRM plugins could access anything. Now they live in a sandbox which was not possible when they were NPAPI plugins. So the security story is actually much better as far as I know.

It still sucks to infect the web with this nonsense, but at least it can't do as much evil crap.


Now the DRM plugin can only access the DRM subsystem installed on your machine that has root enough access to verify your files, OS version, and graphics drivers, as well as a callchain allowing them to make draw calls to your GPU driver.


Ultimately, the actual standard of the web is the behavior implemented by major browser vendors.

Assuming the W3C committee voted down the EME standard, at this late point in the game and with no competing standard to satisfy the use case, what stops Google, Mozilla, Apple, and Microsoft from just implementing the standard as-drafted without the W3C's sign-off?

At that point, the browsers will be enabling functionality that browsers that don't implement EME support can't enable, media channels can take advantage of EME-supported encryption modules, users will see less functionality in other browsers and therefore have soft incentive to migrate away from other browsers, and it becomes incumbent upon the W3C to either release documentation describing already-existing browser functionality (as they've so often had to do) or be ever-so-slightly inaccurate as an authoritative source for describing web standards.


Nothing stops them, and in fact each of the major browsers have already implemented EME.


Chrome has been using EME with Netflix since early 2013. This fight was lost years ago.


The point of web standards isn't to stop browsers from implementing anything else. Such a viewpoint is naive, that's not what W3C is.

Back when IExplorer had a 90% market share, you could have argued that ActiveX needs to be a web standard. But it wasn't considered a standard even if it was a de facto one and now ActiveX is gone.

I must be getting old if I'm talking with people that don't remember the browser wars or what web standards are about.


I've been around since the browser wars, and disagree with your characterization here. Standards don't serve marketshare, they are about interoperability and documentation.

A single user-agent technology shouldn't be standardized because that user agent has large marketshare. A tech should be standardized because multiple user agents want to use it, and be interoperable. The ActiveX comparison doesn't make much sense to me.


"User agents" serve the market. The market wanted ActiveX. There were many companies and government institutions requiring ActiveX for their interfaces.

Mozilla could have implemented ActiveX btw, but they took a stand against it.

So by your definition, what does "many" mean? Is it more than one? More than two perhaps? Should it be all of them?

What if I create a browser and announce that it will not support DRM. If market share isn't important, shouldn't this proposal be dropped?

Yes, web standards are about interoperability, but the problem is that DRM being fundamentally broken it means that open source browsers running on open platforms won't be able to "interoperate", which in my book means that this can't be a standard.


I had a long reply, but when I went back and read your original comment, I realized I was just restating a portion of your original comment but with far more words. So I think I'm being unnecessarily contentious.

Standards serve the purpose of when user agents want to interoperate, so Mozilla was definitely ok with not implementing ActiveX, just as they would be ok with not implementing EME.

But if Chrome and Safari and Edge all want to interoperate with EME, they're going to do that. Whether it's a W3C standard or a WHATWG standard, or an RFC, or a IHateFreeSoftworeSociety standard doesn't really matter. It's just whether W3C wants to be part of the conversation or not. I see little benefit and little downside to having it be a W3C standard vs. anything else. Or even for that matter, whether the term "standard" is used; even if it's somehow disallowed it's still the same situation.


Recall that one of the reasons Web SQL was rejected was lack of variation in implementations - pretty much every browser implementation was based on SQLite.


The object element in HTML 4 had some attributes that were pretty ActiveX-specific in practice, so in large part Microsoft got the HTML integration bits for ActiveX into the standard.


> you could have argued that ActiveX needs to be a web standard.

Yep, it is called WebAssembly.


And yet, because it's not "integrated with the operating system", Netflix content providers do not trust Chrome's implementation and thus Chrome users are intentionally given lower-quality video.


A younger version of myself would be against Web DRM, but these days I wonder if there's a potential for it to help in democratizing distribution among indie content producers. Ideally I'd have some time to piece together an essay, but the major points are:

1) Ted Nelson's vision on how Project Xanadu would have some form of copyright protection / micropayments for authors.

2) Independent content creators that have called it quits. There's tons of examples, but here's one that highlights issues: http://www.tonycomstock.com/2011/09/12/why-i-dont-make-movie...

I guess I see a vision where webDRM is an improvement over the walls of 'Apps' where content may not be DRM-free, but at least be linkable/URL-addressable.

(Disclaimer: I'm writing this without actually reading into the WebDRM spec, so feel free to criticize)


As far as I know/talked to Indies/helped some, no.

#1 on most of their lists is getting the music/name out. DRM is counterproductive.


How much of this is a result of the predatory music industry where musicians typically never see anything from album sales anyway?


Has DRM ever actually stopped piracy?


The one example I have ever seen is Denuvo DRM for PC games, in certain games for (very) limited times.

Denuvo has gained widespread adoption among AAA game publishers because it tends to hold for the critical period when a game first goes on sale. The DRM is typically broken within weeks but that is good enough for the publisher, as the release period has generally passed by that point. They made their sales.


I think we should distinguish interactive things like games from the sort of title that's copyable via the 'analog hole' -- for movies/songs/books, effective DRM is incompatible with human liberty, but I don't have that problem with DRMed games.

(This isn't to argue in favor of DRM on the web. It ought to stay in its restricted-device ghetto.)


From a sales standpoint, I don't see the distinction. If DRM of movies is broken past the initial sale craze, and the content producers feel they've made their money before it gets broken, then they'll certainly feel that it's been a value-add for their business.

If web-based DRM actually does remove the browser as an attack vector entirely, and the majority of copyright infringement occurs in other places (studio leaks, etc.), then the content producers might see that as acceptable.

Regardless of all that, I think the distinction is more a philosophical one: you seem to believe that the creative output involved in a game is more reasonable to protect than the creative output involved in a movie, just because of the method of consumption. I think the "human liberty" aspect is a bit much, as well: why do you think you're entitled to the content (on "your terms") that someone else has labored to create?

We can certainly argue (and probably agree) that things like copyright terms are effectively unlimited and that's wrong, and even if they were limited, DRM doesn't give you the ability to get at the content DRM-free after copyright has expired. But I don't see it as unreasonable that a content producer should be able to use technical means to protect their content for a period of time after initial distribution. I think the current implementations of DRM leave a ton to be desired, but I think the concept is sound.

I think overall, though, it's a matter of market forces. People consume "pirated" content because either they can't get the content and consume it in a manner that they want to (and feel strongly enough about that to not settle for the "approved" channel), or people pirate things because they believe the price is too high for a legit copy (and then there are those who just won't pay anything at all, no matter what the price). DRM for music purchases has been largely dropped because people are happy enough with the distribution channels and price that they usually don't look for pirated copies, at least not to the extent that makes the content producers nervous. Will we eventually get to the same place with video? I don't know.


> If DRM of movies is broken past the initial sale craze

What you're missing is that this delay is fundamentally impossible. The day a movie is available, it will be ripped, no matter how good the DRM is.

Game DRM can hold people off, because the game actually has to run once pirated. Game DRM has to be broken. Movie/audio DRM doesn't have to be broken; it can be ignored entirely by pirates.


The distinction I'm drawing is that to consume a movie (etc.) you need the images to make it into your brain; OTOH a game can be played without its code ever leaving the device. To effectively stop people from saving the images means stopping freedom of thought; that's different from "I'll rent you this program only on this closed tamper-resistant platform" which doesn't claim a right to control what happens in your own brain. Maybe it's clearer if you think of a cochlear implant -- should it be against the law for me to run my own software on my own cochlear implant? Fuck no. Likewise for future cognitive prostheses. So DRM can't be more than a tiny speedbump to a person wanting to copy a movie, in a free society; but it might still work for things like games, if sellers can keep convincing people to accept good-enough DRM platforms.

When it comes to suing someone for distributing a work they copied, like you I don't see a difference between a game and a movie.

(added: I dunno why you were downvoted.)


No, but maybe we need to look at it from relative numbers.

Example: DRM music hasn't stopped music piracy, but better models for the content distribution (i.e. DRM music platforms like spotify, etc.) have demotivated more people from bothering to pirate music.


The fact that spotify has DRM is inconsequential to it, and those like it stomping out a ton of music piracy. It's all about the distribution model, and the DRM is just to make the rights holders happy.


But Spotify is a native app.

It can have all the drm it wants. It's not part of the open web.


I always listen to spotify through web browser. I think it uses flash then.


A big problem with piracy is that piracy tech hasn't advanced in 2 decades, whereas the rest of the world has moved on. There are two major challenges. Due to DMCA, anonymity is a major obstacle for which there isn't a good solution yet. TOR, vpns etc. aren't well suited for content distribution. Second, the bittorrent model itself doesn't work very well for streaming.


"Second, the bittorrent model itself doesn't work very well for streaming."

Wrong. It works incredibly well. That's why the anti-piracy companies are all up in arms over things like PopcornTime. All you need are a couple of other people to download from. Hell, there's whole pieces of software whose whole purpose it is to stream torrents and they do it extremely well. Nothing even compares to the video quality, which is the same as if you downloaded the file ahead of time.

"TOR, vpns etc. aren't well suited for content distribution."

WTF does this mean? You can't distribute content over Tor or VPNs? I only do it every single fucking day without any problems and with ease.

"Due to DMCA, anonymity is a major obstacle for which there isn't a good solution yet."

The DMCA created anonymity? Whatever, I'm not even going to try to understand this one.


>The DMCA created anonymity? Whatever, I'm not even going to try to understand this one

Not sure if you are trying to be intentionally dense. Have you heard of DMCA notices ? You get them if your IP is in the swarm, and are uploading copyrighted content. Hence the need for anonymity.

>WTF does this mean? You can't distribute content over Tor or VPNs?

Again, you seem to like being thick for no reason. You can distribute content over every medium imaginable. That doesn't make it the best or an efficient medium.

>Wrong. It works incredibly well.

You can't have adaptive streaming bitrates. The tracker model still relies on a central tracker. Magnet links solve some of those issues, but not everything. There are still some things that are, or would be better off, being centralised. There are several limitations that we don't need to go into length, but it's a far cry from incredible.


Sure. Try pirating Reason or Cubase for one...


I've pirated Reason on occasion. Not lately, though.


Yes, but not after they've added the dongle protection (and new (driver based?) check system).


Other software with dongle-based protection has been pirated in the past. There will almost certainly be ways of circumventing this protection if software crackers want to do it.


I can't fathom a reason why "software crackers" don't want to do Cubase and/or Reason though.

The thing is, those "dongle-based protection" have been pirated in the past only in the rare cases where an issue was found in the dongle scheme or keys where leaked, etc. And those don't happen frequently -- whereas any old school copy protection method was broken a few days/weeks at most post release (sometimes even before release, from the demo/alpha versions).

Hasn't happened in 5-10 years for lots of physical key based products, so even if possible again, it's of theoritical and not practical value (we ain't seeing them anytime soon).


Fravia said, very roughly, that some of the dongle systems were secure, but the implementation by software vendors was often lousy.

I guess they've stopped being lousy at the implementation.


Had to look who Fravia is (or was) -- interesting stuff.


>democratizing distribution among indie content producers

So I have this idea for a video/audio streaming website that operates like an open market. Website operator makes a cut for infrastructure costs. Other than that, the site runs pretty much on its own. No content deals, no drm, no geo restrictions, no ads. Some safeguards to limit abuse. A producer puts up content. Consumers consume content. Revenues are split between producers using some fair and transparent proportionality metric. Would there be any appetite for such a model ?


https://www.collide.com

Not sure if it fulfills everything and I like your model better.


> no drm > no ads > revenues

Does not compute.


so Patreon plus content hosting?


Patreon is more about supporting individual projects. I'm thinking more like netflix/spotify + youtube + ebay. As an end user, you still pay some monthly fees. The total money is divided up between all the producers using some metric minus operating costs. As a producer, your job is pretty much clicking on upload.


What many people that are on the periphery of this discussion sometimes fail to realize is that DRM is already here and already employed by many companies. The current DRM solutions are basically roll-your-own and each company has their own custom stuff which may or may not be vulnerable to attacks and steal/fingerprint the user thus affecting their privacy. This is the current state of things.

The EME/DRM spec is a bit different in which we still have DRM and it still sucks, but this DRM is now running on a sandbox environment and is standardized which makes it much easier to audit and a lot safer to use in terms of privacy for the user.

Of course "no DRM" is a better solution than "any DRM", but that is a pointless debate because content distributors are already onboard with DRM and there is no turning them back. The W3C spec is a compromise, a solution that enables those wanting to use DRM to be able to do so while we maintain some method of sandbox, privacy and safety. Running a module in EME/DRM is probably much safer than doing the same thing now with custom browser plugins.

As for the discussion of "browser X should not implement it, traitors!!!! Hate you forever!!! Will switch to $MORE_PROPRIETARY_ALTERNATIVE" is also a shortsighted argument in my opinion. If a browser doesn't implement EME/DRM spec, they shut their users out from being able to use many websites that employ DRM and what will happen is that that browser will loose users. If every single browser said "no to DRM" except for a single one, you'd see everyone installing that browser just to be able to play Netflix.

No browser can afford to loose millions of users by not implementing the spec. Those users matters. In terms of browser vendor political weight in spec discussions, user count matters. The DRM battle is a lost one because the content producers/distributors already decided to use it.

Now, if you're against DRM, instead of complaining about W3C spec'ing it out and browser vendors implementing it. You should stop using DRM content. No one is stopping anyone from preferring non-DRM solutions. For example, I don't like light beer, the existence of light beer sounds wrong for me, so I don't drink it but I don't try to stop others from drinking said watery yellow-ish drink. It is the same thing with DRM, instead of focusing your actions on W3C and browser vendors, focus your effort in content producers/distributors, prefer other solutions, make them ponder if it is worth loosing you.


>>but this DRM is now running on a sandbox environment

I see this said many times, and it is highly over rated. while Technically speaking yes it calls for a "sandbox" but the need for "Computer Verification" means the CDM has to have full access to the entire system to verify the evil user is not attempting to capture the output. So the sandbox is not really protecting much unless the operating system itself has the CDM integrated as is the case for Windows. So on windows the CDM might be in a functional sandbox but on linux or any other non-proprietary system it is unlikely the sandbox will protect the user from a bad CDM, and given windows track record for security I would not put much faith in their sandbox either.

On the security front I do not believe it has changed much, this idea that the CDM will be more secure seems to be more PR Marketing than actual fact. Further given the refusal of companies to sign onto a Non-Aggression Pledge to protect researchers from DMCA liability it is likely any security issues in the CDM's will go unreported for fear of legal repercussions.

>>>Now, if you're against DRM, instead of complaining about W3C spec'ing it out and browser vendors implementing it. You should stop using DRM content.

Why can a person not do both? Why does a person that has ethical problems with DRM, and view the actual existence of DRM is a threat to their personal liberty be silenced or told to STFU as you have here?

Bad ideas, like DRM, should be continually criticized until they are dead. Vocal opposition as well as monetary boycotts are both valid and should be used to oppose bad ideas like DRM

One of the reason people are opposing video DRM so strongly at the w3c level is we fear it will not stop with Video. Images, Ebooks, Fonts even the web pages themselves are all a target for DRM Supporters. There will come a time that the F12 tools will be useless because the entire page itself is being served via a locked down CDM style plugin. This is just the first phase of killing the Open Web in its entirety


Regarding the sandbox, that's not correct on all browsers:

[I]n Firefox the sandbox prohibits the CDM from fingerprinting the user’s device. Instead, the CDM asks the sandbox to supply a per-device unique identifier. This sandbox-generated unique identifier allows the CDM to bind content to a single device as the content industry insists on, but it does so without revealing additional information about the user or the user’s device. In addition, we vary this unique identifier per site (each site is presented a different device identifier) to make it more difficult to track users across sites with this identifier.

https://hacks.mozilla.org/2014/05/reconciling-mozillas-missi...


A lot has changed since 2014, including the adoption of Google Widevine CDM over Adobe Access CDM.

The sandbox has also changed as have the requirements from vendors and content provider. and while firefox has protected the user better than others, this is also why Firefox is restricted to 720p by all content providers and will likely never get anything more than 720p because they do not allow the deep Operating system inspection and bypasses required to allow for HD and 4K content.

Currently only MS PlayReady on windows 10 is allowed to play back Netflix 4K content because PlayReady is built into the Operating System and treats the User as the enemy.

Mozilla in their ever ending chase to recover some market share has proven time and time again they will sacrifice privacy, and their more Technical User base in order to keep up with Chrome and get back some "regular users" So if Netflix says "We will give you HD content if you drop the sandbox and give widevine full access to the users system" I have little reason to believe Mozilla will not say "Yes Sir Mr. Hastings, anything you want"


DRM is a non-starter and is in reality defective by design.

Pirates have created markets where there were none and are an important part of every entertainment eco-system. It's been that way since the beginning.

This is just another in a long string of bad decisions that attempts to give major distribution channels far more control than they deserve or could ever manage responsibly.

If you want to make money in entertainment, the business plan is simple. 1. Get people to like you. 2. Find a way for those people to get you money. You don't need Google, Netflix, Apple, NBC, CBS, ABC, RKO, ClearChannel, or anybody else that inserts themselves between you and your customers. None of them provides enough real value to anybody who didn't already have a market before leveraging them.

The fact that this standard is coming to be is just plain silly, but it does no harm in and of itself. All of the potential problems are today's reality. A rubber stamp by W3C implementing a tag in the HTML spec and blessing a workflow change nothing.

The FSF is stirring up noise without providing links to what it's talking about. I presume it's this: https://www.w3.org/TR/encrypted-media/

The workflow isn't particularly well thought out - it's not significantly different than what RealMedia or Adobe have had put together for a generation.

The real downside is the fact that browsers will be further plagued with vague integrations. Those integrations will all carry security ramifications that nobody cares to consider until a major exploit is publicized. The fact that so many people are willing to sacrifice their security for access to a 12 year old lionsgate video is beyond me, but such is the nature of the world we live in. Like I said before though... that is a problem that browsers face today. The new "standard" doesn't change much in reality.


> The fact that this standard is coming to be is just plain silly, but it does no harm in and of itself.

I disagree that it does no harm. I agree with this quote from the article:

"If EME is ratified by the W3C, the FSF expects it to cause a long-term increase in the amount of DRM on the Web, by simplifying the DRM implementation process for streaming services."

Standardization is explicit support and encouragement.


Forgive me for having a differing opinion, but just to clarify.

I would agree with the FSF statement that there will be more DRM on the web.

Where I differ is that I believe it would happen regardless. If it's not standard DRM, then it's Apple DRM and Windows DRM... like we already have.

> Standardization is explicit support and encouragement.

Standardization shouldn't be about good or bad. If enough people want to do something, there should be a standard.

Having said all of that, please don't get me wrong. I'm just clarifying how I feel. I do tend to have unpopular opinions. I don't have a dog in the race and I would be perfectly OK with DRM in general being rejected by the W3C because it is a terrible concept that ends up being paid for by consumers.


> If it's not standard DRM, then it's Apple DRM and Windows DRM... like we already have.

which is fragmentation, and bad for businesses that want DRM, but don't want to _pay_ the cost of fragmentation. By adding it to an open standard, they no longer need to deal with end fragmentation (which causes end user a bad experience). But the solution was never to standardize on DRM, but to standardize on _non-DRM_ formats! The pirates can obtain content regardless - DRM only hurts consumers in the long run.


This standard doesn't actually define any DRM formats, each EME module supports whatever formats it wants.


> DRM is a non-starter… […] The fact that this standard is coming to be is just plain silly, but it does no harm in and of itself.

If that's true, for you and for others who share that opinion, what does it matter?

> None of them provides enough real value to anybody who didn't already have a market before leveraging them.

It's hard to take a position like "digital distributors offer no value" seriously when the paid digital media marketplace was created by said distributors.


> If that's true, for you and for others who share that opinion, what does it matter?

I don't have a dog in the race. For me, it doesn't. The world would be a better place without DRM and it would be a better place without TSA, but I can do nothing about either.

> It's hard to take a position like "digital distributors offer no value" seriously when the paid digital media marketplace was created by said distributors.

The market was created by Napster and it's cousins. The ability to hand over money was a matter of getting the music labels and movie studios on board - and half of them are still reluctant participants at this point. Anybody can give them money. None of them provides exclusive access to a customer base, and none of them provide a significant boost to sales for products without their own separate marketing.

There's a "Netflix for..." so many different markets because all you need to do is sign a contract with the studios for access to media which they'll deliver directly to customers themselves.

During the time when Tower Records or Target actually provided access to customers that nobody else could provide, the distribution channels were valuable. Now what they accomplish is a simple and easily repeatable commodity.


Everything that I have read suggests that this is standardizing what has already happened with video, which is a great deal better than the bad old days when companies relied upon Macromedia/Adobe for video streaming. (Or worse, a plug-in from an obscure company with an unknown track record).

As much as I would like to avoid DRM, relatively few producers are going to budge on the issue. The only options are standardized DRM, non-standardized extensions to provide DRM, or simply doing without. None of the options are particularly desirable. This one is likely the best of the three.


The standard argument against this says that while every bug, security breach and inconvenience that arises due to the alternative (non-standardised, proprietary DRM, or no in-browser DRM at all) may individually make engineers thinking about the system from an engineering standpoint break out in hives, the discomfort will also be felt by end users and associated with DRM, therefore serving as an obstacle to its public acceptance and proliferation.

As a relevant comparison, I think the current situation with the plethora of proprietary video game DRM solutions that are universally recognised to be terrible is strictly preferable to an alternative world in which video game DRM Just Works™, possibly with hardware support: in no small part thanks to it, we have a healthy amount of pressure on game studios to hold back and a market for DRM-free publishers such as GOG, and perhaps more controversially a healthy piracy ecosystem to punish the worst actors in the market.


Exactly, not all tough problems have to be solved. In this case we probably should optimise for choice rather than an elegant system!


> This one is likely the best of the three.

I don't agree. Ignoring the massive injustice of ramming proprietary extensions into an open standard, standardising DRM has several secondary detriments to the free culture movement. In fact, standardising EME might actually be the worst of the three choices (the best being no DRM of course). Non-standard extensions are better to the movement (though still disastrous) than standardised ones, and here's why.

The most serious one is that it will appear to be far more convenient. One of the man ways that we could appeal to users who didn't particularly care about their software freedom being trampled on by corporations is that the method they used to trample on their freedoms were inelegant. Your monitor would flicker (and software would break) when it went to HDCP mode, Netflix might break every once in a while, Flash websites always were incredibly buggy. Meanwhile, VLC and family always just worked. Now, EME will make this experience "more seamless" which is a huge downside because now users won't even be aware of how many of their freedoms are being taken away.

The second is that now DRM is more appealing than it might've been 5 years ago. DRM isn't some horrible Flash applet that nobody understands the inner workings of, and when it breaks then you just have to deal with it. It's a standardised system around which more cabals will form. It's not something that just the AAC conspiracy operates around, it's far more accessible. If you thought that Blu-Ray was insane, you've seen nothing yet.

Every Flash vulnerability was a reminder that the status quo was not acceptable. Sure, the reminder came about for the wrong reasons (it turns out the pawns behind a conspiracy aren't generally very good at conspiring), but it came nonetheless. Now that EME will presumably be secure enough, all of these secondary issues that acted as entry-points for people to learn about how badly they are being mistreated will no longer be accessible. "Who needs a copy of their data when you can just stream it with a proprietary player that probably tracks you?"


It's a bit tough to argue we should keep computers insecure and hope people get annoyed and change their minds. Keeping people's computers safe is a primary goal of browser vendors, and this improves that state of affairs. Sure, DRM sucks, but at least the vendors can't root your machine and install keyloggers now.


I completely agree that it's tough to argue for user freedom in a world where widestream education about software freedom is non-existent. But we don't live in a world where users are aware of the importance of software freedom, so it's necessary to use secondary inconveniences to alert them to the primary injustices.

Maybe this comes from a lack of technical literacy. Maybe it comes from the fact that Microsoft and other large corporations indoctrinate children into thinking that proprietary software is acceptable. I don't know, and that is another front that needs to be fought.

However this is only one of the detriments that I listed of standardising EME.

> Keeping people's computers safe is a primary goal of browser vendors, and this improves that state of affairs.

It's unfortunate that this is the case. Don't get me wrong, security is very important, but security should not be the primary goal. The primary goal should be user freedom, with all other goals secondary.

To butcher a quote, "Those who would give up freedom, to purchase a little temporary security, deserve neither freedom nor security."

> Sure, DRM sucks, but at least the vendors can't root your machine and install keyloggers now.

Why are we as a community saying that corporations are allowed to piggyback on the hard work of the free software community to entrap users? Just because they might not be able to repeat their previous unethical and illegal actions such as installing rootkits (which I'm not sure I agree is accurate).


Why are we as a community saying that corporations are allowed to piggyback on the hard work of the free software community

What work of the free software community? Except for Firefox, all browsers with any market share are developed by big corporations.


I feel like you may have forgotten Firefox's role in history. Firefox unambiguously saved the world from Microsoft taking control of the web.

Not to mention that Chromium is a free sofware project. It doesn't matter that the largest contributor is Google (it does for the top-level discussion of why the hell did Chromium implement this), the project itself is free software and is thus part of the free software community.


I feel like you may have forgotten Firefox's role in history. Firefox unambiguously saved the world from Microsoft taking control of the web.

I don't necessarily disagree, but I don't see how that's relevant to "bigcorps piggybacking on the work by the free software community". I'm pretty sure media corps would be fine with an IE world.

Not to mention that Chromium is a free sofware project. It doesn't matter that the largest contributor is Google (it does for the top-level discussion of why the hell did Chromium implement this), the project itself is free software and is thus part of the free software community.

Chromium is developed by the work paid by bigcorps, not by the free software community. The code being open source doesn't change this.


> I'm pretty sure media corps would be fine with an IE world.

But that's not the world we live in. We live in a world where Firefox saved the web, Chrom{e,ium} has changed it as well (though they have done plenty of things I think are horrible). In _that world_, they are trying to piggyback off the current state of the web's open standards by adding extensions that will only work because the same browsers that made the web what it is today are now forced to implement EME.

> Chromium is developed by the work paid by bigcorps, not by the free software community. The code being open source doesn't change this.

By that logic, Linux is not developed by the free software community (80% of kernel development is done by developers paid by companies -- which I think is great).


> Keeping people's computers safe is a primary goal of browser vendors

I disagree with that goal being primary when it comes at the expense of user freedoms.

I for one prefer taking a small risk rather than living in some dystopia where all software must either run in crippled sandboxes or be approved by the central ruling committee for trusted computing.


I disagree. "Doing without" seems the most sensible to me.

There is no rule that industries whose business is built on copyright need to be able to live in the browser. Netflix demonstrated that quite nicely. Just because the want it doesn't mean they should get it. I personally cripple EME on my browsers, and if your content won't display for me, I'll happily go elsewhere. (Haven't had the problem yet, but fully expect to.)

It is bad enough, but unsurprising, that the closed browsers would go along with user-hostile bullshit like this. That Mozilla did, I find appalling.


Well, "doing without" is certainly the principled stand. But there is a lot of (almost certain, moderate) pleasure hiding behind one of door #1 (EME) or door #2 (torrent), and it is difficult indeed to go through door #3, (not this pleasure).


I fully expect torrenting to be made impossible or obscenely impractical and cumbersome inside the next couple decades. The rightsholders are too politically connected, and the general populace too apathetic and ignorant.


For doing without to work, all browsers must agree to do without. As soon as one browser ships it and people prefer browsers that can stream Netflix, everyone else must follow suit or wallow in obscurity.

Microsoft and Google make CDMs; no one else had a chance in this fight.


If I follow, you're implying browsers that hypothetically refused to work with Netflix's DRM would wallow in obscurity.

While probably correct since the majority of users do seem to like Netflix, others ignore Netflix and get their media through, shall we say more "obscure" sources. Such an obscure browser would seem to suit their needs just fine. Tor Browser doesn't need to be popular among the masses for those who use it to find lots of value in using it, for example.


I think you're missing the point here: the minority of users simply do not matter. If Mozilla wants Firefox to remain a browser with large market share, it must implement standards that allow DRM. And that's what they want. They don't want to be obscure like Tor Browser. They want to be popular, and they want to have political clout and influence over standards bodies.

That doesn't remove the ability of a minority of users to use something different and make use of the more "obscure" sources, but it does allow the majority of non-technical users who don't care one bit about all this to play the content they want, and in a way that protects their security much better than the old plugin-based approach.


But the web is the one in the position of power here. Media wants badly to be on the web--it's not the web that badly wants media.

Imagine if, back in the 90s, bigcorp still-image licensors like Getty or Bridgeman were able to magically foresee how big the internet was going to be. They campaign hard to include a DRM standard into the 90s web, so that nobody could right click and "save as" images from the web. After all, their bread-and-butter is licensing images. They succeed, and now it's the 90s, the web is in its infancy, and nobody can share or save images.

How would have the web evolved differently, if that was the case? I think most of us would agree that this would have put a terrible stranglehold on the evolution of the web as a technology and the web as a cultural force.

We're in a similar position today. Video is fairly new to the web, and bigcorp see how important a deal the web is. Instead of us making a stand and demanding the same freedom we got with images (freedom we largely received because of a combination of ignorance and benign neglect), we've caved and allowed videos to be locked away. Now we'll never see how the web could have evolved if anyone could have right click "saved as" a video.


I feel like that case was true back when this fight actually mattered. These days people use native-ish apps on iPads and smart TVs and not just laptops. So I think there is less market power on the web's side than there used to be.

Google and Microsoft both sell the CDMs (content decryption modules, ie, the actual DRM components used in EME), and it was certainly a benefit they touted for consumers before Firefox had an implementation as well.

Now anyone who wants to make a web browser must pay to play, and the people you pay are your competitors. Even if you could write your own CDM and get it ceritifed/trusted or whatever, you'd still have to convince every DRM-using video provider to also use it in addition to the others, which is going to be a very tough sell. And of course, it may be that no one wants to license a CDM to you to start with, and now part of the web is closed off to your users.


There's no "web" vs "bigcorp". There's only bigcorp vs a motley bunch of weirdos like us, Mozilla, FSF and so. And they control 80%+ of the browser share.


> relatively few producers are going to budge on the issue

They would budge if they had to - what are they going to do, stop selling their only product to paying customers out of spite? But of course it doesn't cost them anything to bluff, and they are used to get their way far beyond what their importance merits.


I, for one, am perfectly happy not giving money to companies enforcing DRM. If only 1/10 to 1/5 of the population cared (which will never happen), I'm sure we would see a major change in attitude from media companies.


Can EME prevent people from doing 30fps screengrabs of their screen and dump all into an mp4 file using FFmpeg or such?

As someone else pointed here:

> You can't simultaneously give us the content and not give us the content.


The server can send an encrypted blob to your browser which hands it off to the DRM module which can hand it off to the system's ring -2 PAVP/Trustzone/etc. stuff that only runs signed firmware which passes it encrypted over the PCIe bus to the gfx hardware which passes it encrypted via HDCP2 to the monitor.

So in principle fully encrypted paths that can'e be screengrabbed exist. Not all DRM makes use of those components because it excludes users which don't hardware which supports it. But it is there.


Thanks for the detailed description.

> .. which passes it encrypted via HDCP2 to the monitor.

And where does the decryption actually takes place?

> EDIT

https://en.wikipedia.org/wiki/High-bandwidth_Digital_Content...

> In order to make a device that plays HDCP-enabled work, the manufacturer must obtain a license from Intel subsidiary Digital Content Protection LLC, pay an annual fee, and submit to various conditions.[5][6][7] For example, the device cannot be designed to copy; it must "frustrate attempts to defeat the content protection requirements";[7] it must not transmit high definition protected video to non-HDCP receivers; and DVD-Audio works can be played only at CD-audio quality[7] by non-HDCP digital audio outputs (analog audio outputs have no quality limits).

This sounds quite far-fetched though. I'm quite sure we're going to see people literally recording their TV screen with a hand-camera soon.

How about the case where the hardware doesn't support it. Would screen-grabbing be possible then? Where will the decryption take place in that case?


> How about the case where the hardware doesn't support it. Would screen-grabbing be possible then? Where will the decryption take place in that case?

There essentially are several tiers of DRM

  - hardware-assisted encrypted pipelines (described above)
  - kernel module assisted
  - pure userspace obfuscated code
If it's in userspace, such as some software DVD players or game DRM then you can use a debugger to dump the keys or maybe hook some method that sends the frames to the gfx card.

If it's kernel-assisted you would have to bypass kernel module signing and hook deep into the operating system because the OS will also prevent screengrabbing of the protected surface.

If it is hardware assisted you will have to find a flaw somewhere in the pipeline or buy devices that contain decryption chips that basically are repurposed official decryption chips.


> How about the case where the hardware doesn't support it. Would screen-grabbing be possible then? Where will the decryption take place in that case?

You don't get the content then. Full stop.


With many providers, you do still get the content, just limited to 480p.


You can screengrab at the interface between the decoder in the monitor and the panel itself, using an LVDS capture card. Not cheap at the moment, and you still have to process the gigabits per second of uncompressed video, but you can expect the Chinese to come up with some inventive and low-cost solutions if they start locking down the other routes... in fact a lot of DRM-stripping hardware already exists for sale, if you know where and what to look for.


But what about literally recording your screen with a hand-camera? That would be quite tech-proof right? It's been done in cinemas for decades.


With a bit more dedication and electro knowledge, I'm sure one could open up a screen and capture the data straight from the output circuit. Few people can do this, but piracy doesn't need more than one source to be distributed over the world.


>So in principle fully encrypted paths that can'e be screengrabbed exist

This is the worrying part. While DRM has always existed, it has always been possible to defeat it largely because any software can be reverse engineered. Once you get down to the processor, it's close to impossible. And it's not like we have a lot of processor companies.


If the W3C does this, it will be time -- regrettably -- to turn away from that organisation and make a completely new one that exists to serve users of the Web rather than those seeking to monetise it. That Tim Berners-Lee has lent his name to this hijacking is shameful.


How are we to deal with the problem that the browser developers are also on the side of monetization?


How do you propose that your new utopian organization actually get its standards implemented by user agents?

The only time there has been a half successful splintering off of the W3C was WHATWG, and WHATWG only worked because it was backed by the browser vendors themselves.


I don't understand the point of WebDRM.

You can't simultaneously give us the content and not give us the content.

WebDRM is broken by default and pushing it is just absolutely retarded.


As dumb and broken as it is, the state of the world is such that you can't deliver most video without something like it.

So the options are:

1. Stick to your guns and keep it out of the standard, free browsers will be unable to play Netflix, Hulu, HBOGo, BBC, etc... Propriety plugins that only work on one browser and/or one platform will exist and be annoying and buggy.

2. Give in and allow this braindamage in the standard because it means most browsers will be able to support video streaming from most sites.

3. Convince the MPAA and all of their members and all of the worldwide organizations like it that DRM is bad and that they should stop demanding it.

In the realm of what the W3C can accomplish, #2 seems like the least worst solution.


Option 1 is the best because playing DRM content should be Netflix's problem.

Why in the world would you want to subsidize Netflix's development?

So what if Netflix's DRM plugin would be proprietary and buggy? Heck, that's a window of opportunity for DRM-free competition.

By making it a standard it means that we'll never, ever get rid of it. Even if DRM is fundamentally flawed.

#2 is in fact the worst solution.


> Option 1 is the best because playing DRM content should be Netflix's problem.

By not making it a standard we'll make sure that Neflix never, ever comes to Linux. That guarantees that proprietary operating systems, browsers and hardware will always be prevalent.

> By making it a standard it means that we'll never, ever get rid of it.

<marquee> and <blink> were standards. NPAPI was a quasi-standard.

Black-and-white worldviews are often accurate albeit negligently unrealistic.


> By not making it a standard we'll make sure that Neflix never, ever comes to Linux.

Netflix already works on Linux, with Chrome and Firefox: https://help.netflix.com/en/node/23742

It uses EME with closed-source CDMs bundled with the browser (Chrome) or downloaded by the browser (Firefox).


My understanding is that it's using basically what the W3C is now considering. The browser manufacturers already decided on this months ago and implemented it. Now the question is if it becomes part of the standard so there aren't annoying differences between each browser.


> By not making it a standard we'll make sure that Neflix never, ever comes to Linux.

Isn't the EME a system binary that would be specific to each platform? There's no guarantee tat they'll be a linux one for each provider.


Agreed. However, Widevine is Google's thing and it's plausible that they'd ship it with some non-free build of Chrome. Unless they're worried about trusting the OS, in which case my original argument is void.


Plausible sure. anyone using any other plugin is also plausible, though much less likely.

The point is since it's not standard Linux and BSD will get the shaft.


Wildvine works on Linux today.


And other plugins that other providers might choose to use?


In most browsers, they aren't actually plugins in the typical sense. As far as I'm aware, Chrome doesn't allow any other EME modules to be installed, so if a provider wants to work with Chrome they must support Widevine.


Put yourself in the shoes of a browser dev faced with a torrent of angry users asking why you "broke Netflix". They won't listen to what seems like a wishy-washy response about the principles of "the open Internet", all they will care about is that they had Netflix and now they don't and it's your fault.

Devil's advocate, I'm no fan of DRM, but from the end user's point of view, it's a necessity.


If (in an ideal world) Chrome and Firefox had said "no, we aren't implementing it" then it falls back to Netflix to stop harming users. And they need to make business so they'll make a crappy SilverLight client that breaks every other week. It's not the browser developers' fault that a several million dollar company decided to build their business model around the need for DRM.

The biggest problem with taking the principled stand is that you run into the prisoner's dilemma. And every CS student can tell you that the game theory says you should always defect, if the other parties are adversarial.

I think the biggest problem in the "browser game" is that the different free browsers often see each other as enemies and not as friendly competition. It's a shame because monocultures are what almost killed the internet in the early days, and I don't understand why we're heading back to ActiveX.


In an ideal world nobody would want DRM. In the real world, Chrome and Firefox are not part of the same team, and never were. Google is a media distribution platform like Netflix (YouTube, Play, etc), and like them, they have zero interest in pissing off producers based on lofty ideals.


It boils down to what is more important for user: will they change browser to play DRMed videos or switch video provider to one without DRM. Not supporting EME in browser with falling usage (Firefox) is likely suicide, but W3C doesn't make browsers and can take any ideological position without consequences.


#2 is the worst solution if you care about principles over end user experience. Most organizations and corporations do not prioritize things that way.


Free browsers can't play Netflix anyway, because EME is just a standardized interface to a proprietary CDM, which one must license from a vendor (Microsoft of Google mostly).

What giving in achieved is a reasonable security story around the CDM module as opposed to the free for all of NPAPI plugins. It still totally sucks, but at least hte capabilities of these CDMs are quite limited.


> You can't simultaneously give us the content and not give us the content.

You actually mostly can, today, and "mostly" is good enough for the content producers.

If you have a DRM pipeline that has software and hardware that validates that it hasn't been tampered with (which is absolutely possible with today's technology), then the best an "attacker" can do is point a camera at the display device (and live with the reduced quality that brings), at least not without spending a ton of money on expensive hardware to defeat this.

And as another poster pointed out, DRM isn't really about protecting content from piracy, it's more about content producers having leverage over the people who make content-consumption technology. And it's working quite well for them for that purpose.


The best answer I know to this was written by Hixie (main editor of the HTML spec) a few years back:

https://plus.google.com/+IanHickson/posts/iPmatxBYuj2


“Under the spreading chestnut tree I sold you and you sold me"

Orwell, 1984 - A very sad day, a very poor decision:

"Today, the W3C announced that it would publish its DRM standard with no protections and no compromises at all, stating that W3C Director Tim Berners-Lee had concluded that the objections raised "had already been addressed" or that they were "overruled."

"EFF understood that the W3C had members who wanted to make DRM, so we suggested a compromise: a covenant, modeled on the existing W3C member-agreement, that would require members to make a binding promise only to use the law to attack people who infringed copyright, and to leave people alone if they bypassed DRM for legal reasons, like making W3C-standardized video more accessible for people with disabilities.

This was a very popular idea. It was endorsed by Unesco, by the Internet Archive, by the creator of the W3C's existing membership agreement, by hundreds of top security researchers, by the competition expert who coined the term "Net Neutrality", and by hundreds of human rights organizations and activists from the global south. The Open Source Initiative amended its definition of "open standard" so that DRM standards could only qualify as a "open" if they protected legitimate activity.

Now, it's fair to say that the W3C's DRM advocates didn't like the idea. After a perfunctory discussion process (during which some progress was made), they walked away from the negotiations, and the W3C decided to allow the standardization work to continue despite their unwillingness to compromise."[1]

https://www.eff.org/deeplinks/2017/07/amid-unprecedented-con...


I have only had one long conversation with TBL, but he appears at least to me to have his heart in the right place. I met him at the Decentralized Web Conference June 2016.

I want two things, at least, from the web:

1. An open platform where I can post content on my own web site, link to other people's web sites, and let them link to my sites.

2. I like to buy access to entertainment: Google Play Music and Movies, Netflix, Hulu, and HBO Now.

Ideally I should be able to have both of theses modes of using the web, and people who don't want DRM should be able to disable DRM and rent Bluray movies, check movies out of their local libraries, etc. There are some producers, like Spiritual Circle Cinema and others, who sell DRM free video.

I would like to see everyone get everything they want from the web.


This truly is the death of the open web. I hope the appeal is successful. Freedom seems to be losing on all fronts these days.


> This truly is the death of the open web

About as much as music DRM was the death of music players. And as we all know the only way to play a music file today is to buy them in the Microsoft Zune store and squirt them over to your FairPlaysForSure(tm) certified KindlePod.

It's not a good thing; it lets some very big actors hurt themselves and their paying customers by still pretending that people will eventually come around to paying more for inferior service if only they force feed enough "you wouldn't download a car" ads to their dwindling customer base, and it encumbers the browsers to support yet another legacy standard that will be used only by exploit writers in ten years time.

But in the end this is never going to prevent you or anyone born after the sixties from accessing any significant piece of content. It is only going to stop you from going out of your way to pay for it.

I guess if YouTube started putting DRM on everything, that would reach the level of 'annoying'. Is there any indication they would do that?


Right now DRM is the death of you being able to preserve the TV shows you love (they'll just disappear from Netflix after some time and you're not allowed to download them even if you paid for them), the death of being able to watch things on planes and the death of being able to watch things if one of your increasingly unreliable ISPs drops a connection.


What if it was legally bound that a securing tech (enforcing users not to abuse content) HAS to be opened in case of future demise of the author company ?

If Apple and iTunes suddenly crash, they have to make a tiny effort into releasing a conversion/stripping tool and/or open source the system so that ex-customers can at least attempt to help themselves.


Netflix is a streaming company. Users have no rights to the content after their contract with the platform expires. Hell, they have no rights to the content if Netflix happens to remove it from the platform.


If a business is failing THAT BADLY, they're not likely to have resources to implement the safeties. And if they don't, who's going to get in trouble?


It's not about businesses failing - content disappears from Netflix and other services all the time. Shows people were watching previous month regularly disappear even though people pay for service. And DRM prevents them from exercising the legal right (in most juristictions, even US) to make private copies and watch them later. Remember VCRs and DVR devices? We changed laws to explicitly allow that.


> Is there any indication they would do that?

There won't be. Unless we actually make things happen to assure against "suddenly DRM", at some point the technology will be there that you cannot trivially bypass.


Well this doesn't actually change much in practice. Web browsers have allowed black-box extensions for DRM'd content since the dawn of flash.

Personally I am disgusted that this standard is being promoted by the W3C and Tim Berners-Fucking-Lee. The browser vendors are perfectly capable of building (and even standardizing) this tech by themselves.

The open web is as available today as it ever was, and even more so with blockchain and "dark web" technologies like tor and i2p.


> Personally I am disgusted that this standard is being promoted by the W3C and Tim Berners-Fucking-Lee.

Yes, that's the disgusting part. But so it goes. The flesh is weak.

Overlay darknets are indeed the only hope for freedom.


> Personally I am disgusted that this standard is being promoted by the W3C and Tim Berners-Fucking-Lee. The browser vendors are perfectly capable of building (and even standardizing) this tech by themselves.

I don't understand these two sentences in conjunction, which is most of why I don't understand all the complaining about this issue. If, as almost everyone admits, the browser vendors are going to ship DRM-enabled playback one way or the other, what difference does it make whether it's in the official spec?

The HTML5 spec is just a piece of paper that exists to make web developers' lives easier. I don't understand the need to assign attributes like "purity" to it, especially when (as you yourself said), whether or not the DRM is in the spec changes nothing on the ground.


> whether or not the DRM is in the spec changes nothing on the ground.

no, having a sanctioned DRM mechanism in an open standard means DRM is being normalized (and by extension, acceptable). The fact that DRM already exists as plugins isn't the point - but making DRM part of the web standard gives free reign for the pro-DRM camp that it's acceptable, or even desirable!

The only acceptable standard is one where the user benefits. I don't see how a user can benefit from DRM, except that this standard makes DRM less difficult to swallow for an end user (who, let's face it, don't give a shit about DRM). The added convenience of standardization means we can never get to a place where DRM-free content is the majority/norm.


As I understand, EME is the only w3c recommendation that forces web browsers to run proprietary black-box code. I am a proponent of the open web, so I view this standard as a big step in the wrong direction.


Nothing forces web browsers to run any code except perhaps market pressures. Keeping EME out of the standard would have sent a political message, but since everyone is already shipping it, kind of a useless one.

I am sad too. Perhaps there was a window of time when we could have gotten rid of NPAPI plugins and not added DRM to implementations and forced media companies to come along. That didn't happen though.


I think all people who think that this will end with media only are naive. Next step is DOM.


Thankfully you can't obscure the DOM, but people certainly obscure JS and CSS plenty already. Mostly in the name of shrinking its size, but not always just that.

Try to learn how a Google web app works by inspecting the source code sometime.


Let's encrypt the DOM in our open source browser... wait what?

EME is pretty great for cracking too - they enable rendering with the browser's own video engine, giving you a nice "hook to dump pre-decoded frame here" point.


Not necessarily, the CDM can offload the rendering to protected hardware pipelines instead of the browser's usual video rendering.

https://www.w3.org/TR/2016/CR-encrypted-media-20160705/#medi...


The Web in Chains. The symbolism behind the "inventor" of the web signing on this is sending the wrong message to the young ones (the new generation) that idealism must give way to pragmatism and money interests.

Terrible, IMO.


What's the reason DRM can't be implemented as an open-source solution? Is the closed source just to prevent people from easily accessing the secret key or are there other reasons it needs to be closed source?


Not to be a pedant (who am I kidding), but this is actually one of the examples where distinguishing between "free software" and "open source" is more than a philosophical disagreement.

You actually can create an open source DRM solution, because none of the OSI definition[1] makes reference to user freedom or other issues that DRM violates. As far as the OSI is concerned, DRM is can be released under an OSI license. Of course, you have to consider that according to the Digital Millenium Copyright Act, breaking DRM is _very_ illegal (regardless of whether or not the DRM'd media is still under copyright -- which means that DRM has no expiry).

However, if you subscribe to the free software definition[2], then you run into a problem. DRM in principle violates freedom #0: the freedom to run the program for any purpose. Now, there exist free software licenses that don't protect you against this threat (I believe only the GPLv3 actually addresses this issue), but note that just because a piece of software is under a free software license doesn't make it free software (there are whole classes of programs that might be GPLv3 but are still not considered by the FSF to be truly free -- DRM falls under that example).

[1]: https://opensource.org/osd [2]: https://www.gnu.org/philosophy/free-sw.html

--

Another reason is that I guarantee their EME implementations are going to be full of bugs and making the source available would just make it easier to find them. This is the same AAC conspiracy that gave us the Sony rootkit after all[3] (which then went on to be used by other viruses).

[3]: https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk...


CDMs are sandboxed, which is an improvement over the NPAPI plugins. I don't think we have to worry much about Sony rootkit attacks at least.


> which is an improvement over the NPAPI plugins.

why does that argument get thrown around so much? flash runs in sandboxed processes too these days.


It runs in a separate process. I don't think that process is sandboxed in Firefox. And you probably can't restrict it too much or most Flash apps wouldn't work.


DRM is fundamentally security by obscurity. Being closed source is the only way to maintain obscurity, and thus the illusion of security.


Yeah, this may change (in a somewhat scary way) with the Intel TXT and SGX extensions as then you'd only be relying on the obscurity of the hardware rather than the software.


I disagree. Technologically it is possible to build a content protection system without obscurity, using open source software and open source hardware (and suitable cryptographic bootstrapping). That no one chooses to do so is another matter.


How so?

The effect of DRM is to prevent the user from doing things that would otherwise be technically possible, such as copying. Once the software has decrypted the media, it can do whatever it wants with it. It is just so designed that what it wants to do with it is not the same as whatever the user wants to do with it.

Free or open-source software give the right and the ability to the user to modify what the software does. So if a feature is missing (save a backup copy), the user can add it (or pay someone to).

I piece of software cannot at the same time: * be able to decrypt a video * be able to be changed at the users' will * be prevented from doing certain things the user wants.

If you merely write a piece of open-source software that lacks the ability to save a copy, you merely have a missing feature that can be added by anyone who wants to fork it, you are not preventing copying.

If the decryption is done in hardware, the problem is the same, just shifted. If people have the ability to change the hardware, then we're back to square one, and if they don't, then it's not a free/open-source system.


I think the parent's point is that it's absolutely feasible to build hardware and software that successfully enforces a DRM scheme, and also release the specs for the hardware and the source of the software.

That doesn't mean that a content producer will verify any old (modified) version of the software and allow it to play (and possibly "leak") their content.

Put another way: it's possible to build a secure DRM pipeline and then release all the source to it while maintaining the security of _that particular version_ of the pipeline. It's perfectly possible (cryptographically) to set it up so an unmodified version of that pipeline will be able to play protected content, while modifying it to (for example) dump decrypted bits to disk will cause the content to fail to play at all.


but what part of the pipeline is responsible for the verification of the 'unmodified' trait?

If it's a part that's open-sourced (hardware or software), then won't it simply be _modified_ to allow it to pass and allow extraction of decrypted content?

If it's _not_ open-source, then you don't have a fully open-source DRM scheme.


open source does not imply modifiable


From the Open Source Definition:

> 3. Derived Works

> The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.


yes, that was my point


I was thinking along the lines of Kerckhoffs' principle.

You seem to be conflating open source with key extraction or decryption ability. You seem to be saying that if a specification is known then that implies an ability to modify the system to a degree that allows those things.

You can have a system whose workings you know precisely, without obscurity, where the SW/HW specifications are open and the only secret is the key material. For instance, you could have keys be embedded in processor fuses. How would a user extract the keys in that scenario?

For DRM systems the user or consumer is the adversary, but the principles of secure system design still apply. You can still place an asset outside of adversary reach. For example, by ensuring that they need a super expensive FIB machine to read keys. Or, more traditionally, by tailoring cryptography to their computational power.

You seem to be conflating the malleability of software with its modifiability in a given system, but in reality those can be controlled. Yes, you can fork the software, but why are you assuming you can replace it on a given system?

Consider a black box with an LED. The box has an internal power supply and the LED emits light pulses in a given pattern pleasing to the user who purchased it. I could give you its physical properties and circuit diagrams. The box has data stored in internal memory. You can call parts of this data software if you like, as long as we agree that the output of the box is a function of this data and time.

The only contradiction inherent in DRM systems is that knowledge of the data/function needs to be given to the adversary and not given to the adversary at the same time. This has less to do with open or closed source, and more to do with whether the user can open the box.

I think that the "solution" to this contradiction has been reduction in fidelity, where the user/adversary is only given an approximation of the function (analog outputs that they have a hard time spreading to other would be users).

DRM sucks, but is not fundamentally at odds with open source.


If you plan on putting a chip in my head that speaks DRM, then yes.

Ultimately my screen has to show me the pixels and my speakers have to play the audio.


Sure, and you can point a camera at the display device, but you'll suffer lower quality.

And you can also buy some expensive hardware to sit between the HDCP decoder chip and the output to the display panel, and buy some more expensive hardware to deal with the huge volume of raw, uncompressed video that comes out of it.

But the content producers are betting that most people won't consider the first option good enough, and will find the second option prohibitively expensive. They're also betting that most people will opt for the convenience of getting it through the browser or mobile device (for a fee) and won't want to deal with getting it from not-so-legit sources. They're comfortable with these tradeoffs, for now, so they're doing what they're doing.

They absolutely don't care about the small minority of people who will do anything to get hold of the content unencumbered. They know they can't control that group of people, but they aren't losing sleep over it. Because, for now, that minority is too small to hurt their bottom line. If that changes, I'm sure they'll pursue a new strategy. But for now, they don't need to.


A DRM solution could be implemented with disclosed source code (though it would be more difficult than with concealed source code) but the key thing a DRM implementation does is to attest that the user hasn't modified the implementation--i.e. that the user hasn't exercised the freedoms provided by Open Source.


If false DRM initiatives are what it takes to get browsers to implement proper crypto modules, then sign me up.

Obviously it can't be used for DRM, I will just capture the frame and redirect it to a codec to re-encode the stream. Alternately, I can just stream it somewhere else.

On the other hand a secure place to store keys, free from the reach of plugins and javascript would be nice.


Yeah thats fine, freedom of choice and a better experience for users, sounds pragmatic to me.

Much better than the many posts here trying to force their opinion on the world!


Anyone know if the EFF plans to throw some of their weight behind this particular appeal?


I believe they want to, but the appeals process is an untested one, and will be evaluated by the same people who made the original decision. Don't get your hopes too high.


That's a shame. He should know better than to approve this unethical garbage.


I can't wait until this gets used by malware!


That was my first thought when I saw the spec for WebGL.

"Oh boy! I'm super excited to be running arbitrary code I downloaded from web sites against an API that was never security-hardened!"

Fortunately for me, my fears turned out to be overblown in that specific instance; there were a few security bugs, but they were patched with relative swiftness.


I believe this specific fear is why Safari waited so long before enabling it for everyone (for a long time you had to manually turn it on in the Develop menu).


Can you explain how malware could benefit from EME? Note that EME only applies to video.


The reasoning goes that EME is a standard that specifically allows for attaching a closed-source black-box to the browser in a standardized way. This code is not auditable by outside sources, and therefore could be a breeding ground for malware and exploits (standard open-source philosophy that "sunlight is the best disinfectant"---many eyes on open source software minimizes the opportunities for exploitable bugs to hide). We've seen codec software---even open-source codec implementations---used as an attack vector in the past.

This reasoning, IMHO, ignores the fact that the user-agent still asks for consent, so the user may choose not to allow anything they can't audit. It's just the "Do you want to allow Flash to play this cool video?" story all over again.


Presumably they feel the same way about all closed-source browsers?

Also, the comparison to Flash is not quite right. For example, Flash was an entire black-box, top to bottom, with a runtime, codecs, UI, a JS engine, etc., which downloaded code from the internet to run it.

Web DRM, on the other hand, is a standard that allows for an encrypted video stream to be decrypted. The only differences that I can see between this and the current state of web video are that now the stream can be encrypted. Everything else is still using Javascript, HTML, CSS, HTTP, h.264/265, etc.

The thing that gets me is that open-source browsers are free not to implement this extension if they're not comfortable with (or opposed to) it. The theory is that if companies start encrypting their content then open-source browsers will have to follow suit, but we already have that kind of junk; the difference is that now, with EME, we can keep 99% of the stack open standards, open-source, and auditable, rather than having to rely on Flash or Silverlight to do our decoding.

EME isn't the death of the open web, it's the death of the closed web. It's the death of awful, insecure, and obsolete technologies like Flash and Silverlight by taking the one single thing they're still good for and moving it to the browser. If EME failed and no one implemented it, Netflix wouldn't just stream their content unencrypted; they'd keep using Flash or Silverlight, or maybe implement something themselves so they didn't have to.


> For example, Flash was an entire black-box, top to bottom, with a runtime, codecs, UI, a JS engine, etc., which downloaded code from the internet to run it.

And, notably, the DRM modules can be sandboxed far more than Flash can.


The user often does not have a choice because websites that they must use for one reason or another will require these extensions, just like some required Flash. And that's assuming that the extension even works on their system. The extensions are native code IIRC. Ever get a "sorry, your OS isn't supported!" message on a website that you really need to use to get something done? It sucks, a lot. I don't know why the W3C would want to steer themselves in such a direction, it's the antithesis of what the web was supposed to be. The web is supposed to have a well defined set of standards that anyone can implement and use to view the web. This was never true in practice because of things like Flash, but the W3C never endorsed such a thing. Now they are, and that is sad.


> This reasoning, IMHO, ignores the fact that the user-agent still asks for consent, so the user may choose not to allow anything they can't audit

Aaaand we're back to the days of good ol' ActiveX.


"It's just the "Do you want to allow Flash to play this cool video?" story all over again."

Another comparison to existing tech is Javascript. A lot of sites break if you disable Javascript in your browser, but if you enable it you open yourself to Javascript vulnerabilities.


Open browsers have open, auditable Javascript engines. There can be vulnerabilities, but you aren't waiting for some company to put out a closed patch containing a fix. EME blobs are like Flash plugin blobs.

So, it's similar in the sense that enabling JS increases the potential attack surface, just like installing EME/Flash/whatever does. But at least the JS engine can be examined by whoever wants to.


Yes, that'll be tasty.


EME is useless garbage. It's one of the first things I disable when I install Firefox. I can't do much, but I boycott any service that uses it.


I have given money to the FSF for years and will continue to do so as a member. However, I do not support them in this fight. Berners-Lee is doing the right thing here.


Can you elaborate on that? Why do you believe this?


The choice we're faced with is either we get some standardized DRM in browsers or we get unstandardized DRM in browsers. That's the choice.

I've had email discussions with people at the EFF about this and we basically just had to agree to disagree. Their interpretation of the choice we're making is that we either get DRM in browsers or we get some magical fairy-tale land where DRM suddenly ceases to exist. I don't buy it.

Plus, as a Netflix subscriber I don't really mind DRM that much. Feel free to ask away, I'm always willing to talk about this.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: