- From: Brett Zamir <brettz9@yahoo.com>
- Date: Sun, 30 Sep 2012 11:39:10 +0800
- To: whatwg <whatwg@whatwg.org>
- Cc: webmaster@mithgol.ru
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
Received on Sunday, 30 September 2012 03:39:44 UTC