Not at all. They can type any URL they like into the URL-location field. The
issue is then, what is displayed in the Pet Name location field? Unless I have
chosen to give something the Pet Name "www.xn--paypal-4ve.com" or
"paypal.com", there’s no URL I can type into my URL-location field that would
cause my Pet-Name-based browser (e.g., the Waterken browser) to apparently
display "paypal.com" in the Pet Name location field.
If I assign both "www.xn--paypal-4ve.com" and "paypal.com", and if my browser
uses a Unicode rendered, then I have succeeded at confusing myself. What’s a
use case where I’d do this accidentally? If such a use case is sufficiently
implausible, then haven’t Pet Names solved the problem?—Mark
|
|
|
|
|
|
|
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
|
|
|
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
|
|
|
|
|
|
Suppose the user sees "paypal.com" in the URL field while establishing a
trust relationship with the site. Users reasonably expect that if they
then type "paypal.com" back into that URL field, they will get back to
the same site.
If the URL field initially contained "p\u0430ypal.com" instead of
"paypal.com", identifiability is violated because typing in "paypal.com"
takes the user to a different site than the original site where the
trust relationship was established.
It seems to me that, for a Petname field to truly solve the IDN problem,
the URL field would have to be removed. In that case, we’d have to come
up with a new way of bootstrapping trust in websites (e.g. getting from
a URL printed on a business card to the intended website).—Ping
|
|
|
|
|
First, asking people to stop clicking on links is infeasible and
defeats the whole point of having a Web in the first place. Second, the problem is more complex. Consider these examples:
(a) Assume that i trust you and i have somehow managed to get myself
to your website with some assurance. Your web page says "I use
Paypal and i recommend it. Get your own account at paypal.com."
Instead of clicking the link, i type "paypal.com" in the bar.
But what if you meant to recommend "p\u0430ypal.com"? Because
the Cyrillic "a" and Latin "a" are indistinguishable, i have now
gone to the wrong site even though i typed in the URL as i saw it.
The point: visibly indistinguishable URLs are inevitably a
problem as long as users are allowed to type them in.
(b) Assume i trust the EFF and i have correctly arrived at their
website. I want to make a donation. The EFF webpage at
<eff.org>
provides a bunch of links for making donations with Paypal.
Here is an the URL for donating $25:
<secure.paypal.com>
That link is important because it establishes the trust
relationship between EFF and the account where Paypal will
deposit the money. Do you expect the user to type in that
entire URL?
(c) Assume that i like the E project and i want to make a donation
in e-gold. The page at
<erights.org>
provides e-gold’s donation form. But it’s not a link i can type
into the location bar; e-gold needs me to fill out the form.
Your rule of always typing in URLs can’t work here.—Ping
|
|
|
|
|
|
|
|
|