[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:       Andreas Pour <pour () mieterra ! com>
Date:       2001-08-02 2:39:15
[Download RAW message or body]

George Staikos wrote:
> 
> On Wednesday 01 August 2001 21:28, George Staikos wrote:
> > On Wednesday 01 August 2001 21:24, Neil Stevens wrote:
> > > On Wednesday August 01, 2001 06:09, George Staikos wrote:
> > > >    We have a contract to the user that his data is entirely encrypted
> > > > except for in RAM when that lock icon appears.  If it is not being
> > > > encrypted, we are liable.  It is 100% our fault in that case.
> > >
> > > Is that documented?  I've never seen that mentioned before.
> >
> >    If it isn't, it is now.  That's the presumption that I've always worked
> > on when developing the SSL features of Konqueror.
> 
>    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
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.

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).

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.

Life is always a trade-off between risk and convenience.  For example,
in the US I have a good chance of being killed or injured in a car
accident.  I could make this risk almost 0 by not traveling in cars. 
But it is quite convenient to do so, so I take a risk.

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.

> 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.
 
>     This is a security hole.  I have already had some values written to my
> disk that should not be there under any circumstance.  Netscape doesn't write
> it there.  KDE shouldn't either.

Netscape doesn't have auto-completion, which is one of the things that
really sucks about it.

Ciao,

Dre

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