Recently, the Shmoo Group discovered that Firefox is vulnerable to precisely the exploit that i predicted in my 2002 paper—Ping
➡
➡
➡
➡
➡
➡
➡

Does your email reader render it as a link? If so, and if you haven’t already assigned a Pet Name to this URL, then it would generate and render a "proposed Pet Name", such as "unknown-3", or perhaps one based on the site’s nickname, such as "paypal-3". In the latter case, you know only that this is one of the sites that wish to be called "paypal". See <erights.org> .

Reading the raw text of the URL itself is about as meaningful as looking at the memory address of an object; and user interfaces should show them to us about as often. Of course, this isn’t currently practical, because we’re starting with a legacy of DNS names, and will co-exist with this legacy for the foreseeable future. But any confusion caused by the text in the URL itself is due to the non-pet-name logic of DNS.

Many people have learned not to believe that any random piece of spam will make their penis bigger. Many have not learned this lesson. Once there’s a practical alternative to reading URL strings, we should regard people who believe what a URL itself seems to say as we regard people who fall for spam. Likewise for people who take nicknames (and therefore the proposed pet names generated from them) too seriously.

Yes, all this is a pain, and much less pleasant than what we might wish were possible. But wishing won’t repeal Zooko’s triangle. I know of no other way to actually solve the problem.—Mark

And so we can go round this loop again. You propose to "fix" this problem by removing all meaning from the URL. How do I then find out what the URL is good for?—Ben

Great question. It is clarifying to think about this problem in a world where URLs truly have all meaning removed from them (I would claim that URLs don’t have any meaning to remove already, but that is a matter that takes us away from engineering and into philosophy, so let’s not go there :-)

Suppose all URLs were large random strings. It is then obvious that meaning must be imposed externally (as opposed to the current situation where meaning still has to be imposed externally, but it is not obvious :-).

Now we use the usual capability tenet, only connectivity begets connectivity. A friend whom I trust to supply a first crucial URL gives me a URL to a site he calls "Goggle", and says it’s a great place go to find other sites that other people will recognize. He gives the URL to me either by handing it to me physically on his flash drive, or he emails it to me, or he reads it off to me over the phone (carefully, though we make the string long enough, it would be really hard for a spoofer to figure out a URL that was similar enough so that a person could make a mistake and be likely to wind up at the spoof site, i.e, an error will take you to nowhere, so you can try again :-).

Now I have a site that my friend Bob trusts as a place to find other sites, I give it the pet name Bob’s Goggle. I type in "paypal", and go to the first hit and the default name suggested as a pet is bob’s goggle’s paypal.

Meanwhile, I also ask alice for her favorite search site. She’s got one she calls Google, which she sends me. If this is the same site as bob’s goggle, my user interface notes that, and I have new confidence in Goggle. Perhaps it is different, and I change the name to Gargle so that it is sufficiently different from Goggle so I don’t get confused. I search for paypal on that one too, and take the first hit, which perhaps is a match for the first hit off goggle. Cool. Looks like, by signing up with this paypal, I will be on a system that allows me to exchange bucks with both alice and Bob.—marcs

I’m new to all this, so maybe I’m thinking about things the wrong way, but my first impression is that your conclusion above looks like a bit of a leap. It looks to me like it is succumbing to two fallacies about reasoning about trust: 1) "transitive trust"; 2) the difference between "I trust X" vs "I trust X for purpose P".

You assumed that if Alice trusts Goggle as a useful general-purpose search engine and if I trust Alice to introduce me to useful general-purpose search engines, then Goggle can be trusted to introduce me to trustworthy payment systems. But that is questionable. With longer and longer chains, it becomes more and more questionable.

Also, you assumed that if Alice introduces me to Goggle as a useful general-purpose search engine, then she would also be willing to claim that the first search result for the search query "Paypal" is trustworthy for purposes of handling your money. But maybe Alice only intended to assert that Goggle is adequate for the former purpose but not for the latter.

I’m not convinced it is as easy as all this. This strikes me as a problem that might be unavoidably hard. What seems to make it hard is that it involves humans. We’re trying to solve a people problem with an (admittedly elegant) mathematical technique. That strategy worries me, because technical "solutions" to social problems often don’t work nearly as well as one might wish. The human is embedded in the protocol, and we’re trying to prevent social engineering attacks on the human, which means that we have to anticipate all the ways that humans might be fooled into coming to the wrong conclusions—but humans behave in surprising ways, and their behavior isn’t easily formalized in a mathematical framework.

To put it another way, maybe this isn’t one of those problems with a perfect and elegant principled solution. It might be an engineering problem where no single clean solution suffices, and where workable solutions tend to look messy. I don’t have any proof of that, just a fear that it might be the case. But we shouldn’t let my fears stop us from looking hard for good solutions to this problem, so please don’t let these remarks get in the way of the continuing the discussion.—David

I believe all we’re trying to do and in fact all we can do is to enhance the safety of communication like:

"<I> (who you have some trust in) assert <this> about this other <entity>"

If by technical means we can enhance the safety of the knowledge of <I> and <entity> and the communication about any such assertion, <this>, then I believe we’ve enhanced human communication—whatever else one might say about the foibles of such communication. This seems to me a worthy cause—made somewhat more tractable in the digital realm.—Jed

How do you determine that the ’site’ is the same? Do you do a URL or DNS or IP match? It seems to me you leave yourself vulnerable to IP or DNS spoofing or even just being on another network. You also have the possibility of missing the identity of one URL you receive uses a DNS and another an IP or a DNS alias or ...

It seems to me what you want to do the identity match on is something like a key fingerprint. If you treat the address portion of the URL as really just a hint of how to reach the intended destination but demand a public key fingerprint match to determine the identity then it seems to me you have a pretty strong system.

One interesting aspect of this thinking for me is that in most of my past capability thinking I’ve focused on the concerns of assuring the server that a client is presenting a valid capability. I haven’t focused on the concern of the client that it’s communicating with the appropriate server—also a valid concern.—Jed

Let me see if I can address the issue that I think is being raised that I believe to be independent of the original issue of "Firefox breaks the principle of identifiability".

I believe as it seems Mark Miller does that the Petname mechanism solves the identifiability confusion issue. However, what others seem to be raising is the problem that still exists of establishing a trust relationship with an identity. Naturally if someone I trust tells me, "Oh yeah, you can trust ’Paypal’ and uses my "Paypal" Petname I should understand that such a recommendation is nonsense. The choice of the Petname was mine, was essentially arbitrary, and can have no meaningful relationship with the name "Paypal" that my trusted source refers to— except in so far as I establish such a relationship.

So then what can someone I trust tell me that might induce me to trust this identity I’ve established? They might tell me something about what the site can communicate. For example, they might tell me that if I visit the site and view the SSL certificate presented and I find that it’s MD5 Fingerprint is A9:04:4D:...:E2:31:9A then I can trust that it’s "Paypal" the organization that I can place some trust in. They might tell me that if I communicate with the IP address 216.113.188.32 then I can trust that it’s "Paypal" the organization that I can place some trust in, though we all know about the problems with IP spoofing. Ditto DNS and DNS spoofing. They might also tell me that if I view their certificate and I see Organization (O) Paypal, Inc., Serial Number 16:CD:58:...:4D:3D:4f Issued by Organization (O) VeriSign Trust Network then it’s "Paypal" the organization that I can place some trust in, though if they did so I would stop trusting them :-)

I believe, however, that this issue of establishing a trust relationship with an identity is independent of the original "Firefox breaks the principle of identifiability" issue that I believe is solved with the Petname mechanism.—Jed