[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Outstanding critical issue for KDE 2.2
From:       George Staikos <staikos () kde ! org>
Date:       2001-08-02 3:00:36
[Download RAW message or body]

On Wednesday 01 August 2001 22:39, Andreas Pour wrote:

> >    To clarify this, I don't mean we are liably in a contractual sense and
> > it looks like I wrote.  I mean that we are STUPID for knowingly shipping
> > functionally broken code and that users should never have used such
> > broken code to begin with.  The user expects that the lock icon does
> > exactly what I outlined, and if it doesn't, then our code has a bug.
>
> I'm sorry, where did you do your user survey to conclude this?  I for
 
    Look through the bugs database.  Look through my received mail folder.

> one never thought that.  It was patently obvious to me that since I have
> auto-completion in the SSL forms that the data was being stored
> somewhere.

   You are an educated user.  99% of them are not (they use certain other 
software afterall...).

> I think rather than have this arbitrary distinction between HTTPS and
> HTTP (where in one case nothing is saved and in the other everything is
> saved, and there is nothing the user can do about it, no matter how
> trivial the HTTPS data and how personal the HTTP data) it would make
> more sense to have finer user-control.  So add to the right-mouse-click
> of a text form element the option "Do not save this data for
> auto-completion" (or if auto-completion is disabled by default "Save
> this data for auto-completion"), then the user can decide if some data
> is too personal to store on his computer.  Another alternative:  on SSL
> pages, next to the lock, put a little disk icon, which toggles, with a
> helpful tooltip, and this icon state determines if the form data is
> saved or not (and b/c HTTP forms can also contain personal information,
> do the same for non-SSL pages).

     The first suggestion is much too tedious, but the second suggestions 
seems ok too.  As long as it defaults to not storing these things on disk.  
Users don't need to find out the "hard way".

> I just know users will hate this "protection".  They won't understand
> why data they type in one page is saved and another page it is not.
> When you explain it to them, you will socially engineer them to prefer
> HTTP over HTTPS, b/c you have made one "better" (in terms of
> convenience) than the other.  Personally I would prefer social
> engineering in the other direction.

     You can't place an order at amazon.com without using SSL.

> I think the only thing we "morally" are responsible for is to give the
> user intelligent defaults, but let the user make his or her own
> decision.  We are not "morally" responsible that people will trade off
> risks for convenience; that is life.

    Of course.  I'm not saying to make it impossible to do so.  I am saying 
that it must at least default to off and optionally be configurable.

> > The code is of course
> > provided without warranty (as says the licence we ship with).  However, I
> > don't want it on my conscience that this has caused anyone any problems. 
> > I also don't want my name and reputation associated with it.  Finally, I
> > don't want the bug reports for this being emailed to me. (as I've had
> > happen so many times already for related things -- How many of you have
> > had a CERT advisory against your code?  Tell me after if you would
> > consider such a scenario so lightly.)
>
> I haven't seen any CERT on IE's data-caching, though I have read some
> news reports.  Users like it anyway.  I think we can one-up this with
> the "let the user decide" approach.

   There have been against konqueror though.  Guess who had to deal with it.

   I'm not against a user option, but it must default to off upon 
installation.  I just want something done.  I'm not asking anyone else to do 
my work for me, but I am saying that it needs to be fixed.

-- 

George Staikos

[prev in list] [next in list] [prev in thread] [next in thread]