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.