Re: HTML5 proposes introduction of new family of URI schemes

On Jan 19, 2012, at 16:51 , David Booth wrote:
> On Thu, 2012-01-19 at 12:47 +0100, Robin Berjon wrote:
>> A configuration option is not user-friendly enough, which would hurt
>> adoption of the Web as an application platform — providing web site
>> with the ability to set this up easily is good (though there may be
>> kinks in the current approach's security model). 
> 
> And that could be done by the web site offering "hints" that the user's
> browser could choose to use or not.  "Click here to auto-configure your
> browser to use Acme Web Mail as your default email client."

Are you saying that it could be declarative rather than API based? I don't think that this would change anything to the topic being discussed in this thread except that it would make it harder to provide a good UX since users would be reprompted with every visit.

>> What's more with your solution we'd still need some form of standard
>> or convention for how to content of the URI (e.g.
>> mailto:nrm@arcanedomain.com) would be transmitted to the web app.
> 
> Yes, to be totally seamless and user friendly, standards or conventions
> would be needed in either case.  But in the end it could be just as
> user-friendly, without the need for a new URI scheme.  It is a question
> of what trigger is used to initiate this browser-website handshake: a
> new URI scheme versus any of the existing mechanisms.

I'm sorry but I have to ask: have you actually read the specification? There is no question of a URI scheme triggering the handshake (I don't even know how that would work). The handshake happens through an API. The proposed URI scheme prefix is used as a security mechanism in that.

> Sure, that's what the web site owner wants.  But that's also what every
> phishing site owner wants

Which is why there's a security mechanism involved in the first place, which leads to this discussion. Any why it's useful to figure out if putting that security at the URI scheme level is the right way to go.

>> But that part isn't registerProtocolHandler, it's
>> registerContentHandler, which doesn't use URI schemes but media types
>> (and since it's blacklisting rather than whitelisting, it doesn't
>> create a new magic +web suffix for media types). 
> 
> I don't understand that.  If registerContentHandler is blacklist driven
> instead of whitelist driven, then what would prevent phishing sites from
> inventing new legitimate-looking schemes that are not on the blacklist?

Again, I would like to kindly suggest that you may understand the issue better if you read the specification, or perhaps one of the introductions to these two methods that can be found through your favourite search engine. You can use schemes with registerContentHandler since it has nothing to do with URIs but rather applies to media types.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Thursday, 19 January 2012 16:07:44 UTC