Keybase raises $10.8M(keybase.io)
keybase.io
Keybase raises $10.8M
https://keybase.io/blog/2015-07-15/keybase-raises-series-a
37 comments
Keybase is the wrong way to do a PKI directory.
First, people should have multiple keys/identities by default; multiple identities should be the normal thing everyone does. Single identities will be used by governments to control people. They'll also work against normal communication patterns where people speak differently to different groups (think parents, friends, coworkers.)
Second, matching a name with social media is the wrong way to lookup others. It only works if people put enough personally identifiable information (PII) on their social media accounts, otherwise we won't be sure we found the right person. This matching system encourages PII, works against multiple identities, and associates multiple accounts on disparate systems. Everything you told Facebook, you've now told Reddit and Github, etc.. because the companies can also lookup your (single) Keybase identity and connect the accounts, as can advertisers and governments.
Third, leaving people to manage their own private keys is worse for security than having them managed by others. Software changes, glitches and upgrades should be overseen server-side and managed; there should be a help-desk to contact and backups should actually be done, etc... Multiple identities would make it easy to let an employer manage an 'employee' identity, and Facebook manage -or consume- a public 'personal' identity, and Twitter manage a private 'political' identity. (A PKI version of OAuth and 'Sign in with Facebook'; strong crypto can't fix the UX problem.)
I think the winning solution will be: a distributed, server-side PKI system that individuals and companies can host themselves; a DNS-like distributed registration and searching system; a host-provided web UX for managing accounts. Moving private keys to the client will work better if the local key is signed by a hosted key, rather than leaving all the private keys in the hands of end-users.
First, people should have multiple keys/identities by default; multiple identities should be the normal thing everyone does. Single identities will be used by governments to control people. They'll also work against normal communication patterns where people speak differently to different groups (think parents, friends, coworkers.)
Second, matching a name with social media is the wrong way to lookup others. It only works if people put enough personally identifiable information (PII) on their social media accounts, otherwise we won't be sure we found the right person. This matching system encourages PII, works against multiple identities, and associates multiple accounts on disparate systems. Everything you told Facebook, you've now told Reddit and Github, etc.. because the companies can also lookup your (single) Keybase identity and connect the accounts, as can advertisers and governments.
Third, leaving people to manage their own private keys is worse for security than having them managed by others. Software changes, glitches and upgrades should be overseen server-side and managed; there should be a help-desk to contact and backups should actually be done, etc... Multiple identities would make it easy to let an employer manage an 'employee' identity, and Facebook manage -or consume- a public 'personal' identity, and Twitter manage a private 'political' identity. (A PKI version of OAuth and 'Sign in with Facebook'; strong crypto can't fix the UX problem.)
I think the winning solution will be: a distributed, server-side PKI system that individuals and companies can host themselves; a DNS-like distributed registration and searching system; a host-provided web UX for managing accounts. Moving private keys to the client will work better if the local key is signed by a hosted key, rather than leaving all the private keys in the hands of end-users.
1. You can set up multiple Keybase accounts if this is an issue for you. It doesn't seem like that much of a problem.
2. Most people do put enough personally identifiable information on their social media accounts. If you don't want to, that's fine, but you'll have to find some other way to identify yourself to people who you want to use your public key.
3. You can have Keybase manage it for you, if you want. Yes, of course there are problems with this, but it provides a reasonable compromise, especially if your threat model isn't a government entity (in which case, you're likely screwed anyway).
The truth is, most people have trouble working with more than one email account. Adding multiple sets of keys on top of it isn't going to make anything easier. At least with Keybase, I could get someone who isn't all that aware of security measures set up with public key encryption in a way they have a chance at using.
There's ideal, and there's better. Unfortunately, ideal has proven to be too onerous for people to use, but we can work on better.
2. Most people do put enough personally identifiable information on their social media accounts. If you don't want to, that's fine, but you'll have to find some other way to identify yourself to people who you want to use your public key.
3. You can have Keybase manage it for you, if you want. Yes, of course there are problems with this, but it provides a reasonable compromise, especially if your threat model isn't a government entity (in which case, you're likely screwed anyway).
The truth is, most people have trouble working with more than one email account. Adding multiple sets of keys on top of it isn't going to make anything easier. At least with Keybase, I could get someone who isn't all that aware of security measures set up with public key encryption in a way they have a chance at using.
There's ideal, and there's better. Unfortunately, ideal has proven to be too onerous for people to use, but we can work on better.
Note that recent .gov data breaches now show in public what we already knew, that once someone has your private data (like private key) then everyone has it eventually, except perhaps for the general public, for a limited time.
This insight factors into another criticism of ops list of problems. IF we lived in a world where all data wasn't shared and merged, then this could be used as a tool to help FB and twitter and .gov do a merge. But we can assume the merge has already happened and the data is near perfect. Therefore the sole remaining benefit of not putting PII into social media etc is the general public / private citizens have no idea who I am so they can't send me secure email. This sounds fairly useless, if every .gov and .com and criminal with a copy of breached data know exactly who I am and who my accounts are.
You see there's been an inversion in security, that some people can see and some people cannot yet see, future being unevenly distributed and all that. If we didn't live in a total surveillance Orwell society, then a tool to make it microscopically easier to connect the dots would be bad despite its good parts, but given Big Brother's infallibility, eliminating the tool because it might help (infallible) Big Brother in a very small way that BB doesn't need anyway, only eliminates the small amount of known positive that the tool does provide.
I have a keybase account and its pretty awesome and well implemented. Cool! I never use it because the use case of randomly sending encrypted stuff to people I don't already know doesn't come up very often. But if I had to, it is pretty slick...
This insight factors into another criticism of ops list of problems. IF we lived in a world where all data wasn't shared and merged, then this could be used as a tool to help FB and twitter and .gov do a merge. But we can assume the merge has already happened and the data is near perfect. Therefore the sole remaining benefit of not putting PII into social media etc is the general public / private citizens have no idea who I am so they can't send me secure email. This sounds fairly useless, if every .gov and .com and criminal with a copy of breached data know exactly who I am and who my accounts are.
You see there's been an inversion in security, that some people can see and some people cannot yet see, future being unevenly distributed and all that. If we didn't live in a total surveillance Orwell society, then a tool to make it microscopically easier to connect the dots would be bad despite its good parts, but given Big Brother's infallibility, eliminating the tool because it might help (infallible) Big Brother in a very small way that BB doesn't need anyway, only eliminates the small amount of known positive that the tool does provide.
I have a keybase account and its pretty awesome and well implemented. Cool! I never use it because the use case of randomly sending encrypted stuff to people I don't already know doesn't come up very often. But if I had to, it is pretty slick...
Interesting points. The below is a friendly disagreement from someone passingly interested in this field.
> First, people should have multiple keys/identities by default
I feel like you can do this already, no? Just create different Keybase accounts for each identity. I don't understand how having a single keypair prevents you from managing your contact groups however you like. They seem like orthogonal problems to me.
> Second, matching a name with social media is the wrong way to lookup others. It only works if people put enough personally identifiable information (PII) on their social media accounts
Key verification is the problem in crypto. Like it or not, many people already put tons of PII online. It's a perfectly valid way to verify lots and lots of people. Perhaps it doesn't work for everybody, but it's clear that keychains don't work. This is a different strategy to solve the verification problem, and I think it's got legs.
> Third, leaving people to manage their own private keys is worse for security than having them managed by others.
I understand your point here, but I disagree. Given all the server hacking going on these days, I'd much rather not have a single point of failure. Or several large points of failure, in the case of your distributed system. The odds of someone hacking keybase.io or keyexchange.google.com seem much higher than the odds of someone attacking my phone or my desktop.
I think it's a mistake that keybase allows uploading and storing private keys.
> I think the winning solution will be: a distributed
Your idea doesn't seem to solve the verification problem. Keybase's strength is that in order to subsume someone's identify, you have to hack several of their accounts. That's much more difficult than hacking a single keyserver. How do you verify that the key I get when I search your crypto-DNS system for irq-1 actually belongs to you?
> First, people should have multiple keys/identities by default
I feel like you can do this already, no? Just create different Keybase accounts for each identity. I don't understand how having a single keypair prevents you from managing your contact groups however you like. They seem like orthogonal problems to me.
> Second, matching a name with social media is the wrong way to lookup others. It only works if people put enough personally identifiable information (PII) on their social media accounts
Key verification is the problem in crypto. Like it or not, many people already put tons of PII online. It's a perfectly valid way to verify lots and lots of people. Perhaps it doesn't work for everybody, but it's clear that keychains don't work. This is a different strategy to solve the verification problem, and I think it's got legs.
> Third, leaving people to manage their own private keys is worse for security than having them managed by others.
I understand your point here, but I disagree. Given all the server hacking going on these days, I'd much rather not have a single point of failure. Or several large points of failure, in the case of your distributed system. The odds of someone hacking keybase.io or keyexchange.google.com seem much higher than the odds of someone attacking my phone or my desktop.
I think it's a mistake that keybase allows uploading and storing private keys.
> I think the winning solution will be: a distributed
Your idea doesn't seem to solve the verification problem. Keybase's strength is that in order to subsume someone's identify, you have to hack several of their accounts. That's much more difficult than hacking a single keyserver. How do you verify that the key I get when I search your crypto-DNS system for irq-1 actually belongs to you?
First, Keybase is not just a website or app. It's an API, which happens to have them. Look at my keybase proof at https://news.ycombinator.com/user?id=mirimir The key is at https://keybase.io/mirimir, but it could just as easily be at http://mirimir...onion or wherever.
Multiple identities are trivial. Mirimir is just my primary persona for advocating privacy, anonymity, etc. Keybase links Mirimir's public GnuPG key to a few social accounts, and to an email address. Anyone who cares can validate all of those linkages.
I have another Keybase account under my true name, But it's linked to an entirely non-overlapping set of social accounts, with different friends etc. And there are other personas, similarly compartmentalized. Some of them never use English, for example, and display zero interest in privacy, anonymity, etc. Some hang out only on Tor hidden services. And so on.
While most of my personas are fully compartmentalized, a few are related. Mirimir, for example, looks like a simple pseudonym. And there's no reason why those "with nothing to hide" couldn't just use weakly compartmentalized pseudonyms. Facebook, Twitter, Hacker News, Reddit, etc could host the relevant keys, and all rely on the keybase API and proof structure. Facebook is already using GnuPG keys to secure system messages to users.
Multiple identities are trivial. Mirimir is just my primary persona for advocating privacy, anonymity, etc. Keybase links Mirimir's public GnuPG key to a few social accounts, and to an email address. Anyone who cares can validate all of those linkages.
I have another Keybase account under my true name, But it's linked to an entirely non-overlapping set of social accounts, with different friends etc. And there are other personas, similarly compartmentalized. Some of them never use English, for example, and display zero interest in privacy, anonymity, etc. Some hang out only on Tor hidden services. And so on.
While most of my personas are fully compartmentalized, a few are related. Mirimir, for example, looks like a simple pseudonym. And there's no reason why those "with nothing to hide" couldn't just use weakly compartmentalized pseudonyms. Facebook, Twitter, Hacker News, Reddit, etc could host the relevant keys, and all rely on the keybase API and proof structure. Facebook is already using GnuPG keys to secure system messages to users.
> Multiple identities are trivial. ... linked to an entirely non-overlapping set of social accounts, with different friends etc.
That's not trivial, and it's certainly won't be the default, normal thing everyone does. Instead Keybase will encourage a single identity linking multiple accounts. This is fundamentally bad.
That's not trivial, and it's certainly won't be the default, normal thing everyone does. Instead Keybase will encourage a single identity linking multiple accounts. This is fundamentally bad.
Having an identity and associated public keys that are fully validated is essential in many contexts. Let's say that I'm using a GitHub project, supposedly from a well-known Debian developer. Or let's say that I'm adding the Tor Project repository to Debian, in order to build the latest alpha release. Without well-known and readily validated public keys, how would I know what I was actually getting?
I agree that it's unusual to have multiple independent personas. It's quite common among my cohort, in order to provide deniability. Given the surveillance clusterfuck that's developing, deniability is becoming essential for everyone, even if they don't yet realize it. That will be especially important for young people, who are being profiled virtually from conception.
It does take some technical skill to establish multiple independent personas. One typically uses Linux and/or *BSD, virtualization, VPN services, Tor, Bitcoin, and so on. But getting up to speed only takes a few weeks.
I agree that it's unusual to have multiple independent personas. It's quite common among my cohort, in order to provide deniability. Given the surveillance clusterfuck that's developing, deniability is becoming essential for everyone, even if they don't yet realize it. That will be especially important for young people, who are being profiled virtually from conception.
It does take some technical skill to establish multiple independent personas. One typically uses Linux and/or *BSD, virtualization, VPN services, Tor, Bitcoin, and so on. But getting up to speed only takes a few weeks.
You laid out a number of points there, and I think some of them are indicative of what's really holding back security for the masses.
"Matching a name with a social media is the wrong way to lookup others" -- this is the one I take greatest issue with, because it's the way we know people now. All the people I collaborate with online now, I know them by those exact names. Coworkers, remote collaborators, friends on instagram, famous software engineers (whose work I might want to consume), even my own brothers... I know them by a set of these identities. This is how I know people.
To illustrate this point: if my own brother wrote me a message and posted it simultaneously on Twitter, Facebook, and LinkedIn, I would think "yeah, that's my brother." Moreover, and more importantly, if he left those posts up publicly, over time the strength of my conviction that he actually wrote the messages (and it wasn't a short-term compromise) would grow.
This works even for people you've maybe never met in real life. If hacker news user "jashkenas" announces on HN that he has a new version of CoffeeScript, I expect that's him. If he pairs it with a tweet, then I really expect it's him. The fact that this method works for possible strangers and loved ones is very powerful. Remember, this isn't just about secure messaging. If someone doesn't have any such identities, then there's always still the fallback: exchange an identifier in person.
The alternatives are so nasty -- in person meeting, coordinating enterprisey apps, and so on -- we'll never get anywhere with this kind of thing. The solution I think you are suggesting requires a lot of human effort to figure out if you have the person you want. This is one of the danger points of PKI. And one of the inconvenience points.
"Leaving people to manage their own private keys is worse for security than having them managed by others." Part of me wonders if you're just trolling. I don't understand this, and I've read your paragraph a few times. There is the confusion argument - that people don't understand how to manage them, which is a problem we're tackling. Our argument is that it's possible to build something usable (finally!) where people do in fact own their own keys.
But you go on to say "software glitches" and "updates" are dangerous for individuals who have device keys, and then suggest they'd be ok if their enterprises / social networks managed their private keys for them. In this case, you're talking about expanding the threats considerably, while still leaving client apps that need to be updated and do the work.
"Matching a name with a social media is the wrong way to lookup others" -- this is the one I take greatest issue with, because it's the way we know people now. All the people I collaborate with online now, I know them by those exact names. Coworkers, remote collaborators, friends on instagram, famous software engineers (whose work I might want to consume), even my own brothers... I know them by a set of these identities. This is how I know people.
To illustrate this point: if my own brother wrote me a message and posted it simultaneously on Twitter, Facebook, and LinkedIn, I would think "yeah, that's my brother." Moreover, and more importantly, if he left those posts up publicly, over time the strength of my conviction that he actually wrote the messages (and it wasn't a short-term compromise) would grow.
This works even for people you've maybe never met in real life. If hacker news user "jashkenas" announces on HN that he has a new version of CoffeeScript, I expect that's him. If he pairs it with a tweet, then I really expect it's him. The fact that this method works for possible strangers and loved ones is very powerful. Remember, this isn't just about secure messaging. If someone doesn't have any such identities, then there's always still the fallback: exchange an identifier in person.
The alternatives are so nasty -- in person meeting, coordinating enterprisey apps, and so on -- we'll never get anywhere with this kind of thing. The solution I think you are suggesting requires a lot of human effort to figure out if you have the person you want. This is one of the danger points of PKI. And one of the inconvenience points.
"Leaving people to manage their own private keys is worse for security than having them managed by others." Part of me wonders if you're just trolling. I don't understand this, and I've read your paragraph a few times. There is the confusion argument - that people don't understand how to manage them, which is a problem we're tackling. Our argument is that it's possible to build something usable (finally!) where people do in fact own their own keys.
But you go on to say "software glitches" and "updates" are dangerous for individuals who have device keys, and then suggest they'd be ok if their enterprises / social networks managed their private keys for them. In this case, you're talking about expanding the threats considerably, while still leaving client apps that need to be updated and do the work.
To use your example, your brother posts a message on Twitter and you don't know your brothers Twitter username. If you're confident that it's your brother posting, then there's no problem. If you're uncertain that it's your brother, Keybase will let you verify it's him -- but that's a problem. Imagine a political dissident living in a dictatorship and it's the government who uses Keybase to match a Twitter username to a Facebook account.
We don't want accounts tied together. People need multiple identities online.
How do you get a persons key, and how do you know it's the right key? I think the answer will work like email addresses do now: someone will tell you a little info (name + hash@org) and you'll lookup their key.[0] Then you'll verify it as appropriate to the situation. That kind of system would allow and encourage multiple identities, and doesn't encourage posting PII.
To "bring public key crypto to everyone" you don't need to build this kind of directory (where you verify accounts.) You can instead get companies to participate in a PKI that they control (like they control email, DNS, http, etc..) and then they'll integrate it into existing software, provide it to users, experiment with UX and client designs, etc... Making an open source, server-side solution lets you turn 'Sign in with Facebook' into an ally that not only gets Facebook to provide keys and integrate crypto, but invest in servers and software.
Last, many people share a sentiment that a private key shouldn't leave our computers or phones (or fobs) to be managed by others. It's a reasonable attitude, but I think getting "crypto to everyone" and widely implemented is more important, and a managed system today doesn't preclude unmanaged keys in the future.
[0] To expand on this example: I'm irq-1 [email protected], and at work I'm Alice 23ff45@work. If you lookup hash@org and find a string that looks right (a username or real name) then you get their public key. You have some confidence it's the right person, and are free to verify it further with any other means.
We don't want accounts tied together. People need multiple identities online.
How do you get a persons key, and how do you know it's the right key? I think the answer will work like email addresses do now: someone will tell you a little info (name + hash@org) and you'll lookup their key.[0] Then you'll verify it as appropriate to the situation. That kind of system would allow and encourage multiple identities, and doesn't encourage posting PII.
To "bring public key crypto to everyone" you don't need to build this kind of directory (where you verify accounts.) You can instead get companies to participate in a PKI that they control (like they control email, DNS, http, etc..) and then they'll integrate it into existing software, provide it to users, experiment with UX and client designs, etc... Making an open source, server-side solution lets you turn 'Sign in with Facebook' into an ally that not only gets Facebook to provide keys and integrate crypto, but invest in servers and software.
Last, many people share a sentiment that a private key shouldn't leave our computers or phones (or fobs) to be managed by others. It's a reasonable attitude, but I think getting "crypto to everyone" and widely implemented is more important, and a managed system today doesn't preclude unmanaged keys in the future.
[0] To expand on this example: I'm irq-1 [email protected], and at work I'm Alice 23ff45@work. If you lookup hash@org and find a string that looks right (a username or real name) then you get their public key. You have some confidence it's the right person, and are free to verify it further with any other means.
I am with you 110% that people need to be able to have multiple identities online that are not linkable. That does not mean they should not be able to link multiple accounts to a single identity.
That is to say, "one identity per person" is wrong; "one identity per account" is also wrong. Both of these in the sense that they should be permitted if that is what the person desires but should not be expected or (especially) enforced.
That is to say, "one identity per person" is wrong; "one identity per account" is also wrong. Both of these in the sense that they should be permitted if that is what the person desires but should not be expected or (especially) enforced.
> Second, matching a name with social media is the wrong way to lookup others.
Assuming it /is/: a well known social media site called Facebook already has a space for GPG keys.
That doesn't mean keybase can't succeed and I do wish them luck though. First step: buy keybase.com, because people who don't know what encryption is don't understand .io domain names.
Assuming it /is/: a well known social media site called Facebook already has a space for GPG keys.
That doesn't mean keybase can't succeed and I do wish them luck though. First step: buy keybase.com, because people who don't know what encryption is don't understand .io domain names.
I think each identity is going to need multiple keys too. The key in the secure element on my smartphone may well be different to the key on my Yubikey. There will also need to be a robust mechanism for revoking keys, if/when they are compromised/lost.
Key management is tough. OAuth and tokenisation are great solutions for authentication but applications like GPG and crypto-currencies will likely still require "proper" crypto. Smartcards feel like the now-old'n'clunky prototype/PoC implementation of something better. I can't help feeling like the banks and telcos could contribute to a solution if they could work more collaboratively.
I don't think the end solution is a proprietary, for-profit one. It needs to be open and accessible to everyone, instead of fragmented into competing walled gardens.
Key management is tough. OAuth and tokenisation are great solutions for authentication but applications like GPG and crypto-currencies will likely still require "proper" crypto. Smartcards feel like the now-old'n'clunky prototype/PoC implementation of something better. I can't help feeling like the banks and telcos could contribute to a solution if they could work more collaboratively.
I don't think the end solution is a proprietary, for-profit one. It needs to be open and accessible to everyone, instead of fragmented into competing walled gardens.
you've essentially described what google is trying to do with gnubby/u2f, now hamstrung by FIDO and converging UAF standards. If you are interested a high level explanation is here: https://docs.google.com/presentation/d/16mB3Nptab1i4-IlFbn6v...
the idea being you mint a new keypair per service and the private keys are stored securely on your device (currently yubikeys but soon all devices will have a secure way to store key material (e.g., secure enclave, TEE, secure elements)), public keys get stored on the service you want to authenticate against.
the idea being you mint a new keypair per service and the private keys are stored securely on your device (currently yubikeys but soon all devices will have a secure way to store key material (e.g., secure enclave, TEE, secure elements)), public keys get stored on the service you want to authenticate against.
Great response. Do you think there's a way to monetize this proposed solution?
I like the idea but I also think it can be fully distributed - something like bitcoin/block chain
Hopefully they'll be able to address this then:
http://i.imgur.com/3VAMerv.png
(from https://twofactorauth.org/)
http://i.imgur.com/3VAMerv.png
(from https://twofactorauth.org/)
Yes, addressed soon. The ideal answer for 2FA in a key-per-device app isn't really the same as the normal site + Google Authenticator / Authy kind of thing.
The fatal problem with this plan is that all end user devices are by now hopelessly compromised. Take a look at the Snowden documents, which are now years behind the state of the art.
It doesn't matter if your crypto is both bulletproof and easy to use. They'll just break into your phone or your laptop through a side channel and read the key. And you won't even notice.
It doesn't matter if your crypto is both bulletproof and easy to use. They'll just break into your phone or your laptop through a side channel and read the key. And you won't even notice.
Have it ocurred to you that different people have different threat models? Yes, if a powerful state actor really is after you, they will most probably find a way sooner or later. Crypto is still useful for lots of use cases. E.g. protecting data from competitors, stalkers or identity thiefs.
This sort of thing may have been limited to powerful state actors a few years ago, but now Pandora's Box has been opened. Many other actors are now actively exploiting the holes deliberately created in the entire stack of computer security infrastructure over the past 20 years by those state actors.
It's far more likely that you'll run into someone trying to steal your credit card than an intelligence agency, but they'll be using the same exploit to get into your phone.
It's far more likely that you'll run into someone trying to steal your credit card than an intelligence agency, but they'll be using the same exploit to get into your phone.
So the only resort then I guess is to abandon computers and only use cash and pen and paper.
Nobody's saying that. I think what's being said here is just that we need to fix what's broken. Acknowledging that your physical devices have side channels is important.
Has it occurred to you that if your device is full of side channels, anyone can use those side channels?
How can you create a legitimate-government-only side channel? You could do it by basing all encryption off a master key that only the legitimate government controls. However, there's no way for a legitimate government to force everyone to only communicate with the master key.
Any other side channel is going to be exploitable by non-legitimate-government's in some way.
How can you create a legitimate-government-only side channel? You could do it by basing all encryption off a master key that only the legitimate government controls. However, there's no way for a legitimate government to force everyone to only communicate with the master key.
Any other side channel is going to be exploitable by non-legitimate-government's in some way.
I have never endorsed ”legitimate-government-only side channels”. I’m trying to nuance the discussion by asserting that not every attacker is equal in their skills and resources.
Agreed. Cool EM side-channel attack published March this year: http://eprint.iacr.org/2015/170.pdf
That stuff is spooky. But I don’t think it’s usage is widespread.
Yeah, this is true. But the OP still has a point, if we want true privacy there need to be changes at the hardware level.
Agreed.
> all end user devices are by now hopelessly compromised
This is news to me. Are there known side channel vulnerabilities for an arbitrary ubuntu desktop?
This is news to me. Are there known side channel vulnerabilities for an arbitrary ubuntu desktop?
I'd like to know the answer to that question.
But also, this one:
But also, this one:
s/an arbitrary/each/[deleted]
I just looked at the source of the page:
A) external CSS which might leak about a visitor to Google
B) <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Still leaking visitor info: bad.
A) external CSS which might leak about a visitor to Google
B) <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
No Google Analytics or other 3rd party hosted script tags on Keybase.
And this has the added bonus that we'll never be able to serve ad code.
\o/ \o/
chris max
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->
Still leaking visitor info: bad.
hah, I forgot about that note.
Good point - our stance was to protect from targeted code injections (by a coerced or hacked Google). But of course you're right, there's no point letting Google know at all.
I've made an issue to move font/css hosting off Google.
Good point - our stance was to protect from targeted code injections (by a coerced or hacked Google). But of course you're right, there's no point letting Google know at all.
I've made an issue to move font/css hosting off Google.
You might also consider setting Content-Security-Policy headers to enforce your intent. http://content-security-policy.com/
Thank you very much - great reaction.
Congrats! Increasingly pessimistic as a British subject that I'll ever be able to use something like this without attracting the attention of my own government though.
RIPA in the UK already allows for mandatory key disclosure if required by law enforcement: https://en.wikipedia.org/wiki/Key_disclosure_law#United_King...
And intelligence agencies have been known to retain encrypted content for longer (in theory, forever): http://www.darkreading.com/risk-management/want-nsa-attentio...?
The older I get the more impressed I am with how prescient Scott McNealy was when he said: "You have zero privacy anyway. Get over it."
And intelligence agencies have been known to retain encrypted content for longer (in theory, forever): http://www.darkreading.com/risk-management/want-nsa-attentio...?
The older I get the more impressed I am with how prescient Scott McNealy was when he said: "You have zero privacy anyway. Get over it."
Maybe you'll be okay in the UK?
Still avoiding the UK like the plague right now...
http://www.businessinsider.com/uk-government-not-going-to-ba...
Still avoiding the UK like the plague right now...
http://www.businessinsider.com/uk-government-not-going-to-ba...
Unfortunately the headline for that article doesn't, to me, reflect the letter that's published at the end.
They say that they're not targeting encryption directly, but they still say that they essentially want a back door into all communications systems, which is going to necessitate either getting technology providers to give them one, or banning of those that don't.
(of course it also won't even come close to achieving their goal, but I somehow don't think that'll stop 'em)
They say that they're not targeting encryption directly, but they still say that they essentially want a back door into all communications systems, which is going to necessitate either getting technology providers to give them one, or banning of those that don't.
(of course it also won't even come close to achieving their goal, but I somehow don't think that'll stop 'em)
> The Node reference client to our PGP directory will be retired. (PGP support will continue, of course.)
Can anyone from Keybase shed light on the reasoning behind this? It sounds like you are moving away from programmer-friendly API libraries and into GUI apps. Even if they're open source, as a developer I really liked your up-front API. Will you still be providing those APIs?
Can anyone from Keybase shed light on the reasoning behind this? It sounds like you are moving away from programmer-friendly API libraries and into GUI apps. Even if they're open source, as a developer I really liked your up-front API. Will you still be providing those APIs?
Oh, a clarification: the Node client will be replaced by the Go version. The `keybase` command line app will be a superset of what's available in the Node client now. Sorry. So yeah - still providing those API's.
PGP support will continue, always, it's just that you won't need to have PGP on all your devices -- just the ones you use PGP on. Your PGP key will be part of a family of keys you're known by. If you install Keybase and have no idea what PGP is we don't make you get a PGP key.
By switching to device-specific keys via apps on every platform, we can solve security and convenience problem at the same time. As the blog post says, this can only work if you can bring pairs of devices together. Which has only been possible and convenient the last couple years.
PGP support will continue, always, it's just that you won't need to have PGP on all your devices -- just the ones you use PGP on. Your PGP key will be part of a family of keys you're known by. If you install Keybase and have no idea what PGP is we don't make you get a PGP key.
By switching to device-specific keys via apps on every platform, we can solve security and convenience problem at the same time. As the blog post says, this can only work if you can bring pairs of devices together. Which has only been possible and convenient the last couple years.
It's about time for your obligatory /r/golang post about how you switched from 30 servers to 1 by switching to Go ;)
It's client-side code they're migrating rather than server-side.
Fingers crossed it makes the CLI a bit snappier!
Fingers crossed it makes the CLI a bit snappier!
Ah, ok. Go binaries tend to be more portable and don't require npm, so I can understand that direction. Thanks for the explanation!
I'm really excited to see a (relatively) large and complex desktop application being written in Go. Waiting for it to go public!
Very excited for your repos to go public! I'd love to contribute :)
From my limited following keybase.io it seems like this is mostly hobby project. How does one get investment for this kind of projects? Do you need to know someone already? Or do you decide to pull a plunge and create business plan and present it on one of these demo days organized for investors?
I feel like there is a huge gap between potent, but still hobby, project and series A funding.
I feel like there is a huge gap between potent, but still hobby, project and series A funding.
The founders previously made SparkNotes and OkCupid (acquired by Match.com), I suppose track record really helps with fundraising.
Being in the in-crowd of silicon valley seems to be the best way to get funding. So, in all seriousness, your question would probably better be phrased "how do I get into the silicon valley in-crowd?"
U jelly?
I imagine you walk up to Marc and say, "Hey, we are building PGP for the world."
Some days later, $10,000,000 pops in to your bank account.
Edit: Would be considerate if the down-modders would provide an alternate scenario.
I imagine you walk up to Marc and say, "Hey, we are building PGP for the world."
Some days later, $10,000,000 pops in to your bank account.
Edit: Would be considerate if the down-modders would provide an alternate scenario.
Edit: Would be considerate if the down-modders would provide an alternate scenario.
I'd imagine you're being downvoted more for the "U jelly?" childishness than the (im)plausibility of your (completely out of touch with reality) notion of how Keybase got their funding.
That's why I downvoted, anyway; I saw your opening line, clicked the down arrow, and moved on to the next comment without further thought or consideration.
Whether you agree with the mod-supported position that downvotes can legitimately be used as a form of disagreement or not, they're explicitly also meant to be used to discourage the kind of discourse that brings down the tone of the site. "U jelly?" certainly qualifies as that.
I'd imagine you're being downvoted more for the "U jelly?" childishness than the (im)plausibility of your (completely out of touch with reality) notion of how Keybase got their funding.
That's why I downvoted, anyway; I saw your opening line, clicked the down arrow, and moved on to the next comment without further thought or consideration.
Whether you agree with the mod-supported position that downvotes can legitimately be used as a form of disagreement or not, they're explicitly also meant to be used to discourage the kind of discourse that brings down the tone of the site. "U jelly?" certainly qualifies as that.
Thanks for your opinion.
>"U jelly?" certainly qualifies as that.
I'd argue that maligning keybase as a hobby project qualifies as much as "U jelly?".
At least it is discourse, rather than an anonymous downmod.
>"U jelly?" certainly qualifies as that.
I'd argue that maligning keybase as a hobby project qualifies as much as "U jelly?".
At least it is discourse, rather than an anonymous downmod.
It's a matter of tone. Whether you disagree with the Ur-parent's position that Keybase is — or, more accurately, "feels like" — a "hobby" project, the position was presented first as an individual's perspective, and second, was asking for clarification. He (?) wasn't saying, "Keybase is just a hobby project," but rather, "Keybase feels to me like a hobby project. How does something that seems like a hobby project get $10MM in funding?"
Your response was low-brow dismissal, and not of the poster's position (you didn't respond to what they said), but of the poster (again, you talked about the poster, not what they said).
Do you see the difference?
Your response was low-brow dismissal, and not of the poster's position (you didn't respond to what they said), but of the poster (again, you talked about the poster, not what they said).
Do you see the difference?
Mine was more terse, surely. However, it accurately reflected my perspective, based on what I just read. I didn't present it as anything different.
Further, I directly answered the question that was asked. Do you not think that is the general interaction structure of funding? Surely, it doesn't cover every case, but do you seriously think it did not happen in this case? No one has yet put forth any other scenario.
Further, I directly answered the question that was asked. Do you not think that is the general interaction structure of funding? Surely, it doesn't cover every case, but do you seriously think it did not happen in this case? No one has yet put forth any other scenario.
Again, the downvotes, and this entire sub-thread have nothing whatsoever to do with the structure of funding, and whether your scenario is more or less plausible than the money being left under their pillows overnight by an army of Oompa Loompas wearing magical flying tutus.
It is (IMO) solely and utterly about "U jelly?". If you hadn't opened with that, you may or may not have been downvoted, but none of this discussion would have ensued, because then your post would have been a response to what its parent said, instead of a comment about its parent's author.
I don't know how many more flashing neon arrows I can put around the distinction I'm trying to draw here. Either you get it, or you don't.
It is (IMO) solely and utterly about "U jelly?". If you hadn't opened with that, you may or may not have been downvoted, but none of this discussion would have ensued, because then your post would have been a response to what its parent said, instead of a comment about its parent's author.
I don't know how many more flashing neon arrows I can put around the distinction I'm trying to draw here. Either you get it, or you don't.
>Either you get it, or you don't.
Yes, I like binary logic.
Comments about the parent's author vs. comments about the commitment level of the people behind the parent's content's focused project (which is therefore a comment about the author's of Keybase)
I guess there is a distinction there (or at least I just named some distinction), but I'm not really sure why one was judged more acceptable than the other.
Edit: Ok, I guess you (or some anonymous down-modder) want more.
> and this entire sub-thread have nothing whatsoever to do with the structure of funding
This is just plain false. You lampooned my scenario in your first sentence into this sub-thread.
Yes, I like binary logic.
Comments about the parent's author vs. comments about the commitment level of the people behind the parent's content's focused project (which is therefore a comment about the author's of Keybase)
I guess there is a distinction there (or at least I just named some distinction), but I'm not really sure why one was judged more acceptable than the other.
Edit: Ok, I guess you (or some anonymous down-modder) want more.
> and this entire sub-thread have nothing whatsoever to do with the structure of funding
This is just plain false. You lampooned my scenario in your first sentence into this sub-thread.
leshow(1)
what do you mean by "maligning"? Second paragraph of their blog post:
"Keybase started as a PGP keyserver hobby project, aimed at making key lookups as easy as knowing someone's username."
"Keybase started as a PGP keyserver hobby project, aimed at making key lookups as easy as knowing someone's username."
That's fair. When did Keybase start? They seemed to be much further along than hobby, unless they just started working full-time (and with $10million!).
No, I am not jealous or anything. I have bunch of side projects which I never considered "investable" since none of them has clear path to monetization and/or built openly. Therefore I wanted to know what it takes to grow a full scaled business out of currently non-monetizable hobby project.
Sorry, that's just the first impression I got when I read your comment.
I wouldn't say a new company with (presumably) no revenue, but $10 million in funding is a full scale business. Certainly more of a business than a hobby project, but at some point a business needs revenue to qualify as a 'business'.
To be invested in, you need to convince your investors to give you money to do something. You have to explain what you are doing in a way they can understand and once they understand what you are doing, they need to be excited and want to invest (because they are interested in what you are doing or because they think they can make a lot of money off your work).
In this case, the investors are very interested in public key cryptography and Keybase was able to explain to them what they are doing and what they need going forward to build what they are trying to build.
I wouldn't say a new company with (presumably) no revenue, but $10 million in funding is a full scale business. Certainly more of a business than a hobby project, but at some point a business needs revenue to qualify as a 'business'.
To be invested in, you need to convince your investors to give you money to do something. You have to explain what you are doing in a way they can understand and once they understand what you are doing, they need to be excited and want to invest (because they are interested in what you are doing or because they think they can make a lot of money off your work).
In this case, the investors are very interested in public key cryptography and Keybase was able to explain to them what they are doing and what they need going forward to build what they are trying to build.
I wish we didn't push outdated crypto protocols such as PGP. So many companies seem to want to invest money or development time into making PGP "better" - with one exception: they can't make it forward secure, which I think is absolutely critical in today's world of companies and individuals "losing everything" in a hack.
Investing in a protocol that will last another 20 years and doesn't even have forward secrecy seems like such a wasted opportunity. It feels like one of those things where 20 years later you think "I wish we hadn't done that then".
Investing in a protocol that will last another 20 years and doesn't even have forward secrecy seems like such a wasted opportunity. It feels like one of those things where 20 years later you think "I wish we hadn't done that then".
Good for them. I've been watching them quietly working hard, and it has been like that for a while now. Good luck! Hopefully some projects that make security completely invisible come about from this.
An open-source, audited, encryption application based on NaCl already exists:
https://github.com/Spark-Innovations/SC4
I also have a keyserver that is currently in closed beta. Contact me if you want an invite.
https://github.com/Spark-Innovations/SC4
I also have a keyserver that is currently in closed beta. Contact me if you want an invite.
This is an amazing pursuit, and I wish you guys the absolute best! Unfortunately, I think public adoption of encryption will continue to be a problem until there is absolutely no barrier -- both in knowledge and UI design -- between the average user and encryption. This is a huge step in the right direction though!
One request Keybase friends...
Can we get a forum or mailing list to discuss crypto design decisions, security etc on launch day?
Can we get a forum or mailing list to discuss crypto design decisions, security etc on launch day?
It's pretty awesome how simple it is to use.
But why trust a third party to hold your private key?
Why trust them to not store the plaintext when you encrypt/decrypt with them?
But why trust a third party to hold your private key?
Why trust them to not store the plaintext when you encrypt/decrypt with them?
You don't have to trust them, you can use their open source downloadable client. The web interface is only for ease of use, and they make it clear that many people consider that "unsafe" compared to their desktop/command line alternative.
Yet they still offer it as the easy option, despite it being absolutely wrong.
I once thought of doing the same for medical information. I am really excited and eager to see you succeed. It's a shame that America does not offer some kind of national repository, but at the same time, it's great that you can tie a user's own data to his consent. It all works great for non emergency situations. Good job getting the money. I hope you can get the work done too.
Congrats! Keybase has been making cryptography easier for me and everyone I know.
The Terms and Conditions for Keybase.io seem lopsided (https://keybase.io/docs/terms). Why is that?
Very timely, considering the possible resurgence of the crypto wars.
I have a small question here for the people who use keybase and it's been difficult to find answers for this. How do you encrypt per email address ? is that even possible ? I would like to use it for a personal project of mine and that would be the use case. (Sorry to hijack this thread, it might be interesting for other people).
Congratulation to the whole team for your hard work !
Congratulation to the whole team for your hard work !
I don't know what you mean by "encrypt per email address." Who is doing the encrypting, and to who? Do you want to have multiple keypairs associated with a single keybase account?
You can encrypt with lots of things, for example
$> keybase encrypt twitter://twitter_id -m 'message'
But there seems to be no way to to it with an email address like this:
$> keybase encrypt email://[email protected] -m 'message'
Or maybe I did not understand something.
$> keybase encrypt twitter://twitter_id -m 'message'
But there seems to be no way to to it with an email address like this:
$> keybase encrypt email://[email protected] -m 'message'
Or maybe I did not understand something.
Yeah, email's a bit more complicated than twitter. I think for the time being, you want to just encrypt to a file and attach that. Maybe there's a standard (PGP mail?) that keybase could output to a file, but that doesn't tend to play well with the GUI mail clients that people typically use.
Thanks for your answer. The main goal on my case is to use the email address as an identity (since it's currently the closest thing I have for this) and not to send encrypted PGP email messages. That's why I never really understood keybase. You can encrypt with a twitter id but not send a encrypted tweet with GPG anyway, so why can't you encrypt by email ? I assumed the most basic form of identity is an email address. Thanks again for your answer.
Well, keybase only uses verified identities like twitter, hackernews, etc as identifiers. As far as I know, there's no way to publicly verify that someone actually owns an email address...
[deleted]
Happy to hear this, love what they're doing.
> Chris Dixon championed the deal; he’s known for his visionary investments, ranging from Soylent to Oculus to Airware.
Pretty strong language there (and definitely not provably true or fale), but I guess bold phrasing is what SV is known for.
Pretty strong language there (and definitely not provably true or fale), but I guess bold phrasing is what SV is known for.
Awesome! I hope some of this $ will help to shorten the waiting list queue...
I just sent an invite to your adlervermillion address.
To be honest I haven't found their service to be useful in my day to day life. I am mainly inviting you out of sheer guilt, because I have been accruing invites and not using the service.
"Use your keybase account. There are insecure children in the US that write their passwords on post-it notes." ;)
To be honest I haven't found their service to be useful in my day to day life. I am mainly inviting you out of sheer guilt, because I have been accruing invites and not using the service.
"Use your keybase account. There are insecure children in the US that write their passwords on post-it notes." ;)
I've been on it for a couple months now. I've used it twice: once was to exchange AWS IAM keys for a consulting job and the other was for someone to give me their credit card details.
But in most cases it's just to track someone.
But in most cases it's just to track someone.
Thanks, appreciate it.
Throw me an email if you'd like an invite.
Edit: I don't have any more!
Edit: I don't have any more!
I've still got six invitations - ping me.
I have 8 invites if someone wants one...
I'd like one if any are still left. How would I go about getting it?
Wonder just how secure the @keybase.io email part of this is going to work? Would you have to load this email into a client or would you just pull down the email in Node?
Thoughts anyone?
Thoughts anyone?
This could help solve the personal identity verification issues associated with smart contracts and such. This is one of the key problems with the Ethereum project too.
"Your mom is on LinkedIn and Facebook, downloading toolbars." I laughed too hard at this. To be honest I still am.
https://keybase.io/jobs is timing out (504).
=)
=)
Congrats guys! I had played around with this 6 months ago. Looking forward to seeing what you guys build.
Doesn't this just set up a central failure point? Does Keybase have a forward secure key system?
It feels like their growth strategy is "make security decisions for other people".
>server-side PKI system that individuals and companies can host themselves
It is not possible to deploy this to the mainstream who probably need encryption the most. Keybase's mission iirc is to bring encryption to the masses without having to learn about encryption. It is imo the best alternative to the status quo, i.e: no encryption.
It is not possible to deploy this to the mainstream who probably need encryption the most. Keybase's mission iirc is to bring encryption to the masses without having to learn about encryption. It is imo the best alternative to the status quo, i.e: no encryption.
Can someone please send a Keybase invitation to:
[email protected]
This help would be appreciated.
[email protected]
This help would be appreciated.
Just sent you an invite. If anyone else needs an invitation, I still have 8 left. Shoot me an email or reply here if you want one.
Edit: 6 still left.
Edit: 6 still left.
Why the invite thing? Really? Why shorten artificially on who you let in?
Referral trees let you control abuse; if someone suddenly spawns lots of accounts via nested referrals for abuse, you can just cleave off the appropriate subtree.
Really? How can they publicly state that they promote security and open source tools while denying anyone access who like to use the service?
You're not really using the service, you're connecting to "the" web of trust (Are there disconnected non-contiguous islands on keybase? Only the admins know, probably). That makes me feel "meh" about giving out my invites to random HN users. I mean, if you're not going to connect to me, or the rest of the WoT, then what value do "we" get from you joining, and if you're not going to connect to me, or the rest of the WoT, then what value do you get from my invite?
Now what I don't understand is there are existing large WoT in GPG keys and they "shoulda" given like 1000 invites to anyone with a debian.org developer key because thats a community of deeply connected very long term WoT (well, more or less).
Find someone in your existing WoT who is on keybase and they probably have invites and will give one. I have invites. I will give them out to anyone in my existing WoT who asks. If they aren't in my WoT then theres no point for them to ask, or me to give. Even friend of friend or more distant, not just signed each others keys.
This also creates a dilemma where I have to keep a stockpile of invites in case some I closely connect to "needs" an invite. So FoFoFoF of some guy I met at a HOPE conf might not get one of my invites because I need to save it in case my coworker finally gets off his butt and signs up and he needs my invite. This is rollout mistake two, I should be able to request via a form or something "I have a really good excuse now gimme an invite". However they're AFAIK randomly granted over time or something.
Now what I don't understand is there are existing large WoT in GPG keys and they "shoulda" given like 1000 invites to anyone with a debian.org developer key because thats a community of deeply connected very long term WoT (well, more or less).
Find someone in your existing WoT who is on keybase and they probably have invites and will give one. I have invites. I will give them out to anyone in my existing WoT who asks. If they aren't in my WoT then theres no point for them to ask, or me to give. Even friend of friend or more distant, not just signed each others keys.
This also creates a dilemma where I have to keep a stockpile of invites in case some I closely connect to "needs" an invite. So FoFoFoF of some guy I met at a HOPE conf might not get one of my invites because I need to save it in case my coworker finally gets off his butt and signs up and he needs my invite. This is rollout mistake two, I should be able to request via a form or something "I have a really good excuse now gimme an invite". However they're AFAIK randomly granted over time or something.
Invite-based sign ups create a false sense of demand. This is the tactic behind gmail's huge growth.
Really well written. Kudos to whoever wrote your copy!
I've still some invites left, who want one?
Hi, I'd be interested in one if you still have any left. My email is [email protected] if that's what you need to send an invite.
Done
-----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.12 (GNU/Linux)
owEBOgLF/ZANAwACAert2DDXuRFrAcsKYgBVp03FRG9uZYkCHAQAAQIABgUCVadN xQAKCRDq7dgw17kRa6MIEACX5rLZo7t+Wt+0NYBaIQd3JPY0A/5TxPec8bKa2k6/ Mj1Gg9Dl+UJ0GB9WXraYiWz65BhwjsyyI0ZCtisRJ/pprr7adMi5uRs0W6HgydEh ixm9FEqHsH4jjwr2gmfb8Xs2+ILq6ZbwIX5aPzcLNIZoePNp3Upxx+eCOG+iPbmI whSjIfLgM92KsH6kvKxYDIpnkx+RJfT2JPcTDisfIkgPuka+10OmdZV7BS1RxBKT resQutP4faMWtU1z49Nn0ZokQOqTvE7ZAXBj6sremKDt8uu2aaavcDnWkpKSsqXD 6fiq53T9kdp3mNK/Q9QnN3IEYMdhq+WIkmKSKUX8AmGby3wNVTLM0QSq76FLWzE3 WWcVIGllFFBwCg+2GK0Car+zet+SqcBTd4EMUJUT2Avy0WLVXxSFodF8pYN85FXy /CrRdyJYxoAoyy+8Qb8IFQ7CNfZeThJvm3YYAXAIV0Qvo7XtPiNcXsfjt1Oy512G lmi7vWweDdT7liF6Q7exd8dA1AyuM1p0yOqIXdYJiLo6zUtunJzS3uTmQ6KYUV/E lVv5c5CGmRKf+jBAls/1pVcybfncZpRZ9FnXiuFdmsfSmuu8yy0Vmu1GMmqV5MCq hHkalT8gqY7fXN1hLnlLxV8ymJIrKlOzN7TN8W0hKOUkEF1Am0eCvKbtEkQWAJ98 iQ== =oKGe -----END PGP MESSAGE-----
-----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.12 (GNU/Linux)
owEBOgLF/ZANAwACAert2DDXuRFrAcsKYgBVp03FRG9uZYkCHAQAAQIABgUCVadN xQAKCRDq7dgw17kRa6MIEACX5rLZo7t+Wt+0NYBaIQd3JPY0A/5TxPec8bKa2k6/ Mj1Gg9Dl+UJ0GB9WXraYiWz65BhwjsyyI0ZCtisRJ/pprr7adMi5uRs0W6HgydEh ixm9FEqHsH4jjwr2gmfb8Xs2+ILq6ZbwIX5aPzcLNIZoePNp3Upxx+eCOG+iPbmI whSjIfLgM92KsH6kvKxYDIpnkx+RJfT2JPcTDisfIkgPuka+10OmdZV7BS1RxBKT resQutP4faMWtU1z49Nn0ZokQOqTvE7ZAXBj6sremKDt8uu2aaavcDnWkpKSsqXD 6fiq53T9kdp3mNK/Q9QnN3IEYMdhq+WIkmKSKUX8AmGby3wNVTLM0QSq76FLWzE3 WWcVIGllFFBwCg+2GK0Car+zet+SqcBTd4EMUJUT2Avy0WLVXxSFodF8pYN85FXy /CrRdyJYxoAoyy+8Qb8IFQ7CNfZeThJvm3YYAXAIV0Qvo7XtPiNcXsfjt1Oy512G lmi7vWweDdT7liF6Q7exd8dA1AyuM1p0yOqIXdYJiLo6zUtunJzS3uTmQ6KYUV/E lVv5c5CGmRKf+jBAls/1pVcybfncZpRZ9FnXiuFdmsfSmuu8yy0Vmu1GMmqV5MCq hHkalT8gqY7fXN1hLnlLxV8ymJIrKlOzN7TN8W0hKOUkEF1Am0eCvKbtEkQWAJ98 iQ== =oKGe -----END PGP MESSAGE-----
Thanks! I appreciate it :)
Hacker news managed to kill even keybase.io.
Grats @gabrielh!
Love the vision, guys. Huge congrats! Looking forward to seeing this one unfold.