Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Petnames: A humane approach to secure, decentralized naming

files.spritely.institute

Post reply on HN
Print view View original

11–20 of 50 posts

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

#11

Post by woodruffw »

davexunit wrote: post #9
woodruffw wrote: post #5

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…

There's an associated paper that goes through implementing a petname system in a simple chat application. Petnames compose well with object capability security. https://files.spritely.institute/papers/implementation-of-pe...

That's great, but I don't think it addresses the basic point: sharing edge names requires a way to share those names, and that's a trusted third party (one with a degree of centralization, to boot).

There are ways to (dis)intermediate that trust (like a PKI), but the shape of that PKI or other technique is itself a question of decentralization, security, etc. I think that's a very hard underlying problem that the petname design needs to at least offer some opinions on in order to make claims about security.

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

#12

Post by catlifeonmars »

woodruffw wrote: post #5

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…

> trust isn’t really transitive

Not sure I agree with this. Sure, trust might drop off pretty quickly (like an inverse square law), but I would still trust a friend of a friend over a complete stranger.

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

#13

Post by paroneayea »

woodruffw wrote: post #11
davexunit wrote: post #9

Earlier quoted context omitted.

There's an associated paper that goes through implementing a petname system in a simple chat application. Petnames compose well with object capability security. https://files.spritely.institute/papers/implementation-of-pe...

That's great, but I don't think it addresses the basic point: sharing edge names requires a way to share those names, and that's a trusted third party (one with a degree of centralization, to boot). There are ways to (dis)intermediate that trust (like a PKI), but the shape of that PKI or other technique is itself a question of decentralization, security, etc. I think that's a very hard underlying problem that the pet…

Jessica Tallon's implementation of petnames and edge names was extremely simple within the paper davexunit linked, but used in-band mechanisms to communicate edge names that didn't require any sort of large trusted authority. You could retrieve them directly from fellow peers, who could publish their current set of edge names. This even works in a p2p context over ocapn, etc. The implementation was naive but it did work and used a publish-subscribe mechanism directly from other peers.

That said, edge names are only one way to share contacts. In fact "share contact" on peoples' phones is a great way to have contextual sharing: "Oh, let me introduce you to my friend Dave. Here's Dave's contact info!"

At any rate, petnames aren't a particular technology, they're a design space of "Secure UI/UX". However I do agree more research needs to be done in that space; we've only barely begun to scratch the surface.

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

#14

Post by woodruffw »

catlifeonmars wrote: post #12
woodruffw wrote: post #5

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…

> trust isn’t really transitive Not sure I agree with this. Sure, trust might drop off pretty quickly (like an inverse square law), but I would still trust a friend of a friend over a complete stranger.

I would also trust a mutual friend over a complete stranger. But that's not the point of the observation: the observation is that "trust" isn't a boolean, but an umbrella term for a wide range of policies that we apply to different principals.

Or in other words: transitive trust is a thing, but it's of a different color than "trust." Attempts to gloss over this in web-of-trust designs have historically not gone well.

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

#15

Post by skybrian »

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 want, or people are going to end up re-rolling until they get a "nice" number, and then there's competition for nice numbers just like in other namespaces.

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

#16

Post by catlifeonmars »

woodruffw wrote: post #14
catlifeonmars wrote: post #12

Earlier quoted context omitted.

> trust isn’t really transitive Not sure I agree with this. Sure, trust might drop off pretty quickly (like an inverse square law), but I would still trust a friend of a friend over a complete stranger.

I would also trust a mutual friend over a complete stranger. But that's not the point of the observation: the observation is that "trust" isn't a boolean, but an umbrella term for a wide range of policies that we apply to different principals. Or in other words: transitive trust is a thing, but it's of a different color than "trust." Attempts to gloss over this in web-of-trust designs have historically not gone well.

100% agree about the difference in meaning between the two uses of “trust”. To be frank I responded after only skimming over your comment, and should have read a bit more closely. FWIW, I think there’s a way to unify those two realms: if you model boolean trust in terms of a random variable and sum over the transitive web à la binomial distribution.

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

#18

Post by EGreg »

So, a malicious entity can poison the petnames that others see, but only if prefixed by their own first? So people will learn not to trust them, I guess… but as usual with trust, they can be 99% correct and poison a specific one (eg claim a certain number is a well-known rich guy, and impersonate them)

The bigger issue is that people will need to be careful not to give embarrassing or compromising nicknames to people in their addressbooks.

I had considered using these personal contact list display names as default names for when people accept invites, but the problem is that they’ll know the inviting user had them as “that crazy pooky bob”

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

#19

Post by gregmac »

catlifeonmars wrote: post #12
woodruffw wrote: post #5

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…

> trust isn’t really transitive Not sure I agree with this. Sure, trust might drop off pretty quickly (like an inverse square law), but I would still trust a friend of a friend over a complete stranger.

I'd argue "friend of a friend" is strong transitivly because it's explicitly chosen by all parties involved.

Trust in a professional relation - a doctor, especially - is actually very strong, because of the professional requirements to be trustworthy, and the protections built into that (being held accountable by an organization and/or lawsuits).

"Family of friend" or "family of professional" isn't necessarily a strong relation for exactly the opposite reason, unless maybe the first-degree contract is vouching for the person.

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

#20

Post by RainyDayTmrw »

fanf2 wrote: post #8

I have long been a fan of petnames, and graph naming systems in general. I like to use the term “nickname” for what they call “edge names” in the article: a nickname is not as personal as a petname, it’s a name you share with others. An interesting thing that the article sort of hints at is that these kinds of systems have a fairly smooth range of operating points between globally unique and centralized vs decentrali…

While watching some non-technical people use a web browser, I noticed that they tended to type the name of their intended destination - not the domain name - into the navigation bar. In effect, they had delegated the resolution of names to destinations to their default search engine - Google.

How do we solve the "billboard test"? Delegating to mostly central, mostly trusted authorities gets us roughly on par with the current reality. More interesting is if we could then diffuse this authority by having multiple resolvers and combining them. The details - how to combine results, how to resolve divergences, and results changing over time - could be tricky for UX.

Post reply on HN