[cap-talk] A petname toolbar for Firefox

[Jed at Webstart]

At 04:10 PM 2/21/2005, Tyler Close wrote:
>...
>Yes, I haven't been able to figure out how to get a "Petname" title to 
>appear in the toolbar palette. Documentation of this feature of XUL is 
>extremely sparse.

It would be helpful, especially in the long run.  However, at this time 
it's probably not essential.

>>...  Now having gotten some experience with this Petname toolbar, here is 
>>the thought that most strikes me:
>>
>>To get effective protection from such a mechanism I believe it important 
>>that there be some mechanism to warn a user if they enter data into a 
>>site that is "untrusted".  Of course I understand that there are trust 
>>issues even to reading data.  Perhaps one should have the option of being 
>>warned about even viewing data from untrusted sites, but I definitely 
>>think there should be an option (which I believe should be the default) 
>>for getting warned about submitting data to an untrusted site.
>
>So, there is a warning. The petname toolbar does show "untrusted", 
>indicating that you are submitting data to an untrusted website. It's just 
>not very pushy about it. ;)
>
>Ping has also suggested this more intrusive form of warning. I am still 
>unsure about it. At first, it seems like a good set of training wheels to 
>encourage use of the petname toolbar. Further thought makes the idea seem 
>more dubious.
>
>The user should *not* make a petname for every site he interacts with, 
>only for the sites for which he extends some trust. A dialog which forces 
>the user to create a petname for an untrusted site creates a 
>misunderstanding of the purpose of the petname toolbar and builds bad user 
>habits. It also has the side-effect of making the petname toolbar seem 
>like an annoying bit of homework that constantly pesters the user.
>
>In "The Humane Interface", Jef Raskin argues that these types of messages 
>from the computer to the user not interrupt the user's workflow. The user 
>may know very well that he's using an untrusted site, so having the 
>computer interrupt the workflow is an unwanted and unneeded distraction. I 
>think this argument is applicable in this case. I think it's better for 
>the petname toolbar to always have the data displayed and ready to be 
>used, but not interrupt the workflow.

I believe I understand your reasoning, but I respectfully 
disagree.  Firstly I believe the "side-effect of making the Petname toolbar 
seem like an annoying bit of homework that constantly pesters the user." is 
a considerable exaggeration.  How often do you enter information through a 
*new* SSL protected Web site?  For me doing so is a rather rare 
phenomenon.  Certainly not something that I would consider being "pester"ed 
about with a popup.  Remember, I'm only suggesting the warning when 
entering data and to a new site.  I seem to recall that there is some sort 
of popup anyway that happens when entering data through a form for the 
first time - though perhaps this is global and not specific to SSL sites 
without chosen Petnames.  If one chooses to accept the "untrusted" 
designation, then that could be it, though it might be nice to have it a 
bit more visible (e.g. bold?) to distinguish "untrusted" from being just 
another valid Petname.

On that note - is "untrusted" just another valid Petname?  It seems to me 
that perhaps this current implementation is a bit "thin".  Of course others 
(e.g. you Tyler?) might consider it appropriately sparse.  For example, 
what about the issue of name collision.  I noticed that I can assign the 
Petname "IBM" for https://www.ibm.com/ and then it will happily (without 
notice) let me assign that same Petname "IBM" to 
https://www.wellsfargo.com/.  Don't you think it would be helpful to at 
least point out the name collision?

Also, I don't know about others, but I would value the ability to view my 
Petname binding "database".  Is there a way to do that?

>>On the implementation side I want to know how the binding between the 
>>Petname and the site actually works.  If the sites certificate is changed 
>>will it become untrusted?
>
>No. The relevant details are quoted below. Just to recap, the browser 
>stores a binding of: ( domain name, CA public key) to petname.

Got it.  With all the discussion about expirations, etc. the above sounds 
reasonable to me.

Regarding:

At 09:05 AM 2/22/2005, Ian G wrote:
>Sandro Magi wrote:
>>
>>Firstly, I believe the statement went:
>>
>>"A petname toolbar records and displays a *trust relationship* between a
>>user and a web site."
>
>The middle ground then appears to be that:
>
>    "A petname toolbar records and displays a *relationship*
>     between a user and a web site."
>
>So one singular link and one singular relationship is displayed, ...

That sounds reasonable to me.  I agree that words are important.  We aren't 
talking
about The relationship between a user and a web site, but rather a 
relationship,
namely the binding of the Petname.

I hope this answers the objection in:

At 03:52 PM 2/21/2005, szabo at szabo.best.vwh.net wrote:

>A certain version of a proposed "point of consensus" read:
> > A petname toolbar records and displays the relationships between a user
> > and a web site.
>
>How can such a statement avoid dissent?  Almost none of any relationship --
>neither the thoughts, feelings...

However, with regard to:

>BTW, why does anybody expect "consenus" on such subjective statements?

Perhaps 'expect' is too strong a term.  Certainly I'm hopeful of some consensus
on this topic.  Perhaps not unanimous, but if not then with some thoughts on
the issues of disagreement.

> > This indication enables user detection of phishing
> > attacks.
>
>Unless this means a trivially broad definition of "enables" -- such as if the
>user works very, very, hard to build up their petname database, then the
>risk of phishing may be decreased -- beyond such a trivial meaning there
>is no empirical evidence for this claim and not much other reason to believe
>it.

I don't believe there need be anything very, very, hard nor even very hard,
nor even indeed hard about developing a Petname database - e.g. from my
early experience with the mechanism Tyler put together.  In general
sites are "unknown".  I think perhaps it would be useful to make a distinction
between "unknown" and "untrusted".  To me "untrusted" sounds like an
active designation.  That is, I know this site, I know it's binding, and I've
decided that its "untrusted".

It's the transition from what I would call "unknown" to having a Petname
that's the one that creates the name binding that avoids phishing and
can facilitate trust.  This is the simple act of typing in the Petname for
a site that the user has some reason to trust.  I don't see anything
hard about that.  Are you saying that it is hard to develop the trust
relationship?  That may be true, but to me that's orthogonal to the
issue of the name binding and avoiding phishing.

>Indeed, in another post Ka-Ping pointed out yet another good reason to
>believe that petnames, without a way to securely populate them across trust
>boundaries, would fail:
>
> > If petnames are only assigned by requiring the user to do extra work,
> > the path of least resistance is not to assign names for most sites.

I just want to make sure we are focusing on sites that require some
sort of trust relationship - esp. with SSL.  That already reduces the
number of sites significantly.  Then I believe there is another reduction
in the number of sites when one considers those sites where one
enters information (e.g. personal identification information, etc.).
While I accept that some trust may be important even for 'just'
reading information from some sites (e.g. even without any sort
of user binding), I believe that the number of sites that are likely to
require the sort of name binding and trust development that Petnames
facilitate are not so numerous that assigning Petnames for such
sites will be a onerous task.

Still, not assigning names for any sites is fine also.  In that case
one is simply not making use of Petnames, is subject to phishing,
and should have little faith in the name binding to the site.

> > That leads to the problem i described earlier:
> >
> > | In short, the problem is that when the user sees "unknown" in the
> > | petname toolbar, he must make a distinction between (a) this is a
> > | potentially dangerous site with which i have no trust relationship;
> > | and (b) this is the site i want, except i haven't set up a pet name
> > | yet.  The user has to make a judgement about whether or not he forgot
> > | something, which by definition is hard to do since if you forgot
> > | something you wouldn't remember it.  I think that in order for the
> > | petname toolbar to be truly effective, the frequency of situation (b)
> > | must be minimized.

I agree that the distinction between "unknown" and "untrusted" is
a relevant one.  I believe the Petname mechanism should be enhanced
to support it - though I suppose one could argue that simply making the
default "unknown" would suffice.  If that distinction is available then a
person can explicitly assign the "untrusted" designation to a site.  I believe
that would avoid the potential ambiguity above.  It wouldn't help the situation
where people choose not to assign Petnames.  That is of course a choice
that one has.  Might as well remove the Petname toolbar in that case and
either accept phishing or use some other mechanism to deal with it.  I haven't
seen a competitor proposed.

> > Do you have other ideas for how to address this problem?
>
>Indeed I do: treat names crossing trust boundaries as property, and
>securely agree across trust boundaries on who owns what names, as
>described in
>
>"Secure Property Titles with Owner Authority",
>http://szabo.best.vwh.net/securetitle.html
>
>This provides a public, inter-trust-boundary namespace far more accurate
>and reliable than a "hint" or "introduction", by which one can populate
>the petnames database.

I believe from reading the above that your property notion is addressing
itself to a much broader topic than dealing with phishing as the Petname
mechanism does.  Even with such a property notion the possibility of
phishing still exists and, to me at least, the Petname mechanism seems
a valuable/viable way to defend against it.

--Jed http://www.webstart.com/jed/