[whatwg] isAnyProtocolHandlerRegistered

[Brett Zamir]

Hi,

A former proposal (at 
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-January/018101.html 
) mentioned protocol handler check which did not require a URL string as 
in the second argument to isProtocolHandlerRegistered().

I don't see any other discussion of this, but I am puzzled by why a 
mechanism presumably designed to allow sites NOT to have to commit their 
users to using a specific location is set up to effectively fail in this 
goal because there is no such practical way to fallback to a specific 
site or even a custom message (e.g., pointing users to instructions on 
where and how to register a protocol available on other sites) because 
there is no programmatic way to detect whether ANY protocol has been 
registered (nor any content-creator-friendly markup solution such as a 
link attribute to be tried before the href attribute).

Yes, one can attempt to register a protocol through one's own site, but 
this requires the user to be willing to register with the linking site 
(and to do so) and requires the linking site to be willing to provide 
its own handler (and to do so). If, for example, I am not a bookstore, 
why do I need to pollute the users handlers with my own ISBN handler 
just to be able to ensure the user clicking on my recommended book links 
can see something useful? Why should users of my blog have to trust my 
site as a competent ISBN handler for all their ISBN numbers? (This also 
raises the question of why one cannot register a protocol by some regex 
or at least wildcard ability, but that will hopefully be addressed by 
the apparent merging of registerProtocolHandler with Web Intents.)

I seem to recall some security discussion with concerns that being able 
to check would leak information such as whether the user had registered 
protocols like "whistleblower-ID123:", but:

1) It is already effectively possible in all modern browsers (not sure 
about IE9) to do the necessary check of whether any protocol is handled 
(at least whether it is loadable) through inserting a hidden iframe with 
an onload event (DOMContentLoaded is sadly not available for iframes in 
any browser I tested) and waiting for a timer to detect after a likely 
sufficient load time whether the protocol loaded something, though this 
obviously is clumsy, and besides requiring one to load the hopefully 
idempotent URL twice which one wishes the user to visit, it requires a 
guess at an adequate timeout to wait for a likely complete page load.

2) The spec could overcome this (seemingly obscure) security concern if 
deemed necessary by requiring a distinct prefix for either readable 
and/or especially non-readable protocol types (e.g., 
"exposed+whistleblower:").

Thanks,
Brett