W3C home > Mailing lists > Public > www-tag@w3.org > January 2012

Re: HTML5 proposes introduction of new family of URI schemes

From: David Booth <david@dbooth.org>
Date: Thu, 19 Jan 2012 13:00:41 -0500
To: Robin Berjon <robin@berjon.com>
Cc: "www-tag@w3.org List" <www-tag@w3.org>, Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@intertwingly.net>
Message-ID: <1326996041.13396.45575.camel@dbooth-laptop>
On Thu, 2012-01-19 at 17:07 +0100, Robin Berjon wrote:
> 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.

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.

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

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?

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.

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

What other options are being considered?

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

If I've misunderstood, please set me straight.  I definitely do not
fully understand this proposed HTML5 feature, so I may have got it all
wrong.


-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.
Received on Thursday, 19 January 2012 18:01:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:44 GMT