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. :laughing:

[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?

[maxtaco]

Here's the JSON object that I'm signing when I track Erica.

The relevant features are:

• body.track.basics --- a summary of Erica's user object, so I can tell if she changes it later.
• body.track.seq_tail --- the tail of Erica's hash chain, which summarizes everything that she's publicly signed
• body.track.remote_proofs --- the remote proofs that I've OK'ed
• body.track.key --- the details about Erica's key, used to verify the above proofs.
• body.key --- My key, that I'm using to sign this tracking certificate.

{
   "ctime" : 1395242478,
   "body" : {
      "version" : 1,
      "track" : {
         "ctime" : 1395242478,
         "basics" : {
            "id_version" : 7,
            "last_id_change" : 1395122282,
            "username" : "ericajoy"
         },
         "seq_tail" : {
            "payload_hash" : "4d253e9de594dbc1926dad16dfe27c5a215387949e7c8e5e35b27659e77092db",
            "seqno" : 4,
            "sig_id" : "8d8a298b639867f6183edfee8a3c05654cb06b40bbc25662988fe9cec19bdf7f0f"
         },
         "remote_proofs" : [
            {
               "ctime" : 1395122257,
               "etime" : 1552802257,
               "seqno" : 2,
               "curr" : "7eb2fbac9d9cd608bb24b64302d0208a72100f28296f65f270d73b7c462760b6",
               "sig_type" : 2,
               "sig_id" : "f2ac76ac5c88b571396e26eed1993cefc246eba31b42a298e92c8951a370d8160f",
               "remote_key_proof" : {
                  "check_data_json" : {
                     "name" : "twitter",
                     "username" : "EricaJoy"
                  },
                  "proof_type" : 2,
                  "state" : 1
               }
            },
            {
               "ctime" : 1395122114,
               "etime" : 1552802114,
               "seqno" : 1,
               "curr" : "61a3f236bb5e2967b9450a471cb15d8829c6ece36353976ad3fec1f28715d63e",
               "sig_type" : 2,
               "sig_id" : "b23aeafe02e4dc04db71f49720045f88156bd282c12577de197858f6128c86080f",
               "remote_key_proof" : {
                  "check_data_json" : {
                     "name" : "github",
                     "username" : "EricaJoy"
                  },
                  "proof_type" : 3,
                  "state" : 1
               }
            }
         ],
         "id" : "cebe39978ac90f0db6ae3234b6aa1f00",
         "key" : {
            "kid" : "010182cb81f55dc659c245cc9c7ef6d9a7477caba8a3cf1df261bd595386c94b3d450a",
            "key_fingerprint" : "47cf5e0b8025ab6d5db9b75aa620b84340e9daa9"
         }
      },
      "type" : "track",
      "key" : {
         "uid" : "dbb165b7879fe7b1174df73bed0b9500",
         "key_id" : "6052B2AD31A6631C",
         "fingerprint" : "8efbe2e4dd56b35273634e8f6052b2ad31a6631c",
         "username" : "max",
         "host" : "keybase.io"
      }
   },
   "seqno" : 20,
   "prev" : "4ad325cfd0b724f5951c9ab779487a2e133a6863ac3027854e954d6c7d824507",
   "expire_in" : 157680000,
   "tag" : "signature"
}

[maxtaco]

Btw, you're signing it with your public key. This captures the WoT component that PGP has, but with way more specifics. You can later verify your own signature on the tracking if you want to move between computers. You can also share these tracks with your friends, so they can base their trust on your signatures. That feature is still to come, but we thought we'd leave the option open.

[timbray]

I'm thinking about the scenarios where the NSA drops by keybase with a National Security Letter, and it occurs to me that tracking might be a firewall against some of the bad things that they might be able to force you to do.

[maxtaco]

An adversary who has full control of the server has three attacks that we can think of: (1) brute force secret keys stored on the server, for those users who have opted into this feature; (2) send malicious code to clients (which is why we recommend running the command-line program if possible); and (3) suppression of updates. The adversary can't forge tracking statements since they are all signed by the users.

[mattieb]

Wait, this is a trust thing now? I thought it wasn't. I thought it was effectively a personal seal.

An adversary can definitely create a tracking statement if nobody has bothered to check their (the adversary's) key in the first place. What's stopping the adversary from creating a key, compromising/tricking/coercing Twitter and/or GitHub into posting proofs signed with that key, and posing as a trusted party?

[CameronBanga]

@zigg I'm not very well informed on this, so someone else can better describe, but I also thought that while keybase is Twitter/Github for now, personal server proofs were planned for the future as well, along with a handful of other potential services? But that Twitter/Github are the only two implemented now.

I assumed for the trust part, the idea being that if proofs are spread across enough locations, the difficulty compromising all would be more difficulty, thus making it much more likely that the key is true and not from an adversary.

[maxtaco]

Sorry to be unclear. Right now, tracking is exactly as you say, a personal seal.

There's the potential for future features based on multiple hops, but as you correctly point out, it's a minefield, and we have to be extremely careful.

BTW @CameronBanga, we're nearly done with proofs for third-party domains names via HTTPS.

[timbray]

@MattBehrens granting everything you say, if I track someone today, because I know that person really is that twitter handle, and then the adversary goes and slips in a new key, if I understand correctly, the tracking signature will break, so tracking provides a useful defense against exactly that. Or am I missing something?

On Wed, Mar 19, 2014 at 9:50 AM, Maxwell Krohn notifications@github.comwrote:

Sorry to be unclear. Right now, tracking is exactly as you say, a personal seal.

There's the potential for future features based on multiple hops, but as you correctly point out, it's a minefield, and we have to be extremely careful.

BTW @CameronBanga https://github.com/CameronBanga, we're nearly done with proofs for third-party domains names via HTTPS.

— Reply to this email directly or view it on GitHubhttps://github.com/keybase/keybase-issues/issues/100#issuecomment-38076505 .

[mattieb]

@timbray Slipping in a new key to an existing Keybase tracking relationship should indeed get noticed, but I bet some social engineering could convince the target that it's an actual new key because the old one was lost or compromised.

It is true that the more proofs you have, the harder the exploit becomes. I am concerned, though, that most proofs likely reduce to email, cf. the Mat Honan incident. This is why I think it's critical to both carefully check PGP fingerprints and keep private keys tightly held.

[timbray]

Actually, there is a real live bug here. The web page at https://keybase.io/timbray still asserts that I’m tracking paulehoffman but in fact I no longer am, because he changed since I did so. So the page-render logic should check that, right?

On Wed, Mar 19, 2014 at 10:09 AM, Matt Behrens notifications@github.comwrote:

@timbray https://github.com/timbray Slipping in a new key to an existing Keybase tracking relationship should indeed get noticed, but I bet some social engineering could convince the target that it's an actual new key because the old one was lost or compromised.

It is true that the more proofs you have, the harder the exploit becomes. I am concerned, though, that most proofs likely reduce to email, cf. the Mat Honan incident. This is why I think it's critical to both carefully check PGP fingerprints and keep private keys tightly held.

— Reply to this email directly or view it on GitHubhttps://github.com/keybase/keybase-issues/issues/100#issuecomment-38079232 .

[maxtaco]

I think it's currently working as we originally intended, but we need better messaging here. We probably shouldn't break the tracking relationship if a proof was added. It should probably break if a proof is deleted (the Website doesn't currently do this). And it should probably break on public key update. Thanks for bringing this up, more work to do here (one of many reasons we're still in alpha).

[timbray]

Mildly but not very sorry about hijacking this bug report into a discussion of vulnerability models...

Upon reflection, it seems to me that the nastiest attack by far is the combination of (2) and a stored private key. Because when I type my pass phrase into malicious javascript, the attacker has my private key and it’s 100% game over. Right?

I wouldn’t mind trying out keybase-without-stored-private-key, but there doesn’t seem to be an admin interface to remove the stored private key. Am I missing it?

On Wed, Mar 19, 2014 at 9:31 AM, Maxwell Krohn notifications@github.comwrote:

An adversary who has full control of the server has three attacks that we can think of: (1) brute force secret keys stored on the server, for those users who have opted into this feature; (2) send malicious code to clients (which is why we recommend running the command-line program if possible); and (3) suppression of updates. The adversary can't forge tracking statements since they are all signed by the users.

— Reply to this email directly or view it on GitHubhttps://github.com/keybase/keybase-issues/issues/100#issuecomment-38073345 .

[CameronBanga]

@timbray My uninformed thought would be that in a situation where this scenario is a concern (and I hadn't thought about it personally, that does seem somewhat scary, good point), it'd be probably best to revoke the private key together and then go ahead with create a new private key and go through the verification process all together.

Inconvenient, but if a person has concern about something like a malicious person compromising the server, you probably also shouldn't trust that you haven't been compromised in the past, etc, and start fresh, as opposed to just trusting that when you hit "Delete private key from keybase", that the key has been deleted/handled properly?

[timbray]

Well, the nice thing about keybase is that if you use the command-line client and don’t store your private key, you're immune to that particular attack. Which is a really powerful statement, and one of the things that makes Keybase interesting to me.

On Wed, Mar 19, 2014 at 1:57 PM, Cameron Banga notifications@github.comwrote:

@timbray https://github.com/timbray My uninformed thought would be that in a situation where this scenario is a concern (and I hadn't thought about it personally, that does seem somewhat scary, good point), it'd be probably best to revoke the private key together and then go ahead with create a new private key and go through the verification process all together.

Inconvenient, but if a person has concern about something like a malicious person compromising the server, you probably also shouldn't trust that you haven't been compromised in the past, etc, and start fresh, as opposed to just trusting that when you hit "Delete private key from keybase", that the key has been deleted/handled properly?

— Reply to this email directly or view it on GitHubhttps://github.com/keybase/keybase-issues/issues/100#issuecomment-38105835 .

[CameronBanga]

@tinbray Oh sure, get that and agree 100%. Maybe I'm misunderstanding, but I though that Keybase had this feature and that storing the private key was an optional decision that the user made on account setup, so if the user wanted to use Keybase without storing the private key, they would choose this option during set up and key would never be stored in the first place.

At least I thought I remembered that from setup, in that storing the private key was not required, but was recommended by Keybase (presumably for using things like the web encrypt/decrypt UI, etc). So my only thought was that if you set up your account initially with a stored private key, you'd first have to revoke the key and then go through setup process/verification again, without the "store private key" option.

[maxtaco]

We do a full SQL delete on "Delete my private key from keybase".

But we keep encrypted DB backups for a few weeks, so your key is still in those (encrypted) backups. We encrypt the backups with a key we keep in cold storage.

BTW, one important point about the attack in which the bad guy roots our servers and captures your password via bad JS is that it's an online attack. If you stay offline during the attack, your key won't be compromised. The longer the attack is ongoing, the more likely it is to be noticed.

So in other words, in the case of an attack (or subpoena), it's not game over for everyone who stores a private key all at once.

[timbray]

Interesting stuff. I’m assuming you’re proactively building a legal strategy, and will have something to say on that front.

On Wed, Mar 19, 2014 at 8:18 PM, Maxwell Krohn notifications@github.comwrote:

We do a full SQL delete on "Delete my private key from keybase".

But we keep encrypted DB backups for a few weeks, so your key is still in those (encrypted) backups. We encrypt the backups with a key we keep in cold storage.

BTW, one important point about the attack in which the bad guy roots our servers and captures your password via bad JS is that it's an online attack. If you stay offline during the attack, your key won't be compromised. The longer the attack is ongoing, the more likely it is to be noticed.

So in other words, in the case of an attack (or subpoena), it's not game over for every who stores a private key all at once.

— Reply to this email directly or view it on GitHubhttps://github.com/keybase/keybase-issues/issues/100#issuecomment-38131759 .

[dougalcorn]

Discovering who people track on Keybase is a fun thing, we hope, and it will help grow the service's popularity.

I'm not sure tracking has any value unless you're sending or receiving encrypted messages from the user somewhat regularly. It seems like it's just a shortcut for inspecting their verifications. Until you actually need to use someone's key, there doesn't seem to be a reason to track them.

[malgorithms]

@dougalcorn - as Keybase grows in popularity (hopefully!) we hope people start doing a lot more with public keys. While encryption/decryption is everyone's favorite go-to example, signing is very important. (And as a consequence, authorization.) So you might track someone not just for private communications, but because you want to use code they sign, or perform crypto currency transactions with them, or simply read a blog they write in which every entry is signed.

we hope that by building a collection of signed tracking statements, your crypto life will be easier as these tools get built out. But you're right in the higher sense, the value of tracking someone is simply that you know you have the right public key. If you'll never need their public key, there's little to gain by tracking.

So why track now if you don't yet have a crypto action you want to take with someone? I think the simple answer is that you've taken the time to look at them now, so the track effort is negligible. With a guarantee that if you ever do need their public key you have a tracked history of it.

A tracking statement which hasn't broken for a long period of time is better than one which is brand new. Why? Well, hypothetically, an attacker could compromise your email, then your twitter account, then your github account, then your keybase account. If someone looks you up in that moment and everything looks legit, they'll have bad data on you because every aspect of your identity has been hacked.

But it's hard for a hacker to maintain that level of control over a long period. You'd realize it and take steps to correct your identity, regaining control of at least one of those accounts, or publicly renounce them all. Meaning: if someone has been tracking you on Keybase for months, and your account is still active, your tweet is still live, your github account still has the gist, etc., and you're still known by those identities, then your public key is basically guaranteed to be the correct one.

[zQueal]

I think it's more the term tracking that's the most confusing thing about the feature. Instead, something such as certify could be used. The very definition of certify (declare as true) really supports what the tracking feature is trying to do.

It's also important, I think, that we all take a moment to remind ourselves one of the single most fundamental talking points in cryptography; not only is it not perfect, but it's also a lowest-common-denominator practice.

[nomicode]

How about this for a summary: tracking is a way to cryptographically assure that the owner of a username does not change on me when I'm not looking.

[zQueal]

Tracking is a way to cryptographically assure that the owner of a username does not change on me when I'm not looking.

Sounds pretty spot on, if you ask me.

[nomicode]

How about this:

Usernames are just a shorthand, so it's important to be able to verify that bob still points to your friend Bob, and not some other Bob, whenever you want to communicate with him. When you track a user, this is done for you cryptographically. If another Bob is using bob, you'll know about it.

[bladealslayer]

I'd say that mainly the confusion for me is about mixing tracking and PGP key signing. The wording is you are signing their key and identity proofs, which leaves it unclear whether proofs refers to the key as well, like in signing their key proofs and identity proofs (I assume this is really the intended meaning). So perhaps simply switching the word order would improve things: signing their identity and key proofs. As long as it is clear that tracking doesn't mean that you sign the other person's PGP key as in the WoT, then it's OK.

Since at least part of keybase.io's users would be pretty well versed in PGP, an explicit statement that tracking does not make a PGP signature of their public key would make things clearer.

[philihp]

I don't think it's realistic to expect users to read the fine print to find out exactly what "Track" means. True, it's just a word, but words carry implicit connotations. Track = bad. Trust = good. Certify = good.

[malgorithms]

I've been working on a pretty heavy attempt at getting everyone to understand tracking, so it's clear where you encounter it. It'll have fancy art like our splash page, etc. This issues is not forgotten and remains very important to me.

I think "trust" isn't the right word because it implies something stronger than what's going on. Someone said "snapshot" but I also want to capture the fact that (especially moving forward) we'll make it clear to you when someone you track has an identity change, not just when you try to perform a crypto action on them. So in effect you are tracking their identity.

[bgpugh]

"watch" is likely right out, but what about the basic "follow"? It denotes observing changes over time, and also has connotations similar to how a social network works.

[malgorithms]

"follow" is what we were calling it initially (before the alpha site went up) and in fact it's still called that in our server-side code. I don't know...does it seem (a) too much like twitter or (b) not meaningful enough? I was thinking that by using a different term we could teach people what it meant - not that I'm doing this well yet - but if we used something like "follow" people would just make their own assumptions and not be curious.

Thoughts? It's definitely not too late to change the name, although I don't want to be too quick with a change. We should let proposals get discussed for a while.

[zQueal]

If anything I think follow is great, although I also believe it's not meaningful enough as you suggested. But at this point, if people are this confused about "tracking", I think it should at least be taken into consideration. But that's just my opinion.

[jeremy-w]

What about:

• remember: Captures the "yes I want to save my judgment this is that person" and goes well with the "hey waitaminute that's changed!" experience.
• subscribe: More focused on the "get identity updates" bit.

Both are (I hope) less susceptible to the social pressures tied to following/friending someone. We don't want pressure to follow-back for example, do we?

Jeremy W. Sherman http://jeremywsherman.com/

El 09-04-2014, a las 9:54, Zach Queal notifications@github.com escribió:

If anything I think follow is great, although I also believe it's not meaningful enough as you suggested. But at this point, if people are this confused about "tracking", I think it should at least be taken into consideration. But that's just my opinion.

— Reply to this email directly or view it on GitHub.

[timbray]

"Remember" really strikes a chord with me. At the simplest level, remembering you believed this was person X. At a deeper level, remembering the proofs so if anything changes you hear about it. On Apr 9, 2014 7:08 AM, "Jeremy W. Sherman" notifications@github.com wrote:

What about:

• remember: Captures the "yes I want to save my judgment this is that person" and goes well with the "hey waitaminute that's changed!" experience.
• subscribe: More focused on the "get identity updates" bit.

Both are (I hope) less susceptible to the social pressures tied to following/friending someone. We don't want pressure to follow-back for example, do we?

Jeremy W. Sherman http://jeremywsherman.com/

El 09-04-2014, a las 9:54, Zach Queal notifications@github.com escribió:

If anything I think follow is great, although I also believe it's not meaningful enough as you suggested. But at this point, if people are this confused about "tracking", I think it should at least be taken into consideration. But that's just my opinion.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/keybase/keybase-issues/issues/100#issuecomment-39967719 .

[mclarkk]

I also like "Remember." I think it captures the idea of remembering the proof quite nicely. It also avoids the social pressure for reciprocity (at least, more than something like "follow" or "subscribe").

On Wed, Apr 9, 2014 at 11:17 AM, timbray notifications@github.com wrote:

"Remember" really strikes a chord with me. At the simplest level, remembering you believed this was person X. At a deeper level, remembering the proofs so if anything changes you hear about it. On Apr 9, 2014 7:08 AM, "Jeremy W. Sherman" notifications@github.com wrote:

What about:

• remember: Captures the "yes I want to save my judgment this is that person" and goes well with the "hey waitaminute that's changed!" experience.
• subscribe: More focused on the "get identity updates" bit.

Both are (I hope) less susceptible to the social pressures tied to following/friending someone. We don't want pressure to follow-back for example, do we?

Jeremy W. Sherman http://jeremywsherman.com/

El 09-04-2014, a las 9:54, Zach Queal notifications@github.com escribió:

If anything I think follow is great, although I also believe it's not meaningful enough as you suggested. But at this point, if people are this confused about "tracking", I think it should at least be taken into consideration. But that's just my opinion.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub< https://github.com/keybase/keybase-issues/issues/100#issuecomment-39967719>

.

Reply to this email directly or view it on GitHubhttps://github.com/keybase/keybase-issues/issues/100#issuecomment-39976301 .

[emory]

fwiw I wasn't confused or concerned about Tracking until I read this Issue. I assumed that this widget would allow me to subscribe to updated directory and relevant crypto metadata for a user and in-turn suggest they do the same for me.

[malgorithms]

hey @emory what do you mean by subscribe?

If you "track" a user, and then later perform a crypto action on that user, your client will query Keybase for both (a) your tracking statement (which is verifiable on your end with your own public key) and (b) their identity, as a series of signed statements by them (technically, it's a blockchain of statements to prevent omissions). If their identity has changed, you'll get their signed changes and the client will prompt you that your tracking statement is now out of date.

In effect you've signed the state of their personal identity blockchain and are tracking that.

Is this what you imagined when you said 'subscribed' to a directory? The goal here is to let you run a client of your choice (ours or someone else's), verify someone's proofs, and then later trust your own verification of those proofs without going through them again.

[bgpugh]

... Why not just "Confirm"? That's what you're doing, right? "I'm confirming that /chris is also @malgorithms"... if that changes, then the confirmation is voided and you're prompted to re-confirm the new identity?

[malgorithms]

Oh, one thing I should remind everyone of, as you think of possible names, is to be sensitive of how it will appear in different contexts. Consider the 2 lists on profiles (currently "trackers" and "tracking"), as well as sentence versions ("chris is now tracking you"). With "confirm", you're probably talk about "confirmations" or something. (Although what would it be called in the other direction?)

Oh, also, and this may be subtle, I wanted to point out that the social elements of tracking can serve a purpose beyond an indicator of interest between two parties.

If I run the command line client and track you, I timestamp that and it becomes another verified source that your identity proofs worked. In this sense "confirmed" is a good name. If I know you and you "confirmed" some party's proofs 3 months ago, that's cool.

But I'm hesitant to use this word when someone tracks in the browser. (Let's not fight here about whether we should allow that.)

Browser users' tracking statements are more like "snapshots"; they tag their tracking statements as browser tracking, which means they performed the human review of the identities and want to know if the target's identity changes, but they trusted the Keybase server to perform the scraping of those services. In this case "confirmation" would be way too strong of a word. It would be misleading to say user A confirmed user B if it's a track they performed and signed in the browser.