[whatwg] [WhatWG] Some additional API is needed for sites to see whether registerProtocolHandler() call was successful

[Mithgol the Webmaster]

In the year 2007 or 2008 the site http://fghi.pp.ru/ was launched to
act as a gate between the Fidonet echomail system and the Web browsers
like Firefox. For example, for people who not have direct access to
Fidonet and thus cannot open the Fidonet message that has the URL

    area://Ru.Blog.Mithgol?msgid=2:5063/88+49659a64

it is still possible for them to use the Web gate by using the URL

    http://fghi.pp.ru/?area://Ru.Blog.Mithgol?msgid=2:5063/88+49659a64

This gate handles several FGHI URI schemes such as area:// and fecho://
for Fidonet hyperlinks.

And then (though already several months ago), Firefox 3.0.x appeared, the
browser that implemented WhatWG proposal of registerProtocolHandler() API.
It then became possible for web sites to register themselves as handlers
for URL schemes previously unknown to Web browsers. Schemes like FGHI
URLs of Fidonet that previously remained unknown to the browsers of
Internet, though they are gradually implemented in more and more
browsers of Fidonet, such as HellEd and NoSFeRaTU's GoldED+.

I immediately wrote a Fidonet echomail message to the FGHI URL gate's
author and explained the advantages of registerProtocolHandler():

    area://GanjaNet.Local?msgid=2:5063/88+48319a1f

Then the FGHI URL gate's author created http://fghi.pp.ru/handler.php
as the page that anyone may visit and register the gate as a handler
for area:// and fecho:// hyperlinks in Firefox.

However, even after such registration is complete, the reader visits
the pages such as http://fghi.pp.ru/?area://FTSC_Public/ and there
encounters Fidonet URLs in their gated form, like the following:

    http://fghi.pp.ru/?area://FTSC_PUBLIC?msgid=2:280/5555+48c0e781

I asked the gate's author why the URLs are not provided then in their
natural Fidonet form, like the following:

    area://FTSC_PUBLIC?msgid=2:280/5555+48c0e781

The gate's author then explained to me that the WhatWG API is not
complete and does not provide the site with any means to determine
whether registerProtocolHandler() call was successful and whether the
URL scheme was actually registered, and whether it remains registered
when the page is served by the server.

I hereby ask the WhatWG team to think of some additional API in order
for this task to be handled as well.

The HTML5 standard function registerProtocolHandler() should probably
remain void as in standard, but WhatWG could invent yet another
boolean protocolRegistered("area"), with the only argument (protocol
name as string), to check whether a protocol is registered.

See http://www.whatwg.org/specs/web-apps/current-work/#custom-handlers
section 5.6.1.1 for the list of possible security implications. Take
the following two thoughts into your consideration:

1) The browser should prevent continous registration spamming,
   i.e. a site should not harm its reader (the user) even if the site
   decides to repeat registerProtocolHandler() until
   protocolRegistered() returns true. At http://fghi.pp.ru/handler.php
   I already noticed that Firefox already shows its notifications
   one after another ("fecho://" after "area://" only if "area://" was
   registered or cancelled by the user); that's probably enough.

2) A site should be prevented from being able to bargain for protocol
   registering, e.g. the scenario "in order to login for porn,
   register your mailto handler here and allow us to harvest your
   addressees for spam" should not be made possible. A mere checkbox
   ("I register evil.example.org as a handler for mailto links that
   appear on the pages of evil.example.org only.") should be enough
   for the site to see protocolRegistered() as true and even verify
   that a "mailto:example at evil.example.org" link, when clicked on the
   evil site, leads to the same site's handler page, but no other harm
   would occur.

Yet another thought to clarify: protocolRegistered("area") could
return not just boolean true but a string such as
"http://fghi.pp.ru/?%s". However, that would be likely to leak
intranet structure (of handler pages) to the outworld, and would also
encourage handler sites to use their own prefixes to non-standard URLs
even when they could use such URLs directly (but when that would
direct their user to a rival handler site that the user prefers).
That's an obvious Bad Thing, so I suggest only a boolean
protocolRegistered() function here.


-- 
Best regards,
 Mithgol                          mailto:webmaster at mithgol.ru