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.