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

So the fact that the WWW does not currently support safe hyperlinking doesn’t bother you? Your bank has a web site, but on the current WWW, it is not safe to follow a hyperlink to that web site. In my opinion, this is deeply broken. That petnames fix this problem is very important and exciting. Are you sure you disagree? Is the web part of the World Wide Web really not important to you?

I want to continue to delay the introduction discussion until we nail down the phishing part of the discussion, but I will get to it if you want to.—Tyler

We have agreed that they fix the problem of confusable URLs, not the problem of trustable URLs. —Ben

The fact that a site I don’t trust points to another site I don’t trust doesn’t particularly disturb me. Also, I have mechanisms that appear adequate to allow me to form trust relationships on the web as it exists today. A web consisting only of sites I trusted would be a very boring place. You appear to want me to read something into the word "web" other than "a pile of links to stuff, some of which I find useful". I don’t particularly see the value of redefining the word.—Ben

I’m ready to hear it. Perhaps you could just point me to some stuff on your YURLs. As you can see I was led in another sub thread to trying to bind a Petname to a certificate fingerprint. I’ll be interested to see if there is something comparable in your proposal, though you seem to object to cryptographic means. If you refer me to:

<waterken.com>

I don’t believe I see anything comparable there. It states the requirements but not how to meet them technically. When you say (in the above URL): __________
 Site authentication

A YURL MUST provide all the information required to authenticate the target site. Authentication of the target site MUST ONLY rely on information contained in the YURL. If any outside information were used for authentication, the creator of that information would have power to determine the target of sent messages, violating the y-property. In particular, any URL scheme that depends on the PKI for authentication, such as https, is not a YURL. __________

If my "YURL" was something like:

<paypal.com>

it would seem to be going directly against the idea of your YURL. Tell me why the above is inadequate. Tell me what you propose as an alternative.—Jed

For now, I am just going to give you some links. I really want to try the discussion in steps this time. We’ve had this discussion on cap-talk before (maybe before you arrived) and not made much progress. I suspect it’s because everyone just piles all naming related problems onto the discussion all at once, and then we circle around it endlessly. Petnames + YURLS + keyword servers do provide a complete solution, but I guess it’s just too much to communicate all at once. Petnames all on their own provide important and tangible benefits, and establishing that fact might make communicating the rest of the system easier.

The YURL Definition paper you’ve already seen is a requirements specification. The httpsy protocol is an implementation of these requirements. See:

<waterken.com>

This specification explains the crypto and networking part of the solution.

An example introduction scenario is examined in the paper at:

<waterken.com>

The home page for all these papers is at:

<waterken.com>

There are many papers under that root that explore different parts of the naming problem. Taken together, they might give you a more complete picture of what we have in mind. For now, I want to continue to focus the discussion on the phishing aspect. If we reach consensus on just that part, we will have made important progress, and done much better than we have on previous tries.—Tyler