I don't understand tracking #100
Comments
|
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. |
|
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:
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? |
|
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! |
|
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. |
|
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:
Very soon, yes, if Steve's identity changes since you started tracking him, then a few things will happen:
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. |
|
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? |
|
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. 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. 😆 |
|
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? |
|
yes, that's correct. |
|
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 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. |
|
@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. |
|
yeah, well said. I feel sandwiched between the two. We'll definitely work on this. |
|
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". |
|
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? |
|
Here's the JSON object that I'm signing when I track Erica. The relevant features are:
{
"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"
} |
|
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. |
|
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. |
|
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. |
|
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? |
|
@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. |
|
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. |
|
@mattbehrens granting everything you say, if I track someone today, because On Wed, Mar 19, 2014 at 9:50 AM, Maxwell Krohn notifications@github.comwrote:
|
|
@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. |
|
Actually, there is a real live bug here. The web page at On Wed, Mar 19, 2014 at 10:09 AM, Matt Behrens notifications@github.comwrote:
|
|
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). |
|
Mildly but not very sorry about hijacking this bug report into a discussion Upon reflection, it seems to me that the nastiest attack by far is the I wouldn’t mind trying out keybase-without-stored-private-key, but there On Wed, Mar 19, 2014 at 9:31 AM, Maxwell Krohn notifications@github.comwrote:
|
|
@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? |
|
Well, the nice thing about keybase is that if you use the command-line On Wed, Mar 19, 2014 at 1:57 PM, Cameron Banga notifications@github.comwrote:
|
|
@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. |
|
One of the inherent risks in tracking is the meta-data regarding the people you track, or the people tracking you. This information establishes a relationship between two entities and erodes privacy, regardless of who stores it (on keybase or locally). Look to some of the issues with PGP clients updating keys within keychains. Intelligence actors would find this to be a very sought after source of connection data. Establishing trustworthy private identities is probably the number one challenge in todays trust model. |
|
mlinton, I think your concerns on metadata tracking are valid however I don't believe that preventing this kind of tracking should be a goal of keybase. Keybase exists as a layer of trust above what PGP provides and will be easier for beginner/casual users to grasp (eventually). If your threat modal includes actors who would be interested in who you're communicating with then Keybase is not the right tool for you. Having said all of that I think it would be a cool thing for the keybase folks to explain metadata tracking on the site and why using keybase's modal might be a bad idea given certain circumstances. |
We'll post more info on this in the future, when we exit alpha. One thing to consider is that we've designed our data model so that it's easy to mirror Keybase's sig chain in its entirety, even with no fears of lies by omission. (See our server security docs and how we put our merkle tree root in the bitcoin blockchain.) What this means for people who worry about the leakage associated with requesting someone's key: you can ask any server that mirrors keybase. You can also implement a mirror easily, and prove to a client that they're getting up to date info. You could even run a small program which mirrors every user's key and proof chain. Or even a "random" seeming subset. There are a number of solutions for those who fear key lookup metadata leakage. You can also visit Keybase and Keybase proofs over Tor. Outside of Keybase, checking the proofs themselves is arguably metadata leakage. If you visit someone's tweet where they say "this is my fingerprint", someone could have infiltrated twitter and noticed this. This is true outside Keybase, too: if you're getting someone's key anywhere on the Internet or reviewing statements about that key, you're leaking info. But yeah, public tracking does/will have metadata leakage - we figure this is abundantly clear when we publish trackers on the website and use the word "public" in the client. The idea is that you've posted a public statement that on date X someone's proof looked like P...and this strengthens the audit of their key. cc |
|
I'd like to suggest yet another alternative for the word "tracking": "recognizing".
The rest (including the crypto) is just plumbing. Also: the sentence "@thedod has recognized @malgorithms" is a past event (i.e. a snapshot), while "@thedod is tracking @malgorithms" sounds as if I'm regularly verifying stuff. It's true I may "recognize" you again once my "recognition" expire (or your proof does), but once again — this would be a snapshot and not an ongoing process (and there's no guarantee I'll "recognize" you again: e.g. if you change your avatar and start speaking a different language 😉). |
|
I hope you'll excuse me for not reading the whole discussion (I skimmed through it), but I wanted to report a little mistake:
Yes, it is very hard to use, as is apparent from the fact the information in that very footnote is inaccurate, or wrong, in an important aspect! :) It says you trust John, but you'd also need to trust Carla if you wish to be able to get key validity for Maria. If you don't assign ownertrust to Carla, the PGP Web-of-Trust model will not assign any validity to Maria through Carla's signature. This makes sense because trust is not transitive. I've signed a good number of keys of people I don't know at keysigning parties. But I'm making a statement about their identity, not their trustworthiness. If it were to work as it is explained in the footnote, somebody who trusts me would also suddenly trust signatures made by people I only met once on a keysigning party and don't know in any other capacity. And since Carla apparently signs keys while drunk (XKCD fan?), I would not trust her signatures ;).
|
|
Sorry to dig up an old thread. Am I right in thinking that "tracking" somebody on keybase, is entirely separate from signing someone's public key? I notice that the contacts keybase has imported into my keychain are both untrusted and unverified in the eyes of the command line gpg tools. This means that when I send an encrypted email in mutt, I get a warning. Should we also sign each others keys int the traditional manner (i.e. external to keybase)? |
|
For what it's worth, I do. |
|
Hi, |
|
@DigitalBrains1 I think you're right. I've filed a ticket for us to fix the footnote. @quinot you're right, the local tracking instructions don't automatically verify proofs for you. It's expected that you'll do this to your satisfaction by hand. A couple reasons:
|
|
To my understanding, "tracking" is more like "pinning". You pin a key of somebody else and remember it. |
|
As someone just about to finally unsub from this long-running thread, that is imho a much better term @mitar! |
|
I opened a ticket: #1913 |
|
If Pinning, then why not use MONITOR as a base crypto verb?
If monitoring is the first action taken by a user upon another user, then many other sub-actions could fall beneath it. Such as FOLLOW (receive alerts, quick access to activity in client UIs etc), VOUCH (periodically vouch for someone after meetings, projects and other associations, loose or tight, that warrant this social gesture), CERTIFY (voluntary occasional assessment of the users identity chain), MESSAGE, etc etc.... Now as I type this, MONITOR could be akin to Facebook Friend, however on FB you don't have to FOLLOW a friend or even interact with them. It has become the initial thread of tethering people together. MONITOR is also like a cousin to TRACK. It is less agressive, however. Tracking makes me thing of sniffing and pursuing and hunting. All aggressive actions to find someone or keep them close to watch every move etc. Monitoring to me is just more passive and easy-going. It seems that's the more proper vibe of this Keybase usage pattern. So, there is my input after reading this entire thread on a Friday night and Sat morning :) |
|
I've been keeping an eye on Keybase for more than a year now and so far it seems promising. Just like everybody else on this thread I got super confused by the notion of "tracking" but I am better now ;-) For anybody (like myself) coming from hardcore PGP background it would've been much easier to get what Keybase is doing if the notion of sigchain was explicitly exposed and discussed from the get go. Speaking of which, are there any plans to allow CLI-driven inspection of sigchain for a given user? Is there an issue for an extension like this or should I file a new issue? |
|
As it stands, the Perhaps you can already view what you need if you add the debug string ( |
|
@zQueal thanks for pointing out -t this is super useful! (like I said I really think keybase should advertise this more especially during the time when the whole thing is trying to boostrap and gain trust). Anyway, this definitely gives me a point at which to look for doing my hacks. As far the CLI goes it still has a few annoying limitations:
|
One of the biggest issues with keybase is documentation. But qute honestly, the Go build isn't even finished to the point of being pushed to the general public. But once that's done, you can expect documentation to be scrubbed and amended.
This would probably be best in its own ticket. For posterity and because it's a really great feature. (assuming it's not already a planned feature) |
|
@mitar I too think a verb change would be an improvement. It is important to distinguish "tracking" from an actual signature of someone's public key, which occurs only when their identity can be confirmed in real life. Tracking seems to be a Keybase-specific and user-specific signed snapshot meant to save me from repeatedly checking Github, Twitter, etc proofs for a frequent contact. I'd call that "pinning", "memoizing", "sealing", etc before calling it "tracking". The way tracking/trackers are prominently displayed on a user's profile seems misleading to newcomers, even dangerous. The fact that I "track" person A just says at one point I checked a few social proofs (enough that I was somewhat comfortable) and created a snapshot of their key and signed it for my own personal use/convenience later. I'm not sure I see value in the trackers/tracking list being public - nobody else should make decisions based on it imo. |
|
Update here : we've renamed "tracking" "following". There were lots of proposals in this thread from early on, and lots of considerations pointed out and good ideas proposed. Ultimately "tracking" gave too many people the creeps and we wanted to teach people it's a casual decision (as in not an attestation) and a public decision (you can look at the people that someone follows). People have learned the term "follow" from other sites, and it achieves those goals well. we'd been talking about this for a few months - it wasn't an abrupt decision. happy to keep this thread open for further discussion of what it means. The latest app and website should have this wording. The |
|
@malgorithms: Why not pinning? |
|
It's a good word...I think for non-technical users who haven't learned the underlying meaning, it's less universal as a social action. people will still be left wondering:
For "follow" the UX is pretty clearly expected because of many sites. Pinning is obviously used elsewhere (notably pinterest), but it brings up more questions about what it means to pin a person. All that said, "pin" could still be a bit better word for describing what's going on underneath it all. |
|
I think pinning might be more familiar now because of Pinterest. From Pinterest they would know:
But I just wanted to make sure you considered it as well. I do not want to reopen the discussion. Following is much better than tracking. It just does not mean anything technically. But it is easier to explain to technical people what you are really doing than vice-versa. :-) |
|
I agree, "Pin" makes more sense compared to other options, it also doesn't confuse people thinking they're actually doing something like key signing. |
|
For what it's worth, I read the doc page on "following", didn't understand what I was asserting by following someone, came to the linked bug and saw the body of the bug itself saying
This is exactly my question (which at least for me isn't clear on this page). What am I asserting by following a user? I'll (selfishly) neglect to read the 94 comments on this issue to better understand it and just hold off on following anyone for the time being. I'll try checking back to the doc page another time and see if it makes any more sense about what I'm saying publicly by following someone (that I'm confident their accounts haven't been taken over at this point in time, that I trust keybases assertion that the listed accounts are linked because I've verified the account assertions client side, something I'm not thinking of, etc) Update@nealmcb pointed me below to comment #100 (comment) above by Chris Coyne which explains this well. Thanks @nealmcb |
|
What about hiding followed and followed by people ? |
|
ここでいいですか。お互いもう一度信頼するためにしておくべきなのでしょう。信じてるけどね。大事なことでしょう |
|
Following people is a good thing for you to do so you can easily keep track of your own verifications. |
and others
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:
I'm with you so far.
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.
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.
The text was updated successfully, but these errors were encountered: