I realize a first version of this might sound too restrictive, but the point here is to show how it can be made to work.
The server could instead send a data structure (as opposed to code) describing what to do, without having the power to replace any encryption functions or to execute additional functions that can subvert encryption.
#Keybase server source code#
The point is to make it impossible to do what you just described.įor example, to make it impossible for code sent by a server to execute any Javascript (or other scripting languages) at all. Crypto stuff like the Stanford library would benefit. With folks pushing to make this happen across all browsers, javascript theft of bank passwords and credit card numbers would be much harder. js properties that can be made private (only the object itself can use them) js objects that can be made un-protypable (can't copy or "subclass" them)
js objects that can be made immutable (can't change them in any way) js native extensions: able to talk to native code that was previously installed Think ascii armored GPG signature as a comment for the code it encloses. js that can be cryptographically signed and verified, a trust model and a browser security policy to enforce it. I agree with some of the Matasano points, but these are the minimum, exhaustively complete changes that would improve browser security: On a serious matter, javascript (eg all browsers) absolutely needs to change to make the web more trustworthy. 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. Everything from proving you own a domain to having a tumblr or reddit accoun. We will build out this list of identity checks, hopefully making all kinds of them easy to do. (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. 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. With your known StackExchange profile it might mean posting a statement in a specific part of your profile. With owning a tumblr account, it might be something similar. With twitter, it's the ability to post a tweet under a certain username. So any given identity check has to match some human definition of what it means to have that identity. But someone else could do that it in a comment, and so that wouldn't work with Keybase. For example, what does it mean that you own a certain blog? How would a person confirm it? Well, at first glance it might mean that you have the power to post a message there.
#Keybase server source software#
Good question! There will be no such thing as a general check, because - for any identity - the client software has to perform a check that a human would agree means something. Fortunately you can confirm by following the link to her gist, where she announced her keybase username and posted her key fingerprint. When you look up maria on keybase's website, you are trusting that keybase.io did not lie about her github account. The website itself is of course a different story. But it cannot invent ones that do not exist, without the client knowing.Īgain, the premise here is that maria is the sum of her online identities. The server could also lie by omission, leaving out an identity. 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 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.
Rather, the server replies with links to tweets, gists, etc. When the keybase client requests maria's key from the keybase server, it does not simply trust the public key because it trusts the server (or uses https - huh?). There were multiple questions/comments below about this, so I felt I should clarify one detail about the keybase client's trust of the server.