Re: web+ and registerProtocolHandler

On Sun, Sep 16, 2012 at 4:21 PM, Mark Nottingham <mnot@mnot.net> wrote:
> On 17/09/2012, at 6:55 AM, Adam Barth <w3c@adambarth.com> wrote:
>>> I don't really know enough to be against it myself but
>>> it does sound like a bad security idea from the mails I've
>>> seen pass by so count me amongst those concerned about
>>> this.
>>
>> I'd caution you about forming an opinion after having heard only one
>> side of the issue.
>
> So, let's hear the other side; we're listening.
>
> As Chris said a few days ago, it'd be helpful to see an end-to-end use case, to give some context.

I don't particularly have a dog in this fight.  I can try to summarize
my understanding of the use case and contraints, but if you want to
have a more detailed discussion, you're probably better off having it
with folks who are more specifically interested in this topic.

Here's what the Web Applications spec says:

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

The spec then goes on to list a number of whitelisted schemes for
which web applications can register handlers.  My understanding is
that the forgoing isn't controversial.

What is controversial, I believe, is that the spec also whitelists
schemes that begin with "web+".  For example, the hypothetical
web+openid scheme is allowed as well.

Suppose, for example, the the OpenID folks wanted to make it possible
for a web site to easily discover the user's identity provider.
Today, the user either needs to select from a NASCAR of IDPs or needs
to enter something complicated, like a URL or an email address, in
order to tell the web site about his or her IDP.  Using this
mechanism, the OpenID folks could have IDPs register a protocol
handler for web+openid.  Web sites could then direct the user to some
URI in the web+openid scheme in order to ask them to authenticate.

Without an open-ended list of allowed URI scheme, using new URI
schemes with registerProtocolHandler would require updating browsers,
which can take a while.  With an open-ended list, folks can use these
new URI schemes immediately.

Once we decide that we want an open-ended list of URI schemes, we can
ask the question of how best to construct such a list.  The question
that started this thread was why don't we just allow all URI schemes
with the exception of a finite list of known-dangerous schemes.  As I
explained, there's no feasible way to construct such as list as there
are a large number of dangerous URI schemes that we need to prevent
web sites from registering protocol handlers for.

Instead, the authors of the spec have selected an open-ended list that
(1) doesn't contain any known dangerous URI schemes and (2) seems
unlikely to include any currently unknown dangerous URI schemes.

This is probably going to be my last message to this thread because I
don't view this discussion as being overly productive as it does not
include the relevant stakeholders.  If you view the above design as
problematic, I would encourage you to think about how to address the
above use case in the presence of the above constraints.  If you're
able to find a better solution, I suspect you'll have success
convincing implementors to change direction.  If you're unable to find
a better solution, it seems unlikely that you'll have much effect on
what gets implemented.

Adam

Received on Monday, 17 September 2012 07:51:07 UTC