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

Firstly, as above, the browser needs to index from the cert, and currently does not. (I’m not sure what amount of work is required for this, but I’d anticipate some work there.)

Secondly, petnames may "solve" the problem in theory, but are not as well as logos. The ergonomics of graphical presentations work much better than just words. Intiutivelly, just looking at the research done on the graphical presentations indicates that, and there’s been no research done on the effect of the petnames to my knowledge.

The main issue here is that petnames are just one idea that could assist. What will be required is experimentation along different lines, trying petnames along side other methods.—Ian

What cert? If we’re talking about a Verisign-like cert, then we’ve already lost. In any case, YURLs + Pet Names need no certs.—Mark

I don’t know that there is any general technical solution to the problem of confusing names and assuming the trust one has for one of the names applies to the other. (I think about my aging in laws, who get confused rather easily.)

One technical "fix" that might be useful would be for the browse to keep a list of all sites previously visited with https. Anytime a similar, but different site is visited, issue a warning about the similarity.

The details of how similar is determined need to be developed heuristicly, so the code and tables involved need to be easily replaced as a separate upgrade from that of the browser. I would start by treating all characters that can be confused (e.g. 0O 1l $S) as the same character. (It would greatly help to have native readers for each language group in the Unicode standard help with this process.) Also flag sites which differ only by one or two characters (perhaps 10% or 20% of the characters?). Note that www.paypal.com vs. www.paypa1.com would match twice under this algorithm.

When the user has visited sites that match under the similarity algorithm, use a pet name or a logo/icon scheme to clearly separate them during later visits.

Cheers—Bill—Bill

I have no problem with Pet Logos, so long as they follow the Pet Name logic. (CapDesk uses Pet Icons in such a fashion in addition to Pet Names.) In any case, could you explain a scenario where Pet Names are insufficient?—Mark

Yes, if the user ignores words. Or, are you saying that using logos is a subset of petnames, in your lexicon? —Ian

If the user ignores words, then they can’t be misled by them. What threat model are we addressing? —Mark

<thinks> that a URL is introduced into the browser that shows a facsimile or mockup of a trusted site.

The thing is that words are "low bit rate" whereas logos can be "rich" which provides a more efficient processing scenario for the brain. A picture is worth a thousand words, and all that. As the notion of who the site is has more to do with the eventual presentation, and some cunning trick pulled by the phisher, a concentration on names and conflation is probably only a subset of the security space.—Ian

A logo is only a Pet Logo if the choice of which logo to display follows Pet Name logic. In that case, fine. I’ve only skimmed <cs.biu.ac.il> , but, as far as I could tell, they don’t use Pet Name logic to determine what logo to display. If indeed they don’t, then these wouldn’t be Pet Logos, and I fail to see how this system would then solve the problem.—Mark
 
 

I think there’s been equally little research on Pet Logos. But if you mean the logo logic explained at <cs.biu.ac.il> , then I fail to see how it solves the problem.—Mark

And pet icons should be introduced into the mix as well. In CapDesk, users pick both a pet name and a pet icon for an application. The pet icons exploit the value of graphical presentations too.—marcs