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

RE: Opera's three security levels

From: Hallam-Baker, Phillip <pbaker@verisign.com>
Date: Mon, 27 Nov 2006 13:30:07 -0800
Message-ID: <198A730C2044DE4A96749D13E167AD37E7E7DF@MOU1WNEXMB04.vcorp.ad.vrsn.com>
To: "Mike Beltzner" <beltzner@mozilla.com>
Cc: "Amir Herzberg" <herzbea@macs.biu.ac.il>, "Michael\(tm\) Smith" <mikes@opera.com>, <public-wsc-wg@w3.org>

> [mailto:public-wsc-wg-request@w3.org] On Behalf Of Mike Beltzner

> On 27-Nov-06, at 9:47 AM, Hallam-Baker, Phillip wrote:
> >> Users care about security, and will more and more, thanks to the 
> >> phishers... but this does not mean, they have to 
> understand security 
> >> mechanisms or indicators. As long as the indicators and 
> their use are 
> >> simple and non-obtrusive, users will use them.
> >
> > Any security indicator has to answer the question that the user is 
> > already asking.
> >
> > Does the user ask 'is this safe?' or do they ask 'is this 
> Bizybank?' ?
> Frankly, I don't think the user asks either of these 
> questions. I think the user first visits a website assuming 
> that they are being taken to the destination advertised by 
> whatever link took them there
> (ie: "Click [here] to go to Bizybank", or "Update [your profile at
> Bizybank]!") The text of the link creates an expectation 
> ("I'm going to go to Bizybank!") and as long as the 
> destination site minimally confirms this expectation 
> ("Welcome to Bizybank!") then the user won't have any reason 
> to be suspicious or ask any sort of question.  
> In fact, the next question they're most likely to ask is:

OK here is a crazy idea I had in the meeting but did not flesh out there since I wanted to avoid taking us off track.

The use case Mike describes is really about preserving context across application context. At the moment this is done differently on each platform but in most cases the transfer of information essentially boils down to a single URL.

There is no reason why we can't have a more comprehensive intra-platform communication mechanism that preserves as much context as we might want.

Lets consider Windows since in this case that's the harder platform to change.

We would create a new set of URI schemes: CTX-HTTP, CTX-MAILTO, ....

[Note URI schemes with a dash in them are reserved for this type of use so there is no possibility of a collision]

A Web browser that is CTX-HTTP enabled registers for BOTH the HTTP scheme and the CTX-HTTP scheme. When accepting a CTX-HTTP message the Web browser checks to see that it is also registered for HTTP, if it isn't the message is handed over again to the default HTTP provider.

An email client that is CTX-HTTP enabled looks first for a CTX-HTTP registration to hand off to, otherwise falls back to HTTP.

The handover message itself is simply a small chunk of XML:

<CTX uri="http://www.verybadperson.com" xmlns="foobar">
        <DOMAIN sender="accounts@bizybank.com" authentic="unverified"/>
        <HTML matcheduri="False"/>

We could also URI encode this but this is not essential.

The point here is that we can do this without waiting for a platform release of Windows. The browser and the email client can both adopt this unilaterally and we can progress to the desired endstate without ever arriving at an undesirable state.

Last time I used UNIX on a daily basis was a decade ago, we did this type of configuration using MAILCAP. I am guessing that there must be a similar handler to the registry, the only difference being whether the communication/administration is centralized or not.
Received on Monday, 27 November 2006 21:32:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:12 UTC