This video explains sampling and reconstruction of digital audio very well, and is a good jumping off point if you want to learn more.

http://www.youtube.com/watch?v...

It isn't like Code Jam is their main stream of employee finding, and in general their engineer interviews are less puzzly than they used to be.

Google has a broad variety of problems that need solving, including a lot of problems where understanding algorithms is tremendously important. If anything Code Jam allows Google to cast a broader, more inclusive, fairer net - giving opportunities to people to shine who don't have a degree from MIT education or who don't fit the average software developer mold.

Well, the starting point for this discussion a discussion like this is "the attacker has access to the hashed passwords and they understand our hashing algorithm, are they able to recover the passwords". Nobody is talking about attempting a million logins through their interface.

Rather, my comment was just stating the obvious - if you are capable of logging in a single user based on the information at rest, then an attacker can use that same test, with the same information, in a brute force attack on a short password.

Their actual solution, which I didn't realize when I wrote my first comment there, is that their system can't just validate a single user.

Google Code Jam is a really super excellent way to get into algorithm programming competitions, at least in North American. The serious competitors are pretty thin on the ground here (or at least they have been in past years) so with a bit of commitment, some programming experience, and a little luck, getting to the on site rounds is very achievable.

It's especially a great opportunity if you're interested in working at Google - doing well will definitely attract their attention.

It's also one of the most approachable competition formats; it's very "approach agnostic", and doesn't focus on anything too obscure in terms of required knowledge or skills. The time bounds are loose enough that you don't have to worry about things like "reading from a file efficiently". The initial rounds usually just test whether you can do basic programming. The test cases they supply do a good job of making sure you get things like formatting right - meaning you get to focus on the actual problem instead of goofy side issues.

Very well run contest, and lots of fun even if you're not a real expert.

Yes, that is the point. My point, in turn, was that you can't do what they describe while still being able to log in a single user.

The surprising resolution to this little dilemma (as discussed in other posts) is that they can't log in a single user (they need kind of a quorum of login attempts before a newly rebooted server can actually log someone in). This wasn't what I expected, so my first post there is kind of misleading (because I was, in turn, mislead by the summary).

The point of this thing is to get an effective key into memory without storing it somewhere (ie. you can reconstruct it based on login attempts). If you just store the logins somewhere, you might as well just store the key there instead (and this, combined with communication restrictions, is how a normal setup like this would work), because from the logins you can get the effective key you need to do authentication. So this scheme isn't really adding anything to that scenario.

To be clear, I don't think you're wrong - you could do a setup like you describe; I just don't think adding this process into the mix would effectively increase security (or, at least, wouldn't help any more than storing passwords in 1000 different files around your network would - it makes things less convenient for the attacker, but not really more secure given the assumptions we have about the attack).

Well, the starting point for this kind of discussion (and the reason you'd use a system like this) is "they've stolen the database and they know how the hash algorithm works". This system is to prevent you from getting passwords out from here by making them more difficult to brute force (and they can't exactly stop you from trying more passwords after you have the database).

They do this by having an effective key that isn't stored in the database and is required for authentication, but is instead reconstructed based on a number of logins (and those logins don't "work" until there's a quorum). Like my post suggested, with something like this you have to pick between "can you authenticate a user" and "can you prevent a brute force attack on short passwords". I assumed they picked the former, but they actually picked the latter - using this system you can't just authenticate a single user on a newly rebooted system.

Anyway, it's a cool thing, but I think there's practical problems.

Yeah - I was wrong. I had assumed that the system would need to be able to log in a single user based on their password (crazy me!) and that was incorrect.

Yeah - but that system would have nothing to do with this. If you want to do that, it's cool and it'll work.

The interesting part of THIS system is that it can recover the secret it needs just by having multiple users authenticate. Which is a really cool property for some possible purpose, but I don't see how it fits well with the requirements of a "normal" authentication system and how that needs to respond.

So it turns out their system, after a reboot, can't just validate a single user (I guess that was a crazy assumption on my part) - it has to have logins from a number of users before it can authenticate anyone. And if you don't want the system breakable by someone just creating a bunch of accounts (eg. normal users on a public website), these prime logins have to be more "special accounts".

Practically, if you need some special logins after every reboot in order for the system to come online, you're going to have to have multiple people assigned this job. Or one person with N passwords he logs in with. In which case, why not just give that guy a one time pad sort of thing that he primes each server with? I mean, these passwords are going to be unrecoverable and encrypted with, effectively, an unchanging key. So... uh, we have ways to do that.

Oh wait, there's an extension that gets around this, and has the property of "the server can check and eliminate most wrong passwords right after reboot". I'm sure a lot of bosses will like that - it'll reject most wrong passwords. Great.

It's a clever idea, but I think there's some real hard sell problems there.

To be useful, the system still needs to be able to tell whether a single user password is correct (and needs to do so reasonably efficiently). So if someone has a 6 character password (which is dumb) you can just try all possible passwords (there isn't that many possible 6 realistic character passwords). Either lots of them work (which would a problem) or you found the password. And it didn't take all the computers in the universe forever to do so.

Maybe this is a great system, but the hyperbole in the summary is ridiculous.

There are some games that WD TV can play - but I have no idea how they're packaged, what their limitations are; the ones I've seen have all been very simple affairs.

If one of these low cost set top boxes could get a good selection of games, I could certainly see that being a big differentiator (and possibly a blow to consoles).

Two hours before they're dead, you can treat them by telling them not to go out tonight because they're going to get stabbed.

Lol - this isn't like some secret or something. There's a reasonable number of service jobs that will persist for some time, because some people prefer a human touch for restaurants, health care, or random other stuff (personally, I'd rather type my order and have food pop up without a waiter - especially if that made it cheaper). Even for grumps like me, I imagine there's lots of stuff that I'd still want a human to do - make music or write books for example. But there's just not nearly enough of those jobs, total, for anything like the current economy to work, once you have robots that can do simple decision manual labor (drive trucks, run farms, clean, navigate neighborhoods, fetch goods, etc..).

And futurist's never take this into account? I've read probably 50 variations on how the "next" economy will work, and they've taken this in tons of directions (some realistic sounding, others more fanciful). There's attention based economies where the majority of people are doing creative work, and competing for attention. In the Prime Intellect books, one of the last ways for humans to earn something like money is to sell their suffering to those who get joy out of causing a real human pain.

I don't think it's dangerous or stupid. I'm willing to put something funny looking on my head. I don't care if it's a bit awkward or unpolished, or even if it doesn't work well for extended play (I don't have time for extended play usually anyway).

This is cool tech, and I'm excited for it. I hope it catches on. There was a time when Slashdot would mostly be with me on this. Now new tech is pretty much universally turded on.

That said, I'm much less sanguine about Sony's prospects. It feels like the Move before it, kind of a half-hearted effort to grab onto a trend. The Oculus people (and Valve) seem to be taking development much more seriously, and focusing on the right things to optimize the experience. They're gamers eating their own dogfood, and they like it enough that they've repeatedly doubled down.

Once it's released and gets some good software support, I think it's going to be something special.