[HN Gopher] Petnames: A humane approach to secure, decentralized...
       ___________________________________________________________________
        
       Petnames: A humane approach to secure, decentralized naming (2018)
        
       Author : simonpure
       Score  : 38 points
       Date   : 2022-08-17 14:45 UTC (8 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | wcerfgba wrote:
       | So, /etc/hosts ?
        
       | ryanschneider wrote:
       | This happy path seems pretty nice, but I feel like there's lots
       | of room for attacks of various types, anyone aware of pre-
       | existing discussions around possible attacks?
       | 
       | For example would something like a robocaller be able to
       | reconstruct my social graph? What about work/life contacts
       | leaking across boundaries I'd prefer they didn't?
        
         | fwip wrote:
         | The article doesn't really go into it, but most real life
         | applications would not share every contact with every other
         | contact. You can imagine a number of different solutions to
         | this problem, but it's mostly a UX issue on how users would be
         | most willing to share their contacts with others. Apps with
         | different approaches could still share data with one another.
        
           | zcw100 wrote:
           | There's a link in there for it but it would be easy to miss
           | that does a much better job of explaining the system
           | 
           | http://www.skyhunter.com/marcs/petnames/IntroPetNames.html
           | 
           | A pentane system actually protects you from phishing attacks
           | and you don't really share your pentanes. You can use your
           | petname as a nickname when introducing a key to someone else.
           | One of the most important parts is to have a good UI/UX that
           | does not confuse nicknames with pentanes or allow you to
           | accidentally accept a nickname as pentane that is confusingly
           | close to an already existing petname.
           | 
           | Nicknames are names that you propose using when introducing
           | yourself or someone else. A pet name is the name you assign
           | privately. So Lumberg could be a nickname but your petname
           | might be "dickhead boss". You're free to introduce him to
           | people you know either way you'd like.
        
       | schanzen wrote:
       | For our transitive use of petnames in name systems see also
       | https://datatracker.ietf.org/doc/draft-schanzen-gns/ and
       | https://www.gnunet.org/en/gns.html
        
       | mlinksva wrote:
       | I would guess this is being posted today because of
       | https://news.ycombinator.com/item?id=32500151 by the same author,
       | which is 2022.
        
       | unixbane wrote:
       | This version of petnames is too complicated. You can't get a good
       | petname system without getting rid of broken crap first. Scanning
       | a QR code on a flyer should be the sole introduction point and
       | just lead to a secure communication from then on. Why do I want
       | petnames for phone numbers or other insecure things?
       | 
       | To put it differently, no petname system built on top of unix /
       | web crap will ever be good. Everyone (like posters here) will not
       | understand what they're doing and just write code that breaks it
       | on all layers of the OS and GUIs. Guaranteed if Android starts
       | using petnames more there will just be issues like it copies
       | someone's petnames all over yours, shares the ones you didn't
       | want to share, etc.
        
         | Zamiel_Snawley wrote:
         | _no petname system built on top of unix / web crap will ever be
         | good._
         | 
         | This claim is unsupported.
         | 
         | If you have created or know of a better version of petnames,
         | I'd love to hear about it.
        
       | pfraze wrote:
       | Basically petnames change the addressing architecture from "one
       | global mapping" to "many local mappings." This means that
       | petnames cannot be used as shared identifiers; you use a global
       | UUID when you need to identify information between users. There
       | are some contexts where this works great (the phone address book)
       | and some where it doesn't (Web URLs). In effect, if I wanted to
       | drop a URL in this comment, the petname model requires that I use
       | the UUID. You can share petnames with each other to help people,
       | and you could publish petnames and do searches (but this creates
       | trust questions - how do we verify a pet name is accurate?).
       | 
       | It may be an entirely suitable approach, but it basically means
       | there are no global short names. I can't tell you Im at pfrazee
       | dot com if there's no global dot com registry.
        
         | unixbane wrote:
         | The replacement for the web will have secure identifiers
         | instead of "URLs", and the GUI will simply replace them with
         | whatever nickname you gave, and all programs on your OS will
         | share the same registry. Or I guess we'll just have another 40
         | years of misconceived ideas first, it's hard to predict.
        
         | ryukafalz wrote:
         | Sure, but I'd offer an observation: you typically aren't typing
         | in the URLs people link in comments here anyway! You just click
         | the link and your browser takes you there. This works just as
         | well for a human-readable name as it does for a UUID.
        
           | pfraze wrote:
           | For sure. It might be a totally serviceable approach.
        
         | infogulch wrote:
         | So instead of having one global registry you have many local
         | registries. If registries are also identified by UUID then you
         | say pfraze dot com in the <registry uuid> registry. I like this
         | because then you can have registries that correspond 1-1 with
         | other real-life things that can be internally consistent
         | without having to worry about global uniqueness, like a
         | registry of all registered businesses in a state, or all
         | trademarks, etc.
         | 
         | The next step is to create a system for "peering agreements"
         | between registries, or meta-registries.
        
           | pfraze wrote:
           | You can, but any shared address book needs to have a very
           | clear scope of applicability. Basically: any users that are
           | communicating need to either share the same registry, or have
           | some clear indication that they aren't in order to avoid
           | significant mishaps. I'm not totally sure how you accomplish
           | that.
        
             | kixiQu wrote:
             | <del>The federated approach would be the same way that we
             | distinguish cooluser@gmail.com from cooluser@proton.me; in
             | this case, the server part would just determine who you're
             | asking to map cooluser to a UUID.</del>
             | 
             | Actually, this is handled pretty clearly in the example
             | article.
        
         | Kinrany wrote:
         | > In effect, if I wanted to drop a URL in this comment, the
         | petname model requires that I use the UUID.
         | 
         | Could you drop the petname and let the clients resolve it via
         | the UUID of the Hacker News website?
         | 
         | Edit: I believe the article calls this "edge names".
        
         | jwalton wrote:
         | > In effect, if I wanted to drop a URL in this comment, the
         | petname model requires that I use the UUID.
         | 
         | Yes... or, not at all, depending on how you want to look at it.
         | To use their phone book example, if I want to call my dad, I
         | look up "dad", and I call him. I don't use his phone number
         | (although obviously down in the internals of my phone it's
         | going to use his phone number).
         | 
         | If you had a local mapping for a web site saved as "coolsite",
         | you might post a link here on HN as "web://coolsite". Your
         | browser would take care of translating that into a UUID under
         | the covers, so the actual post would contain the UUID. When I
         | read the post, though, I would probably see the link as
         | "web://@pfraze => coolsite" (obviously your browser would need
         | to post some metadata for that to happen - similar to how you
         | can include a name with an email address) or if I already have
         | the site in my local mapping I might see it as
         | "web://thatawesomesite", or whatever name I'd chosen. Or
         | perhaps my browser would go to something like DNS to reverse
         | lookup the UUID.
        
           | biotinker wrote:
           | This unfortunately only works in situations where rich text
           | is available that can hide the UUID, which is not the case
           | for HN. The person you replied to is correct: they cannot
           | share the URL literally in that comment, without using the
           | UUID visible to all.
        
             | jwalton wrote:
             | Maybe... But maybe not. If the browser was the one with
             | support for pet names, the browser could see the UUID URI
             | and replace it transparently for you. Would we want the
             | browser to transparently replace a URI in plain text, even
             | outside an anchor tag? Maybe, maybe not - this is a good
             | question. Maybe it would pop up the pet name in a popover
             | if you hover on the URI? Or maybe we'd have some special
             | markdown syntax for these links that has the URI, a
             | suggested pet name for people who don't have one, and a
             | link text (since markdown URIs at the end of a post are
             | pretty much how we roll here on HN today anyways).
             | 
             | I wouldn't try to think about this as "What if we
             | implemented a browser plugin that supported this?" Instead,
             | think about if this was "the standard". Imagine a world
             | where there was excellent support for it in _all_ software
             | that we use, and browsers and /or sites would find ways to
             | make it transparent and friendly. Like, what if VS Code
             | made it so when you hovered over a URI in a piece of code,
             | it would look it up in your local pet name database, and
             | show it in a popover? If this were just "the way things are
             | done", then you'd never put up with crappy software that
             | showed you the UUID. It would be like web sites that don't
             | let you highlight or copy text - software that didn't
             | handle naming resources correctly would be obnoxious
             | software you'd hate to use.
        
               | ryukafalz wrote:
               | Right, if we're talking about what this _could_ be like
               | then it 's instructive to consider what a client would
               | look like that supported this natively. For example, we
               | might have a "petname" tag that a browser could use to
               | display a petname link like so:                 <petname
               | ref="pet:4f30b43ec38b43c3abad5d422125900f"
               | proposed_name="Google" />
               | 
               | The browser would then display this in the same way
               | mentioned in the OP; if you already have an entry locally
               | it shows your local name, otherwise it shows the proposed
               | name and marks it as such.
        
               | pooper wrote:
               | I was kind of hoping we can just use long urls... as long
               | as we are NOT typing them by hand :)
               | 
               | Previously, on HN (just this morning, still on the front
               | page) https://news.ycombinator.com/item?id=32493946
               | 
               | so if I wanted to share a document about how much water
               | we need in total per day, I could just share you the
               | complete url... or at least that's what I was thinking
               | earlier. As long as I don't have to type it by hand, it
               | should be ok, right?
               | 
               | https://numpad.io?#text/O4ewTgNgJg+gDiOBXCBDALgSxAOwAQC8e
               | A7A...
               | 
               | my rough estimate calculation if anyone is interested, a
               | cube that is about one kilometer and half (under a mile)
               | on each side is enough water for all the people in the
               | world for a day.
        
       | rambojazz wrote:
       | I'm looking forward for the comments about this. I
       | discovered/read about "pet names" a while ago, but I could not
       | understand very well what problem they're trying to solve, and if
       | they solve it.
        
         | c0mptonFP wrote:
         | Petnames try to solve a trilemma known as Zooko's triangle.
         | 
         | A naming system that is both permissionless and globally unique
         | will tend towards unreadable names. You'll see lots of Sybil
         | attacks on these systems, with botnets squatting any decent
         | name.
         | 
         | For DNS, you have many governance bodies that act as
         | gatekeepers for domain registration. Repository hosts like
         | GitHub avoid Zooko's triangle by having namespaces, and an
         | appeal process if someone is squatting your trademark.
         | Crates.io on Rust doesn't allow automated crate creation.
         | 
         | In many cases, naming systems are not permissionless, and
         | gatekept by a central entity. Once you open the floodgates of
         | permissionless-ness, you're dealing with a hostile environment
         | that's difficult to control.
         | 
         | Petnames are _one_ solution to this issue. Others are
         | Handshake, Namecoin and ENS
        
         | unixbane wrote:
         | The proper way to connect to a service on the internet after
         | the 70s when crypto was invented, is to connect by public key
         | or hash thereof. Instead of a bloated insecure HTTPS stack,
         | your code just connects and checks against the public key which
         | was used as the address (actual implementation details like
         | finding the IP address or routing over an overlay network is
         | done automatically with something like a DHT).
         | 
         | The second piece to this is how the GUI works. Instead of
         | showing long bit strings or hex encoding them in some pointless
         | way, it allows you to assign names to these addresses as you
         | come across them. When you see the address in some other page
         | it will show up with the name you assigned and so you will
         | recognize it.
         | 
         | A key point to this is that HTTPS does not actually cause you
         | to know you are using the right domain name. Aside from the
         | fact that HTTPS is untrustworthy due to the CA model,
         | mybrand.com or mybrand.net or one of the other infinite number
         | of legitimate sounding things could all be the correct domain
         | for some brand, you would never know unless someone previously
         | _introduced_ you to the right domain name. Since you had to get
         | it from somewhere, you may as well have received the public key
         | at that point, which could be encoded in a QR code, or, on the
         | internet, which is the main use case of petnames, trivially
         | included as a link in some web 8.0[1] page or chat where you
         | first heard of the brand.
         | 
         | 1. I guess it will take them 6 more tries to get this right.
        
       ___________________________________________________________________
       (page generated 2022-08-17 23:02 UTC)