W3C home > Mailing lists > Public > public-usable-authentication@w3.org > September 2006

Re: Usability model

From: James A. Donald <jamesd@echeque.com>
Date: Tue, 12 Sep 2006 18:25:14 +1000
Message-ID: <45066EEA.9020903@echeque.com>
To: public-usable-authentication@w3.org

     --
Hallam-Baker, Phillip wrote:
 > The users correctly work out that certain areas are
 > not trustworthy. But they never get told what they can
 > trust. And because they were never told that they can
 > trust the chrome lots of people have assumed that its
 > OK to let content providers walk all over it. So we
 > have abhorences like frameless popup windows.

These days popups are is usually disabled by default.

Javascript should never have been allowed to launch
popups programattically.  Instead, it should be allowed
to cause a user interface widget to be displayed which
can enable the user to launch a popup.

 > But would you check it if you received a message
 > claiming that your paypal payment for the wire wheels
 > you sold last night had been blocked? This happened to
 > the guy who I paid $560 to last week. Fortunately he
 > is sending me the wheels. But a key problem in the
 > communication here was the fact that I just don't have
 > any way of telling him 'this is what a completely
 > trustworthy message looks like'.
 >
 > I also agree that if we really want to get a handle
 > here on the specific problem of credential theft then
 > we need to have a trustworthy path for entering the
 > credentials. Probably something like CardSpace. But
 > phishing is only one of the frauds that impersonation
 > makes possible and we have to make sure we solve both
 > problems.

We need both belt and braces.

We know the cryptographic protocols needed to make
things work, and these protocols have been implemented,
but are not connected to the user interface, not
connected to the user, in ways that are useful.  When we
discuss protocols, we talk of Alice and Bob as if Alice
was personally encrypting stuff.  In future, we need to
discuss the communication between Alice, Alice's agent,
Bob's agent, and Bob.

To illustrate the problem, let us suppose that tomorrow
everyone in the world gets a verisign certificate
attesting to their unique identity, credit rating, and
so forth, and this certificate is installed on their
computer - but oops, people move between computers.  OK,
assume everyone in the world gets a portable, perhaps a
cell phone, that they never lose.

Shortly thereafter banks and merchants start relying on
this client side  certificate.  Very shortly thereafter,
you find lots of ads for sites offering various free
goodies - porn, useful information, coupons, whatever.
And when your browser goes to one of those sites, an
invisible frame window then proceeds to make a
transaction with your bank.

Of course this problem with client certificates results
from the the silent and automatic login that client
certificates do, and that most single signon systems do.
Silent and automatic login is a violation of Kim
Cameron's laws of identity.  So if our system complies
to Kim Cameron's rules, all will be well, right?  Well,
actually no.  It is far from clear than existing
browsers can comply with the rules of identity, because
of poor sandboxing.  Even plain html without javascript
has capabilities it definitely should not have, and we
cannot deprecate those capabilities, for no one is even
thinking about providing alternative methods for
accomplishing the things that these dangerously powerful
capabilities accomplish.  We have extremely serious
architectural problems, for example frames, get, post,
img and XMLHTTPRequest, all of which violate sandboxing,
and no one seems to be even trying to visualize a path
out of these problems, except for the occasional
deranged sounding voice in the wilderness, such as
myself.

     --digsig
          James A. Donald
      6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
      B5LTdW+7ciCrIPBmC5Vfg6gBpwEhW+7RYoo0pkn2
      4lqynB/LG9dCrLAsiY/7M2Nm7PPasn1fwB/CnPsja
Received on Tuesday, 12 September 2006 08:25:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:14 GMT