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

RE: ACTION-338: Issues for safe browsing mode

From: Dan Schutzer <dan.schutzer@fstc.org>
Date: Wed, 28 Nov 2007 13:11:04 -0500
To: "'Hallam-Baker, Phillip'" <pbaker@verisign.com>, <public-wsc-wg@w3.org>
Cc: "'Dan Schutzer'" <dan.schutzer@fstc.org>
Message-ID: <01a201c831ea$0e0b9ed0$6500a8c0@dschutzer>
I think we are in agreement. 

 

I believe that Safe Browsing should deal with restricting content but
otherwise capable of performing general browser actions.

 

The way we handle sensitive transactions such as sending authentication
credentials, changing biller addresses or transferring funds should have
another set of restrictions and protections about them, that get escalated
relative to the risk they present. 

 

Passwords are never sent in the clear and are augmented by behavioral
pattern monitoring and in other cases stronger authentication technology

Adding billers and changing addresses, and transferring funds across banks,
requires second channel confirmations, etc. These mechanisms need to be in
place with or without Safe Web Browsing mode.

  _____  

From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org] On
Behalf Of Hallam-Baker, Phillip
Sent: Wednesday, November 28, 2007 12:46 PM
To: Dan Schutzer; public-wsc-wg@w3.org
Subject: RE: ACTION-338: Issues for safe browsing mode

 

Too restrictive in what ways?

 

You would still build the transaction as is done today, the only difference
would be that the final confirmation step would be taking place in the
secure interaction mode.

 

Linking back to the comments on the call today, I don't think we can expect
people to get out of the habbit of giving out their password in dubious
circumstances. We need to very clearly distinguish the authentication mode
and the transaction confirmation mode from the regulat interation mode, and
do so in a way that is cleaner, easier for the end user.

 

I agree that users can be habbituated to 'allow or deny' type dialogues, but
they still have significant value. For example, if I put a DVD that has a
rootkit style copy protection on it into my computer I am not expecting a
program to install and I can deny the thing pronto.

 

 

Equally if I don't think many folk are going to be habbituated to procedures
such as adding new unauthenciated bill pay recipients to their bank account
or wiring funds out of their account. We don't need to stop every bad thing
an attacker might do to someone's bank account, just the ones that make
money for them. 

 

Is there any security sensitive transaction we engage in today that does not
end up in a confirmation ceremony?

 

 

  _____  

From: Dan Schutzer [mailto:dan.schutzer@fstc.org]
Sent: Wed 28/11/2007 11:40 AM
To: Hallam-Baker, Phillip; public-wsc-wg@w3.org
Cc: 'Dan Schutzer'
Subject: RE: ACTION-338: Issues for safe browsing mode

With respect to 'safe browsing mode concepts' I agree that case 1 needs to
be achieved and that case 2 is worthwhile including as well, but that case 3
is not very practical

 

With respect to 'safe browsing mode approaches', I would be for approach 1 -
restricted content mode, and not approach 2 - minimal interaction mode. A
minimal interaction mode would be too restrictive to be useful for most on
line banking applications. Also things like transfer of credit card details,
as Phillip explained on the phone is better handled other ways, and needs to
be if off-line credit card and debit card fraud is to be eliminated.

 

  _____  

From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org] On
Behalf Of Hallam-Baker, Phillip
Sent: Wednesday, November 28, 2007 10:50 AM
To: public-wsc-wg@w3.org
Subject: ACTION-338: Issues for safe browsing mode

 

We have been discussing a number of 'safe browsing mode concepts'. I propose
that we distinguish between the following cases:

 

1) Informing the user that they are in an area of the Internet that may be
regarded as 'safe' (e.g. accountable, censored for minors, virus scanned
etc. etc.)

 

2) Limiting the set of content actions available (i.e. no javascript,
limited java script, limited ActiveX, etc. etc.)

 

3) Limiting the set of user actions that are possible outside safe browsing
mode (e.g. no forms unless you are on an EV SSL site)

 

 

We have discussed (1) extensively, if we are going to want the user to
behave differetly in safe browsing mode we will need to achieve (1), while a
safe browsing mode may permit a more aggressive approach (e.g. active
security indicators rather than passive) it is really the second set of
issues that distinguish the safe browsing mode topic. I don't think (3) is
very practical so lets start with 2

 

 

There seem to be two approaches to 'safe browsing' on the table:

 

1) A restricted content mode capable of general browser actions that assures
the bank &ct that the user does not have foreign active content running

 

2) A minimal interaction mode that is only capable of performing a highly
restricted set of actions that are highly security sensitive (e.g. transfer
of credit card details, transfer of authentication details to bank).

 

The second is not a 'safe browsing mode', it is making the potentially
unsafe interactions safe.

 

 

The question here is how tightly the security perimeter is drawn. As a
metaphor imagine we are protecting the crown jewels. We can guard the whole
Tower of London and prohibit any unauthized access (bad for tourist trade
and it failled in the past). At the other extreme we can put the jewels in a
locked box, this also fails as the perimeter is so tight that we loose the
security context (and in the case of Scotland the Honors themselves were
lost for a couple of centuries).

 

Policing the whole browser is liable to be impractical. HTML has a huge
amount of power

 

But if we only police the release of the credit card details or bank
authorization we loose context and thus fail for the opposite reason.
Consider the problem of a smartcard, it securely represents only the fact
that it was presented to a card terminal. If the card terminal itself is
compromised it can make fraudulent charges to the card. The user only
authorizes the transaction, not the transaction amount.

 

 

It seems to me that for safe browsing mode to be practical we would need a
middle ground, something that looks a bit like cardspace but with the
ability to transfer slightly more information. 

 

So lets look at some use cases:

 

1) Log in to bank site

     Cardspace already handles this and is built into the O/S core on
windows and can be built into other platforms.

 

2) Authorize a sensitive bank transaction

      Here we want to present the actual summary of the transaction as part
of the authorization ceremony. In other words:

 

     Bank creates summary of transaction in a highly restricted subset of
HTML, i.e. no images, fonts, colours, forms. Just <P>, <h1..6>, <em>,
<table> and <span>. Non presentation semantics via RDFa might be acceptable.

 

     Secure browsing mode presents this to the user as part of the secure
interaction mode, similar to cardspace.

 

     Customers who use the mode can lock their accounts so that they only
access their accounts this way. So no portable static credentials to phish.

 

3) Authorize a credit card transaction

 

      Here we use the same technique: generate an invoice in Restricted
HTML, present to the user in secure browsing mode. Train users not to edit
their card details.

 

 

Clearly this is closer to the security requirements than trying to define a
restricted content mode, it is also more practical in that it is probably
easier to persuade browser providers to implement a new security feature
than remove or change existing features.

 
Received on Wednesday, 28 November 2007 18:18:36 GMT

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