[Freedombox-discuss] human-meaningful names and zooko's triangle [was: Re: FOAF developers taking FreedomBox into their equation]

[Adam Zimmerman]

On 11-03-16 02:13 PM, Henry Story wrote:
> This topic also falls under the WebID ISSUE-42: Describe the abstract WebId architecture (aka the meaningOfLife issue). Here's my summary of this for that issue.
> 
> On 16 Mar 2011, at 16:31, Adam Zimmerman wrote:
> 
>> On 11-03-16 03:14 AM, Henry Story wrote:
>>> I came across Zooko's triangle in a few recent posts by Dan Kaminsky, of which this one
>>>   http://dankaminsky.com/2011/01/13/spelunk-tri/
>>
>> For those who are interested (and thinking about implementing naming
>> systems like this), I'd also recommend this post by Paul Crowley:
>>
>> http://www.lshift.net/blog/2007/11/21/squaring-zookos-triangle-part-two
>>
>> In addition to proposing his own system, he also makes two interesting
>> points about the problem:
>> - Zooko's triangle actually has 4 properties, but people generally treat
>> one of them as essential and don't mention it
>> - Instead of entirely dropping one of the properties of a naming system,
>> you can make a tradeoff. By lowering (but not eliminating) the
>> memorability of a name and the security of the system, you can still
>> keep all the properties
>>
>> Overall, I still like petname systems more than the one that Crowley
>> proposes, but it's more food for thought which is always nice.
> 
> 
> Thanks Adam for getting me once more to look into this space.  I had not followed up on Daniel Kahn Gillmor's petname hint. I have now read that piece
> 
>   http://www.skyhunter.com/marcs/petnames/IntroPetNames.html
> 
> There is the PetName Markup Language (partly a joke) which I find makes it easier to understand what is going on
> 
>   http://www.erights.org/elib/capability/pnml.html
> 
> It is amazing how much one can learn about naming!
> 
> So petnames are local unique names for a key. Making locally unique names is always easy. It's as easy as creating a locally unique name on your file system. The proposal is that machines be allowed to exchange humanly difficult to read keys with human readable labels, which the user can accept or modify for his own display purposes.
> 
> If we put this in Web Architecture terms perhaps things can be clearer (at least for me). So let us start again with the httpk url scheme.  We have now URLs that look like this:
> 
> <httpk://lhslkdhfsdfsdfsfsfdsxxs23sfsdf/people/Alice#me>
> 
> That is one of Alice's WebIDs. If browsers were httpk enabled we could write
> 
> <a href="httpk://lhslkdhfsdfsdfsfsfdsxxs23sfsdf/people/Alice#me">Alice</a> came to <a  href="/event/2011/03/10/ev1">my party</a> yesterday. 
> 
> (With RDFa we could also mark up the relationship between Alice and the party precisely.)
> 
> The petname idea is that a reader could assign a mapping to Alice's WebID that would not be global but would be memorable for the reader of the page alone. A reader, call him, Joe would allow the following relation to be added to his RDF mapped database:
> 
> <httpk://lhslkdhfsdfsdfsfsfdsxxs23sfsdf/people/Alice#me> foaf:petname "Bob's friend Alice" .
> 
> Then, whenever a UI component on Joe's computer sees Alice's WebID it shows Joe her petname instead.  
> 
>     In fact with an RDF database it could do a lot more: the UI could show an icon using Alice's foaf:depiction.

It could, although in a petname system it's important to separate the
user's petname for Alice (which could potentially be a picture, btw)
from Alice's description of herself (her "nickname", in the terminology
of the page you linked to). Joe always chooses the petname to use for
Alice (even if it's only by accepting the default suggestion), and Alice
is always represented to Joe using his chosen petname.

> It could say "your old friend alice" if it had the history of the relationship between the user and alice in the database. 

Exactly. If Joe already knows Alice under a different petname, it will
show up. There's only one petname for a given key, although the user can
change the name.

>    That would of course require the user first to trust that the WebID was indeed a legitimate identifier for Alice, something we saw could be done via a web of trust, and using mechansims such as http://en.wikipedia.org/wiki/ZRTP

Right. It can also be done using a shared secret to authenticate the
key, like in OTR.

> 
>     In effect those are just ways for the User Interface to use a web of accepted relations around Alice's WebID, in order to build an acceptable and friendly human user interface.
> 
>   But that does not make for a Global Name that one can read off the back of a bus. So we are back to Zooko's triangle, originally explained here http://zooko.com/distnames.html
> 
>    But perhaps DNS is ok for global names that one can read off the back of a bus, since those will usually be companies publishing them. The rest of us may be happy enough with httpk urls. Most people don't read URLs off the back of a bus anymore, but receive them as a link in an e-mail. So perhaps DNS was a just a required bootstrapping technology.

Another part of the petnames proposal is "nicknames". These are names
that Alice can use to identify herself. They are global and memorable,
but are not unique to Alice.

Nicknames could be searched, like you might do on Facebook to find
someone you know, or the way you search Google to find the proper
website for "Debian". Anyone can say that their name is "Alice", but Joe
needs to somehow establish the fact that this specific "Alice" is the
one he wishes to talk to. Once he does that, he binds a local petname to
Alice's key.

> 
>   Now that I understand the petname proposal, I can say that clearly WebID enables something like this. But a few mails back I added to the above that a web site could enhance security by publishing the public keys of all the https servers it had referred to in its pages. This would both be a first step to enabling httpk based urls, and also be a way of helping spot DNSsec abuses once DANE public keys get published there.
> 
>     One could of course also then publish public keys of one's friends client certificates. 
> 
>     So again, oddly enough, it seems that security can be built up slowly off insecure foundations... 
> 
> 	Henry
> 
> 
>>
>> Cheers,
>>
>> - Adam
>>
> 
> Social Web Architect
> http://bblfish.net/
>