Netflix ditches Silverlight with support for HTML5 video in IE11 | Hacker News Reader

Netflix ditches Silverlight with support for HTML5 video in IE11

thenextweb.com

216 pointsmindstab144 comments

Quoting Netflix, from the article:

  We expect premium video on the web to continue to shift away from using proprietary plugin technologies to using these new Premium Video Extensions.

Quoting the article:

  According to Netflix, Microsoft made this possible by implementing three features in its still-unfinished IE11:

  The Encrypted Media Extensions (EME) using Microsoft PlayReady DRM.

Netflix is using some doublespeak here. Yes, Silverlight was a "proprietary plugin", but they've just shifted to using proprietary DRM with proprietary extensions to HTML5. They got rid of the plugin--great! But they've replaced one proprietary experience with another.

In fact, they've replaced one proprietary experience with an even more proprietary one. Silverlight was available on more than one browser and OS; this is Windows-only and IE11-only. I believe Netflix are already using EME on Chromebooks but they have a different, totally incompatible DRM scheme (Google's Widevine).

But even so, the DRM system was not available cross-platform. Something like Moonlight could process the data but could not play back encrypted video using the Microsoft DRM system.

Each platform will offer a different DRM implementation, but there would be only one HTML5 player and would use the same API on all systems.

I assume that they will continue to use Silverlight on Windows prior to IE11.

"Continue to shift away" doesn't mean proprietary steps can't or shouldn't be taken nor does it mean there will never be proprietary parts behind the scenes. The API to these Extensions are trying to become stable and not proprietary [0]; do you have suggestions or time to contribute? If Netflix is made to simply talk to a ratified API, it is a big step forward from a non-standard API exposed by the likes of Silverlight.

[0] https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med...

You are correct in asserting that the EME should become standardized, and that Netflix is participating in that process. I should not throw stones unless I'm willing to help.

I admit to being conflicted about the philosophical need for such extensions--although I have no pragmatic objections. Netflix makes their coin by selling limited access to an artificially-restricted resource; the resource would probably not exist in its present form without the restrictions.

However, as someone who lived through web development in the 1990s, my brain shut off after reading "away from using proprietary" followed by "Microsoft MarketingTerm".

EME should most certainly NOT become standardized, as the future it will bring is even bleaker than the one we have with Flash and Silverlight as far DRM and compatibility goes. Instead of a few NPAPI-compatible solutions, we'll likely have dozens of proprietary DRM binary blobs that will have even less compatibility on average than Silverlight does at the moment.

This is not the kind of thing that we should be encouraging.

I think your feelings and assertions are valid, but I can't really blame Netflix here, which was my reaction, and I don't really think you meant to paint them in that light. I feel they are hamstrung between staying profitable and trying to court the dinosaurs that are content providers.

It always strikes me as odd that it would appear the "internet crowd" would both like to abolish advertising (re: commercials) _and_ DRM (re: subscriptions). I don't know that Netflix or Steam exists without the later, and I much prefer the "price" I pay for that "burden" over the alternative(s?).

And I have to say, it's hard for me to cast stones at MS for the innovations IE5 brought to market, in the late 90s. It's pretty crummy to subject MS to feelings that only manifested many years later and only because of things they didn't do -- continue supporting and innovating in the browser space. We're just pissed it was so good that people could hold onto it until pried from the cold, dead hands.

Why do you equate DRM with subscriptions? It's perfectly possible to have subscriptions to content without DRM.

A DRM-free subscription service would immediately lead to a ripper tool that would download everything in one month, which would immediately lead to Hollywood studio execs pitching hissy fits.

It's not like having DRM is really stopping piracy, especially in Netflix's case. For example their new original series of House of Cards and season 4 of Arrested Development were both pirated (I assume using some kind of desktop screen recorder?) and posted online within days of their netflix release. So the use of DRM did not stop people from pirating their content, in only prevented potential customers on other systems, like Linux, from legally purchasing their content.

Those responding to shit, pay close attention to my original quip towards dinosaur content-providers and "Hollywood execs" here. What Netflix wants or not is largely irrelevant; I can't say for sure they would ever consider running their service without some sort of DRM or downloading deterrents. It is clear to me they want to provide a more sane service than other offerings, allowing me to watch what I want without being hamstrung by a DVR, multi-month contracts, and holding back episodes to be played one week at a time and having to hold a subscription for 3-4 months to catch the whole season, or only providing the last 5 episodes and being screwed if I start a season when the 7th episode is airing.

With all that MPAA and the like have done to this industry, I can't fathom Netflix getting to serve much content and for very long if they can't guarantee a strong protection over the content. Obviously there are always ways to circumvent the steps taken, so long as the GPU stream is pipeable.

Content publishers tried to get DRM into broadcast television (the "broadcast flag"). They failed, and now they broadcast everything in the clear. In that case, there was a bunch of push-back against DRM. But Netflix and Microsoft aren't pushing back against web DRM; they're just rolling over and implementing it.

So digital broadcast television started with publishers demanding DRM, and then giving up on it (and realizing that it wasn't actually necessary). The exact same thing happened with music. And it's happening with ebooks too. But for some reason, you think that web video is different? And you advocate giving up on it without any real fight.

You may not know what advocate means, but it can take steps to eradicate DRM, as if it is really always a bad thing.

Do I think web video and broadcast TV are different? Absolutely; definitely; unequivocally, yes. Obviously. Maybe not for technical folks; maybe not when usenet or FTP trading was your only option for content not music; but nowadays, torrent software and search is really damn easy and free. Broadcast also comes with a landslide of garbage between 95% shit channels and 33% commercial times; Netflix does not operate this way.

I think ebooks and music are totally different ballgames. You'll pay more for an ebook or mp3 album than you will for a month of Netflix; you think they can service you like that without some guarantees to content providers? I really don't know, but I know some of you are up in arms about Netflix having DRM, when it really isn't harming anyone. If you want to own the content, go do that; Netflix is only offering a non-ownership service.

$8 for 24/7, front-running picture-quality, enormous-catalog of content; it has DRM; it _never_ gets in the way of the service; it frankly works so good that owning the content would provide nigh a worse experience. Can you really explain to me the downsides to how Netflix has implemented DRM? What if they offered an additional cost to be able to download content for offline use, which is about the only thing I can conceivably imagine some might have reservations?

> it _never_ gets in the way of the service

... if you use a supported platform. In other words: It never gets in the way of the service for you

Until recently, running it on Linux at all was not feasible. Even today, it requires running it in Wine or a VM. The only reason this is the case is because the DRM prevents us from using a standard player.

That is the downside of DRM. And for me it's the reason why I won't touch Netflix even if it becomes easier to use it under Linux as long as they keep at the DRM nonsense.

I learned this the hard way with iTunes, and I am not touching DRM'd content again unless I can effortlessly break the DRM (so e.g. I do buy DRM'd books of Amazon, and promptly uses Calibre to secure a DRM free copy; but I've still not made the move to Bluray because it's too much hassle)

> You may not know what advocate means

advocate, verb: publicly recommend or support.

In this thread, you've been publicly recommending and supporting the idea of giving up on fighting web DRM.

Web video and broadcast TV are the same in terms of the effect of piracy, and in terms of the need for DRM. A TV show pirated from a broadcast stream is almost exactly the same as a TV show pirated from a web stream. DRM isn't necessary over the air, therefore it isn't necessary on the web.

Requiring DRM for web content but not for broadcast content is like locking one door but leaving another open. The broadcast door has been open for years and Hollywood still hasn't imploded. Web DRM isn't necessary for their business; they're just trying to use it to get more control.

One strange choice they have made is restrict content depending on the device. PCs can play more shows than consoles that run netflix apps.

"A DRM-free subscription service would immediately lead to a ripper tool that would download everything in one month"

Why would anyone bother doing that when they could just download what they wanted over bittorrent?

they would bother because it's not easy for rippers to get eg HD video rips before the bluray version of the movie is out. So at the very least, it's making rippers' work much easier, and it brings the date when HD content is available on torrent from "whenever bluray is released" to "whenever it is available for streaming", which we are all crossing finger to become "when it is released in theaters".

Whatever gives you that idea? HD rips usually show up a few hours after an episode first airs.

Movies are a much different story.

Why is a video stream featuring a movie different from a video stream featuring a TV show?

Early movie rips tend not to be in HD, as many exhibition leaks are still standard definition. It takes longer for an HD rip to appear for movies.

And how does that factor into whether Netflix should use DRM or not?

I can walk down any number of streets nearby and get approached by people with bags full of professionally pressed DVD's of movies pirated by filming a cinema screen. Or I can install a bittorrent client and get HD content everywhere anyway. Access isn't stopping those who are willing to put in a minimal amount of effort to get the content.

It does, however, stop people like me from subscribing to their service, as I refuse to pay for a service that is hampered by DRM this way, as from long experience as a Linux user, relying on formats that are not open and unencumbered is pretty much guaranteed to cause annoying hassles for me in some way or another with uses that I consider completely reasonable, and that does not include storing copies or distributing the content to others in any way.

It's a nice try from Netflix. Dropping Silverlight is great. But it's not enough.

GOG is a DRM free game distribution service, and they seem to be doing well even despite the ease of pirating a DRM free game.

GOG is not a subscription service where you could download every game for less than $10.

They will still be rendering the interface and probably the video with standard HTML5 components, in fact even the DRM - Browser mechanism is standardized. It's just that the DRM code itself may be proprietary. So this is still a step forward.

In what way is it a step forward? Okay, they can now use default video codecs in their proprietary plugin, instead of the same codec being used in Flash.

So does that make it anymore cross-platform than Flash was? And now instead of having "one" monolithic proprietary plugin, it's now more "decentralized" and you'll have to use "many" such proprietary plugins from Netflix, from Hulu, from Amazon, and many others, that may or may not be cross-platform.

Why is the news only about IE (11 even). Does it work in Chrome and Firefox, too?

Well, the good news is that as an end-user you'll probably only have one monolithic proprietary chunk of code that's even conveniently integrated into your web browser. The bad news is that you'll have to hope that all the DRMed video sites you're using support the proprietary scheme your particular browser and platform use. In this case, it's Microsoft's PlayReady DRM.

Also, the codec used is actually part of the proprietary blob, and there are no requirements as to which codecs or containers a particular DRM scheme supports, so in theory every DRM scheme could require a different, incompatible proprietary codec and they'd still all be 100% standards compliant.

There is also no reason to think that these binary blobs will be built for platforms that the video providers have not given two shits about in the past. Anyone who is supporting this stuff because they think it will get them Netflix on a GNU/Linux desktop (not ChromeOS or Android) is crazy. That's not what this does, and they don't care about supporting us.

So far, Google's binary DRM blob isn't just restricted to ChromeOS either; it only runs on official Chromebooks running the official Google-provided image that haven't been rooted.

AFAIK it doesn't care if your Chromebook is rooted. My Glacier Snow Chromebook is "rooted" and Netflix (the reason we bought it) continues to work well on it.

Isn't ChromeOS running on GNU/Linux?

ChromeOS runs on a Linux kernel, but the entire experience is very different from what you would normally expect from a Linux distro. I call the more recognizable distros "GNU/Linux" to differentiate.

Maybe, but quite a few stuff (enough to implement DRM) is different.

Theoretically one piece of it is now cross-platform, however the core functionality only works on one platform, and actually seems explicitly engineered to be incompatible with the Ubuntu computer I have hooked up to the TV in my living room.

This is a pretty disappointing move, since I'm pretty sure Netflix will never run on that computer, and Netflix doesn't care.

Which is why DefectiveByDesign launched a campaign against them: http://www.defectivebydesign.org/cancelnetflix

I think Google has been first in implementing the proposed EME standard in HTML5 video. The ARM Chromebooks have been already using it to see Netflix video since a few months. Netflix can use Silverlight in IE11, but ARM Chromebooks don't have an alternative way of support and don't forget that Youtube doesn't like people easily downloading their videos like they do now.

http://hothardware.com/News/Netflix-Backing-HTML5-But-Not-Wi...

And I think Chrome nightlies had the web DRM in place but were not enabled by default? Don't quote me on that.

Anyway, I think Firefox will be forced follow Chrome and IE now to implement DRM in HTML5 video. Firefox does not have the market power it once had thanks to Chrome.

Remember how the whole H.264 in HTML5 support thing played out for Firefox? They were on the side of not supporting it, and Google said it would remove it from Chrome, but that never happened, and Mozilla finally got tired of the effects of "Firefox doesn't support this site's video, let me use a browser that does" and added support.

The same thing is pretty much guaranteed to happen with EME as sites start using EME to stream video and IE, Chrome and Safari add support.

The "good news" is that they are using web crypto, and knowing how many will try to crack Netflix's streaming now, this means the developers behind web crypto will be getting a lot of feedback and "bugs" to fix, and eventually make web crypto stronger, and maybe some day we can finally use it for e-mail and storage services.

This doesn't make sense, because you have to have the key to play the video. Cryptography and security practices are the medical science to DRM's snake oil, and I don't really expect this usage will help security at all.

A "known key" attack isn't an attack at all, cryptographically speaking.

In addition: it doesn't even look like they're meaningfully using "web crypto" APIs, but rather the much-debated proposed DRM blob APIs.

I only know the basics of crypto, but couldn't the key be hidden and itself encrypted within the machine code for IE, and then authenticated via HTTPS? I would think this is mainly a problem for open-source browsers, which would require closed-source plugins.

The user has access to the machine code for IE.

However, you are onto the right track. One proposed solution to DRM (that I believe was impleneted with DVD and/or blueray) is to establish a chain of trust in the hardware. The idea would be that you send an encrypted signal to the monitor, and the monitor has a tamper resistant decryption chip with its own key.

Obviously, this only gets you so far, as once someone cracks the chip (or acquires the master key through other means, as happened with DVD), then the entire scheme is broken.

Ultimatly the problem is that you need to provide the user with enough information for them to be able to view the decrypted content, while at the same time not let them know the decrypted content. The real question is how difficult/expansive can you make it to bypass. Unfourtantly, in every system I am aware of, once one person figures it out, it become cheap and easy for every else; and coming up with a new crypto-system is a great way to get the academic community to try and break it.

The hardware DRM you are talking about, is HDCP. It is required for Blu-ray.

Thanks.

For anyone interested, it looks like HDCP has been broken on pure crypto grounds [1]. As much as I agree that this type of DRM is fundamentally not possible, I'm still kind of surprised that their was a direct attack on the crypto.

[1] http://www.cs.rice.edu/~scrosby/pubs/hdcppaper.ps

You can't hide a key for long. And you can't encrypt a key without another key.

But doesn't client-side encryption already function at the OS level? For instance, the keys for FairPlay and the App Store have not been cracked, as far as I know.

FairPlay has been cracked a lot of times, there have been many tools to remove the DRM from FairPlay encrypted songs/videos/books.

App store apps have also been cracked in that their keys have been stripped, on a jail broken phone you can run all those apps without needing a valid key.

FairPlay for video still hasn't been cracked (I wish it were). But I take your point.

FairPlay video was (kind of) cracked a few years ago I was in the habit of decrypting TV episodes using Requiem so I could watch them on my Linux netbook. You had to decrypt the files on a computer with iTunes installed though.

I don't know if Requiem has been keeping up with the latest iTunes releases.

One has to wonder whether asm.js will play a role in playing encrypted content in the browser. Surely decryption on the fly is feasible?

I believe that web crypto is an API implemented natively in the browser, there will be no need to implement decryption in javascript.

Thank god. I hate Silverlight. It's so resource intensive.

EDIT: I just felt like ranting against Silverlight some more. The only reason I use Silverlight is because of Netflix. I run it in Chrome on my Mac Air. Besides being buggy and resource hungry, it also doesn't stop my Mac from dimming even when watching a video in fullscreen, unlike YouTube videos, etc. (Could this be because it doesn't use the graphics card?) I watched a movie on it the other day and the audio/video kept going out of sync due to lag (not a network problem) and I had to reload the page every 5 minutes. Aaargh! Death to Silverlight!

Firstly, this is on IE11 on Windows so it won't affect your Mac. Secondly, you have no idea if the resource intensiveness of this proprietary DRM video decoder will be any better than Silverlight's.

Are you implying that Flash is any less resource intensive or buggy?

Where did he mention Flash? HTML5 video is the alternative being discussed here, and it's far less resource intensive and buggy (depending on the video format), from my experience at least.

To be fair, he mentioned Youtube, which even in Chrome uses Flash by default.

http://www.youtube.com/html5 granted it doesn't always work.

AFAIK, HTML5 video on a Mac pretty much requires it to be H264, which Apple has optimized their whole stack for.

Well that's what you get for running microsoft apps on a mac, now you know what windows users go through with itunes.

For some odd reason each company makes their apps really buggy and annoying on the other's platform... weird.

I managed to completely resist installing Silverlight for however many years it's been available, and what finally got me was that I needed it to watch the new Arrested Development.

I just watched it on my T.V., the ipad also works without forcing you to install Silverlight.

Don't forget buggy as hell! It's got that going for it, too.

Your perception is not based at all on factual evidence. I see people all the time complaining about flash/SilverLight performance problems. The reality is that no browser has so far outperformed either of these plug-ins in terms of CPU or memory utilization.

You might want to use this as a reality check. What other "truths" in your life are actually true and not merely biases created by the agenda's of others around you.

Let truth alone influence you, question all hearsay. Be a leader, not a follower.

Wtf??? I'm ranting about my personal experiences... not parroting others'. Can you say the same?

Are "Premium Media Extensions" also plugins? Because if so this didn't really get much better. It still means Linux users could be on the backburner until someone decides we can watch too. Until Mozilla and Google are on board this doesn't necessarily seem better from a "universally available" standpoint.

Yes. There is no reason to think that things which did not work on Linux before will suddenly start working just because this API is being crammed into HTML5.

I'm not necessarily saying that Linux will ever be a high priority, but having to only provide a PlayReady Media Extension for a few browsers on Linux is a much more reasonable effort then providing the whole Silverlight or Flash runtime.

Linux will never get a PlayReady Media Extension. Linux users control the kernel of the device. Even if hypothetically TPM technology or similar could be used to play video "securely" nevertheless (with hypothetical future tech), it would still be too great a risk to let it on to such a "compromised" system.

You could delegate decryption to the video-card itself. This would also prevent the attack vector of running a 'secure' system inside of a transparent VM.

Not to mention the fact that Linux has some very smart people, with a history of reverse engineering stuff for compatibility; and breaking any advanced DRM system is an honor onto itself.

That was the hypothetical future tech I had in mind. AFAIK, it does not exist. It would also need to integrate with the audio, while still letting DRM-unprivileged processes manipulate the location on the screen, volume, pause, fast forward, etc etc etc. It's a pretty tall order to make all this work on a system where the user is controlling the entire rest of the software stack, and absolutely, positively ensuring that there is no way whatsoever to get the audio or the video, even though the user has every other bit of hardware at their disposal, in what are presumably numerous distinct hardware configurations. It's certainly theoretically possible but it would take numerous released-to-the-public iterations to get right and probably a few more for this to be remotely stable.

>ensuring that there is no way whatsoever to get the audio or the video

I await the patent on how to DRM photons.

Relating to the rest of your points, I am not convinced that it is that difficult to mix protected and non-protected graphics. The untrusted software tells the graphics card a square region of the screen where the movie should be played, and streams the cipher text to the card. When the graphics card goes to render a frame for the physicall display, it first renders the the protected content, then renders any unprotected content from the software. Where the two overlap, the protected content simply gets hidden by the unprotected content. Obviously, all of this rendering would happen in an undisplayed buffer, so the user only sees the finished frame.

Yes... the spec is simple. I don't deny that. But in a world where the leading graphics vendors can barely write drivers that don't crash on their own hardware... who, exactly, is going to get it all right? On real hardware? That people will buy?

It's all simple and obvious until you try to implement it on real hardware.

They would have no control over the rest of the stack. If netflix created a linux build of a DRM binary that worked with their service then it would become the tool of choice for everyone that wanted to rip/upload to usenet the latest Netflix exclusive content. Also they frankly just don't care about linux users.

If this were something that they were interested in having, they would have had Netflix on Chrome on 'regular GNU desktop' Linux months ago when it started working with Chrome on a Linux kernel with ChromeOS.

If an extension to XvMC or the proprietary ATI/Nvidea equivalent supported a protected path for media content, which could theoretically bypass the kernel by sending ciphertext directly to the renderer, then Widevine or another DRM system could be supported on GNU/Linux.

Seems possible, though theoretical. I would not expect to see this unless somebody was paying for it (no particular reason for ATI/Nvidia/Whoever to go out of their way to support such a thing), meaning that I will not expect to ever see it in "normal" Linux distros (perhaps in "ChromeOS style" locked down distros being marketed with their own completely separate branding).

Proprietary graphics stuff in Linux has always been a world of hurt anyway (despite the lower performance it was a godsend when progress on the radeon drivers started to accelerate). I would expect few Linux users to be thrilled about compromising their streamlined modern Linux installation to watch netflix when a separate Roku or smartphone would do. (I know I would never go for this proposal. It would not be worth the grief to be plunged back into 2005. Not on the computer that I try to get work done on...)

This was the spoken about way of achieving the goal on the HTML WG mailing list, if that is required, on Linux (note Flash doesn't do that currently and many are happy to licence content for it despite that, so this may well never come to fruition).

Does it matter what tool or OS people use to get rid of the DRM?

Since DRM is all about making it inconvenient/difficult to delay the inevitable, yes.

They are not going to do anything that will only help a very fraction of their subscribers but would streamline, let alone automate, the ripping process.

But it surely already is an automated process?

The only reason for it not to be ought to be that netflix doesn't have any content of interest or of too low quality.

Moreso than a few pipes and a hacked up curl? I doubt it. My impression is that the current preferred method is ripping the decoded video stream from an unsecured cable.

The situation for Linux users is better with Netflix on Silverlight, because Silverlight runs in Wine. With EME or PME or whatever they want to call it to make it sound less onerous, Linux users have no hope.

Premium Media Extensions (which we should probably just call Proprietary Media Extensions) sounds like a marketing name for EME+CDM. We should not let major media providers co-opt the term "premium" to mean "encrypted" or "blessed by Hollywood".

Windows in VirtualBox :)

Here's the EFF's formal objection to including DRM in HTML specs: https://www.eff.org/pages/drm/w3c-formal-objection-html-wg

This is interesting. Google still hasn't completely converted over to HTML5 video for YouTube. You've been able to opt in to the trial for years now (http://www.youtube.com/html5). But it seems that more than half the videos I watch are still using the crappy old Flash player.

Content wise, YouTube has way more content to convert to be able to take advantage of HTML5. I wonder if Netflix is having to convert video on the backend for this as well. Or if they're just using a base format that allows for delivery over Silverlight and HTML5 without having to re-encode and store. But they wouldn't really be re-encoding on the fly though, would they? That would seem to be hugely resource intensive. Does anyone know more about how they're doing this on the backend?

> But it seems that more than half the videos I watch are still using the crappy old Flash player.

That's because of the ads. With things like ClickToFlash or youtube-dl, you notice that most videos are actually available as MPEG4 and/or WebM.

The Flash player is playing the exact same H.264 video that you could get with the HTML5 player.

Then why do they bring up the Flash player when I've opted in to the HTML5 preview?

Probably because they haven't implemented all of the same features in HTML5 as they have in the Flash version, such as ad overlays and annotations. It's up to the person posting the videos whether or not to use these features, and if they do, it forces the player to use Flash.

For ads (and DRM).

The HTML5 player can play ads too...

>I wonder if Netflix is having to convert video on the backend for this as well.

They won't. They're using H.264 video, which all major browsers can play in HTML5 <video> tags now. Not so sure how they'd handle stuff like multiple audio tracks though - as far as I know they're bit of an issue now even if muxed with the video, and if you don't want to load extra audio tracks then you're pretty much out of luck since there's no decent way to play video and audio separately in sync with HTML5 at the moment (a combination of <video> and <audio> isn't exactly that reliable for this).

I'm guessing that older YouTube content may not have the source upload files available... some may be relatively poor quality, or not frequently watched. Re-encoding from the "flash" version of the videos would yield a worse result. Some of this may be from before Google bought YouTube. All speculation of course.

Nice Frank Lutz-ian reterming of HTML5 video DRM extensions as "premium extensions".

Netflix is indeed using some slippery and perhaps contradictory wording that has passed through at least one marketing filter.

Although we may interpret "premium" to connote "better", the usage meaning "something you have to pay" is accurate.

Perhaps we could take back the language and start referring to the extensions as "Media Fee Extensions"?

I think it has nothing to do with being paid - it's not like you pay for the plugin itself. Plus, they wouldn't want you to think about having to pay for it anyway.

I think in this case it's just a meaningless word introduced to make it sound better than the "proprietary plugins" like Silverlight and Flash. I think their alternatives were naming it like "Awesome Viewing Experience Extension" or "Netflix True HD Vision Extension", or something like that.

In each case they wouldn't mean what they normally mean, and would be used in a misleading way just to give you a "good feeling" about having DRM on the web.

The issue is there's already accurate words to describe these extensions; DRM.

But the accurate words have negative connotations so they avoid them on purpose and try to use positive ones which may be technically accurate but wouldn't be how anyone would normally choose to describe them. This is the definition of spin.

I think we should just all start calling these extensions either something like "Digital Restriction Extensions" (DRE for short) or just plain and simply "DRM Extensions". If misleading garbage like "Premium Media Extensions" were left to the likes of Netflix press releases, reporting on the subject would be much more truthful.

Netflix will be taking advantage of EMEs for HTML5 DRM in IE11.

Microsoft has not confirmed IE11 will be supported in any OS other than Windows 8.1.

Older versions of IE, including IE10 on Windows 7, will still require Silverlight, meaning it still will not die.

If this is to be a nail in Silverlight's coffin, it's a very tiny one.

Edit: Per freehunter's comment below, Microsoft has confirmed eventual IE11 support for Windows 7.

Many sites are reporting that Microsoft has confirmed IE11 support for Windows 7 [1]. The question is when, not if.

[1] http://www.pcworld.com/article/2043129/internet-explorer-11-...

Is Microsoft really releasing a new version of IE with support for only 2 major (8.1, 8.2, etc are just service packs anyway) versions of Windows back?

I guess that's good for everyone, though, since it means IE won't have a huge market share anymore.

I really don't think it's as big of a problem as you're trying to make it out to be.

http://en.wikipedia.org/wiki/Usage_share_of_operating_system...

Your point? XP is essentially on life support at this point, and even that ends in a year. General support for XP ended in 2009. At that point, not supporting it in terms of software compatibility would be fine in my books.

Supposedly the speed of IE 10/11 comes from not having any portability or backwards compatibility layers.

They should say that it comes from being a shitty browser that lacks many apis, tools, extensibility, stability that other browsers have; just to get a cover-up for the first time.

It took an awfully long time to get IE10 for Windows 7. Hopefully this time it will go faster.

The ideological debate is potentially interesting: Does DRM belong in HTML5?

(and yes, it's hard not to view the Netflix/MS situation cynically)

That said, ditching that godawful Silverlight plugin, is probably a welcome change from the customer experience perspective.

Incidentally, that puts another nail in the coffin for Adobe Flash, which is still widely used for DRM'd video streaming.

I never thought I would say this, but I think I would prefer Adobe Flash and other browser plugins instead of making DRM a built-in feature of the web.

At least as a browser vendor you just had to implement NPAPI to get Flash -- EME requires contracts and money.

Am I the only one who, given the vast proliferation of mobile and TV-connected devices with Netflix clients over the past few years, can't even remember the last time they used the Silverlight app to stream something?

I used it every day because I find all HTPC media center implementations of netflix to be lacking so I use it straight through the browser.

I don't know but I use it every day. It is how Eurosport delivers its streaming channel to Windows. There is an Android and iOS version. The Android one doesn't allow the 3 hours rewing feature that Silverlight does and drops frames rather than buffering.

http://player.eurosport.com/

And so in a small part the MSIE team is back to "creating" new "standards" for the web because they were the first on board so the get more input to the final product. I hate to say it (in part because I'm not 100% sold on web DRM, tho netflix on Linux will be nice...) but by being sticks in the mud over the issue Google and Mozilla are now going to be following IE's lead for probably the first time in a while

Also, standardizing EME will not bring Netflix to Linux (the most common misunderstanding around EME). Please name one CDM for a Linux distro other than ChromeOS. Widevine is available only in ChromeOS, and Playready is only available in Windows. So looks like you have to buy one of those Operating Systems to have Netflix.

These proposed changes to the standard do not add DRM. Rather they add a standardized interface between javascript in a browser and a proprietary binary blob that actually contains the DRM. Why do you think this would improve the situation of Netflix on Linux?

All you are going to have is a fancy API with nothing to plug into it.

Google implemented DRM in Chrome before IE did.

The key specs for all this to work are:

* Web Cryptography API[1], edited by Mozilla and Google

* Media Source Extensions[2], edited by Google, Microsoft and Netflix

* Encrypted Media Extensions[3], edited by Google, Microsoft and Netflix

These are not pseudo standards pushed only by Microsoft. ChromeOS already supports two of these specs.

[1] http://www.w3.org/TR/WebCryptoAPI/

[2] http://www.w3.org/TR/media-source/

[3] http://www.w3.org/TR/encrypted-media/

> tho netflix on Linux will be nice...

What's annoying is that you can run netflix on linux right now[1] via `netflix-desktop`, which combines `firefox`, `silverlight` and a modified copy of `wine` to access their site.

If they switch over to these new plugins and the plugins are IE-specific, we'll be locked out again.

[1] * https://launchpad.net/netflix-desktop * http://www.compholio.com/netflix-desktop/

Over my dead body.

Can we stop calling video that uses extensions "HTML5 video" (even if it may be part of the HTML spec)? I suggest we call it "EME video".

I'm curious. With all the railing around Flash and its obsolescence, is Silverlight destined to go the same route?

I don't hear much about it anymore, particularly in the enterprise and the video provider space in which I currently work, where things like Verimatrix and Azuki are mentioned far more often than Flash/Silverlight.

Anyone have any intel on any major projects that use Silverlight aside from Netflix?

As pointed out by many, this is even more proprietary than any plugin. Microsoft are fricken idiots, they are trying to be hip and open standards etc but nobody is going to buy it, at the same time they are annoying everyone who couldn't care less and probably don't even know what a plugin is, on top of disenfranchising legions of developers.

You say nobody is going to buy it, but doesn't this article show that Netflix "bought" into it?

Sorry for the ambiguity. My intention was to communicate that I didn't think anyone would buy the idea that MS is hip and an open-standards advocate.

Nice!! I've been holding out on downloading a new version of Silverlight because I heard this was just around the corner. Now I get to uninstall the last MS product on my machine!

>Now I get to uninstall the last MS product on my machine!

...Except you'd have to install Windows 8.1 and use IE11 in order to use the "wonderful" HTML5 Netflix with their proprietary DRM blob that has even less compatibility than Flash and Silverlight.

This works great on Linux, this is true HTML5 support (or they say it's HTML5 - and it works):

http://www.videojs.com/

What does this mean for anything not running IE11?

Netflix already support ChromeOS on Samsung Chrome books using this method. Only that Chrome doesn’t support an end to end solution, as it doesn’t support the Crypto API, so Netflix rolled their own. They also support a different DRM plug-in.

As this involves three different specs, which are all from the W3C, this means that it will work in any browser that implements them, and supports the DRM that Netflix uses.

Microsoft and Google are already on board. I expect Opera will inherit this from Blink/Chromium. As both YouTube and Netflix support this already, I wouldn’t be surprised to see WebKit and Firefox/Gecko implement it eventually.

Hope that your browser supports whatever method Netflix is using

In the near term, nothing.

Can you say you are supporting HTML5 if you just get in bed with Microsoft?

I don‘t see why not. Two of the editors of the HTML5.1 spec are Microsoft representatives: http://www.w3.org/html/wg/drafts/html/master/

If you have to say they will support HTML5 but only on xyz browsers or OS'es then it's like a gas station saying they support Regular but only for Ford and General Motors cars. The reason I can say that is any _other_ site that claims HTML5, works fine on my Chrome browser on Ubuntu.

Netflix was and remains DRMed, which is enough of a reason to avoid them.

This means netflix might finally come to the raspberry pi!

Far more exciting than IE11

No, it won't. As far as compatibility goes, EME is even worse than something like Silverlight. This should be evident just from the fact that in order to use HTML5 Netflix, you either need a) IE11 on Windows 8.1 or b) an official Google Chromebook with Google-provided image and which hasn't been rooted. In comparison, even Silverlight has a pretty amazing track record as far as compatibility goes.

EME, MSE, and Web Crypto are very new specifications. They’re just starting to be rolled out in browsers. They’re not going to be rolled out everywhere overnight.

H.264 video codec is on pretty much every major browser now, including Firefox. This wasn’t the case when browsers first supported the video element. It is a similar situation to EME and friends today. Including the potential licensing fee (I assume vendors have to licence the DRM module to plug into EME or get it from the underlying OS in the same way to how they have to licence H.264, but I'm not sure about this area)

Does this mean it will now support Surround Sound?

there's really too much of this going on lately...i hate the path on which we are on....it's a slippery slope.

About effing time

About time. Now if they only added some good movies...

Exchange one crappy plugin for another... Way to innovate.

Reply on news.ycombinator.com