I don't understand tracking

[panicsteve]

This is more of a problem with me than a problem with Keybase. But I bring it up since you specifically asked us to file issues if we were unclear on anything.

Please forgive my naivety when it comes to signing and crypto matters. I understand, in a general way, the basic principles of signing and public key encryption, but I am no expert.

When I go to "track" someone on Keybase, here is the info that appears:

Tracking on Keybase is a big deal.

Tracking is sort of like "following" on other sites.

I'm with you so far.

However, when you "track" someone on Keybase, you are signing their key and identity proofs.

As far as signing someone else's key and identity proofs, I interpret that (possibly incorrectly) to mean I am vouching that this person's keybase identity is authentic. Like a "web of trust" sort of thing.

But that seems at odds with the word "tracking" -- to me, tracking/following evokes something that you can do frivolously on a whim. On the other hand, if I'm saying "yes, this person is really who they say they are", it seems like there should be more of a barrier to entry. Like I shouldn't "track" anyone I don't personally know.

This way you can request their username on any computer, and know you're getting the same answer from Keybase. This is especially useful in your terminal.

And now I'm really off in the weeds. What do you mean "when I request their username"? In what specific way is it useful in the terminal?

I guess what I'm fundamentally not understanding is what is the benefit (to me) of tracking someone? Is there a benefit to the other person?

Apologies again for cluelessness.

[copumpkin]

As I understand it, your signature of their profile information is primarily for your own benefit. Say I track @malgorithms but don't trust his website not to get compromised. I plan on sending him a top-secret encrypted message in a week. I know his information is legit now, so I track him. If a week from now, the website gives me a different key for him (I can identify that it changed based on my signature), I'll certainly be suspicious of encrypting a message with that key.

If I indeed understand this correctly, a simple HMAC would be sufficient for this purpose, except for the fact that you might be sending that secret message from a different computer without your secret key, so you might know your public key fingerprint and nothing else. The public key signature scheme lets keybase tell you that you trusted that information at some point in the past.

Does that make sense? Please someone correct me if I'm missing the point.

[malgorithms]

hi @panicsteve - glad we're having this conversation, because it's something I've been struggling to explain on the site. And I need to do a better job. And yeah, it's confusing, because people think of "signing" someone's key in the WoT model, where you're making a statement that they are who they say there are.

Oh, and explaining things in a web form is tough because you pretty much have to get it down to 2 or 3 sentences or so, which is a constraint I don't have here.

So the problem, in a nutshell: when you first hear that there's some Keybase user you want to deal with, it's be nice if you could think of them in terms of a username, instead of some long fingerprint. That's probably what they told you or you read somewhere. Usernames are easier to remember and parse for errors that big fingerprints.

Our security model with Keybase is that the server isn't trusted. The client is (and you can write your own), but the server isn't. So when it replies with malgorithms' identity, there are two steps that have to happen:

1. your trusted client has to make sure:
   • malgorithms' key is self-signed
   • each of the identities the server claims is verifiable by the key; this is done by scraping each of those sites, checking the statements, making sure the statements make the right claims, that they're signed by the key provided, etc.
2. you, as a human have to review those identities and decide that's the person you want. it might be you're interested in a different twitter or github user, for example.

So now let's say you're on computer A and you encrypt a message for malgorithms. Then you go to computer B. Unfortunately you have to go through this process all over again. Because all you're typing in is "malgorithms" and once again, what if the server gives you the wrong info?

This is solved by you signing a statement of who malgorithms is and posting it on the server, for your own benefit. So when you perform a crypto action on malgorithms, you download that statement and know it hasn't been f'ed with, and you don't have to trust whether you got the right public key.

Does that make sense?

[panicsteve]

It does make sense. And I also don't know how you'd reduce that to a 3 or 4 sentence summary. :)

It seems like using a word other than "tracking" might help, but I'm not sure exactly what to suggest.

The first thing that came to mind is "snapshot". Like, snapshotting a person's identity at this point in time. This conveys that it's something that could change the road, but that you have a historical piece of evidence to compare those changes to.

Perhaps a new term along those lines, along with a link to a longer explanation from the web form for those who need the additional clarification?

It's a tough one!

[foozmeat]

Tough problem indeed. Fundamentally you're protecting against a MitM attack correct?

Do you plan to expose to the user if someone you've tracked has tracked a user that you're interesting in communicating with? The key concept to convey to a novice is that if the stakes are greater than zero then they need to take an extra step to ensure that they're encrypting to the right key/ keybase identity. If, as a novice, I can see that my keybase social network has vouched for someone's identity then I'll feel more comfortable using them myself.

The rub I have with tracking is that it describes an active process. In other words if I'm tracking Steve then I expect to get notified about changes to Steve's account. That's not what happens. Steve's point about snapshotting is in the right direction in that it conveys you're recording the current state of someone's credentials and now you have something to compare to in the future.

If the site asked me if I wanted to "verify" (as opposed to track) Steve and then gave me his list of credentials to follow up on I think I'd know what my action accomplished and also understand that the action wasn't going to provide any further information to me in the future. You could also make clear that my vouching for him becomes a part of his public record. This has the potential side-effect of making the verifier feel a little more invested in the verification steps. I'd like to see when I verified him in the list currently labeled "Tracking".

Unfortunately this overloads the word Verify in a sense which is maybe not a problem.

[malgorithms]

Yes, MitM and coersion of our server; your satisfaction of Steve's identity is not portable without your signing it.

To clarify one thing about the future of tracking:

The rub I have with tracking is that it describes an active process. In other words if I'm tracking Steve then I expect to get notified about changes to Steve's account. That's not what happens.

Very soon, yes, if Steve's identity changes since you started tracking him, then a few things will happen:

• in the CLI, if he adds an identity or something else making his new identity a superset, you'll receive a warning that he's added to his identity and you might want to review it
  • in the CLI, if something goes missing or he removes/revokes something, you'll get an error; how often this kind of thing is checked is subject to a couple controls
  • an email will be generated for you when his identity changes (which you can turn off)
  • on the website if you're tracking an out of date version of him, you'll be alerted when viewing his profile or trying to take some crypto action
  • and of course, if his key is deleted/revoked/replaced/whatever, you'll be notified too, in all these places

Obviously these things are not all implemented. But I just wanted to address the active/passive nature of it; "tracking" is intended to mean you have an ongoing interest in changes to his identity and key. They shouldn't be often.

Also, we chose "tracking" because we didn't want it to seem an endorsement of the accuracy of his identity. This seems to confuse people a lot. "Snapshot" is a good word, too, but we also want there to be a social element here, which will lend itself to future tools we may build (and others may, too), such as messaging platforms.

In summary: hmmmmmmmmm.

[CameronBanga]

I'm not nearly as qualified to comment as you guys, but some thoughts from am extreme crypto novice. Like Steve, I was also a bit confused as to what tracking was at first. And while @malgorithms following me almost immediately on account creation felt neat and special, it did give me the sense that I should reciprocate or go out and find other users to track? I wasn't quite sure what the next step was.

I agree that this is difficult to do in one or two sentences, but maybe some sort of system could be written where users receive a signed encrypted message after account verification from @malgorithms? Is that even possible? I honestly have no idea, again I'm a complete novice and this is my first step into crypto. But maybe this message could include helpful links/long form information on next steps?

Thought being that if someone follows through far enough to this point, they will benefit from this information and not mind the longer explanation, and it won't cause friction during sign up, so won't be a 2-3 sentence limit?

[mattieb]

I think this is the right place to pitch in with my own thoughts on this. Thanks for the discussion so far.

@trenton42 is a good friend of mine, but we've never got around to actually verifying each other's fingerprints properly. (Later this month, I will do it.) But I thought, okay, I could track him.

$ keybase track trenton
info: ...checking identity proofs
✔ public key fingerprint: 7E3C FC83 D64E 2A7B C124 5AC9 191A 0473 89DD 2A77
✔ "trenton42" on twitter: https://twitter.com/trenton42/status/441778278521909248
✔ "trenton42" on github: https://gist.github.com/9404822
Is this the trenton you wanted? [y/N] y
Permanently track this user, and write proof to server? [Y/n]

This makes me a little uncomfortable, specifically the line about his fingerprint, and whoa, I'm writing a proof. I do rely on his Twitter handle already, but I feel like it's trust of the class that involves trusting a third-party, not direct trust. I get nervous asserting his fingerprint because I haven't actually been introduced to that via a trusted party.

I can certainly look at and verify his proofs myself without trusting the server, but that all reduces to a trust of Twitter, Github and Keybase, since if any of those are compromised or tricked, anyone can post a proof with any key they choose.

I guess what I'm trying to say is that I was all gung-ho to track until the above text popped up on my screen. 😆

[mdekstrand]

To make sure that I understand what is going on with tracking: tracking a user writes a signed statement or object to the keybase.io server. This statement is a Keybase-specific concept, and is used to remember my verifications of the user's web-based identity, such as Twitter account.

Tracking a user does not create an actual PGP signature of their identity, such as is used in the Web of Trust.

Is that correct?

[malgorithms]

yes, that's correct.

[malgorithms]

and to be clear, you should feel a lot more comfortable tracking someone on Keybase than signing their identity in a WoT model. If you run the keybase client and id someone, it verifies the tweet, gist, etc., and makes sure both that it all exists, and also that the key is the correct one. It does the bulk of the work.

So all you have to do personally -- if you trust the client -- is make sure it is in fact the twitter or github username you want, and then you can reliably access their public key on any machine, without fear of the server lying.

Discovering who people track on Keybase is a fun thing, we hope, and it will help grow the service's popularity. (We'll do what we can to make crypto popular!) But note you can also track privately with --track-local.

I am frustrated trying to find an easy way to explain tracking. But it's very useful.

If you know someone on the site who only has a public key but hasn't proven their identity on any services, tracking is also helpful. Just make sure they tell you their fingerprint in person and you review it.

[mdekstrand]

@malgorithms Thanks.

It seems there are at least 2 major difficulties in communicating tracking: communicating to new/unexperienced users what it is, and communicating it to experienced PGP users in a way that does not confuse or scare them with respect to existing trust and signature models.

[malgorithms]

yeah, well said. I feel sandwiched between the two. We'll definitely work on this.

[jeremy-w]

After reading this, the prompt that comes to mind is, "Would you like to remember your judgment that this keybase user is so-and-so?" It's like notarizing for yourself that indeed this Keybase username with this quiver of social services is indeed the person your were hunting for.

Put antoher way, tracking seems to be adding a personal seal-of-approval on the identity for my own use, a seal that I can verify was written by myself and rely on in the future, but that no-one else need worry about. "Note to self" might be better as far as avoiding overloaded/stylized crypto terminology.

From that point of view, what's missing to me is a way to leave a private note for yourself along with the recorded judgment saying who that person is, in the event their social service/keybase names are not the first that come to mind for you when describing the person to yourself. For example, maybe you've always called the person "JW", even if their usernames happen to all be variants on "amigahaxx0r".

[timbray]

OK, I just read this thread and the explanations I’ve seen still aren’t working for me. I’m confident enough in my own mainstream-ness that I'm pretty sure this means lots of others too. Let’s make it operational:

*** I do track "ericajoy". I say

keybase encrypt ericajoy -m whatever

It goes ahead and gives me the encrypted message

*** I don’t track “arlen”. I say

keybase encrypt arlen -m whatever

It goes and checks identity proofs right then and there, asks me whether this is the right arlen (and finally asks me if I want to track this person).

So...... this feels to me essentially like a caching/shortcutting operation. It uses a signature to protect the result of the checking computation. I suspect that if keybase ever takes off and needs to operate at scale, tracking is going to be a requirement, practically speaking, otherwise you’re gonna have twitter and github mad at you, among other things.

I assume that what you do is just sign the “user” object? With what, exactly?