[cap-talk] A petname toolbar for Firefox

[Ka-Ping Yee]

On Wed, 23 Feb 2005, Tyler Close wrote:
> We have a fundamental disagreement over what a petname is.
>
> A petname is a mnemonic for a trust relationship. A petname is *not* a
> mnemonic for an entity. There is no need for you to name the entity. It
> already has a name, a nickname.

The nickname is not controlled by me.  That lack of control makes me
vulnerable to attack.  The purpose of the petname is to give me a label
that i control.

We do have a disagreement, though i would characterize it differently.
It seems you are saying that petnames could be used either to represent
entities or to represent trust relationships, and that i see one purpose
while you see the other.  But i don't see it as an exclusive, one-or-the-
other choice.  The petname is a label i use to describe the other entity;
it could be the name i use, or a word or phrase describing how i trust it,
or both, or something else entirely.  All that matters is that it triggers
the appropriate association in my memory so i can guide my decisions.

It's impossible to forbid users from typing a "mnemonic for an entity"
into the petname field, and even if you could somehow convince them not
to, it wouldn't matter.  The two kinds of labels are isomorphic:

    (a) Alice assigns her own label to Bob.

    (b) Alice assigns a label to the arrow from Alice to Bob.

The reason i pointed out a distinction between "unnamed" and "untrusted"
was to call into question the assumption that the presence of a petname
always implies *positive* trust.  If it makes my intent clearer, i wanted
to replace "untrusted" with "unknown or unspecified level of trust".  To
me, "unknown level of trust" and "unnamed" are functionally equivalent.
But "unknown level of trust" is *not* equivalent to "untrustworthy".

> There is a need for you to name the
> trust relationship, since it enables communication between the user and
> the browser about the trust relationship. That's our purpose here.

Petnames form a namespace that the user and browser share when they
communicate, but the petname is *not* a message to the browser about the
trust relationship.  "Communication between the user and the browser about
the trust relationship" suggests that the browser makes security decisions
according to the meaning of the petname itself, which is not what i have
in mind at all.  I see the primary purpose of the petname as being a
tool for augmenting the user's fallible and limited memory.  In the end
the user is still the one making decisions about how to interact with a
givern website.

> When the user is deciding how to evaluate information or actions
> presented by a web page, only the trust relationship is relevant.

I agree.

> In fact, the user should actively ignore the site's identity.

The user should ignore the site's self-assigned identity, but it is
fine (and a good idea) for the user to refer to the site's identity
as assigned by the user.

> The situation is analogous to the way a capability OS implements access
> control. When deciding whether or not to grant a request, a capability
> OS does not consider the identity of the requestor, only whether or not
> the requestor possesses the required capabilities.

Yes, i agree there.  But keep in mind that again you are referring to
ignoring *global* identities, not local namespaces.

> The goal of the petname toolbar is to get the user to start thinking
> about his trust relationships and making effective use of them. To this
> end, we want the user to tell the browser about his trust
> relationships, so that the browser can remind the user about them as
> appropriate.

I agree that it is a good idea for users to think about their trust
relationships, but i don't think that's the main problem we face.
Users already think about their trust relationships; the error they
make when they are phished is not that they ignore trust relationships
but that they choose the wrong one.  (If users didn't think about their
trust relationships at all, then phishers wouldn't have to imitate bank
websites.)

> For these reminders to be most effective, untrusted sites
> must not have an associated petname. The absence of a petname makes it
> clear that there is no trust between the user and the website.

Here we run into a difficulty: users are not computers.  Computers
do not randomly forget things and can respond to the same stimulus in
the same way over and over again.  If humans had these qualities i
would agree with you wholeheartedly.  Unfortunately, humans have
unreliable memories, limited attention spans, and develop tolerance
to repeated stimuli.  Therefore, the goal must be to make significant
events in the user interface reflect significantly unusual situations.

The high-risk situation we are trying to address is the case of
arriving at an unknown website that tries to trick the user into
choosing the wrong trust relationship.  If our defenses are to be
effective, this high-risk situation must be readily distinguishable
from ordinary browsing.  The absence of petnames from most sites
makes the absence of a petname in a risky encounter perceptually
insignificant.

Along the same lines, there is another problem with your current
petname toolbar design: it is only useful on SSL sites.  I have
received 12 phishing attempts in my mailbox so far this February;
how many do you suppose the petname toolbar would affect?  Zero.
All 12 entice the user to click on an http:// link with a numeric
IP address.  Similarly, of the 15 phishing attacks listed at
http://antiphishing.org/, only one uses an SSL link.  Based on
that evidence, a browser that outlawed form submission on numeric
IP address URLs would have a much greater success rate at defeating
phishing than the petname toolbar.

Of course i'm not suggesting that outlawing numeric IP addresses
is the way to solve phishing.  I'm just trying to illustrate the
large gap between theory and practice.  I'm sure you (and most of
the others on this list) would recommend that users should only
send passwords and bank information over SSL connections anyway --
and i'd agree!  But just saying that doesn't solve our problem,
because the phishers are using extremely simple methods that don't
even involve SSL, and they are working.  So we have a lot to do
before an SSL-only petname bar would become effective.

> I suspect the problem is that you have misunderstood Zooko's Triangle.

I would be interested in knowing whether Zooko would agree that his
"human-memorizable names" or petnames could be considered names for
entities.  I believe most readers of Zooko's article or of MarkM's
Petnames article would consider these names to refer to entities.

But that is beside the point.  I am quite aware that the various types
of names described in these articles are different -- each mapping
has a different domain and range -- and that conflating them in a
centralized PKI causes serious problems.  I don't think that is the
source of our disagreement.

> > You're right -- an older version of the warning message did look like
> > that, in an article i was writing at the time.  I ended up thinking
> > about a variety of possible ways to word the message.  On the whole
> > i believe we both agree that the message should not be a command (e.g.
> > "You should assign a petname now.") but a statement of fact (e.g. "This
> > site is a stranger.")
>
> Your original admonition text was not flawed because of a GUI principle
> of proactive versus reactive interfaces. It was flawed because it
> suffered from name conflation in exactly the same way as the URL
> address bar does and therefore aids phishing just as the address bar
> does. Your original admonition was: "The current site is not one that
> you have named. The name chosen by its owner is PAYPAI.COM." Why should
> displaying the domain name in an admonition be significantly less
> confusing than displaying it in the address bar?

Displaying the domain name separately from the URL in a clear,
unambiguous typeface is significantly less confusing than showing it
embedded into the URL in tiny Arial letters.  Omitting the domain name
from the admonition, as you suggest, would be less confusing still --
but only as long as the warning does not appear all the time.  I wrote
the article before i came up with the idea of assigning petnames based
on typed-in URLs, and at that point the user needed some information to
distinguish between potentially malicious sites and sites the user had
merely forgotten to name.  But if we can keep the frequency of missing
names adequately low, the admonition will not need to include any
distinguishing information, which is an improvement.


-- ?!ng