To play to devils advocate - because that other unethical junk requires additional downloads and poses multiple security vulnerabilities. Right? Why wouldn't a sort of 'native plugin' be better in every sense of the word for the end user?

See below: https://news.ycombinator.com/item?id=5599601

DRM by definition implies security and privacy risk. Focusing on minor issue (native plugin) while ignoring the major one (DRM) sounds strange. And in reality this whole EME thing won't even remove native DRM code. It just will hook it into JavaScript. The risk caused by DRM won't get any less than it is already.

>>Focusing on minor issue (native plugin) while ignoring the major one (DRM) sounds strange.

I don't think it is a minor issue at all. My biggest complaint with flash has been the security vulnerabilities, and I trust Google/Mozilla with web encryption WAY more than I do Adobe. Can you explain why you consider it to be such a minor issue?

>>And in reality this whole EME thing won't even remove native DRM code. It just will hook it into JavaScript.

I'm not sure what you mean by 'in reality'. Thats it's entire purpose.

>>The risk caused by DRM won't get any less than it is already. I know? Who is arguing the opposite?

>I don't think it is a minor issue at all. My biggest complaint with flash has been the security vulnerabilities, and I trust Google/Mozilla with web encryption WAY more than I do Adobe.

Why do you think Google or Mozilla would be the ones to implement the black box in the DRM? Firefox is developed by a community. The process is public and anyone can identify or patch vulnerabilities -- that's why the security is good. You expect Mozilla to devise and implement some DRM scheme? The actual DRM would end up being created by someone like Adobe again and have all the same security vulnerabilities, because the wider developer community couldn't be allowed to be privy to how it does what it does or it wouldn't be DRM anymore.

One of the problems with DRM is that pretty much anyone who understands security will laugh at you for thinking you can implement effective DRM, so it ends up being built by snake oil salesmen who don't know what they're doing. I don't see how putting it into HTML would change any of that -- all it would do is pollute HTML and encourage the proliferation of more bad code.

It's a minor issue comparing to the issue of DRM. You say - let's worry about plugins, while users will agree to use DRM anyway. I say - if user agrees to use DRM, user can as well use native plugins - such user doesn't care about security or privacy already and there is no point to drag that issue into HTML at all.

I don't think it is a minor issue at all. My biggest complaint with flash has been the security vulnerabilities, and I trust Google/Mozilla with web encryption WAY more than I do Adobe. Can you explain why you consider it to be such a minor issue?

I don't really understand why you at the same time ready to trust some balck box DRM code from Netflix or whoever. Which can do anything of this sort: https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk...

Their code won't have all of the power of flash and silverlight (ie my full user account on the computer). The worst case scenario is their algo's suck and I can decrypt their videos easier.

> DRM by definition implies security and privacy risk

Source please

Simple logic. DRM requires secret (from the user) code to run on user's machine. DRM doesn't trust the user (user is treated as potential criminal) for the sake of content owner interests. Such kind of predisposition makes it very reasonable for the user not to trust the content owner in return and to treat DRM by default as a privacy breaching malware and security risk (until proven otherwise - which isn't possible, since it's a black box). Trust is always mutual. How else can you view this?

because a drm plugin is a plugin,like flash or java applet. You'll have to download plugin DRM A,B or C to make it work.The only difference is that it will use the video tag.