Re: HTML5 proposes introduction of new family of URI schemes

Hi David,

On Jan 19, 2012, at 19:00 , David Booth wrote:
> On Thu, 2012-01-19 at 17:07 +0100, Robin Berjon wrote:
>> 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.
> 
> I didn't mean to be focusing on one particular browser-website handshake
> technique over the other, since a similar handshake needs to happen
> regardless of how it is initiated or controlled.  I meant to be drawing
> attention to the larger issues of: (a) the advisability of making it
> "too easy" for web sites to make themselves URI scheme handlers; (b)
> whether new URI schemes are needed at all for the desired functionality;
> and (c) whether a standards group should be inventing new URI schemes
> incidentally.

Point (a) is definitely a major area of concern. The currently typical experience here is that when RPH is called, the browser will show an infobar/doorhanger/whatever dialog type it uses for security to ask the user to accept installing that handler. As far as I can tell, on OSX, Firefox just sets that handler up for itself, whereas Chrome installs it system-wide (which is far more useful, but also more dangerous). The first time you activate a link using that scheme, Firefox will also ask you if you really want to use that page to open it (Chrome will just happily jump to the page).

Whether this is sufficient security is an excellent question. My primary concern has to do with how to remove that handler, once installed. In Firefox you have to dig down in the "Application" section of your settings, and search for the scheme. Not exactly friendly. In Chrome, I couldn't figure out what to do. (Other browsers I tried didn't seem to accept the registration in the first place anyway.)

But excellent as it is, I don't think that it's up to the TAG to make the call on this one. This really is an issue of the HTML5 specification.

For point (b) I'm pretty sure that URIs are a good thing for mailto:, smsto:, and a host of other protocols, and I think that the ability to handle them is an important component in making the Web into the universal application platform that it ought to be. The question about minting new schemes with the web+ prefix is the one that I think needs digging into. See http://lists.w3.org/Archives/Public/www-tag/2012Jan/0088.html for the questions I have.

As for (c), I think the answer is "when they need to". The sheer amount of flaming hoops one has to jump through in order to register a new scheme is probably punishment enough for formulating that thought in the first place.

> I have not read the entire spec, so I may have misunderstood the intent
> of the new URI scheme.  I read this section:
> http://dev.w3.org/html5/spec/Overview.html#custom-handlers 
> And I particularly noted this:
> [[
> 6.5.1.2 Custom scheme and content handlers
>  [ . . . ]
> The registerProtocolHandler() method allows Web sites to register
> themselves as possible handlers for particular schemes. For example, an
> online telephone messaging service could register itself as a handler of
> the sms: scheme, so that if the user clicks on such a link, he is given
> the opportunity to use that Web site.
> ]]
> 
> My understanding is that a web page could call registerProtocolHandler()
> to register a web site as a possible handlers for a particular URI
> scheme, and (if successful) thereafter when the browser attempts to
> navigate to a URI that uses that scheme, the browser would use that web
> site's handler instead of using whatever other mechanism it otherwise
> would have used.  Is that correct, or did I misunderstand the intent of
> that section?

Yes, that is entirely correct. The issue is then one of security.

> If I understood correctly, then that URI scheme is being used to trigger
> the browser's use of a special handler, though the handler was
> pre-registered earlier, so much of the browser-website handshake already
> occurred in the preregistration process.

Yes, the handshaking normally happens largely or entirely at registration time. The question is what security do you put behind that? Currently the specification whitelists some schemes, and suggests the web+ prefix for "web-safe" schemes created in the future. I think that *that*, rather than the whole RPH story, is what's looking for some cool-headed thinking (and tinkering). Unfortunately this thread seems to jump all over the place, as seems to always be the case when someone mentions URI schemes...

>> 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.
> 
> What other options are being considered?

I don't know, don't remember them coming up, and couldn't find out — hence my questions in the previous email I pointed to.

> It just seems to me -- if I've understood correctly -- that what's
> really going on here is that the new URI scheme would be created
> specifically for a particular class of handlers, when to my mind a URI
> scheme should be handler-neutral.  Otherwise we would be creating
> parallel universes of URI schemes (e.g., foo: and web+foo).

The URIs and the handlers are separate. But we'd be creating a new class of URI schemes in future that are considered to be safe for usage in a Web context. I strongly suspect that that's going to be a hard decision to make. Suggestions for a better approach would be very welcome.

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

Received on Monday, 23 January 2012 22:12:06 UTC