Live data from Hacker News

Petnames: A humane approach to secure, decentralized naming

files.spritely.institute

41–50 of 50 posts

Re: Petnames: A humane approach to secure, decentralized naming

#41
post #30

Contacts are just a toy example, aren't they? Else this is a privacy nightmare waiting to happen: It's easy to accidentially share numbers. Also it might turn out your new friend J. is superficially pleasant, but actually a horrible human being once you get to know them - congratulations, J. has access to all your shared contacts. If I was friends with Alice, I'd be very annoyed that J. is now harassing me. Or suppos…

A contact list actually seems to me like an abnormally bad example for other reasons, or I'm way more atypical than I think I am and everyone else curates their contacts far more carefully. For me, the proliferation of spam means I'm never going to answer an unrecognized phone number, and thus enter everyone I ever expect to receive a phone call from into the list. The vast majority of the time, these are things like contractors coming to my house, a hand surgeon I visit for one injury and hopefully only one injury, a shop I take my car to hopefully once and only once. Numbers I received a call from a few times, possibly more than a decade ago. The fact they're still in my contacts list says nothing whatsoever about my level of trust in them and doesn't mean other contacts, especially my actual friends, should assume anything about their presence except that I received at least one phone call from them at some point and I was expecting that call.

That's aside from the fact that contact lists are not reciprocal. Adding a number to your list and giving it a name doesn't mean the owner of that number has added you to their list. There is no guarantee whoever is on the other end of that number has any idea who you even are.

This is also aside from the fact that phone numbers can be reassigned. That's an argument that I and anyone else as cavalier about their lists as me should be removing numbers more often, but outside of a fairly short time horizon, there is no guarantee that the person who owns a number you have listed as "Bob" is still Bob.

These issues aren't unique to digital contact lists, either. My wife pulled a book off the shelf a few months ago I hadn't opened in a very long time and found an old sheet of paper I'd written some phone number on, possibly 25 years ago? One was a very good friend from high school, a name I still knew and a number I still recognized as her parent's home number from the late 90s. The other, I have absolutely no idea. Probably some designated driver for a group of friends I was going to a party with who were going separate from me in case I needed someone to call if something came up. I may have never even called that number or received a call from it.

Hell, how many contacts of people in their early 20s are someone you met in a club who gave you a fake phone number that happens to be some other person's real phone number?

This bugs me to no end with all the apps out there for smart phones that want access to your contacts. Why? What significance do you think this list has? It's just a semi-random assortment of some sub-sample of all the people and organizations I have had some kind of fleeting and possibly one-time interaction with in the past quarter century. It doesn't imply I remember who they are, know them, or that I vouch for them in any way.

Re: Petnames: A humane approach to secure, decentralized naming

#42

There are some niceties here, but I think this is a little thin on the security aspects of the scheme: it's not clear how users establish the authenticity of transitively received petnames, for example. More fundamentally, there's a factor outside of Zooko's triangle: trust isn't really transitive[1]. I trust my doctor and my doctor trusts their sibling, but I don't necessarily trust their sibling. With that being sa…

> I trust my doctor and my doctor trusts their sibling, but I don't necessarily trust their sibling. Sure, but let's get back to the use case we are exploring here: Do you trust your doctor's contact info for their sibling? Could it provide you utility? What about your doctor's contact info for the front desk of their practice? What's important here is that the subject of trust is explicit to whoever attests that tru…

> Sure, but let's get back to the use case we are exploring here: Do you trust your doctor's contact info for their sibling? Could it provide you utility? What about your doctor's contact info for the front desk of their practice?

Not inherently: for all I know, my doctor is technically illiterate and their contact book is thoroughly padded with spam.

The problem of trust is that trust isn't a boolean; it's a set of policies that vary by principal and action. It's very hard to encode that in a truly general way, which is why modern cryptographic application design orthodoxy dictates that applications should try to solve exactly one kind of trust at a time.

Re: Petnames: A humane approach to secure, decentralized naming

#44

Contact lists do work and are okay for friends, but businesses also need to publish contact information. What do you put on a sign, on a business card, or in an advertisement? You'd need to print the underlying id number, which makes it part of the UI. Inevitably, people are going to want something like a 1-800 number, perhaps with a mapping to letters that are easy to remember. Either you can pick the number you wan…

QR codes for canonical addressing could solve the publishing problem, with customization of how the QR code appears being a feature for advertising and marketing. Once the canonical address has been accessed once, it could be pet named by the accessing user.

Good answer. But I’m wondering how well this works when a QR code resolves to a meaningless string of digits?

I suppose most people don’t check URL’s anyway, and for some URL’s the domain name is fairly meaningless. Still, it seems like something is lost, at least for techies, when you can’t see and recognize usernames and domain names?

Consider how programming languages work. Who wants meaningless numbers in their import statements or package.json file? Package names seem decentralized enough? Not sure it’s worth throwing out to achieve True Decentralization.

Re: Petnames: A humane approach to secure, decentralized naming

#45
This sort of reminds me of certificate authorities. A certificate authority is just a list of edges in this sense, and you inherently trust what the CA says are valid edges. (with some cryptography magic to verify it's really on the CA's list)

You could make everyone their own "naming authority", so you could trust anyone's list if you choose to, but I would also bet we'd end up with a similar situation, where someone compiles the most names, and becomes a great default to use, so people don't spend much time cleaning up their own data, and things sort of naturally centralize.

Re: Petnames: A humane approach to secure, decentralized naming

#46

Earlier quoted context omitted.

> I trust my doctor and my doctor trusts their sibling, but I don't necessarily trust their sibling. Sure, but let's get back to the use case we are exploring here: Do you trust your doctor's contact info for their sibling? Could it provide you utility? What about your doctor's contact info for the front desk of their practice? What's important here is that the subject of trust is explicit to whoever attests that tru…

> Sure, but let's get back to the use case we are exploring here: Do you trust your doctor's contact info for their sibling? Could it provide you utility? What about your doctor's contact info for the front desk of their practice? Not inherently: for all I know, my doctor is technically illiterate and their contact book is thoroughly padded with spam. The problem of trust is that trust isn't a boolean; it's a set of…

> Not inherently: for all I know, my doctor is technically illiterate and their contact book is thoroughly padded with spam.

Sure, but that leads us to the next question: Could it provide you utility?

> The problem of trust is that trust isn't a boolean

That's also the utility of trust. Most of the information we want to reason about is not context-free. So far, no one has figured out a reliable way to offload context-sensitive work to computation. The next best thing is to offload as much context-free work as possible, and provide the user a direct interface to the remaining context-sensitive work.

By organizing our social networks as attestations of [dis]trust, we can deliver the uncomputable question of trustworthiness closer to the user. By delivering that question to many users, we can collaborate efficiently on that work.

Re: Petnames: A humane approach to secure, decentralized naming

#47

Earlier quoted context omitted.

> Sure, but let's get back to the use case we are exploring here: Do you trust your doctor's contact info for their sibling? Could it provide you utility? What about your doctor's contact info for the front desk of their practice? Not inherently: for all I know, my doctor is technically illiterate and their contact book is thoroughly padded with spam. The problem of trust is that trust isn't a boolean; it's a set of…

> Not inherently: for all I know, my doctor is technically illiterate and their contact book is thoroughly padded with spam. Sure, but that leads us to the next question: Could it provide you utility? > The problem of trust is that trust isn't a boolean That's also the utility of trust. Most of the information we want to reason about is not context-free. So far, no one has figured out a reliable way to offload contex…

It could provide me utility, and it could get me scammed. That’s the double bind.

(I don’t think delivering the question of trust closer to the user has worked all that well, historically. Why do we expect inexperienced users - who should not have to understand anything technical! - to do better rather than worse when they’re given large numbers of datapoints about a principal’s trustworthiness? The default hypothesis should be that the average user is more susceptible to information fatigue than a technically savvy one.)

Re: Petnames: A humane approach to secure, decentralized naming

#48
post #33
post #30

Contacts are just a toy example, aren't they? Else this is a privacy nightmare waiting to happen: It's easy to accidentially share numbers. Also it might turn out your new friend J. is superficially pleasant, but actually a horrible human being once you get to know them - congratulations, J. has access to all your shared contacts. If I was friends with Alice, I'd be very annoyed that J. is now harassing me. Or suppos…

To reinforce the real-world value of contact secrecy, let me share an example of how WhatsApp's contact broadcasting is creating massive opportunities for scammers where I live (Mexico). In WhatsApp, when you join a "community" (sort of like a giant, moderated group), all members of the community are visible to all other members. You can see their phone numbers and their self-chosen nickname. Note that very frequentl…

Is this why I get added to seemingly nonsense communities all the time on WhatsApp?

Re: Petnames: A humane approach to secure, decentralized naming

#49
post #27
post #22

Earlier quoted context omitted.

> I trust my doctor and my doctor trusts their sibling, but I don't necessarily trust their sibling. Isn’t that because that’s a different type of trust? For example, you trust your doctor to give you decent medical advice, and they trust their sibling for emotional support. That doesn’t mean their sibling will be supportive of you, or give you good medical advice.

Yeah, this is one of the big issues with digital peer trust networks. Trust in human interactions is fuzzy and very conditional, which is hard to collect, represent, and update in a user friendly and low effort way. Hence we tend to collapse it to a single, often-binary, trust score.

is not this WoT just about "i fully trust Dr A's public key is P1 because he gave it to me personally. i trust Dr A's sibling's public key is P2 because i've found it somewhere and it's cryptographically signed with P1. so i'm highly confident that this cryptographically signed message is from Dr A's sibling as long as neither P1 or P2 compromised or misused in the meanwhile." ?

Re: Petnames: A humane approach to secure, decentralized naming

#50

Earlier quoted context omitted.

> Not inherently: for all I know, my doctor is technically illiterate and their contact book is thoroughly padded with spam. Sure, but that leads us to the next question: Could it provide you utility? > The problem of trust is that trust isn't a boolean That's also the utility of trust. Most of the information we want to reason about is not context-free. So far, no one has figured out a reliable way to offload contex…

It could provide me utility, and it could get me scammed. That’s the double bind. (I don’t think delivering the question of trust closer to the user has worked all that well, historically. Why do we expect inexperienced users - who should not have to understand anything technical! - to do better rather than worse when they’re given large numbers of datapoints about a principal’s trustworthiness? The default hypothesi…

I would argue that the technological aspect isn't the most significant. Average people put too much faith into authoritative sources, even in person.

People know what it means to trust and distrust each other without authority. That's the way everyone interacts with everyone else on a regular basis. It's not a new dynamic: it's the most familiar one.

All we need to do is communicate the lack of authority, and the rest will be obvious.

Post reply on HN