Certainly, the initial setup of a linux based router is a bit of work, but once you have it all configured, there is literally 0 babysitting aside from periodically installing distro updates if you want. I run fedora on mine, just type in sudo yum update once a week... couldn't be easier.
I actually was really liking the prospect of using this as a router. I currently have an old PC doing this, but it is not the perfect solution (power hungry, for one). The ethernet driver looks like it can do BQL which is great for the fq_codel qdisc, and the wireless card seems capable of AP mode (not 100% sure on either of these... just did a cursory glance). The main issue is it only has one ethernet port, would be perfect if they added an optional second or something, as I'd rather not add one via usb.
3.8 is what Ubuntu is stuck on at the moment I believe, probably what he is using... Their kernel updates are pretty barebones too, it is basically just the plain old 3.8.0 kernel. GP, you should at least try a fedora liveCD or something, they package a pretty solid build of Linux these days. And if you were using the latest Ubuntu version, I'll just say I had a bunch of issues with it too, so please try something else.
The recipient and sender addresses are still publicly readable, though. Sure, they could just tap the internet line itself, but it is more fun to thug it up and threaten people. Then they install logging software onto the servers themselves gives them a nice easy way to build massive graphs of who is talking to whom. Furthermore, they can log all the encrypted emails and, if they ever suspect some individual person, attempt to hack into the persons computers to get their public/private keys. Also, they probably log IP addresses too, to help physically identify individuals. There is quite a bit they can do without reading the contents of the emails.
Anything in or past the CDM is completely non-standardized and can be implemented however the CDM creator wants, so I very much doubt that there will be a layer that enforces isolation. You would also need to define a set of platform APIs for each platform in this supposed layer, like VA-API, VDPAU, Microsoft's secure content path, Xv, ffmpeg, mcrypt, whatever APIs there are to access some trusted computing path... there is a huge list of APIs that they could need or want, and none of them are listed in the standard, which to me, again, strongly implies they will be able to do whatever they want.
A single decrypting module that runs completely arbitrary data. And it will almost certainly load up that data just like it does images, imediately without asking the user to proceed. The potential for abuse there is quite massive. Furthermore, how common will it be to ask the user to install a new CDM? If it becomes fairly common, we will see malware breaches the likes of which haven't been seen since ActiveX.
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/
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.
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?
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.
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.
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.
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.
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.
The nice thing about gentoo is if you are running gentoo stable (no ~ keywords) it *generally* avoids these types of problems completely, since the package maintainers wait and see that there are no problems for about a month at least first. It is of course not perfect though, I just had an issue on my gateway last running hardened stable, and the udev upgrade caused a file collision:(.
Slashdot Mirror
Certainly, the initial setup of a linux based router is a bit of work, but once you have it all configured, there is literally 0 babysitting aside from periodically installing distro updates if you want. I run fedora on mine, just type in sudo yum update once a week... couldn't be easier.
I actually was really liking the prospect of using this as a router. I currently have an old PC doing this, but it is not the perfect solution (power hungry, for one). The ethernet driver looks like it can do BQL which is great for the fq_codel qdisc, and the wireless card seems capable of AP mode (not 100% sure on either of these... just did a cursory glance). The main issue is it only has one ethernet port, would be perfect if they added an optional second or something, as I'd rather not add one via usb.
3.8 is what Ubuntu is stuck on at the moment I believe, probably what he is using... Their kernel updates are pretty barebones too, it is basically just the plain old 3.8.0 kernel. GP, you should at least try a fedora liveCD or something, they package a pretty solid build of Linux these days. And if you were using the latest Ubuntu version, I'll just say I had a bunch of issues with it too, so please try something else.
The recipient and sender addresses are still publicly readable, though. Sure, they could just tap the internet line itself, but it is more fun to thug it up and threaten people. Then they install logging software onto the servers themselves gives them a nice easy way to build massive graphs of who is talking to whom. Furthermore, they can log all the encrypted emails and, if they ever suspect some individual person, attempt to hack into the persons computers to get their public/private keys. Also, they probably log IP addresses too, to help physically identify individuals. There is quite a bit they can do without reading the contents of the emails.
Anything in or past the CDM is completely non-standardized and can be implemented however the CDM creator wants, so I very much doubt that there will be a layer that enforces isolation. You would also need to define a set of platform APIs for each platform in this supposed layer, like VA-API, VDPAU, Microsoft's secure content path, Xv, ffmpeg, mcrypt, whatever APIs there are to access some trusted computing path... there is a huge list of APIs that they could need or want, and none of them are listed in the standard, which to me, again, strongly implies they will be able to do whatever they want.
https://dvcs.w3.org/hg/html-media/raw-file/eme-v0.1/encrypted-media/encrypted-media.html
Note the line between CDM and Platform in the image.
The CDM is allowed to defer to arbitrary platform APIs, as proposed by the spec. To me, this stronly implies that it will not be sandboxed.
A single decrypting module that runs completely arbitrary data. And it will almost certainly load up that data just like it does images, imediately without asking the user to proceed. The potential for abuse there is quite massive. Furthermore, how common will it be to ask the user to install a new CDM? If it becomes fairly common, we will see malware breaches the likes of which haven't been seen since ActiveX.
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.
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?
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
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.
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.
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.
The nice thing about gentoo is if you are running gentoo stable (no ~ keywords) it *generally* avoids these types of problems completely, since the package maintainers wait and see that there are no problems for about a month at least first. It is of course not perfect though, I just had an issue on my gateway last running hardened stable, and the udev upgrade caused a file collision :(.
The fuck? I was expecting something like http://www.youtube.com/watch?v=rVIZx3Cl78k but it was just a bunch of old people dancing?