Re: HTML5 proposes introduction of new family of URI schemes

On Jan 19, 2012, at 04:43 , David Booth wrote:
> On Wed, 2012-01-18 at 22:10 -0500, Noah Mendelsohn wrote:
>> . . . Let's say I author a 
>> Web page, and to make it easy for you to email me, I include a link to 
>> mailto:nrm@arcanedomain.com.  You read my page, and click on the link, and 
>> you've explained why as a (hypothetical) Webmail user you'd want your new, 
>> smart HTML5 Web browser to invoke the Webmail Web app to compose the 
>> e-mail. 
> 
> And that could be easily done by providing a browser configuration
> option to tell it to use web mail at a particular URI instead of some
> non-web-based email client, without any need for a new URI scheme.  

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). 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.

I think that the use cases here are legitimate. The obvious goal of the registerProtocolHandler and web+ is to help remove browsers from the critical path of innovation on the Web, which I think everyone, browser vendors included, agrees is a good thing. The question is whether that's the best way to do it. The points that I think could be most useful to address in figuring that out would be:

• The specification has made the decision to white-list a number of schemes. What sort of rationale should guide someone in deciding to white-list (or in future, use the "web+" prefix) a given scheme, or conversely refuse to do so? In other words, why is it okay for a web app to handle NNTP but not FTP?

• Concerning the web+ thing, is it a good idea to make this security decision happen at scheme minting time? Yes, ideally one would have a solid understanding of the security implications of one's scheme, but in practice no one is omniscient — especially in matters of security. I see a lot of potential for web+ schemes to turn out later to be exploitable, leading to browsers having to blacklist them, or conversely schemes registered conservatively without the web+ that it turns out could be safely handled by web apps and that then need whitelisting. Either way, the purpose is defeated and we risk ending up with two schemes registered for the same protocols.

> Similarly, if a user wants to have a particular web site handle a
> particular kind of content for them, that could also be a browser
> option, just as browser plugins are already configured to handle
> particular kinds of content.  Again, I don't see any need for a new URI
> scheme for this.

Handling content types would also be a bad idea with a browser option. If I invent a wonderful new format with application/chupacabra media type, I really don't want to have to ask my users to go to some mysterious configuration panel and pasting in "application/chupacabra" and "http://chu.paca.br/a". I want them to just click on a link and have it work.

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). My concern with that one is that it is given a URL instead of a Blob. This means that it may not be able to access the content (the source might not allow cross-origin access, and the server side might not have the browser's credentials that allow it access to that resource) and that it creates a situation in which the browser can handle a given file type when it comes from the Web, but not when the same file is opened on the user's computer. But I'd rate that more as a problem with the feature itself than an architectural consideration.

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

Received on Thursday, 19 January 2012 11:47:56 UTC