[Freedombox-discuss] human-meaningful names and zooko's triangle [was: Re: FOAF developers taking FreedomBox into their equation]
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
> For those who are interested (and thinking about implementing naming
> systems like this), I'd also recommend this post by Paul Crowley:
> 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
There is the PetName Markup Language (partly a joke) which I find makes it easier to understand what is going on
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:
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 say "your old friend alice" if it had the history of the relationship between the user and alice in the database.
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
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.
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...
> - Adam
Social Web Architect