3,974 karma · joined July 18, 2011
But for future identity proofs (domains, for example, which we've yet to implement), this kind of attack is real. Our approach here will be that anything outside of normal ascii will be highlighted and addressed to the user, as a serious warning.
I think what Keybase is addressing in the status quo is twofold: (1) sadly, almost no one does what you describe; in person meeting key exchanges and webs of trust may sadly be as unpopular in 20 years as they are now, and as they were 20 years ago. People who go to them are often confused, even programmers. I wish it were different.
And (2) more important, in 2014, often the person you're dealing with is someone whose digital public identity is what matters, not their face in real life or phone number. If you know me online as github/malgorithms and twitter/malgorithms, to get my key, meeting someone in person or talking on the phone to someone who claims to be me is actually less compelling than a signed statement by malgorithms in all those places you know me.
And if you do know me in real life, then I can tell you my keybase username and fingerprint, exactly as you're used to. So it's still as powerful for meeting in person. With the added benefit you can confirm my other identities, which you likely know to.
In answer to your scenario about verifying: you only need to review the "maria" the server provides once, and then your private key signs a full summary of maria -- her key and proofs. Cases 2 through 1000 of performing a crypto action on maria involve you only trusting your own signature of what "maria" is. The client can query the server for changes to her identity, and this will be configurable; if maria adds a new proof, you might wish to know.
Rather, the server replies with links to tweets, gists, etc. -- maria's public identity proofs. The keybase client does not trust that these are honest, so it scrapes them directly and makes sure they were signed by the same public key that the server provided. In other words, the server could reply with a different maria, and simply lie, but not with the real maria's github or twitter account.
The server could also lie by omission, leaving out an identity. But it cannot invent ones that do not exist, without the client knowing.
Again, the premise here is that maria is the sum of her online identities.
The website itself is of course a different story. When you look up maria on keybase's website, you are trusting that keybase.io did not lie about her github account. Fortunately you can confirm by following the link to her gist, where she announced her keybase username and posted her key fingerprint.
With twitter, it's the ability to post a tweet under a certain username. With owning a tumblr account, it might be something similar. With your known StackExchange profile it might mean posting a statement in a specific part of your profile. And so on.
The common thread in each case is (1) that you post in a place where only your identity can, and (2) what you post is a signed statement claiming a connection among three things: (a) your keybase username, (b) your public key, and (3) the identity on that third party service. (The third one is necessary so it can't be moved elsewhere.) Note how twitter and github's are totally different, but achieving these three things.
We will build out this list of identity checks, hopefully making all kinds of them easy to do. Everything from proving you own a domain to having a tumblr or reddit accoun. The definition of those checks will all be publicly reviewable, both in the spec and in the client, which is what checks them for you.
The alpha site's changing every day, and we're working on the documentation now. I don't use the term "alpha" loosely. There will be extensive security details published, explaining every aspect of the identity proof system, client sessions, etc. They will be on the site before we open general access or turn beta. Right now only a few friends are on there. All that said, Max and I can answer questions here.
My profile on the site is https://keybase.io/chris if anyone wants to look. My profile demonstrates early examples of how identity proofs will work, including both twitter and github. We'll of course be adding other public identities in the future.
The site design is also very iffy at the moment; I was about to move into firefox bugs tomorrow.
Does anyone know if it spams your address book?
Also worth noting: OkCupid launched day 1 with the dating system as it is now -- answer arbitrarily many questions in 3 parts to build your own custom matching "algorithm". But we made it easier at the beginning for users to introduce their own questions.
1. You're right in thinking that bootstrapping users will be much harder than coding the site. A dating site requires not just a critical mass of users, but also a critical mass using it in a certain location with enough people that there are internal compatibilities.
2. We loosely categorized our users into 3 groups. (a) those explicitly interesting in dating. (b) those who would consider it, but who weren't ready to make the decision, and (c) those who would never sign up for our dating features. Our early strategy was to (try to) nail all 3 groups, arguing that there was mobility between b and a, and that group c could still be used to spread around dating-related toys without realizing that's what they were doing. All this led us to personality tests and a bunch of other goofy things that attempted to be viral but could also enhance a profile if converted. On average, 10% of our early users became online daters on our site, and the other 90% were spreading the word in one way or another, but we never heard from them again. As we got bigger, we slowly shifted our message towards the dating side of things, as those "growth hacks" diluted our message.
Of course this is not the only strategy. Consider (1) Tinder, a very simple dating app, which has become a phenomenon. I would say it's hard just to invent this phenonmen, though... And (2) pay dating services, which can collect membership fees and then use the money to market. It's an expensive game which requires a lot of cash and marketing knowledge.
Disclaimer: I left OkCupid a year ago.
More to the point: how would this generation feel about the police coming to school and taking DNA samples?
I (and again, this is personal, lest someone drag my former companies into this) stand by my statements, as long as this lawsuit exists.
If the basic facts themselves are wrong, then of course I will back off my statement. If Opera is not suing an individual for ~$3.4MM USD for divulging trade secrets, then great.
Ok, I personally find this kind of lawsuit deplorable for 2 reasons:
(1) The world is better when people share ideas and don't try to claim ownership over them. If, while I worked at OkCupid, someone left my company and used "secrets" we held to start or improve a competitor, I would believe it was their right. And that I had failed to nurture their creativity or compensate them well enough.
(2) This is an individual being assaulted at a corporate magnitude.