[cap-talk] Firefox and identifiability, small steps or large

[Ian G]

David Hopwood wrote:

> Ian G wrote:

>>
>> A clarification: logos, not icons.
>>
>> I gather that CapDesk (? I can't recall the
>> name) has experimented with icons.  I
>> agree that icons wouldn't add much over
>> words or phrases.
>>
>> By logos, I mean a graphical image selected
>> by the user among a list of graphics.  In
>> principle, it could be any logo found on the
>> site, or it could be a picture dragged from
>> the user's photobook.
>
>
> That was what I meant by icon. I don't see what the technical 
> difference is.


When I think icon, I think a limited set of
pictures sitting at the top of my browser,
doing a fixed job.  Left button looks much
like left button on every browser, and (I
presume) bank icon looks like much bank
icon on every browser.  So, technically, to
me, an icon is from a limited set made
available from a purpose made collection
within the application.  By way of example,
the application doesn't normally offer a
feature to turn the Send button into a
picture of a fluffy dog (although I suppose
'skins' are the counter example).

Now, if that image - which I grant hasn't
much founding - isn't the one you are thinking,
by all means let me know.  (I'm not a GUI
programmer, so I might be using poor
terminology.)

By logo, I think something that is individualised
by the service owner.  As a particular extension
to that, TrustBar allows the user to select *any*
logo for a service provider, thus changing the
meaning to that more akin to the pet names
one.

Having said all that, let me re-address these
points you raised:

>>> The disadvantages of icons are:
>>>
>>>  - It isn't practical for the user to create an icon. Therefore it has
>>>    to be provided in the introduction, which increases the 
>>> possibilities
>>>    for confusion and social engineering. With textual names, the user
>>>    can always choose a name that is meaningful to them.
>>

It is practical for the user to select an icon from
any range of availables.  Certainly that includes
something that an attacker presents, and this
does put the emphasis on the Introduction.

I think you may be correct in suggesting that the
logo carries a cost in Introduction that the name
may not carry.  Well, maybe.  If the attacker can
suggest a logo in Introduction, then presumably
he can suggest a name as well, although that
becomes less effective if we have trained the user
to always enter in some phrase.

Against names is the fact that they are more
mental effort and less aligned to how the brain
works.  That was the subject of other posts, and
is somewhat predicted by the unfortunate history
of the padlock.


>>>  - An icon can't be typed. It can only be selected from a list, or
>>>    referred to indirectly via a textual name. This makes icons less
>>>    expressive in the sense that you can't use them in many situations
>>>    where you could use a name, for example in a command line interface.
>>>
>>> I would be unsatisfied (both as a user and as a system designer) with
>>> any system that allowed only icons to be used, i.e. did not always
>>> permit a textual pet name to be used in place of an icon. 
>>

Right, I think I expressed elsewhere that I think
it would be good to have both features available.
The both have merits + demerits, and working
together they could cover more situations.

(In fact, whether it uses logos or pet names or
any of the other ideas is really a side issue in
the process.)

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/