About the need to amend HTML 5

The current HTML 5 project contains the registerProtocolHandler () function in a form that is not particularly suitable for practical use. And it will not be out of place to talk about how I came to this conclusion.

The story will be extensive; who does not feel in himself the reserves of patience, the better not to climb under a habrakat.

A year around 2007 or 2008, the site http://fghi.pp.ru/ was launched - it works as a gate between the Fidonet echomail system and browsers like Firefox. For example, if someone does not have direct access to Fidonet, and therefore he cannot directly open a Fidonet message with a URL
')
area: //Ru.Blog.Mithgol? msgid = 2: 5063/88 + 49659a64

then he can use the web gate by opening the URL

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

This gate handles several FGHI URL schemes (such as "area: // ..." and "fecho: // ...") for Fidonet hyperlinks.

Last year, Firefox 3.0.x appeared - a browser that implemented the WhatWG proposal for the registerProtocolHandler () API. It has become possible for websites to register as handlers for URL schemes that were previously unknown to the browser. For schemes like the FGHI URL Fidonet, which previously remained completely unknown to Internet browsers, although they were gradually embodied in Fidonet browsers (such as HellEd and NoSFeRaTU's GoldED +).

I immediately told the FGHI gateway URL to the Fidonet echomail to the author and explained the registerProtocolHandler () to him:

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

Then the author of the FGHI gateway URL created the page http://fghi.pp.ru/handler.php as a place that anyone can visit and register the gate as a handler for the “area: //” and “fecho: //” hyperlinks in Firefox.

However, even after such registration is completed, the reader visits pages like http://fghi.pp.ru/?area://FTSC_Public/ and sees URLs in a per-game form, like this:

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

I asked the author of the gate, why the URLs are not provided then in their natural Fidonet form, like this:

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

The gate author then explained to me that the WhatWG API is incomplete and provides no way for the site to determine whether the registerProtocolHandler () call was successful, whether the URL scheme was actually registered, whether it remains registered until the next page is returned by the server.

It became absolutely clear to me that HTML 5 needs to be supplemented so that this task can be performed implacably.

It is possible that the registerProtocolHandler () function of the current HTML 5 standard should be left void (not returning a value), as is now written in the standard; however, WhatWG would not hurt to invent a new boolean (logical) function with a name like protocolRegistered ("area") and with a single argument — the name of the protocol — to check if the protocol is registered.

Http://www.whatwg.org/specs/web-apps/current-work/#custom-handlers lists the possible implications of such logging protocols in terms of their security. Personally, the following two considerations come to my mind:

1) The browser should prevent user javascript script registration requests from “cluttering” or “spamming” the user, even if the site is determined to call the registerProtocolHandler () function until protocolRegistered () returns a true value. On the page http://fghi.pp.ru/handler.php, I noticed that Firefox shows its notifications sequentially (“fecho: //” after “area: //” and only if the registration is “area: //” by the user was accepted or rejected); this measure is probably pretty.

2) The site should not be able to bargain for the registration of the protocol; for example, the scenario “to log in to the porn archive, register your mailto: handler here and let us collect the addresses of your correspondents to send spam to them” must be prevented. A simple tick in the browser interface when registering a scheme (“I register evil.example.org as a handler for only those mailto links that appear on evil.example.org itself.”) Would be enough for the site to see the protocolRegistered () true and even could check that the “mailto: example@evil.example.org” hyperlink , when clicking on it with a mouse, led to the handler page on that site - but this would not have brought any other harm.

Some would have thought that the protocolRegistered ("area") function could return not just a logical truth, but also a direct hyperlink (in the example above, “http://fghi.pp.ru/?%s”) . However, the intranet addresses of the pages-handlers could easily flow into the external network. And besides (and this, perhaps, it will still be more powerful), then handler sites could use their own prefixes instead of giving non-standard addresses in their natural form, if and when it would be noticeable that the user prefers (and registered as handler natural appearance of non-standard URLs) some other site, competitors site. This would be such an obvious shit that I think the protocolRegistered () binary function is the best solution.

This is the whole story about why the registerProtocolHandler () function alone is not enough.

Now I turn to Habra with a question: how can I turn the tide? Are there any people on Habré with links in WhatWG and (or) in the browser building industry who can influence decision making and write the URL scheme registration API in a more complete, more convenient form for site builders ?