It makes complete sense. If those kids can play GTA, some of them might be inspired to go into competition with him.

You can't use plugins without a paid version of IntelliJ, which Android Studio is not.

You're still building for your family's future, even if you feel that a 45% estate tax is too much. Not saying it is or isn't, just that passing on 55% is not nothing and is not necessarily removing one of your primary motivators.

If we really want more of a meritocracy, maybe a 100% estate tax would be the way to go. (Note: I know this wouldn't work due to issues of unequal education and nepotism).

Actually, I mostly agree with you. The point I was trying to make was that simply aiming to decrease inequity is a silly goal if you don't have broader constraints such as 'so everyone can afford to eat'. The reason behind wanting to make that point was that if it is considered an improvement for inequity to decrease as a result of pushing middle wages down by allowing more H1Bs, then maybe it could be extended to minimising inequity by making almost everyone dirt poor.

I think that reducing inequality by pulling in the top and bottom ends does have a whole range of benefits.

Extending on Greenspan's idea, you can reduce inequity by having the top 0.01% take all the money from the remaining 99.99%. All that demonstrates is that having low inequity as your sole target is stupid.

Thanks. That's the best read I've ever seen on the subject.

Sure, but they don't play 24/96 audio without downsampling.
(Note: I'm not saying someone could necessarily tell the difference, but there is a difference)

That certainly changes things. The summary for this article and the Ars article both suggested that the key was 10 chars long, and I couldn't find a specific number in TFA to replace it with.

Absolutely, but if the summary and the Ars article are to be believed then the on-device key is 10 characters long. From TFA, the output characterset appears to include 76 characters, so it seems plausible that they are using this same set for the on-device key as well. They are using HMAC-SHA1, and it seems (from Ars) that they are not using iterated SHA1 (i.e. they are using a single pass).

Not saying anyone would deploy it like that.

I think basically using client certificates is too hard for average joes to use, especially across devices.
Different browsers on one machine don't share certs. You need to be able to share certs across devices, which means copying them somehow while keeping them secure - and not just keeping them all in DropBox. If you're using certificates, you can't just log on from your friend's phone when you left yours at home.

Also, if you're trying to replace insecure passwords with certificates, then you have the problem that the people who would normally use the crappy passwords will either not password protect their certificates or use crappy passwords on them too. Even if they do this, it does mean that the server password DB being stolen wouldn't reveal their keys but it does mean you need some way to revoke certificates and get new ones if yours are compromised.

In reality, using the same password across multiple sites is a much bigger problem (for those users) than using rubbish passwords if the site is managing passwords correctly. If the server is salting the passwords and using good hashes, as well as limiting the rate of password attempts and implementing some form of lockout then everything beyond the most abysmally bad password is reasonably safe.
However, if a user has the same password for their e-mail account, and the dodgy torrent forum they just signed up for using that e-mail address then they are screwed any which way.

Sort of, but the server (rather than the client) has the device, and 'having' the device is needed (ideally) in order to check user passwords at the server end. So rather than being used to identify a user to the server, it is used by the server to generate the password hash which is stored and compared.

As was pointed out by someone on Ars, even if the secret key used by this device isn't stolen it can be bruteforced by having a single known account on the system. This is not a trivial problem, because it seems that they are using SHA1 (on the basis that the key can never be stolen, so the hashes don't need to be so strong). As such, there is a mountain of good gear out there for running lots and lots of hashes fast.

Basically:
1. Create account/password with online retailer
2. Steal user database for online retailer
3. Find you own account, for which you know the username and password (and salt, because it is in the database) and associated hash
4. Bruteforce the HMAC key required to get the stored hash using your username, password and salt
5. Use that same universal HMAC key for attacking all the other accounts
6. profit?

This assumes that there is a single key used for the HMAC and stored on the dongle, but it seems that is actually the case.
It does make getting all the passwords a bit harder, but it isn't a miracle cure.

Well, if your starting point is that "open source doesn't lead to bugs being identified and disclosed" then those very posters you are complaining against are partially right, in part. Consider:
Open source: anyone can read the code, but (based on our premise) this doesn't lead to identification and disclosure of problems. It can allow a prospective attacker to identify problems and not disclose.
Closed source: only internal staff can read the code, but (based on our premise) having many eyes looking doesn't lead to identification and disclosure of problems. Prospective attackers can only do binary analysis, not source analysis, to find problems.

If binary analysis is more difficult than source analysis for finding potential bugs (i.e. potential targets for attack) then closed source is more secure in this context (assuming one or more attackers looking for potential vulnerabilities in the library/source/whatever).

Note: I'm not agreeing with the 'ubiquity' argument because it ignores read distributions of OSs. Also I'm not agreeing with the 'financial interest' arguments, because in a closed source there is the possibility that a company will gamble on an internally-detected vulnerability not being exploitable (or exploited) rather than fix it.

There are valid arguments for using open-source software, but I don't think the "many eyes" argument is necessarily a good one.

Good find. The Zeta actually looks like it would probably damage the wheel and tyre less too, because of the longer contact area.

You mean like Windows, which in the case of XP has received updates for 12 years which can be installed on any XP computer irrespective of manufacturer-included crapware? I wish Google provided updates for Android like Microsoft did for Windows.

Also, I think you're overstating:
1. the version issues - Google's compatibility libraries are pretty damn good. Inter-device compatibility is a bigger problem, and is more similar to trying to support a range of video cards well on PCs
2. the 'drum beat' of exploits? The 'master key' vulnerability, which only affected users who sideloaded apps (which is significant, no denying) and this one which affects apps which use WebView content in an insecure way. There are also the exploits used to gain root on devices, of course, but iOS has them too in order to jailbreak - although some exploits to gain root on Android don't require being plugged in (but usually require debugging to be enabled which is in a hidden menu).