And now they have paved the way for allowing only Microsoft and Google owned and patent encumbered DRM schemes. What progress.

http://www.w3.org/TR/2013/WD-encrypted-media-20130510/#introduction

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.

Linux already supports SSD-HDD caching with normal drives so if anything, it will probably already work or work with little changes. Otherwise, just pick up a tiny SSD and ignore this solution. http://bcache.evilpiepirate.org/

Nice troll, btw.

And how about when they were 2000 ppm higher?

http://en.wikipedia.org/wiki/Permian%E2%80%93Triassic_extinction_event

As far as I know, every ath9k device supports AP mode. I have one and run hostapd on it.

More info: http://wireless.kernel.org/en/users/Drivers/ath9k

On an open source system, it is just as trivial to get access to the unencrypted stream from the DRM blob as it is to get it from the javascript DRM. Really, I would not be surprised if there was a firefox plugin that allowed you to "Right Click->Save As..." the drm videos hours after the DRM enabled browser launched. The simple fact of the matter is that any software based DRM needs to pass the unecrypted stream to the video decoding or graphics stack. You cannot veer around this, you cannot protect these streams without a fully protected hardware DRM path.

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.

People are arguing that the point of this DRM is to make sure that the average end users are "too inconvenienced" to break the DRM. Well, the javascript solution already does that, and it does not introduce hostile new mechanisms to the HTML standard in the process, nor does it introduce massive security holes to the general public.

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/

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?

I'm pretty sure we already have the bear technology covered: http://en.wikipedia.org/wiki/Bear_claw_(pastry)

How about you guys actually think about it for more than five minutes?

If making sure the video stream was encrypted was the big deal, it can just as easily be down with javascript. AES is not some mystical impossible to implement technology. The purpose of DRM in HTML5 serves only one purpose, to add a "black box" to websites. So how is this DRM actually implemented by the browsers? Who the hell knows. If it relies on software, then it will simply be cracked instantaneously. There will be no point to it. Firefox is open source, you can just recompile it to direct DRM streams into a file or something. If it instead redirects the DRM stream to hardware, well, then you are basically fucked. It will only work with certain computers/devices. You end up in a situation similar to websites requiring flash currently, where some sites simply don't work with your tablet or such.

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.

So basically what they are saying is, you should always stick to people like yourself and never try to expand your views to any sort of 'foreign' cultures or viewpoints? Because the stereotypical Caucasion American is the peak of human development.

Obligatory Mythbusters: https://www.youtube.com/watch?v=3vFcIpzF7pc

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.

I think Game Informer handles this type of game pretty well. For any new games that come out that have deep online connectivity or such nonsense, they hold off on reviewing it until waiting a bit and seeing how the online features play out in the real world. And SimCity was no exception, they still have not released their review of the game. However, I have no doubt that they will just release it once the server problems are over and give it an 8/10 or something.

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.

I recently turned an old computer into a router/wireless AP, and made sure I picked up a proper wireless card beforehand. Currently the only company that has any serious wireless driver support in Linux is Atheros, and the ath9k driver has become quite good, worked right out of the box with hostapd.

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.

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