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.