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 suppose you created a list of all doctor's phone numbers in your area. You can then look up if any of your contacts (friends, family, loose aquintance) share any of them (e.g. because they recommended a specialist to a friend).
This needs a tremendous work to setup access rights, and it's easy for an individual to screw this up and put themselves in a bad spot.
Sharing contacts on a need-to-know basis (using e.g. Threema or WhatsApp) is the established standard in my peer group; be it the number of a Pizza place or my SO's new number, so a common friend can invite her to a party. And while it's less cool and adds some effort, it requires an explicit action to share a contact. This is more safe.
In my humble opinion, and I might have a bad hunch there: The overall mistake with that example is lies in how it associates identities with phone numbers. In reality, it's the other way around. We want to share identities (be it the Pizza Place, Mum, or a doctor), and should have control who can access the information (not just phone numbers) associated with them.
But that's essentially re-inventing social networks with a narrow focus.
From a academical perspective the technical issue can be interesting of course, and valuable insights might be gained from this research.
There might be use cases beyond the basic contacts example; in fact, I think in a company phone directory this can be incredibly useful as part of the CRM.
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 frequently people will have their names or a shortened version of their name as their nickname.
In emerging markets, people use WhatsApp for everything and many people will naturally join a few communities. Things like:
- A community for your kid's school
- A community for your neighborhood's safety alerts.
- A community for a club or hobby.
So a scammer's workflow is as follows:
1. Infiltrate a community or a group.
2. Check all of the members and find those whose names are publicly shared or you can deduce.
3. Use their name, phone and--crucially--information about the community itself to craft a targeted phishing phone call.
Example:
Sandra is a part of a community for neighborhood safety news. The community is called "Hillsborough safety." Her whatsapp nickname is "Sandy Williams."
A scammer will join the community and see her contact. They will then call her with a message like "Hi, is this Sandra Williams? Yes, I'm calling from the Hillsborough police department. Unfortunately there's been an accident with your husband...".
You can imagine how the simple fact of knowing someoen's name and some sort of "proprietary knowledge" (they know I live at Hillside!) can be enought to for a victim to lower their defenses.
An additional layer to this is that often the scammer will social-engineer their way into gaining access to the victim's Whatsapp account itself. They can then access all of the groups that victim was a member of, including "tight" friend groups, etc.
IMHO contact broadcasting is an inexcusable design decision by WhatsApp.
A contacts list is a superset of the publicly available connections that would make up a web of trust. Out of all my contacts, there are a few people that I would be willing to vouch for. As in: declare publicly that I know who they are, and reveal the name that I refer to them as.
That pet name may be different from person to person, but that's fine. Alice might call a public key "Bobby's Public Key", and Charlie might call it "Robert's Public Key". I can make sense of those attestations when I'm trying to verify that I have Bob's key, and assign it my own pet name. If Alice or Charlie weren't willing to publicly attest to the Bob-ness of the same public key then I wouldn't be looking at their attestations.
> Else this is a privacy nightmare waiting to happen: It's easy to accidentially share numbers.
That's a critical implementation detail, but I think it can be done. All we need to do is make contact-sharing an explicit feature.
> But that's essentially re-inventing social networks with a narrow focus.
Yes it is. That's the utility of decentralized networks: by removing the hierarchy from the network, we have removed the explicitly drawn context. Instead, the context is implicit and flexible. There are pros and cons to this feature. Instead of segmenting "twitterverse", "facebookverse", etc.; we simply have "the universe". The same boundaries can be replicated, but the lines are drawn by the users instead of by the platform, all while preserving compatibility across those lines.
As far as privacy in curated networks goes, I think we could find some interesting strategies to accomplish it. One could be anonymous pseudonyms: publish the attestations you don't want traced back to you as an explicitly not-you user. Another could be attestation laundering: provide a publicly available user (that anyone can use) that publishes a collection of attestations as if it was the original publisher, and let collaborators vote on that user's overall validity via attestation.
Essentially, we must contend with the inverted hierarchy that decentralized networks are made of. It's definitely a change, but I think can provide a lot more utility than centralized networks provide today.
Yes, I think this was a really bad example, and something without humans would have been better, so for example naming of cloud server resources.
With real world names there's also the messy issue of name changes and dead-naming. If Alice changes her (his) name to Bob, but Eve keeps Alice in as Alice, you'd have mutual contacts seeing still referring to Bob as Alice.
There are also of course the privacy concerns you mentioned, despite any optionality of sharing contacts.
Here's a problem that this does potentially solve:
"Two different cloud orchestrators need to be able to create servers which may get referenced by servers they each create. Coordinating unique names would be difficult".
Although that's an odd problem, and it's already solved in a similar way by other hierarchical naming structures with authorities such as domains, which is essentially what this pattern is describing in a roundabout way.
"com" names everything under it. "example.com" names everything under that, etc. Multiple different paths can point to the same resource.
This complaint and thinking of other simple but sliiiightly more advanced permission/privacy systems reminds me of G+ circles - kinda wish it'd have taken off. I thought it was a pretty neat system.
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.
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 said, I think there's a pretty rich research space here, and I think the edge/local aspects of this design are pretty interesting! I just hope we don't end up with a reinvention of historically insufficient web-of-trust architectures :-)
There's an associated paper that goes through implementing a petname system in a simple chat application. Petnames compose well with object capability security.
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.
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.
> 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." ?
> 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 trust. If your doctor intentionally publishes a list of known contacts, then it can be reasonably presumed that they know those contacts. This, along with the ability to attest falsehood, should be enough to replace traditional authority and moderation.
> 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.
> 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.
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.)
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.
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.
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.
It frustrates me that domain names were designed to be a rival good, and that this has attracted so much attention from speculators, and the negative externalities that come out of that. I'm not sure what would be a good solution here.
The existing design of domain names does have one important property, though. When someone successfully registers a name, they're guaranteed that they can pay a renewal fee - small, all things considered - and keep the name as long as they want - perhaps modulo legal and ToS concerns. This gives them assurances that they can invest into the branding of the name and keep the benefits.
Compare that with search engine results. I mentioned elsewhere in this thread that I watched numerous non-technical users treat their browser nav bar as a name resolution mechanism - effectively delegating name resolution to their default search engine. Search engine results should change over time. If someone starts a FooBar Inc. in one industry, and someone else starts a bigger FooBar Corp. in another, who gets the "foobar" name?
A sort of "pin on first use" would save existing users of FooBar Inc. New users trying to find FooBar Inc. might get confused though. FooBar Inc. would understandably be hesitant to print the "foobar" petname on their business cards and billboards.
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 decentralized petnames. The article’s example of the bizdir local business directory is somewhere in between these extremes. It sort of turns Zooko’s triangle into more like a fan, where the “human friendly” point is fixed and there’s an arc describing the tradeoffs, from personal through local to global.
How can a petname system function at the global+centralized point, so it could replace the DNS? It needs to pass the “billboard test”: I type in a name I saw on a billboard and I get to the right place. (It might be a multipart name like a postal address or DNS name, with an extra “edge name” or two to provide enough disambiguating context.) I imagine that an operating system supplier might provide a few preconfigured petnames (well, it probably includes its own petname so the software can update itself securely), a lot like its preconfigured PKIX CA certificates. These petnames would refer to orgs like the “bizdir”, or Verisign, or Nominet, that act as nickname registries. Your collection of petnames is in effect your personal root zone, and the preconfigured petnames are in effect the default TLDs. There would inevitably be something like the CA/Browser forum to mediate between OS suppliers and nickname registries: a petname ICANN.
I wrote an older iteration of these ideas over a decade ago (https://dotat.at/@/2012-02-28-path-names-in-a-rootless-dns.h...). Those notes have a bit too much DNS braindamage, but I included some curious anti-DNS discussion: How you might make use of reaching names by multiple paths? What might it look like to have a shared context for names that is not global but is national or regional or local?
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.
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.
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.
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.
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”
> Even though Ben is trusting that caller ID is correct, he can't imagine any reason why someone would be trying to phish him to authorize a topping change
This is excellent. I think it's only really missing one thing: curation.
There is an example of moderation: the bizdir business directory. This is really useful, since Dr. Jane Nym is able to find an explicitly trusted contact for Pizza Piano. The problem is that she isn't able to implicitly share either the contact itself (Pizza Piano) or its source of trustworthiness (bizdir) with Ben Bitdiddle. In practice, this forces Ben to fallback on Caller ID, which is precisely the system we intend to replace!
This is the failure of moderation in decentralized networks. Traditional moderation is founded on authoritative hierarchy, which is exactly what decentralization removes from the system. To replace it, we need a decentralized alternative to moderation. I propose curation: each user curates their list of trusted contacts, and publishes it as a list of attestations. The bizdir business directory could actually be a good example of this, so long as we clarify some particulars.
Consider "bizdir" as a participating user of the decentralized network. The bizdir user has published a list of attestations, including the contact for Pizza Piano. There is an opportunity here for Dr. Jane Nym to replicate bizdir's attestation of Pizza Piano, thereby solving the problem for Ben Bitdiddle without requiring his involvement. When Dr. Jane Nym calls Pizza Piano, she is implicitly validating it as a genuine contact. Why not make that explicit? At the end of the call, her petname/contacts app may ask if she trusts the number she just called; or she may have it configured to do so automatically. If she ever finds a reason to distrust the Pizza Piano contact, then she can tell the app to publicly attest her distrust.
So what's the difference here? Isn't bizdir functionally identical, whether presented as a curating user or an authoritative moderator? The difference is that, as a curator, bizdir is explicitly redundant. Ben Bitdiddle doesn't need to interact with bizdir at all. He can benefit from it secondhand via Dr. Jane Nym's redundant "bizdir => Pizza Piano" attestation. On top of that, the validity of Pizza Piano's contact info has been attested to Ben twice, which can only help to drown out any potential outdated or fraudulent Pizza Piano listings. This pattern can feed back into itself, such that Dr. Jane Nym would never have actually relied on bizdir alone as a source of trust, because many of Pizza Piano's customers will have already publicly verified the same attestation.
---
The utility of curation can extend anywhere we expect moderation. The greatest struggle for decentralized social networks is that they are immediately overcrowded by taboo content. Anyone who has been banned from traditional moderated platforms will try to build their home on your decentralized one; after all, one of the core features of decentralization is the circumvention of censorship. The problem is that most of the content that gets banned from centralized platforms is content that the average person is genuinely disinterested in. Just because we want to welcome free speech, doesn't mean we want to spend our time reading hate, watching trauma, or arguing with bullshitters. In order to make a space where regular people willingly participate, we must give users equal power to not participate. We can accomplish this with curation.
Essentially, curation is a shift in strategy. Rather than demanding everyone accept the blatantly false attestation, "this content does not exist" (a moderator ban), we can collectively attest, "this content is garbage", and get back to sharing the rest.
Too much entropy. Any 128bit+ thingy with global uniqueness, whether it’s a hash or guid or public key, doesn’t matter. It’s not ever going to be memorizable for mortals.
You can generate novelty nonces for the first X chars, but you will eventually get mumbo jumbo, at which point it’s never gonna be a “good name”.
I think perhaps the PoW/PoS solution to byzantine generals (as used by Ethereum, for example) can and does solve the Zooko's triangle problem via things like ENS.
I don't anticipate that end users will be able to ingest or cope with the mental model involved with the correct usage of the system described in TFA.
I propose an implementation of these petnames by sharing directory access through mutually trusted brokers, whose identity is proven by certificates and whose location is discovered through a standardized directory service protocol. I think we can make huge strides by working with the ITU here — if we can convince them IP is the next big thing, then we might not end up being chained to the OSI netstack for the first release.
It’s proposing a decentralized naming scheme, with nearly zero implementation details, with the idea that it works like split-horizon dns plus some undefined form of list sharing. Adding a bunch of cryptographic stuff to it doesn’t really change the hard bits of discovery.
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 suppose you created a list of all doctor's phone numbers in your area. You can then look up if any of your contacts (friends, family, loose aquintance) share any of them (e.g. because they recommended a specialist to a friend).
This needs a tremendous work to setup access rights, and it's easy for an individual to screw this up and put themselves in a bad spot.
Sharing contacts on a need-to-know basis (using e.g. Threema or WhatsApp) is the established standard in my peer group; be it the number of a Pizza place or my SO's new number, so a common friend can invite her to a party. And while it's less cool and adds some effort, it requires an explicit action to share a contact. This is more safe.
In my humble opinion, and I might have a bad hunch there: The overall mistake with that example is lies in how it associates identities with phone numbers. In reality, it's the other way around. We want to share identities (be it the Pizza Place, Mum, or a doctor), and should have control who can access the information (not just phone numbers) associated with them. But that's essentially re-inventing social networks with a narrow focus.
From a academical perspective the technical issue can be interesting of course, and valuable insights might be gained from this research. There might be use cases beyond the basic contacts example; in fact, I think in a company phone directory this can be incredibly useful as part of the CRM.
reply