mr_brown

/me also misses IRC from the times where you could type --<--{@ and you could be sure it looked just the same on the other end. Monospace was the norm, not the exception and all the IRC clients displayed all lines aligned (to the left, however unbelievable that sounds) regardless of the length of the users name. Today I have to pay attention not to write (b) or (c) because it might turn into a beer or coffee. We often forget to appreciate the simplicity of things.

I continue to use Dropbox as my company is paying for it anyway which makes my dropbox limit bigger than my hard-drive will ever be and it doesn't make sense to make my own life harder for political reasons. On the other hand I also use TOR :)

I never wrote too many C or C++ on the desktop, but often ended up refactoring my embedded code from one style to an other. After a while I realized this is simply my way of understanding the code better, and making sure I haven't missed anything. The direction (inlining or breaking things to functions) almost doesn't matter. What matters is working with the code. It's not so strange If you think about it, designers understand things by sketching and taking notes, that's why you see designers run around with their moleskins.

And indeed I just received an email from QNAP:

http://qnap.benchmarkmails26.com/c/v?e=53F45E&c=47C09&l=149F...

I believe there will be plenty of linux NASs that will be vulnerable for the forseeable future. NASs are usually bigger and more functional than routers, they tend to run a more full system. Many of these for exampe run bash as far as I remember: http://www.amazon.com/s/field-keywords=QNAP

import os os.putenv("ANYTHING", "() { :;}; echo bu") os.system("bash")

If this works (and it does) that means it's enough for a CGI script to invoke bash. It doesn't even have to be written in bash.

CDNs are used to deliver static, highly cacheable content, like assets, images, media content, stuff that will be delivered to many users. It is very rare that a website serves this type of content under the same domain as the dynamic content (think cdn1.whatnot.com, assets-myapp.com). In fact for applications with a lot of assets this is a must because of domain sharding and to avoid the overhead of sending the cookies on every single request. Since you need a different domain, you can (you don't have to) use a different certificate, so it's not a strech to use a different private key.

Then there are the applications where security is more important than latency - online banking, payment gateways, tax filing. Those applications don't have too much cache-able content so they simply won't benefit from CDNs.

I also don't see how is this faster. Sure, CloudFlare Keyless SSL is faster than serving the content yourself, but sending that packet over the internet is always going to be slower than not. So now I have a slower (compared to the CDN having my key), more complicated option that requires me to run an additional keyserver and doesn't provide me additional security. The only upside of this seems to be good PR.

Depending how sensitive the content is, in fact if I could I would choose to deliver it over plain HTTP and sign it somehow. That would be best of both worlds.

Edit: I admit I totally missed the point about DDoS protection.