[whatwg] Whitelist for registerProtocolHandler()
Simetrical+w3c at gmail.com
Fri Jun 10 12:00:19 PDT 2011
On Thu, Jun 9, 2011 at 3:35 PM, rektide <rektide at voodoowarez.com> wrote:
> 1. The current use case for registerProtocolHandler is intra-page. For one example, here's
> the MDC docs:
> "Note: Web sites may only register protocol handlers for themselves. For security reasons,
> it's not possible for an extension or web site to register protocol handlers targeting other
That only means that the protocol can only be *handled* by the current
origin. It still intercepts links *from* any page, or even that the
user manually types in the location bar. So the security issues
> 2. Someone who wishes to register a 'web' protocol for their own usage ought be forced to
> consider that this protocol may not necessarily remain in their own purview.
> 3. It forces syntactical cruft upon people wishing to exercise this capability, and that
> cruft makes website handled protocols less likely to be used, to look cheap, and to be
> regarded as second class citizen of the protocol world. Tim Bray has already lamented
> enforcing the // upon the world, and if web+ protocols take off this will exacerbate his two
> character mistake by another four oh-so-valuable characters. We ought not double the
> obvious + preventable mistakes of the past.
Yes, it stinks. But anything else is a potential security
vulnerability. We don't know what protocols people are using out
there, and we don't want to allow web pages to intercept any protocol
someone might be using. Note that if a protocol proves popular, it
can always be added to the whitelist in unprefixed form, and people
can move to the unprefixed version as browser support for the updated
whitelist is deployed. There's no reason anything has to be
permanently prefixed if it catches on.
> 4. Whitelisting seems fundamentally 'anti-web' by enforcing only what is out there already.
Whitelisting is ubiquitous in security, including on the web.
Blacklisting is just not safe.
> I strongly support the notion that web pages ought be able to provide their own content &
> protocol handlers — especially in an OS native fashion — and it strikes me as unweildy to
> place this ^web\+[:soo:]+ restriction on this extension point. Personally, I think it is
> very high priority to reconsider Ian's informal decree (which has since been pressed into
> service in WebKit), and formalize concensus around this issue.
In that thread, implementers of Chrome and Opera agreed with Ian, and
no implementers disagreed. It's not a decree by Ian, it's up to
implementers to decide what they want to do.
More information about the whatwg