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.

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.

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.

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

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

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.

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.

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

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.

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.

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

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.

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.

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

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.

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...

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?

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.

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.

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

(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.)

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.

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?

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?

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

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.