I don't see the parallel as intended to put Napoleon down, but instead to attribute the same force of personality to Hitler. As someone who never met either man (perhaps that's obvious :), I'm not sure the connection works with me.
Can someone explain to me how the US has jurisdiction over Credit Suisse? I see how they could have gone after the individual tax fraudsters (American citizens), but how can they police foreign banks?
I take this sentiment a bit further - unless it's throwaway-cheap, the reviews and word of mouth are stellar (they're usually not for any but the biggest hits), or the concept immediately clicks for me, I will pirate the game to try it out. If I like the pirated version, I _usually_ purchase the full game (but not always). Not having reasonable demos just increases game piracy.
No. If I shut down my laptop, my hard drive is encrypted and keys are no longer in RAM (modulo a cold-boot attack, but that is only really useful for <30 minutes after shutdown without preparation).
The obvious solution for this would be for Android to expose "derive random numbers from image frame" as a permission. But this is unnecessary, because they can just seed /dev/random from this source at boot (or if the device is unseeded).
That said, mobile devices really aren't lacking in entropy sources. With all the radios and sensors in a modern smartphone, why do they need additional methods to generate random numbers?
For information security purposes, a cryptographically secure PRNG is typically at least as secure as the encryption algorithms that it protects.
2. You don't really need that much randomness. After your machine has been on for a while and has seeded correctly, /dev/urandom is just as secure as /dev/random. Entropy is not gasoline - it does not disappear as you use it.
StartSSL's default usage mode is to generate private keys on their website. Yet another horribly insecure system.
I'd much rather that people used self-signed certs (and browsers had certificate pinning) by default, and could then step up to real CA certificates. Self-signed certs provide almost the same amount of trust that StartCom does.
Each hex character represents 4 bits. That means that a 7 character string is 28 bits. That's about 268 million possibilities. On average, it would take around 134 million commits to get one that started with "badc0de".
My favorite thing about tarsnap is how damn reliable and trustworthy Colin is. If I see tarsnap start to move towards whatever fad all the other SaaS platforms are following today, I'll probably assume that they're trying to be the next Dropbox. That might be the right decision for tarsnap, but I'd move my backups.
This is my question too. Tarsnap is cool, and Colin deserves to get paid for his hard work, but the cost differential is far too much for me to use tarsnap right now. If they cut their costs in half, I'd be able to afford to use them over raw S3.
It's true. The blockchain is at best pseudoanonymous. If you are careful about how you get your coins, and use a high latency mixer (which don't exist as far as I know, but can be faked by multiple runs through a low latency mixer) and take your profits out slowly, you can make them quite anonymous. While they are a richer stream of data that a purely cash business, they don't have the same hassles (mostly physical size and security issues) as cash.
You can also use something like blockchain.info for slightly better security than coinbase. They do client-side encryption and decryption of wallets. Of course, if you forget your password, your coins are gone. And blockchain.info could always modify their code to steal your coins later. At least they couldn't steal them without you logging in.
But a thin wallet like Electrum is probably your best bet.
I'm not sure if it's a certain way to tell, but try running a traceroute. If your traffic seems to go into Level3's network, that's a good sign that it's not getting rerouted.
Here's what I see from my DigitalOcean droplet.
root@derpy:~# traceroute -I 4.2.2.1
traceroute to 4.2.2.1 (4.2.2.1), 30 hops max, 60 byte packets
1 198.199.122.1 (198.199.122.1) 12.055 ms 12.123 ms 12.314 ms
2 xe-10-3-3-100.edge3.Newark1.Level3.net (4.28.6.69) 0.948 ms 0.959 ms 0.959 ms
3 ae-31-51.ebr1.Newark1.Level3.net (4.69.156.30) 1.396 ms 1.477 ms 1.478 ms
4 ae-10-10.ebr2.NewYork1.Level3.net (4.69.132.97) 1.530 ms 1.630 ms 1.659 ms
5 ae-62-62.csw1.NewYork1.Level3.net (4.69.148.34) 1.465 ms ae-82-82.csw3.NewYork1.Level3.net (4.69.148.42) 1.464 ms ae-62-62.csw1.NewYork1.Level3.net (4.69.148.34) 1.390 ms
6 ae-1-60.edge2.NewYork1.Level3.net (4.69.155.16) 1.363 ms 1.389 ms 1.395 ms
7 a.resolvers.level3.net (4.2.2.1) 1.456 ms 1.466 ms 1.421 ms
Anecdotally, at my last job, we had used them on several of our internal file and VM servers (because they were cheap), and they had a nasty habit of falling off the bus overnight, causing the RAID controller to go berserk.