Why I Emptied My Read.Cash Wallet

Your Keys, Your Coins

The read.cash wallet has always been an interesting implementation to me. The private keys are only stored on your device, so you may even have more than one wallet if you use more than one device to access your account. While possibly a bit roundabout, this is the way Bitcoin is meant to work. You are your own bank and you are solely responsible for protecting your keys. However, the roundaboutness presents a conundrum. Because your wallet appears to be controllable on a third-party site, if you are unaware of the information in the articles I linked to earlier in this paragraph, you could wipe out your browser's cache and permanently lose your funds because you never backed up your seed words.

Knowledge vs Responsibility

As those articles get buried by time and content, what happens when new users have that unfortunate experience? Consider the popularity of noise.cash in a world of instant gratification where odds that users aren't reading any instructions are probably higher. When the noise.cash platform was released, it did not have a built-in wallet. I believe this is because the team responsible for both sites (noise.cash and read.cash) shared the same concern due to the fact that platform is more of a social media platform as opposed to this publishing platform. On noise.cash, instead of having a hosted wallet and being able to send tips without using a QR code, the wallet is explicitly the user's responsibility, and to receive tips (from QR tippers and from the system itself), early users only needed to provide a BCH address. This is changing.

Features for the Masses

As noise.cash matures, it continues to add features, and as its user base grows, they continue to request features. Neither of those things are surprising. Likewise, it is unsurprising that an integrated wallet would eventually be introduced to noise.cash. In fact, I believe this feature was planned from the beginning, but in that post, it is immediately clear that the integration at noise.cash differs from the integration at read.cash. See this component of that post:

Brave browser users need to turns off the shields, sorry. We store your private key on another domain to protect it from hackers

Obviously, read.cash doesn't do this, as some comments regarding using Brave here pointed out before I ever saw the post. I wasn't even the first one to question the separate storage on an additional domain, but there was clearly some confusion, so I requested clarification and discussed the implications of this in a comment to that post. Obviously the majority of users would never see a comment to a comment, so it's not problematic that clarification wasn't provided in direct reply to my comment. However, the confusion continues, and users continue to be concerned about the safety of their funds. To that point, the noise.cash talking head has made a follow-up post, but it doesn't really clear anything up for me, because it states both of these things in the same paragraph:

The private key (and the seed phrase) of your wallet is kept on your device only and never leaves it

your wallet (and your private key) is hosted on another domain to prevent theft

Best I can tell, those two points conflict, because at the very least, a private key can't only be on my device while simultaneously being hosted on another domain. If I'm incorrect about that, someone may explain how on my comment to that post, or perhaps in reply to this very article.

Security, Obscurity, or Both

As can be seen in the read.cash article where you can back up your seed phrase in case you failed to do so when signing up or subsequently lost it (first link I made in this article), your seed phrase is stored somewhere. My understanding is that it is truly only on your device, and the code on that page can cause your device to reveal it. To the extent I am correct, that means your keys remain safe so long as a malicious actor or software doesn't gain access to your device and malicious code isn't injected on read.cash. That's security.

Shortly after the first noise.cash announcement post was made, I started digging in a bit to better understand what was happening, and I was able to easily learn which domain was added to store whatever wallet information is stored. I was also able to learn that it was registered through the same privacy-centric domain service as noise.cash and read.cash. I'm not posting specific information because it really isn't necessary for purposes of this article, but I doubt the information I have would put me much closer to attempting to hack in and steal funds even if I wanted to. I don't have a problem with the operator of these sites having privacy, and it is at least a bit less concerning that all three services are are being managed the same way, but that's obscurity, which security experts will argue doesn't add to security.

Regardless, a seed phrase generates an endless string of private keys. To that end, the good news about the conflicting statements in the previous section is that only one private key needs to be stored on a separate server for noise.cash to provide convenience and simultaneously protect user funds from loss by way of clearing browser cache. This appears to be confirmed by the way that part of that comment was worded and again by another follow-up post made for users concerned about whether or not hackers could steal their funds once they provide seed words.

So We're Good, Then?

At this point, it sounds like my funds should be safe on noise.cash, but not necessarily best-practice safe unless I create a separate wallet only for noise.cash and have yet another wallet to manage. I've always managed more than one wallet, but that doesn't necessarily mean I want to manage a separate hot wallet for every service that may operate like this in the future. It seems to me that the most convenient way to deal with this is to use my read.cash seed words on the noise.cash hosted wallet. However, I don't necessarily feel that I have enough information to fully understand the current and future ramifications of that action.

Not Your Keys, Not Your Coins

The heading of this section is the paranoid answer to the question in the post. While I would still have my keys, someone else could theoretically gain access to them as well, and if they were to move my coins to keys that I don't have, then they wouldn't be my coins anymore. I'm sure you've noticed that I'm a bit wordy, so obviously I'm going to elaborate. In trying to understand as many current and potential future ramifications as possible, I came to the conclusion that it wouldn't be unreasonable for read.cash to make a similar move once the hot wallet on noise.cash is proved out. Such a move could even be seamless, as it may be possible for read.cash to include code that causes your browser to provide the seed phrase (or perhaps only the private key of the first address in the derivation path). While I hadn't considered that possibility in this way before, I was already moving funds to other addresses in the same wallet because I like to tinker and I play with coin control every time I merge coins or QR tip. I don't mind QR tipping, so I don't need funds to be on this particular hot wallet anyway. At the same time, if read.cash could do this (and I honestly don't know whether or not they could), a hacker that managed to take over read.cash could do the same thing if I were unfortunate enough to visit read.cash while it was in such a hacked state. Additionally, if I have to provide my seed phrase on noise.cash in order to use the same address there, I'm once again in the dark as to how much risk an action entails. For instance, maybe the processing to a single private key happens locally and that private key is uploaded to the separate server using another layer of public key encryption with no risk at all (so long as the site isn't in a hacked state when I do it), but maybe the entire seed phrase is uploaded using only SSL encryption with processing happening on the other end. If so, it can't be guaranteed that the SSL or remote server couldn't be temporarily compromised when I upload, and it can't be guaranteed that the remote server couldn't accidentally cache something in such a way that it could be accessed by hackers later. These are the thoughts that have motivated me to move all funds off of my read.cash wallet's entire derivation path.

Not Sick, Not Well

This section is entitled with a partial and broken chorus lyric to humor myself and possibly @Abraxas (a music connoisseur who doesn't even know he's waiting for me to post this article). The reference is meant to imply that I am being paranoid, regardless of whether or not "everybody's coming to get me." To be clear, it's most likely completely unnecessary to protect funds from hackers by moving them to a separate wallet if you're using the read.cash wallet on read.cash or even if you use the same seed phrase on noise.cash (outside of defense hackers who actually log into your account with a weak or reused password in order to perform a withdrawal). The amount of funds stored there should probably still be limited as discussed in the same backing up your wallet article I mentioned earlier (again, the first link in this article) where this is stated:

We don't recommend keeping more than a $10-20 in this online wallet.

Even as I admit to behaving in a way that one could classify as paranoid, and even as I suggest that the action isn't entirely necessary, there is more to consider. If we view all of this action through the lens of security best practices, a seed phrase shouldn't be messed with online, even if the online site is trusted and the page where the seed phrase is required does its work offline. Whether that level of security is achievable in a hot wallet and whether that level of security is necessary for a hot wallet could both be up for debate. However, if you want your bank to be as paranoid as possible and you are being your own bank, powered by Bitcoin Cash, then it might be worthwhile to empty your read.cash and/or noise.cash wallets regularly, and that's why I have.