Pretty much everything in the picture is standardized and can be implemented by any browser, but the Content Decryption Module (CDM) can be anything, and is selected by keySystem from the DOM data. There is a single reference system that merely decrypts blocks of the stream. But you can pretty much just dump the decrypted blocks into a file. I'm sure all this will really accomplish is requiring people to download proprietary CDMs, or only allow browsers that ship with them like IE or Chrome to play content. This is a shit solution.
Nice troll, btw.
More info: http://wireless.kernel.org/en/users/Drivers/ath9k
More importantly, allowing video tags to load up binary blobs to do DRM creates a *massive* attack vector. You are essentially giving attackers free reign to execute whatever code they like, and pass said code arbitrary data, of arbitrary size. This will create a minefield of malware.
Programming this in JS is entirely non-trivial, because the language doesn't provide the necessary features to prevent side-channel and time attacks.
The proper features to prevent against these is making sure your wires are coated and injecting random delays into code execution. You can certainly randomly delay js code. And the language can get damn near assembly performance: https://blog.mozilla.org/luke/2013/03/21/asm-js-in-firefox-nightly/
Exactly. A tin-foil hat discussion.
You are the one who brought up side channel and timing attacks on AES, which are used to snoop info from the stream *as an onlooker*, someone outside the AES connection. Do you really think people are going to be snooping random internet connection streams and trying to decrypt them so that they can get free videos? That is a FAR more ridiculous tin foil argument than mine. Furthermore, the person who is decrypting the DRM stream is someone who has full access to the operating system, browser, and crypto library source code. If they want to alter the linux scheduler to make timing attacks easier, recompile the browser so the returned decrypted stream is sent to a file, or just rewrite the cryptographic decoders to dump the decoded streams to files, they can do so trivially.
And if you decide to make this DRM start requiring hardware decryption, well, it will just not catch on, and will recreate the problems of flash and random devices not working. Not to mention that there are already ways to decrypt hdcp streams anyway.
So really, what the hell is the point of all this?
The implementation they seem to want is to have the browser redirect the DRM stream to a software blob that will decrypt it and do "something". God knows what. But it will work on most devices, provided they cross compile plugins. This is the same crappy situation as activeX, where you will are forced to install plugins where you have no idea or control over what they do. If you don't install them, entire pieces of websites will not work. And they will pop up EVERYWHERE.
This is the worst possible outcome, there is a good reason people are fighting this.
What industry do you work in? Because in software, you can get a team to reverse engineer a product and crank out a copy within 3-6 weeks. And if you think that the first-mover advantage is all anyone needs, go talk to NimbleBit about Tiny Tower, or Slashkey about Farmville. And copyright doesn't protect those, because the copyrightable assets - the sprites, the textures, etc. - are all new.
Did you seriously bring up crappy social games in a patent discussion? First of all, games are unpatentable, second of all, Tiny Tower was just a crappy redesign of Sim Tower in the first place, and finally, the whole "Trade Secrets and NDAs!" argument is nonsense since the whole business point of games is to gain as much public viewership/ownership as possible.
The downside is that people looking to see if the game is any good or not on release day will have to go elsewhere, and will probably just end up at some other site that gave the game glowing reviews.
However the only 802.11ac adapter listed on newegg seems to be a Broadcom chip, so you can't really do a damn thing with it. Oh well.
Instead we should develop a simple and robust filesystem that's suitable for embedded systems and have it standardized. Right now there simply isn't an alternative to the FAT filesystems.
It would seem that Samsung has already done just that: http://www.h-online.com/open/features/Kernel-Log-Coming-in-3-8-Part-1-Filesystems-and-storage-1788524.html
Linux now supports F2fs (Flash-Friendly File System), a filesystem that was introduced by Samsung developers in October. It is designed for flash storage media that uses a more basic Flash Translation Layer (FTL) than SSDs for desktop PCs and servers – for example USB flash drives, memory cards and the storage media that is used in cameras, tablets and smartphones.