No problem for me. They can all go to hell, as far as I'm concerned. The web did just fine without them.

I have personally no problem with the death sentence, but I consider your justice system and your prison system an institutionalized crime against humanity. Your country is barbaric.

It is obviously not the right way, at least not to people who know how the Internet works. That's what this whole discussion is about.

The right way to deal with objectionable content is to take down the content from the server on which it is stored. Not from search engines. (There are fully distributed search engines, wonder how this nonsensical EU rule works with them.)

Whenever I get omitted search results, I use a proxy to go to Google.com and read what has been deleted. It's surprisingly informative.

Still waiting for someone to write a Firefox extension to do that automatically.

You mean he did the same as what spin doctors do for politicians?

No, that's not the problem. The problem is that every second secret agency in the world and every third Russian botnet owner could rig the election.

The whole story is lame, because it's not about the paper or his research but about his leisure time activities.

Who cares? How about a story about Joe the Plumber's sports at the local bowling center instead?

what used to be AOL == Gmail now

meaning, only morons and noobs use it

I know this is controversial, so let's start the flamewar and downmodding in 3, 2, 1...

What on earth do you mean by "I don't think TCO has ever mattered much"? TCO is the bread and butter of every Scheme dialect and of all strictly functional programming languages on earth. A vast range of data structures and algorithms for FP rely on it.

Count me amongst the skeptics.

That's a bad design. If the attacker can access the password file, then he will usually also be able to save your fake passwords from within the password manager. Think about your wife trying to find out the password for your porn collection. So either she may (perhaps inadvertently) delete the original ones, which would be a disaster, or you need to have padding space in the original file so the attacker cannot detect that you have saved the additional files. And you cannot have an arbitrary amount of padding space, of course.

What makes sense is to allow some attempts and then create fake passwords and save them encrypted with the fake masterpassword in the already padded database file (so there is no difference in file size). However, that only works if the password manager always modifies the password file in some way whenever it is opened, since otherwise the attacker can choose *not* to modify and save the file (which would be the wise choice anyway, from his perspective) and can easily recognize that he has been served fakes by monitoring file activity. It doesn't bring any advantage when the attacker is reverse engineering the code or debugging it.

What somehow works against offline attackers would be a variant of a 'fully bijective encryption' that was advocated many times by some crackpot on sci.crypt 15 years ago. I forgot his name. In the present case, this would mean that the encryption scheme is hand-crafted in such a way that the ciphertext is mapped to seemingly valid cleartext no matter what master passphrase is provided, and there is no check for correctness. I suppose that's what the authors were working on, but I'm pretty sure that this can only work convincingly if the passwords are random-generated in the first place. It will fail with user-provided passphrases (or, worse, it could become cryptographically insecure). The proof is left as an exercise to the reader. (just kidding)

My 2 cents. But thanks for the linked paper, I'll check it out.

As the maker of a password manager, I'm curious how this is supposed to work. The article is a bit sparse on information.

Suppose I'm the attacker and after say, ten guesses the fake passwords are shown. So if I now save the passwords, will the original ones be overwritten? I guess not, since that would be rather inconvenient. So if not, will the fake passwords along with the master password and the original data be stored in the password database? Than the attacker can check the length of the original file after saving to determine whether he has obtained fake passwords. Or are they assuming some mysterious online password application where the user has no knowledge of where and how his passwords are stored? In that case, the application will be insecure anyway.

I suppose the right way to make this work is by saving fake passwords (or the space for them) along with the real ones all the time but encrypt them separately with the fake master password after it has been created on the fly. Thinking about it, I might add this as an option to my program.

I just can't decide on which loosing horse I should all my money!

Jokes aside, anyone who knows a little bit about the history of Apple should be careful not to put too much efforts in one of their 'projects'. At least develop the core of your applications in C or C++ and use the proprietary technology just for GUI glue code. Unless we're talking about another fart app that requires zero know-how and programming effort anyway.

Your terminal -- mainframe concept sounds a bit too 70ish to me. Why should it be the future of computing now when it already failed in the 80s-90s for most uses? I really don't buy it.

Was? They still are!

Learn Forth now. Or something else.