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

> >> 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:
And I particularly noted this:
[[ 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

David Booth, Ph.D.

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 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:13 UTC