Taylor's S4 Usability Notes

[defuse]

This ticket documents my experience signing up for and using S4. I will avoid making any recommendations, and only describe my experience, since there are multiple solutions to all of the issues I encountered, and what will fix it for me probably won't fix it for everyone.

This was written a day after signing up for S4, based on my memory of what happened.

Background

When talking about usability, it's important to understand who the user is. So here's a brief list of things about me that are relevant:

• I know how to write code and I write a lot of it.
• I have lots of Linux sysadmin experience. I've set up Apache, Bind, Postfix, Dovecot, etc. many times and use Linux on all of my PCs.
• I read the Tahoe-LAFS paper a few months prior to signing up, so I know the basic idea of how it works (i.e. I understand capabilities).
• I read some of the "marketing material" on tahoe-lafs.org a few months prior to signing up.
• Never really used tahoe-lafs before.

  Signing up for S4

Signing up for S4 was easy, $25/month seemed like a good price. The first thing I did was multiply $25 by 12 to see how much it would cost per year ($300), which is reasonable (I'm used to paying $100/month for a dedicated server, though, and I know that biases my judgement, since before I started doing that I used to think $20/month was a lot).

I already use Amazon S3 for backing up about 15GB of data. I do this with a cron job that, every month, compresses it into a .tar.gz, then pipes it through GPG, encrypting it to a public key, then uses s3cmd to upload to Amazon S3. This works, and it costs me less than $1 per month. But I'm willing to pay $25/month if S4 is going to be more convenient and possibly more secure (By the way, I really want RAIC...).

After some false starts (my signup wasn't processed properly so Zancas cancelled it and had me re-sign-up), my signup was processed. Zancas sent me a broken PGP-encrypted message that was sent to an anonymous recipient, so my GPG tried to decrypt it with all of my private keys, asking me for the password of each one (This should be filed as a bug in GPG). I finally got it decrypted and found my furl (I had no idea what a furl is, but I understood from the context that it's what hooks Tahoe-LAFS up to my S4 service).

I was super confused until I found the How To Configure page. I found it by Googling, but apparently a link to that page was supposed to be in the email I was sent.

Setting up Tahoe-LAFS

When I installed Tahoe-LAFS, I ran apt-get install tahoe-lafs. I was worried that the webpage warns to check the version number, and that I have an old version (1.9 instead of 1.10). Are there security vulnerabilities in 1.9 that haven't been fixed in 1.10? Who manages security patches for old versions? I'm also worried by the number of dependencies that are coming along with it. I force myself past these fears and continue on...

Following the How To Configure page, I began setting up Tahoe-LAFS.

Adding the furl to the configuration file was easy, but I wondered:

• Do I have to keep the furl secret?
• What happens if an attacker gets my furl? How do I change it? Contact support? Will they respond fast enough?
• Do I need to do this as root? Should I do this as root?

At this point I realize S4 is definitely a power-user tool. From the looks of the LeastAuthority.com homepage, I was kind of expecting something with a nice user interface, like Carbonite. It's okay, though, I can handle it.

The rest of the setup went smoothly, except I was confused by the aliases part at the bottom. I ran the commands, but I didn't really have any idea what I was doing.

I've made it to the Tahoe-LAFS web page, and can finally start using it...

Using Tahoe-LAFS on S4

Now I'm really super confused.

I click "Create Directory" and it brings me to a directory. I see SI=wkvco in the header so I assume that's the directory name, and that I need to remember that thing to get back to the directory. I see that I can create subdirectories and upload files. Cool.

Oops. I closed the window, and now I want to get back to the directory. I have the SI=wkvco thing, so I try pasting that into the "Open Tahoe URI" textbox, but I get a message that says:

GET unknown URI type: can only do t=info and t=json, not t=.
Using a webapi server that supports a later version of Tahoe may help.

Okay... So I create a few more directories... SI=yeuox, SI=akr6r, SI=4r45b... yeah, that thing is changing every time I create one, so it must be the directory name. I'm really confused, so I ask on IRC. Then, I click on "More info" and, totally by accident, I realize that the writecap is in the URL! It clicks: To get back to the directory, I have to remember the URL with the writecap in it. If I hadn't read the Tahoe-LAFS paper, I would have never figured it out. Then, also sort of by accident, I realize I'm supposed to paste the writecap into the "Open Tahoe URI" box on the welcome page.

Note: The "Open Tahoe URI" box obviously wants me to give it something called a "Tahoe URI", but I am never given a thing called a "Tahoe URI". I'm given a "Directory writecap" that begins with URI:DIR2:n2cz... but nothing helps me understand that that's a type of "Tahoe URI".

I still have no idea what the SI=yeuox thing is for, or why I need to see it.

I also don't know what the difference between immutable, SDMF, and MDMF are, and I don't know where to find documentation about that (so I just select SDMF for everything).

I'm concerned that putting the writecap in the URL is dangerous. Good thing I'm using private browsing mode, or it would have gone into my browser history. This was a little off-putting, since I know the same functionality could have been implemented without it ever showing up in the URL.

I use the web interface to upload and download files. That all works well (except for one time an upload timed out around the same time I created a directory... possibly a race condition).

I started playing with tahoe on the command line. After a lot of trial and error, I figured out how to pass writecaps on the command line (at first I was passing the entire URL to the web interface, which obviously didn't work), and I figured out how to upload and download files with tahoe put and tahoe get. It was really trial-and-error, since the manpage doesn't say what arguments any of those things take.

I tried tahoe backup, then looked at the directory in the web interface. Cool. Then, I wanted to "restore" the backup, but tahoe restore doesn't exist, so I give up on that (I think to myself: I guess I would have to download the files through the web interface). After seeing rename "tahoe backup" to "tahoe snapshot", I realized I needed to use tahoe cp -r, which worked.

Despite the problems, now that I finally understand what's going on, I'm really impressed. This is really cool.

Afterthoughts

The sections above are a rough approximation of what I went through after signing up for S4. This section is a bullet-point list of things I'm now thinking about S4, while considering if I should keep paying $25/month.

IMPORTANT NOTE: I may be mistaken or naive about some of the things I say here. However, even if that's the case, I think there is still value in it, since other people might be mistaken or naive in the same way.

Security

I was not warned that passing things on the command line was insecure. Of course I know it is, but it didn't become concrete in my mind until I'd already compromised a bunch of writecaps. There is a warning in the known issues document, but I was never told to read that (or even that it existed). Minus 10 points for not being warned.

Not only am I worried about other users seeing my writecaps in the output of ps, I'm also worried about secrets going into my bash_history. I have different "security levels" inside my system, and my bash history is in the outermost (least secure) one. For example, I have a TrueCrypt volume that is only mounted when I need to work with the files inside it. If I want to put some of those files in S4, I can't do that without leaking the capability URIs to my bash history file, which is in a less-secure "part" of my computer (I know I can put a leading space to prevent it from going into the history, but I'll forget to do that). I can't use aliases, either, since the alias file is in the less secure "part" too.

Note: I am the only human user of my system, so I don't have to worry about humans SSHing in and running ps to get my caps. However, I do rely on unix user separation as a second line of defense. For example, I allow git-over-ssh to a special low-privilege "git" user. If there is a vulnerability in git-shell, then an attacker might be able to run arbitrary code as that user. Similarly, if someone hacks my web server and can run arbitrary code as www-data, I don't want them to get my caps.

So: I consider having to pass caps on the command line to be a massive inconvenience, if not a security vulnerability. I was disappointed to see that a ticket for this has existed for 5 years and it still hasn't been fixed. Minus 100 points.

I'm also annoyed that the writecaps are in my browser's URL bar. This doesn't bug me so much, though, since I use private browsing mode everywhere. I can imagine someone pasting the writecap into the "Open Tahoe URI" box all the time, and not realizing that every time they do that they're leaking it into their browser history. Minus 5 points.

I'm also worried that the service is listening on localhost, so that other users of my system can interact with it and use up space. I'm not too worried about this, though, since there is no storage space limit and I'd be very surprised if the web interface was vulnerable.

Usefulness to Me

I was shocked to find out that the ciphertext I upload never gets deleted. Knowing this, I am scared to upload anything. What if I upload 100GB of data by mistake? What if I'm accidentally using 10TB of storage, but only actually use 100GB of it? I know that as a customer I have unlimited storage, so I shouldn't worry about it. But I worry anyway, since I would feel really bad if I was wasting space. I think not knowing how much space I've used is the worst.

I was thinking of hacking my S4 service into a file transfer thing, so that I can share files with friends by sending a readcap, but that would waste a lot of space.

I want to use S4 for automated backups. I want to have a cron job that runs tahoe backup regularly. However, I want to do this without storing access credentials anywhere on my computer. Currently I'm encrypting my backups to a public key, so that the decryption (private) key doesn't need to be on my computer at all. I don't know how to do this with S4. I think it's impossible because a writecap implies a readcap.

[zancas]

I don't understand exactly which functionality/what feature(s) make Taylor willing to pay an extra $24/month for S4 over tar-GPG-s3cmd ?

[defuse]

It looks like the PGP issues I had are going to be resolved with the PGP signup automation :)

[defuse]

Summarizing:

• Tahoe-LAFS usability:
  • Non-intuitive web UI (especially creating directories, how to get back to them).
  • What the hell is the SI=yeuox thing? Why is it so prominent in the UI?
  • Disassociation between "Tahoe URI" and "writecap" in UI language.
  • Needs in-page documentation explaining mutable/immutable/capabilities/etc
  • Increase public awareness of Tahoe-LAFS, so that people come in to S4 already knowing about it. This will help solve other problems, like Tahoe-LAFS not being cited where it should be in cryptocurrency research. Ticketed: #294.
• Tahoe-LAFS security:
  • Don't put caps in the URL
  • Same functionality can be implemented with POSTs, or cookies.
  • Don't require caps on the command line (prompt or read from file).
  • Web interface listens on localhost. Any process running locally, including untrusted ones, can interact with it and use space.
  • Implement write-only (no read) caps, so that the backup script doesn't need to know the decryption key.
• S4 Usability / Security:
  • Point users to useful documentation after they sign up, and in the confirmation email. Ticketed: #295.
  • Warn about caps in URLs, on command line, etc.
  • Document explaining what Tahoe-LAFS is and how to use it (I bet most of our customers have no idea what Tahoe-LAFS is until they sign up).
  • Tell users how much space they are using. Even if we're willing to support hundreds of terrabytes of accidental over-use, not knowing is still a psychological barrier, and makes me afraid to use the service. (#296)
  • For the same reason, allow deleting ciphertexts (I beleive other customers have asked for this as a defense-in-depth measure when a cap is leaked) (#297).

[defuse]

I pulled all of the leastauthority.com-ish issues into their own tickets. The remainder should go in Tahoe-LAFS tickets. I'll see about doing that.

[defuse]

I just set up Tarsnap for the Zcash project's server, and I liked it a lot better. The main reasons are:

• You just say "back up this directory" and it will do it. You can repeat that command as often as you want, and Tarsnap takes care of compression and deduplication for you behind-the-scenes.
• Configuration is super simple. You just run a command to register a "machine", which spits out a key, and everything you backup using that key is tied to that "machine." (I'm putting "machine" in quotes because you can think of it as an abstract concept, not as a single physical machine.) Compare this to the process of obtaining a furl from Least Authority and having to edit a config file. It's easy to derive a write-only key from the master key, so that you can effectively have append-only backups.
• You can delete things. And, you don't have to worry about what you're deleting. For example, even though future backups are deduplicated against past ones, you can safely delete past backups without worrying about breaking future ones.

edit: I had a parenthetical remark in the wrong place

[zancas]

It seems like these bullet-points should be made into github issues with a label like "feature request"... perhaps.

[zookoatleastauthoritycom]

Thank you so much for the usability notes, Taylor! I agree it would be good to make a separate ticket for each separably-implementable (or -rejectable) thing.