Hacker News new | past | comments | ask | show | jobs | submit login
Tell W3C: We don't want the Hollyweb (defectivebydesign.org)
179 points by hosay123 on Mar 22, 2013 | hide | past | favorite | 93 comments

HTML DRM consists of two parts. The first part is EME (extended media extension) that defines the API how a browser interacts with the CDM (the actual implementation of the DRM)

The EME is what is being standardized. The CDM is what is up to the platform provider (or any plug-in provider) to implement, such as Google, Sony, Microsoft etc.

There are a couple problems with this.

1) The actual DRM functionality will not help keep people from having to deploy on flash/silverlight because the technology is ladden with proprietary licenses and NDAs. Ordinary web developers will not be able to make use of "HTML DRM"

2) Since the CDM requires to do some user specific encryption/restriction, the CDM will be able to uniquely identify each web user regardless of privacy settings, cookie blockers etc. You will not have control over what the CDM does, it will sacrifice your privacy on the web, absolutely. This is a supercookie on steroids.

3) Due to the CDM having to be provided by third parties as a proprietary blob, this will make it harder to support the DRM on free/libre/speech/beer implementations such as Firefox, Linux etc.

4) It will decrease compatibility of video on the web by fracturing already fractured video support (the codec wars) into the even more fractured DRM format wars.

5) Because the CDM is a proprietary blob, there is no scrutiny, code review and control over what it does. Fiascos such as Sonys rootkits and a host of security exploits in shoddily written proprietary DRM blobs are inevitable.

6) Companies like Google, Microsoft and Apple will use the DRM to gain leverage over their competitors by intentionally denying them compatibility to consume videos of services they created.

7) Companies like Netflix, Amazon etc. will use the DRM to gain leverage over their competitors by denying them the ability to produce videos compatible with their DRM implementation.

8) And finally DRM will be used by everybody implementing it to rise the barrier of entry for companies in the entire market, as well as to exclude innovation.

Actually, it's even worse. EME does NOT define how a browser interacts with the CDM at the moment. That's precisely why some people are objecting to it in its current state.

EME defines how script in a web page can ask the browser to talk to the CDM. How the browser actually does that is up to the browser and CDM vendor. There is no requirement that any CDMs expose any sort of standardized API that browsers can use to talk to them.

For example, given the current proposal Microsoft can ship a CDM on Windows that only IE can talk to, Google can ship a CDM that only works in Chrome, etc.

So in its present state the setup can be trivially used to lock out third-party (and especially open-source) browsers: just don't let them talk to any CDMs.

Thank you for this summary. It helped a lot.

I'm actually a bit conflicted about support for DRM schemes in HTML5.

I absolute loathe DRM and I wish every damn publisher of every damn type would come to their senses and actually sell DRM-free digital products.

However, there is one case where some form of "DRM" does make sense, and that's actual renting - or more specifically, the popular case of "catalog subscription" (ala Spotify, Netflix and so on). You're clearly renting access to a catalog of goods in this kind of model, and therefore it makes sense that you'd want to stop people from permanently acquiring copies in such a scenario, especially if you're selling actual DRM-free downloads at the same time (in my ideal digital store where it makes sense they would offer both of these side-by-side). The catalog subscription model has some clear value to it, and I'd hate for it to disappear due to "technical unfeasibility".

As such, I would at least prefer for most of the tech / architecture to be based on HTML5 stuff instead of closed plugins like Flash, Silverlight, Widevine and so on. I can't really think of a good solution to this, unless you got the big wigs at various publishing outlets to accept that to do HTML5 streaming, you can only make downloading the rentable versions inconvenient for regular versions (instead of being able to use a heavy-weight closed DRM plugin), but I'm afraid that could be quite challenging. It has worked for Adobe and webfonts, though[1], so maybe there's hope. Forcing HTML5 to be DRM-free could eventually lead to this direction.

[1] http://blog.typekit.com/2009/07/21/serving-and-protecting-fo...

> As such, I would at least prefer for most of the tech / architecture to be based on HTML5 stuff instead of closed plugins like Flash, Silverlight, Widevine and so on.

It's not really based on open stuff. EME isn't DRM, it provides a way to talk to a DRM service (probably a hardware DRM in most cases). They are creating a false-sense of "open standards" when this thing still won't work in Linux and most not-locked-down platforms.

Yeah, that's the impression I've got as well, which is why I don't ultimately like EME. It would be a slight improvement compared to the current situation (since you could at least move stuff like video playback to HTML5), but would probably just make the situation of "closed binary blob DRM" more persistent and thus worse in the long run.

Unfortunately, this sort of problem is basically unsolvable for Linux (and other such "open" platforms). Either you get a proprietary blob that implements a protection scheme, or you simply don't get the functionality being promised.

Objecting to efforts to make the situation better for HTML5 experiences on other platforms because it won't work on Linux is, honestly, pretty selfish. It can't work on Linux, so you're basically saying since it can't work for you, it shouldn't work for anyone else too. And that's just dragging down the state of the web to the lowest common denominator.

> And that's just dragging down the state of the web to the lowest common denominator.

Or up to the state of most openness?

Leaving out functionality because Linux can't support it isn't dragging anything up.

It provides a way for script to talk to a DRM service. Assuming the browser has a way to talk to one already. It doesn't do anything towards providing a way for _browsers_ to talk to DRM services; that's up to the browser manufacturers to license or whatnot.

Renting infinitely copyable goods doesn't make sense.

Subscriptions to channels containing them does.

DRM doesn't increase the convenience of those channels. It reduces them.

The problem I have is that I can't really imagine the catalog subscription model to be feasible if any and all catalog entries were available to download without DRM. Someone with a fat pipe could just spend a month downloading absolutely everything, cutting the subscription and enjoying the goods for a long time to come, whereas the idea is that the user remains as a subscriber because of the limited time they have for consuming all the content.

And while DRM is generally very inconvenient, there are also places where it's mostly "invisible" - Spotify and Netflix are pretty damn convenient on the whole, with pretty much the only major downside being the inability to watch stuff without an internet connection (though Spotify offers limited offline downloads for this reason too). The DRM in Steam is also generally quite invisible to the end-users, which is why people generally do not mind it - and also because Steam offers a lot more convenience with its service than what it takes away with its DRM.

As I said, ideally I'd like to see digital stores that combine the catalog subscription model as well as individual DRM-free purchases. Think Netflix, except you could also buy the really good stuff that you like. This would allow you to download DRM-free copies in many formats whenever you want, they could also bundle purchases with stuff like extras, and best of all: since they have a streaming infrastructure in place already they could also offer unlimited streaming for bought titles, even if you don't have a subscription. I imagine it would make for quite the killer service. But if everything could be downloaded DRM-free with just the catalog subscription, the individual sales would not work, and subscriptions would probably have a terrible retention rate.

Again, I just can't see the catalog subscription model working without at least some sort of "download prevention". I guess the biggest question is: Can we achieve that without the need for heavyweight black-box DRM schemes? I mean, you'd really just need to stop "casual" downloading - pirates will always find a way around protections, so they can't be stopped, but you'd just have to make sure a regular customer sees value in both the catalog subscription (which would be essentially renting) and individual title purchasing (actual buying).

Are you looking for a 100% solution? If so, you'll never find it.

Instead, you need to think about how you make offerings cheap enough and compelling enough that a sufficient number of users will choose them over pirating.

There will always be pirated content. However, thankfully, most people are also more or less honest and well-inentioned. The two balance out to a great degree. So what tips the balance is how you treat your customers – does it become painful to deal with your product because of all of the DRM? Do you treat consumers like criminals? Is it significantly less hassle to pirate than it is to buy/rent/view legally (and likely pay for)? If any of those are true, you will tip the balance away from a completely successful business model.

Every business model has inefficiencies in the supply chain. Much of it falls under what's called "shrinkage". Sometimes it's from theft, other times it's from spoilage, weather, etc. The truth is, just like in heating, cooling, power production, engine design or anything else, you can never achieve 100% efficiency and in the case of consumer-facing products and services, I suggest you re-evaluate such pursuits before they ruin what otherwise would have been a profitable business model because you've alienated your customers.

There's nothing about DRM that intrinsically must be obnoxious to the user - setting aside the issue of control over your devices, because so far that's not something that much of the population cares about.

Yes, lots of companies have implemented DRM in really terrible ways. But there are also examples of DRM that users are perfectly happy with. BBC iPlayer uses some very trivial DRM so that their programmes are available for a limited time, usually a week. It's easy enough to bypass, but people mostly don't bother: it doesn't get in the way, and I think people understand why it's time limited.

Netflix has reached the convenience level for me. I didn't even know it had DRM nor do I have any reason to care. Netflix, Spotify, etc, are the future of content online: unobtrusive DRM with subscription oriented payment.

I'd even argue that just in time streaming with minimal buffering is its own form of copy protection - it just gets to be too slow to make it worth the while to copy en masse.

Exactly – as I said, if you're looking for anything approaching a 100% "protection", then it's my contention that it will long since crossed that line into obnoxiousness.

Your point about trivial DRM working well exemplifies just makes my point –- "does it become painful to deal with your product because of all of the DRM? Do you treat consumers like criminals? Is it significantly less hassle to pirate than it is to buy/rent/view legally (and likely pay for)? If any of those are true, you will tip the balance away from a completely successful business model."

If the DRM is minimal and unobtrusive, then it doesn't meet my stipulations, above, and it's probably found some sort of happy-medium. (FWIW, I think most of Apple's DRM approaches in the iTunes store have gotten close, except for the device lock-in)

I think that you are missing something very critical: technology given us new tools the past twenty years which make previous ones more obsolete. Its the idea of creative destruction. When the car was invented, the horse-buggy industry died. In our case, the horse-buggy is the music cd industry. Instead of the industry trying to find a new business model with the emerging technology, they are trying to force us to stay with the old model. Fortunately, other companies have innovated in place of the RIAA (and MPAA) and we have services like Spotify, Pandora, and Netflix.

Do not confuse these companies with the industry itself. Especially with the music companies (Spotify and Pandora) the companies are paying ridiculous royalties on the music they play (especially when compared with an actual radio station). I can tell you that Pandora does not use DRM for the music that they play for you (about a year or two ago I sniffed the traffic and found raw mp3s being transferred, they might have changed that but I hope not). Still, I did not see people simply downloading all of Pandoras music. If people wanted to do that, there are much better ways (a la bittorrent).

Therefore, the real issue here is control. The industry wants to control what you can and cannot do; even more so than they used to be able to. For example, adding music to a home video which you post on youtube is something they dont want you to be able to do. You have the legal right to do so, but they still dont want you to. (You have the legal right to do so, so long as it is a creative use not meant for monitization, etc.) As long as the DRM provider allows you to do what you want to do, it can be seamless. But as soon as you want to step outside those bounds (whether within your legal right or not) theres going to be friction. I bet that people who like making videos with popular songs playing in the background have more of a problem with spotify than people who simply like listening to radio.

> Are you looking for a 100% solution? If so, you'll never find it.

I dunno, getting paid to make information-based content (which includes anything you can stick on a hard drive) by the people that want the content, rather than by people who want to try to profit off its artificial scarcity, could probably be a 100% solution.

Because then the information you have you can treat like anything else you own - you can share it, spread it, etc, without fear, and the content creator got paid by people that wanted it made.

I mean, it would be a culture shift, but it is a 100% solution. Piracy doesn't matter if the point of profit isn't in per-goods sales but in goods creation, where the actual costs lie.

I'm having trouble understanding what you mean by people paying for the creation of goods by the people that want the content. The division between paying for DRM-free content and the creation of that content seems contrived unless you're saying that consumers would pay the content creators directly so that more content can be produced, but that would make it problematic for up and coming artists to break into the market.

Don't take this as an argument, I'm just asking for clarification.

I dunno, getting paid to make information-based content (which includes anything you can stick on a hard drive) by the people that want the content, rather than by people who want to try to profit off its artificial scarcity, could probably be a 100% solution.

Unfortunately, by simple economics, that works only if you can find a sufficient number of people to entirely fund the sunk costs and an acceptable level of profitability up-front, allowing the low marginal costs to be written off. This is the classical patronage model, or in more modern terms, something like Kickstarter.

On Kickstarter, a project that has experienced, well-known, credible people behind it might reach seven figures of funding, though that is a significant success and relatively rare. I'm all for cutting out the middle man and for curtailing the exorbitant fees commanded by a handful of A-lister actors/singers/producers/whatever, but raising a few million a handful of times each year still isn't going to fund the big media industries, not by a long shot.

That culture shift you're talking about would be necessary and dramatic for this idea to work, and that's not going to happen any time in the immediate future, so what's your proposed solution to keep people getting paid to make good content tomorrow?

Netflix streaming is only $8/month, how much cheaper does it need to get before it's better than pirating?

There will always be pirated content. However, thankfully, most people are also more or less honest and well-inentioned.

I think this is likely true, but it's not something you can just take to the bank. Making a movie is a very expensive business venture because people have pretty high expectations for what constitutes a minimum viable product.

I think Netflix does a great job of proving my point. Streaming big content at a rate equal to viewing speed makes a weak target for pirating and helps keep people honest, IMHO.

Tell me again why we need DRM in HTML5? How many people are actively going out of their way to pirate the movies and shows from Netflix?

At the end of the day, pirating from Netflix: A) takes a lot of time (a bit of analog DRM, if you will as the rate is a huge limiting factor) and B)Takes a decent amount of disk space. Sure, storage is cheap, but what advantage does it give me over just keeping a netflix subscription? Not much, IMHO.

So, the upshot is that, pragmatically, I just don't see why Netflix needs DRM in the HTML Spec.

The problem is that you'd need a fully locked-down chain, all the way from server to monitor, to be able to pull that off.

Every single one of the devices in that chain has to be reduced to a black box which we're not allowed to tamper with.

Hollywoord is trying hard to actually achieve that, and that is the scary part.

Not really true, Hollywood just needs to make it inconvenient for casual users to make copies and give to their friends etc.

Tell that to Hollywood. This may be all they actually need, but it's not all they're asking for, not by a long way.

"Download prevention" is impossible. The analog hole cannot be closed. If it can be delivered to our senses, then it can be copied.

Even with DRM, I wouldn't be subscribed to a service for long if it wasn't continually adding new content.

I buy music on bandcamp all the time, yet I could pirate it. It's often more convenient.

Can't explain that!

> [But what if ...]

Yeah, and it already happens. More-over, I go out of my way to give people SD cards full of textbooks, HDs full of books, etc, and even the odd hollywood movie here and there, to make it happen.

So why not pull our heads of out the sand. After thousands of years of grubbing in the mud we've finally got the technology to give everyone a copy of everything worth knowing. So let's do it now, and reap the societal benefits, while thinking of how to reward the creators, instead of sitting and lamenting while it inevitably happens.

The US constitution gave congress the ability to grant monopolies to encourage the public good; it didn't declare that this was the best method, or require it actually be used. The constitution should read "Congress is given the ability to encourage creation of knowledge, including the power to grant limited monopolies where necessary", instead of suggesting them as the go-to strategy.

Watermarking makes a lot more sense than DRM. If your name is on the film you just bought, you will not want to publish it on p2p.

It wouldn't really be a feasible solution for video, though. You'd have to re-encode the whole thing for every individual user, which would be incredibly inefficient. Even if you're showing the watermark in just a few places, it'd still require a damn lot of resources. There's also quite a few things out there for removing video watermarks[1], so unless the watermarks were incredibly obtrusive, they'd probably be quite easy to get rid of. And of course you couldn't really put the watermark outside the actual video stream either, since then the user could just strip it out.

[1] Like various Avisynth plugins for example: http://avisynth.org/mediawiki/External_filters#Logo_Removal

You could split the stream into N chunks. Every time you watch the movie, M of them are selected and fudged just a little bit. Since M << N, this can be done in real time. The next user sees the same chunks you saw, except that some new chunks have been fudged also. Thus the movie slowly drifts away from the original. To counteract this, fudges are more likely to carry the chunk towards the original then away from it. This is what I came up with in 5 min, so there might be problems with the approach.

Sounds like the steganographic equivalent of Y-chromosome genotyping.

You'd have to re-encode the whole thing for every individual user, which would be incredibly inefficient.

It would be inefficient, but not necessarily prohibitively so if you're talking about the kind of business where piracy is a serious problem so there is real money to spend.

There's also quite a few things out there for removing video watermarks

If you're operating on the kind of level we're talking about, you don't just put in a visible watermark, you convert the entire file/stream to embed a unique forensic footprint tied to the account of whoever downloaded it. Such a footprint will stand up to just about any manipulation you can think of that doesn't reduce the quality of the data so much that the value is destroyed anyway, and you're probably not removing it unless you have a PhD or two in the field and you know someone's secret key.

The limitation with any watermarking approach is that fundamentally it's still based on the honour system and obviously does nothing to prevent private copying between people who don't care about ripping someone off. It's not a technical limitation.

Is it really true that they can't do it on the fly? Live streaming is creating the video on the fly completely isn't it?

no, they can do it. There is overlay support in current generation iptv support that can target scrolls and texture replacements at a resolution of less than a zipcode. Take that gear and apply a few static watermarks with timecodes and then swap the different streams at unique times for each viewer and you can end up with a stream thats uniquely identifiable.

Motorola's (Google) new gear can do this, though the purpose is targeted advertising not watermarks. The truth is streaming DRM is about preventing your mother from giving a copy to the neighbors, almost all the content is already on P2P by the time it streams.

In case of live streaming, the video is only encoded once and then distributed to a whole bunch of users. If you were doing unique watermarks, you'd have to encode an individual stream for every single user. Encoding is much more taxing than decoding. The end result would be that you'd need a metric crapton of additional processing power, and the quality would be worse since you'd have to use sufficiently fast encoding settings to be able to do it in realtime (as opposed to being able to use a lot more expensive options when the encoding is done just once and separately from the actual streaming process).

What about onlive, they stream(ed) cpu/gpu intensive games in real time on a one-to-one basis?

No, they don't. You have the game assets downloaded already on your PC. They just stream control messages (move the camera there, that player hits the other player, etc).

Real time gaming is not streaming video...

OnLive[1], which is what was being talked about, is literally streaming video to you of a game that's running in a datacenter somewhere.

[1]: http://en.wikipedia.org/wiki/OnLive

There's been some interesting research on compressed-domain forensic watermarking; check it out.

A film I just bought to play on my fairly high-end setup damn well better not have my name anywhere in the picture.

Is anyone here familiar with the proposed spec? Would the DRM be a private binary included with the OS, or an open part of the browser? Unless they're just specifying an API, and all the actual work is done in a private binary, I don't understand how you can have effective DRM in a publicly specified project.

Could be a private binary, could be a hardware component, but yeah, the actual DRM part is not in this spec.

There's a pretty lively thread over on Reddit: http://www.reddit.com/r/technology/comments/1asm1x/tell_w3c_...

A dark future for HTML. I can't really describe the melancholy I feel when thinking about this. In 10 years, we'll be reminiscing about how the web was once an open platform, and we'll kick ourselves for having said at the time, "I hate DRM...but then again, I do like netflix!"

The W3C requires at least two implementations before standardization can happen, right? Theoretically, if both Webkit and Gecko refused to implement it (or, more diplomatically, "indefinitely deprioritized its implementation"), would this be DOA?

Google and Microsoft are supporters and working on the spec,


Which makes two implementations, I am afraid. Unless we can convince at least one of those to stop.

Right, but it's Apple, not Google, who holds the keys to Webkit. Not that I presume that Apple is so benevolent (naive much?), but it wouldn't be the first time that Apple has outright rejected a Googler's patch (I can't remember the link now, something about Dart integration). Obviously Google could always fork the whole project for the sole purpose of implementing DRM, but what a fiasco that would be!

Google doesn't need to officially fork WebKit, it can keep these features in Chromium and not push them into WebKit - like many other features, including the one you mentioned (Dart support that Apple rejected). But Chrome is still a major implementation, it doesn't have to get into WebKit or not (for standardization purposes that we are discussing here).

Thanks, I wasn't sure what was considered an "implementation" according to the W3C.

In other news, azakai, you work for Mozilla, correct? Have they issued an official statement regarding this?

Chrome certainly counts as an implementation. You just can't count Chrome and Safari as two separate implementations if the actual code is in shared WebKit (but you _can_ count them if the implementation is unshared code, for what it's worth).

As for Mozilla, no official statement yet, though there have been some public comments from Robert O'Callahan on the EME spec.

Not to my knowledge. But it is very possible I just didn't hear a statement if there was one ;)

Google has already shipped this on ARM ChromeBooks, for what it's worth. See https://plus.google.com/113127438179392830442/posts/VASv1hCt...

So that's one implementation, in WebKit.

It's hot HTML's job to fix broken business models.

They are being pressured by businesses that want to support those broken business models like Google. Youtube is a great example - thousands of people are now living their lives off youtube ad revenue, yet you can get a simple addon for any browser to download the mp4s.

DRM isn't necessary, old media just wants total control. I seriously think if we just play the battle of attrition, they will die off soon because they can't compete in an on-demand get-what-you-want information free era.

If DRM is inevitable, I'd take a properly implemented DRM that's been through community scrutiny than another Sony rootkit fiasco any time.

How would you like hooks in your web browser for the Sony root kit?

That's what's being proposed at the W3C.

Please, that's hyperbole. Sony rootkit and the DRM present in Flash/Silverlight are worlds apart.

Actually the description is apt -- the proposal is when a web page loads then a binary blob (that has OS-level hardware access) will be invoked. It would be as simple as including a highly-insecure JS file rather than installing a browser add-on/plug-in/extension/whatever.

The security risks cause me imagine EME news that makes the recent Java 0-day news frighteningly tame.

It is not hyperbole. EME is a plugin API, and the plugin is not specified, and that is what the DRM is. It is inevitable this will result in another rootkit fiasco.

But worse than that, the working of the DRM (called a CDM) will also sacrifice your privacy on the web, because it can inevitably act like a "supercookie" over which you will have no control.

My understanding of the proposed EME is that it does not implement any DRM, and DRM implemented for it would likely be opaque software implemented without community scrutiny.

The EME (again, by my understanding, I could be wrong) only defines an API to communicate with DRM systems. I don't think this helps us gain any scrutiny over DRM.

The reason DRM has to be obscure is to make it hard to extract the key. If the key can be safely store in a hardware component, the need for obscure software goes away, and there's no reason VLC could implement this.

I agree, there needs to be one open DRM specification that everybody can implement. There can then be discussion and debate about what level of DRM is reasonable; balancing rights of content holders and content consumers. Nobody is going to be perfectly happy but such is life. Every time the drm is broken there can be a new revision of the spec, so if you want to play netflix your browser has to be up to date. Ideally there would an open source reference implementation shared by the open source browsers (webkit,firefox) so the impact on development resources are minimized.

You will get a Sony rootkit fiasco this time around as well.

The HTML DRM (EME) is nothing but a plugin API. The plugin is something like Widevines DRM, called a CDM, (already in use on chromebooks) that browsers will no install on your machine without your consent.

The working of the CDM/DRM itself is not specified in any way. Repeated request at specification have repeatedly been rebuffed and ridiculed by Google, Netflix and Microsoft.

I think DRM makes sense sadly because otherwise it'd be as simple as 'right click, save as' and you'd have the contents of a movie. There'd be little incentive to subscribe to Netflix past a month. Rdio too.

Simple anti-copying provisions that are still defeatable, though through effort, help incentivize the migration of those channels. And that's what I really want. I want Hollywood to feel comfortable using the web, because then more open alternatives will emerge when it's a level playing field. (IE watching TV is watching the web.)

No, this doesn't make sense in the slightest.

Fact 1. If I want a movie or song without paying for it, I can get it.

I don't need any more facts, this "solution" doesn't solve fact 1's problem. It simply breaks the internet. So what part of creating a burden that doesn't solve a problem make sense?

They don't have to make it impossible to get movies/songs without paying. They just have to make it hard enough that Joe Random-User doesn't make copies for all his friends

People talk a lot about the analogue hole. Imagine they've got it locked down all the way to a trusted screen and speakers. Now, to make a copy, Joe would need to set up a good camera and microphone in a quiet room, and let the movie play for two hours. All of which is possible, but he won't put that much effort in.

Of course, someone somewhere in the world will bother, and it will end up on file sharing sites. That's why they also go after those sites, and pressure search engines not to list them. Again, they'll never stop it entirely, but they want you to hit dead links and slow downloads, to worry about viruses from dodgy Russian websites, and to imagine that the police are tracking your downloads. Sooner or later, it's just easier to cough up for a legitimate service.

They don't need the unbreakable system that we rightly point out is impossible. They just need to make free copies unappealing enough that people will pay a bit for legal content.

> Fact 1. If I want a movie or song without paying for it, I can get it.

this is actually irrelevant. netflix is contractually obligated to distribute all their content through DRM'ed channels. Hollywood knows that DRM isn't going to stop copying, but they would still like to reduce it, and they certainly aren't going to license their content to services that make copying trivial.

How does it break the internet anymore than Flash and Silverlight do right now?

I have the option to not use flash, or silverlight. When built into a specification, that option is absent.

Not really, you can always disable that option in the browser or use a browser that doesn't implement that part of the spec.

Nobody's forcing you to use a web browser either. You just like it.

Hixie: DRM is not about piracy, but about control over software providers.


Currently Silverlight and Flash are NPAPI plugins, which means that Chromium and Firefox users can use it, so studios can't force any anti-features on users.

But by pushing EME that requires unspecified CDMs without public API the studios will be able to license them only to browser vendors who agree to their wishes and cut off other vendors with DMCA anti-circumvention laws.

They can let Chrome-proper with Google Widevine DRM to work, and cut off Chromium users.

EME+CDM doesn't enable any broader interoperability than NPAPI does. It's still a binary blob. They still don't care about Linux. Apple still won't let them put plugins in iOS Safari.

EME+CDM doesn't give them better browser integration, because the DRM must bypass browser's media stack entirely (otherwise you could modify Firefox or Chromium to dump the video).

But EME+CDM kills NPAPI as binary-DRM-blob interface and shifts power from browser vendors to CDM providers.

What is CDM?

Content Decryption Module, a binary plug-in (with unspecified API, could be OS/kernel-level) that handles the decryption and potentially display of the video.

Anything on netflix exist on torrent sites, and yet, netflix get paid subscribers.

A lot of people subscribe on netflix for the service. Netflix maintain the hardrives, servers, and catalogs of films. They deal with "downloading" of the new movies when they are released.

Even if "right click, save as" was enabled, you still need to download it from a friend or some torrent third party site. You need to know the name of the movie, and deal with software for downloading. You need to know about magenet links and torrent files and seed scores and whatnot. If you just got home from a 10hour work shift, then many people just want to sit down and be entertained for a few hours. Thus there is a need for a service which provides in easy package that will fulfill this need.

netflix provides the same service as a DVD stall at the gas station. It just do not compete with torrent sites. People don't by the content, they buy the service.

Everything that's on Netflix is on The Pirate Bay (or other torrent sites) for free. By your logic there'd be little incentive to subscribe to Netflix at all today.

So how come Netflix has customers? Either you're wrong or some piece of the puzzle is missing (if so, what?)

> So how come Netflix has customers? Either you're wrong or some piece of the puzzle is missing (if so, what?)


Well, there's also the part where I want to pay for what I consume instead of just leeching it. This might have something to do with the fact that I've worked in the film industry for a decade and like being paid to work.

Precisely. It's much more convenient to use Netflix than The Pirate Bay. If Netflix doesn't have content I, as a proverbial user, like to watch, I take the time to inconvenience myself to download it there.

DRM provides lowest-common-denominator security.

I agree.

But that advantage may still exists if Netflix has no DRM.

DRM itself is objectionable for different reasons than the absurdity of their current proposal.

They propose to run third-party binary blobs with OS-level hardware access -- all the security nightmares of Flash/Java plug-ins but even worse.

Rdio is a great example as they currently don't use any form of DRM (if you use the Chrome UA and don't have flash player installed). So I could download songs from Rdio and save them away, but I've never bothered because I want to listen from wherever I am -- the value of the service isn't just having a bunch of music files, but all the other stuff too.

Netflix is probably similar (though I personally use it only infrequently) they provide a huge amount of value via recommendations and having a client on every device (versus downloading the stream, setting up some kind of local server to watch movies on my iPad/TV/whatever, only it'll have a clunkier interface, no recommendations, bad metadata, etc).

I guess what I'm saying is that these guys should all be able to keep people honest by offering the best experience -- a better experience than the illegal alternative.

As an aside: I work on browsers and I really don't like the idea of having to sign agreements and ship binary modules to have a "working" browser. Chrome started shipping widevine a while ago, though I'm not sure where that gets used. It's a bad road which locks out the little guy (but pragmatically that's the way things go...).

There'd be little incentive to subscribe to Netflix past a month.

Have you actually used Netflix?

Sure. Could you provide more context to your question?

It sounded like you were under the impression that it's either possible or desirable to make your own local copy of the entire Netflix library. Why exactly would I want to do that, DRM or no DRM?

I don't know what the solution is here, but I'm worried that if we don't implement this solution, the web will fall even faster out of favor to native apps.

I'm talking about mobile.

Right now running flash or silverlight on your desktop is no big deal. This "solution" is unnecessary. But on mobile we have a real problem: the only way for anyone to deliver encrypted media is via a native app, which is exactly what everyone is doing. That comes at the expense of the web. So now we have an entire generation of users growing up on apps (netflix, hulu, spotify) because those content licensing deals require DRM.

The desktop is fading. If we want the web to stay relevant as everything moves to closed ecosystems, this may be a necessary evil, because the web+EME is infinitely more open than the an iPhone/Android app.

There is more information at the EFF page [0] linked in TFA, although not quite the same "call to action".

[0]: https://www.eff.org/deeplinks/2013/03/defend-open-web-keep-d...

Isn't this going to be necessary for a site like YouTube to be able to fully switch off of Flash?

Currently YouTube doesn't require Flash Player for the overwhelming majority of its videos. It's a bit unclear whether they are still using RTMPE for some Hollywood stuff (as they were a year or two ago), but if you go to https://www.youtube.com/movies the free movies work perfectly using all free and open source client software, with no Flash Player.

Most (or all) of YouTube is implemented as FLV or MP4 files delivered over HTTP. You can watch this in action by using software like youtube-dl.

So apart from the purported, perennial Hollywood threat to boycott things, the empirical answer with regard to the existing YouTube seems to be no. (Though maybe there is still some RTMPE lurking somewhere on the site.)

All YouTube videos (as far as I know) are easy to download and in friendly formats.

Applications are open for YC Winter 2021

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