W3C home > Mailing lists > Public > public-wsc-wg@w3.org > January 2007

RE: Safe surfing

From: <michael.mccormick@wellsfargo.com>
Date: Mon, 8 Jan 2007 15:11:38 -0600
Message-ID: <8A794A6D6932D146B2949441ECFC9D6802B4D214@msgswbmnmsp17.wellsfargo.com>
To: <dan.schutzer@fstc.org>, <public-wsc-wg@w3.org>
I agree but I think "mode" implies a simplistic binary 2-state machine.
There are N degrees of web security, and I'm pretty sure N>2.
 
Furthermore I think the degree of security ought to be jointly
negotiated between the user and the site, since they both have a stake
in the outcome.  For example, I access a bank web site that expects a
minimum level of 3, but I decide that's not good enough and tell my
browser to always go to level 4 at that site.  Later I might access a
blog that demands minimum level 2 but I feel 1 is good enough.  Simple
configurable rules would govern the outcome of these negotiations, such
as "Highest level wins" or "User is always right".  Prompting the user
would be a one time event that occurs the first time I visit a site;
after that the browser would remember my preference for that domain.

Michael McCormick, CISSP 
Lead Architect, Information Security 

This message may contain confidential and/or privileged information.  If
you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein.  If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message.  Thank you for your cooperation.

 

  _____  

From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org]
On Behalf Of Dan Schutzer
Sent: Monday, January 08, 2007 8:48 AM
To: public-wsc-wg@w3.org; beltzner@mozilla.com
Cc: 'Dan Schutzer'
Subject: Safe surfing



I wouldn't completely push off the idea of a safe mode, where one can be
assured that only certain (user selected websites) can come through and
not others. There are certain tasks that a security conscious user which
wish to only do in a safe mode. The idea of a ritual where, such as
Control.Alt.Delete, which a user can simple invoke to ensure increased
safety is not necessarily a bad or dangerous thing if done right and can
make some of the things we wish to do in terms of greater security and
user comfort more practically achieved without crippling all the
functionality that users have grown accustomed to. I think it is an idea
worth pursuing and discussing and not so quickly dismissing.

 

Dan

 

  _____  

From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org]
On Behalf Of Mary Ellen Zurko
Sent: Monday, January 08, 2007 9:02 AM
To: beltzner@mozilla.com
Cc: public-wsc-wg@w3.org
Subject: Re: Safe surfing

 


I agree; it cannot work if the user must put themselves into the mode
during potentially dangerous tasks. I can imagine it working if it is
triggered by, say, a total lack of security context information, or is
the default in general (for a subset of the population). 

          Mez

Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
Lotus/WPLC Security Strategy and Patent Innovation Architect




"Mike Beltzner" <beltzner@mozilla.com> 
Sent by: public-wsc-wg-request@w3.org

01/08/2007 08:51 AM

To

"Mary Ellen Zurko" <Mary_Ellen_Zurko@notesdev.ibm.com>, wdoyle@mitre.org

cc

public-wsc-wg@w3.org

Subject

Re: Safe surfing

 

 

 




It depends what it means, of course, but my forecast on this is
freezing-to-cold with high chance of skepticism. 

Modality, as a rule, is to be avoided, and I twitch at the idea of a
mode that the user must manually enter to be safe - especially since
evidence shows us that phishing works by getting a user to think about
the end-goal ("update my banking info so my account isn't cancelled OMG
OMG!") and thus the idea of "I must first be safe to do this" is often
discarded. Modality a la CardSpace, where the mode is automatically
initiated and becomes part of accomplishing the task is something that
warms me on the idea, somewhat.

cheers,
mike 
-----Original Message-----
From: "Mary Ellen Zurko" <Mary_Ellen_Zurko@notesdev.ibm.com>
Date: Mon, 8 Jan 2007 08:46:12 
To:wdoyle@mitre.org
Cc:public-wsc-wg@w3.org
Subject: Safe surfing

I blow hot and cold on the notion of a safe browsing mode being useful.
This morning, I'm warm-to-hot. There would be a lot of issues; how would
it be enterred and exited, what would it allow, what would be determined
safe and unsafe (or more levels), and how would sites transition between
those levels. It could go a bit like IE's security levels. It could
provide a structure for safe staging principles applied to things like
SSL (no need to prompt before the user is ready; take them to an
unsafe/protected mode). It could borrow much from the training wheels
reaserach in CHI. It could act a bit like sandboxing (but of course,
that begins to push the boundaries of the charter in terms of only
targetting display of security context information). An overall safe
mode probably would be desirable for a non trivial percentage of the web
using population; my mom, Ches' dad: 

http://cups.cs.cmu.edu/soups/2005/program.html#ches

Where are other members of the wg on the notion of a safe mode in web
browsing? If you're active on the wg, please ring in on this question,
even if you have not yet formed an opinion. Thanks. 

          Mez

Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
Lotus/WPLC Security Strategy and Patent Innovation Architect




"Doyle, Bill" <wdoyle@mitre.org> 
Sent by: public-wsc-wg-request@w3.org
12/28/2006 11:25 AM

To<public-wsc-wg@w3.org>

cc

SubjectRE: Browser security warning







The point about self signed certs that I was thinking about is that
self-signed mechanisms do not have a "trusted" 3rd party involved. I
feel that this places the burden of "trust" on the user, the user needs
to verify that trust should continue to be extended and the user should
be aware of this. Is this site still the same site that I trusted when
I allowed it? Lacking a 3rd party to decline the connection the
connection is made.

I don't expect that users are going to remember to re-certify sites
because I won't. I don't remember what sites I have configured to use
self-signed certs unless I own it. For me, a browser with "grandma
mode" that blocks sites with self-signed certs could be useful...

Bill D.
wdoyle@mitre.org


-----Original Message-----
From: public-wsc-wg-request@w3.org
[mailto:public-wsc-wg-request@w3.org] On Behalf Of
michael.mccormick@wellsfargo.com
Sent: Thursday, December 28, 2006 1:11 AM
To: public-wsc-wg@w3.org
Subject: RE: Browser security warning


Just a nit, but there's a subtle yet important distinction between a
self-signed cert versus a cert issued by a self-signed root authority.
My example was of the latter type.  There are legitimate reasons to
create one's own self-signed RCA, and there's no reason why it would
necessarily be incapable of publishing a CRL and/or supporting OCSP.
Mike

-----Original Message-----
From: public-wsc-wg-request@w3.org
[mailto:public-wsc-wg-request@w3.org]
On Behalf Of Doyle, Bill
Sent: Wednesday, December 27, 2006 1:53 PM
To: public-wsc-wg@w3.org
Subject: RE: Browser security warning

I feel that a self signed cert is a trust between the user and the
site.
The self signed cert may not be able to make use of programmatic
mechanisms that support trust of a CA issued cert like CRLs. Continued
trust of a site that uses a self-signed cert places the burden of trust
on the user.

Turning off security indicators (padlock - url color) is one way to
remind the user to keep tabs on the site and to verify that trust
should
continue to be extended.

It may also generate more calls to the sites help desk and maybe the
site will buy a CA cert because it is less of a hassle than continued
use of a self signed cert. If this happens this raises the level of
security for all involved.

I agree that self-signed certs should be viable, but because they may
not be supported by programmatic mechanisms to revoke the cert they are
not in the same category as a CA generated cert.

Bill D.
wdoyle@mitre.org




-----Original Message-----
From: public-wsc-wg-request@w3.org
[mailto:public-wsc-wg-request@w3.org] On Behalf Of Stephen Farrell
Sent: Wednesday, December 27, 2006 12:21 PM
To: Stuart E. Schechter
Cc: public-wsc-wg@w3.org
Subject: Re: Browser security warning




Stuart E. Schechter wrote:

>    I don't think there is a large set of sites that can't afford a CA
cert
> (category 2) and actually require the security offered by HTTPS.

I don't know of any evidence for that, but would be interested if there
were some. (Technically, I could also quibble a bit with your
statement,
since we're discussing server-authentication, so I guess you meant an
SSL-server cert above and HTTPS can also be used with D-H, without
providing server authentication, though that doesn't get much use.)

(At least in the developed world,) the point is not the actual amount,
but whether or not to increase the existing bias towards getting people
to pay commercial CAs for certs or not. Commercial CAs have their
purpose, but should not IMO be required in order to create a perception
of security for HTTP traffic. Sometimes they are appropriate, sometimes
they just add a burden that arguably could cause less use of SSL - if
its too much hassle to turn it on.

>  I think the safest default behavior for a browser that receives a
>
self-signed cert is to show an error page.  The message should tell  >
the user to contact the site's administrator to ask them to fix the  >
problem.

I don't agree that self-signed certs are a problem and would really not
like to see such browser behaviour encouraged.

The main point is that naively differentiating between a "secure"
state (padlock) and an insecure one (no padlock) isn't very effective.
I don't believe that changing from that binary approach to an N-ary
one,
where the N options map to TLS state-machine states will be any more
effective. We need a subtler mix...

S.










 
Received on Monday, 8 January 2007 21:12:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 February 2008 03:52:45 GMT