W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2015

[whatwg] URI scheme whitelisting and the case of cryptocurrencies

From: Krzysztof Jurewicz <krzysztof.jurewicz@gmail.com>
Date: Sat, 07 Mar 2015 20:50:12 +0100
Message-ID: <1425757812.17618.17.camel@gmail.com>
To: whatwg@whatwg.org
The registerProtocolHandler method specifies a whitelist of schemes for
which web applications are allowed to register themselves as possible
handlers ( https://html.spec.whatwg.org/#whitelisted-scheme ). On the
JQuery Standards repository there is an issue stating that “A blacklist
(not a whitelist) should define whether URL schemes are available for
registration” ( https://github.com/jquery/standards/issues/12 ). I would
like to support it with a concrete example.

One of the whitelisted schemes is “bitcoin”, which allows sending money
to a Bitcoin address. The problem is that Bitcoin is not the only one
cryptocurrency. “Crypto-Currency Market Capitalizations” site lists
currently 527 different currencies
( http://coinmarketcap.com/currencies/views/all/ ). Some of them are
very similar to Bitcoin (like Litecoin), some are similar but use a
different mechanism for securing the blockchain (like Peercoin and
Blackcoin) and some are based on a different codebase (like NXT and
Monero). However only Bitcoin clients are able to use

Web wallet Coinkite already tries to bypass that limitation by
generating QR codes and URIs using “bitcoin” scheme for each currency
they support. They also claimed that the world should use one URI scheme
for all cryptocurrencies (
https://twitter.com/coinkite/status/470898769446584320 ). What may work
for their case, not necessarily is a proper general solution. People may
want to use different clients for different coins and, for example,
canonical Bitcoin client shouldn’t need to know anything about
alternative currencies.

I see two simple solutions to this problem:

⒈ Deprecating the “bitcoin” scheme and creating a “coin+xxx” scheme
family, which, analogously to “web+xxx”, will be whitelisted.

⒉ Dropping the whitelist solution in favor of a blacklist of URI schemes
which are forbidden to be registered. Besides backwards compatibility,
this solution has other advantages:
ⓐ It is more flexible and can support not only cryptocurrencies, but
many other emerging technologies, allowing developers to create them
without the need to gain a specific permission. The whitelist looks like
an overregulation which inhibits innovation.
ⓑ It is more adjusted to the nature of the problem. Existing whitelisted
schemes are often about message sending (“email”, “mailto”, “sms”),
while cryptocurrency schemes are about money sending, so it looks that
they belong to the same level of abstraction. Furthermore, some of the
cryptocurrencies allow also message sending.

What are your thoughts about that? Are there any security considerations
preventing the whitelist solution? Or maybe a more general one should be
worked out?
Received on Saturday, 7 March 2015 19:50:43 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:33 UTC