[whatwg] Blacklist for regsiterProtocolHandler()

[Brett Zamir]

  On 4/20/2011 2:11 AM, Lachlan Hunt wrote:
> On 2011-04-19 19:33, Ian Hickson wrote:
>> On Tue, 12 Apr 2011, Lachlan Hunt wrote:
>>>
>>> We are investigating registerProtocolHandler and have been discussing
>>> the need for a blacklist of protocols to forbid.
>>>
>>> [...]
>>>
>>> We'd like to know if we've missed any important schemes that must be
>>> blocked, and we think it might be useful if the spec listed most of
>>> those, except for the vendor specific schemes, which should probably be
>>> left up to each vendor to worry about.
>>
>> I haven't updated the spec yet, but it strikes me that maybe what we
>> should do instead is have a whitelist of protocols we definitely want to
>> allow (e.g. mailto:), and define a common prefix for protocols that are
>> used with this feature, in a similar way to how with XHR we've added 
>> Sec-*
>> as a list of headers _not_ to support.
>
> Other protocols we should probably also whitelist:
>
> irc, sms, smsto, tel.
>
> I'm also curious how we could handle ISBN URNs, like:
>
>   urn:isbn:0-395-36341-1
>
> That would be useful to have a web service that could look up the ISBN 
> and direct users to information about the book, or to an online store.
>
> As currently specified, services have to register a handler for "urn", 
> even if they only handle ISBN URNs.  The other alternative would be to 
> mint a new web+isbn scheme, which seems suboptimal.

Maybe registerProtocolHandler() could take a function as an extra 
argument to let the application determine whether it wishes to handle 
the protocol event, internally using e.preventDefault(), 
e.stopPropagation(), or something similar to indicate that it has 
successfully handled the case, and pass the buck to let other protocol 
handlers be checked in order of user preference otherwise.

>> So e.g. we could whitelist any protocol starting with "web+" and then
>> register that as a common extension point for people inventing protocols
>> for use with this feature, so that people writing OS-native apps would
>> know that if they used a protocol with that prefix it's something 
>> that any
>> web site could try to take over.
>
> That seems reasonable.
>

Now that it seems there is momentum on resolving the URN and custom 
(pseudo-)namespacing issue (I think "x-" might be nice to continue the 
tradition, though "web" seems fine also if real namespaces will not be 
used), can we please put back on the table the ideas of:

1) adding to <a/> an attribute "uris" (for trying alternatives first, 
with greater precedence than "href")
2) adding to <a/> an attribute "fallbackURIs" (for lesser precedence 
than "href", e.g., so a browser might expose these URIs only when the 
link was right-clicked)
3) adding an event to listen for the user refusing or the browser not 
supporting a protocol (even if this can be done with try-catches).

...so that people can actually begin experimenting with 
registerProtocolHandler() rather than expecting content authors to make 
links which may lead to nowhere for some of their users?

Brett