[kijin]

Thanks for the clarification. But the concern remains that a single "central authority", namely hypothes.is, gets to maintain a huge database that links online pseudonyms to verified real-world identities. That's going to make hypothes.is one hell of a target, not only for identity thieves but also for government authorities of all stripes. Meanwhile you'll need to convince people that they should trust you with that information.

Sure, any large online identity provider that possesses enough data to link online identities to real-world identities (such as Facebook) will face the same problem. If this takes off, Chinese hackers will be crawling under your mattress and your PO Box will be overflowing with subpoenas and national security letters before you can say eff-bee-eye. But ideally I'd like to see this problem fixed in some creative way, not merely repeated and exacerbated in a centralized form.

Honestly, I have no idea how one might achieve both verification and pseudonymity without cutting corners somewhere else. But I do have some hope for you guys because it seems that EFF is involved. Those people really know how to play with pseudonyms.

/tinfoil hat

[tilgovi]

Thanks! Wherever possible I'd like to ditch the personal information after signup and just keep a hash or something that we can use to prevent multiple accounts using the same Twitter, OpenID, etc, linking only these opaque tokens to user IDs in our database. I'm trying to put together our user tables and login system in the next day or so and welcome any comments or concerns you have with the implementation. Feel free to jump into our dev list or #hypothes.is on Freenode.

[kijin]

That raises an interesting question. How are you going to hash a person's Twitter username or OpenID in such a way that (1) you can quickly determine if the same person tries to sign up more than once using the same credentials, and (2) the original credentials are effectively discarded?

If you just store something like sha1(openid), it will be easy to check for duplicates, but any staff, intruder, or three-letter agency that wants to connect hypothes.is accounts with OpenID's can also easily launch a dictionary attack. On the other hand, if you store something like bcrypt(salt | openid), it will be a lot of hassle to check for duplicates, and your database is still susceptible to a known-plaintext attack. In neither case have you actually irrecoverably discarded the personal information. And thus we get back to the problem of South Korean web sites requesting National ID numbers from every member. They only claim to use it to prevent multiple signups, but then they wonder why every Chinese hacker has easy access to millions of South Korean National ID numbers.

Meanwhile, nothing prevents a determined spammer from creating multiple Google (for OpenID) or Twitter accounts. So if I had a suggestion, it would be that you should stop wasting time trying to enforce one account per person, and instead give people an incentive to minimize the number of accounts they create. Make it dead easy for people to associate different accounts on different services with any of their personas, and make it dead easy for people to organize and manage them, so that most people don't even feel the need to create additional accounts.

Feel like using your joke personality on Reddit today? Just select that persona in a dropdown menu in the browser add-on bar. Wanna switch to your serious account for just one comment? Another click in the menu and you're automatically logged in as the other user. (Reddit Enhancement Suite can already do something like this, which means there's a demand for this feature.) Different example: I sometimes want to log into Gmail with one Google account while browsing YouTube with another Google account. Right now, this means messing with incognito windows. If each tab were pinned to a different persona, I could do this just as easily as flipping Chris Poole's prism in my palm.

BTW, sorry for the wall of text.

[tilgovi]

I started thinking about the dictionary attacks, too, and ultimately you're right. Not worth enforcing and easy dropdown changing is eventually what we want. Thanks for your thoughts.