I can't answer authoritatively, but I have some observations that suggest they're stored in the cloud.

I have two Ledger Nano S devices. One is a hardware backup of the other. During initial setup, I ran into a weird bug with the Chrome App that made one of the BIP32 chain accounts incapable of being labeled. The UI rendering appeared to crash when it tried to display a null label, so the button you'd press to change the label never showed up. The callback that changed the account's balance from the default of zero to its true balance didn't run, either, which was momentarily very alarming.

Anyway, I hoped that the labels lived on the device, so I hard-reset it and set it up again. The prior labels (including the null one) returned. My working theory at this point was that the labels lived in the cloud, but there was also a possibility that they were stored in the Chrome App's local synced storage. To test that theory, I set up the second Nano with the same BIP39 seed using a completely different Google account. The prior labels still appeared on the second wallet. This ruled out storage in the Chrome App. The only place left to store the labels would be the cloud.

So based on this evidence, my theory is:

• Ledger runs a cloud key/value storage service.
• The key is probably a hash based on the BIP32 xpub for the account.
• I hope but can't prove that the value is symmetrically encrypted with something based on the account's xprv. If it's sent or stored in cleartext, then the Ledger team has a lot of very private data about user accounts ("Spending money," "Illegal stuff," "I am Satoshi," etc.).

The service could also have access to account balances, but that's a risk that comes with any wallet connected to an online computer.

By the way, I fixed the null label bug by opening the Chrome App's developer console, confirming that it indeed was throwing an exception, and then modifying the in-memory code to add which got me far enough to get to account settings, where I was able to set the label for real. It persisted after that and all was well.

The ChromeOS platform is capable of supporting your Block Erupters, but you'll have to write an app. A Block Erupter uses the CP2102 USB-to-serial bridge, and Chromebooks do recognize that chip (I just checked; it appears as a serial device under /dev/USB0). The Chrome Apps platform offers a serial API that you can use to communicate with the device, as well as a socket API in case you need something more sophisticated than XHR for stratum server long-polling.

The rest is a small matter of writing the mining client. While that's not a small task, it's completely doable with ChromeOS platform, and what would be pretty cool about it is that you'd have a cross-platform (Linux/Mac/Win/ChromeOS) controller for CP2102-based mining hardware, and if you ran your Block Erupters on a Chromebook or Chromebox, you'd have the extra peace of mind that malware wasn't going to steal your Bitcoin.

Perhaps the domain I picked is too short, and it looks like an URL shortener (which I agree automatically looks suspicious). I picked something very short at the expense of readability because I figured all the email addresses (like mine, 1BUGzQ7CiHF2FUxHVH2LbUx1oNNN9VnuC1@b1txr.com) would be unreadable anyway, so they'd always be copied or linked rather than read out loud from person to person.

At least the GitHub issue link survived. If you're a Ruby coder you can take a look at the patch, which I thought was pretty interesting.

I hope that the Bitcoin signing feature gets more popular, because it's really useful. So far the feedback I've gotten on the site from my coworkers and friends has been, basically, "neat site, Mike, but I can't figure out how to sign something in my Bitcoin client." It'll be hard for me personally to improve the usability of the Bitcoin client's signing feature, but I hope that use cases like b1txr's become more commonplace, as they'll drive improvements in the client UI.

Looks like the earlier post got chewed up by the spam detectors. Anyway, I'd appreciate some testers. Please send email to a Bitcoin address you control at the dot-com address listed in the subject line, and then try signing into the site to confirm that the email arrived. I'd appreciate any and all feedback, particularly on the usability of the sign-in process. Thanks!

I'd appreciate some help testing a site I built this weekend.

/]b1t[Suspicious link removed] lets you receive email address at your Bitcoin address. For example, if you control 1ABCdefghijklmnopqrstuvwxyz, then you can read the mail at the inbox 1ABCdefghijklmnopqrstuvwxyz@b1t[Suspicious link removed] (and, of course, anyone can send to that address). I extended bitcoin-ruby to add compact-signature key recovery, which both lets you prove ownership of a given Bitcoin address and replaces username/password sign-in completely on the site.

The use case I was mainly thinking of was something like Mailinator, but where you would know that you and only you could read mail at a given address. If the site catches on, however, it could become a de facto place to ping someone whose public Bitcoin address you know.

The site is new and not well-tested. Some of the caveats:

• As with all webmail, you must trust the operator of the site not to read your mail. You don't trust me, so please don't send critical or sensitive email to any address.
• Along the same theme, the site is an experiment and I might shut it down. So for now, don't rely on these email addresses existing for any period of time.
• It's hosted on Heroku with the developer plan. There isn't much storage space, so it'll be pretty easy for the system to be overloaded. Send an attachment of any size and you'll kill the site. Again, don't trust this site with mission-critical email.
• I am very interested in feedback on the sign-in process. I'd like to learn whether Bitcoin signatures could become a viable substitute for username/password-based sign-in flow.
• Finally, to repeat the warning above: please don't trust that this site is in any way secure. The site surely has bugs that might enable others to abuse the site. I'll try to fix those bugs as I learn about them, but at the moment the site isn't well-tested.

Thanks in advance!