Re: [whatwg] URI scheme whitelisting and the case of cryptocurrencies
Dnia 2015-03-07, sob o godzinie 15:45 -0800, Michael A. Peters pisze: Another thing to consider, most crypto-currencies use the same Qt client codebase - so it is easy for a web site to specify a price in one crypto-currency but use the URI scheme for a different one, and some users may not realize the wrong client launched until it is too late and can't be undone. e.g. `Please donate 3 QRK - that's all I ask' but 3 bitcoins are sent before the user realize it was bitcoin-qt that the link launched. There is also an example of multiple currency wallets, like Coinomi Android wallet or previously mentioned Coinkite. An user may launch a QR scanner inside his multi-wallet and scan a code which is said to represent 3 blackcoins, but instead will resolve to 3 bitcoins. Or the site may say it is requesting a payment of 35254.432424452 blackcoins, but instead 352534.432424452 blackcoins will be presented on QR code. Those are issues which can’t be fixed by HTML5 specification and in my opinion it is the client which should ensure that the user really knows what he’s doing. If the client feels scared by externally given URIs, it may choose not to register itself as a protocol handler or, for example, strip the “amount” part and require the user to enter currency symbol as an additional confirmation.
[whatwg] URI scheme whitelisting and the case of cryptocurrencies
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 registerProtocolHandler. 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?
Re: [whatwg] URI scheme whitelisting and the case of cryptocurrencies
On 03/07/2015 03:40 PM, Michael A. Peters wrote: Especially crypto-currencies where even on Linux systems, the client is often not under a package management system control and may be out of date. QR codes pose the same problem but it is more difficult to trick a user into scanning a QR code, so it is harder to get the user's client to launch via a trick. Another thing to consider, most crypto-currencies use the same Qt client codebase - so it is easy for a web site to specify a price in one crypto-currency but use the URI scheme for a different one, and some users may not realize the wrong client launched until it is too late and can't be undone. e.g. `Please donate 3 QRK - that's all I ask' but 3 bitcoins are sent before the user realize it was bitcoin-qt that the link launched.
Re: [whatwg] URI scheme whitelisting and the case of cryptocurrencies
On 03/07/2015 11:50 AM, Krzysztof Jurewicz wrote: *snip* 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? I do not allow bitcoin: on my servers, nor anything except for http, https, or ftp. The reason is because I have no way of knowing what third party applications might have vulnerabilities (including social engineering) that could be exploited by a specially crafted URI string being fed to them. I don't even allow mailto: I'm a big supporter of bitcoin but especially for a financial application where it can't be undone once confirmed in the blockchain, I just personally think it is too dangerous to even allow bitcoin: URIs on a web page. I prefer the user launch the third party application and enter whatever parameters they want to enter into the client than a link that does things for them, including possibly some things they don't necessarily understand is happening. Especially crypto-currencies where even on Linux systems, the client is often not under a package management system control and may be out of date. QR codes pose the same problem but it is more difficult to trick a user into scanning a QR code, so it is harder to get the user's client to launch via a trick.
