Tarsnap public beta
daemonology.net
daemonology.net
Move out of privacy --- privacy is a dead end, nobody has ever capitalized on it successfully (see: the original PGP, Zero Knowledge Systems, that stupid data center in the pylon off the coast of England).
Rewrite your content to focus on shared hosting. Emphasize that you don't keep the keys to the backup data. Consider an OEM deal with a Slicehost-like provider. Backup services at hosting providers fucking blow.
People won't pay much for privacy, but businesses will pay a decent premium over basic hosting for CYA security.
Take your crypto content off the front page; ironically, I think you're decreasing its value by fronting it like this. Instead, brand it: 100% audit-ready, fully transparent, something like that: "the only secure backup provider with [blah blah blah]".
I should have to click to see that stuff. For normal users, they should just see the stamp of assurance and a page they can click to with lots of docs.
I'm a lot less concerned about the clientside security here and more concerned with the serverside --- even though I know intellectually it doesn't matter much, because the security has been factored out to the client. That could mean one of many things, including these two:
(1) People are never going to get over their concern about serverside security and you're going to have to do so something to demonstrate that the server code and associated web apps are secure.
(2) You're not doing enough with your pitch to emphasize that your design moves security off the server and onto the clients, where the customers control it.
How do you do dynamic updates? Spend less time sniping at SSL, because SSL is still the weak link in this system.
Server side security -- you're right, I should probably talk about that more. The cryptographer in me says that there's no need to talk about it because it's irrelevant... but people tend to care about irrelevant things anyway.
What do you mean by "do dynamic updates"?
I'm not saying talk up serverside security; I'm saying, after allllllll that content about crypto algorithms, I'm still left wondering whether I can trust my data to your app. Most everyone else who talks about secure backup is going to leave it at "SSL, plus we encrypt the data on our servers". Your #1 feature is that you do the opposite, but all I see is RSA OAEP.
Also, I'm not saying downplay the crypto; I'm saying, reverse pyramid style, find a way to come up with a brand-y feature-y way to summarize (a) custom crypto, (b) open, auditable design, (c) freely available source code. Then use the crypto details to back that up (on a seperate page).
Dynamic updates: how do you update the tarsnap clientside software?
Consider a name other than tarsnap, too.
* STOP using the word "paranoid". You're not paranoid, you're right (or I'm not paying). Paranoid + merit badge sash of algorithm parameters = vanity project. You don't have a vanity project; stop being self-effacing.
* Consider taking a few minutes to write a positioning statement, then bucket your feature/function accordingly. A no-brainer template for positioning: For {companies,nonprofits,summer camps} that need {puppies,secure backup,surface mount soldering}, Colin Percival offers tarsnap. Unlike {mozy,carbonite,idrive}, tarsnap provides {block level security,puppy mincing} that allows users to {save the world,make better tacos}.
* Along similar lines, "my dream backup system" probably not the best positioning ever. Maybe kill those words. =)
* One feature you're probably unwilling to play up is that you're actually (probably ;) qualified to design a custom cryptosystem. Get some cryptofriends to vouch for you!
I don't. Users do (by downloading the latest version, extracting the tarball, compiling, and installing).
Actually, you're right that I depend on SSL for this at the moment -- but I will be adding GPG signatures for the tarballs soon.
Consider a name other than tarsnap, too.
What's wrong with that name? In all seriousness, the people who would be turned off by that name are also people who would be turned off by the command-line interface.
Yeah, and, about that...
Also, from your example, I've crafted the perfect position statement: For summer camps that need surface mount soldering, Colin Percival offers tarsnap. Unlike carbonite, tarsnap provides puppy mincing that allows users to make better tacos
After reading that, I'm buying tomorrow.
This is a problem: successfully cornering the market for disassemblers and selling to ever security research team wins Hex-Rays literally thousands of dollars!
If you're going to craft a product pitch that appeals to the very high end of the market --- those comfortable with per-host command-line backup who care very intensely about security --- you may need to price way higher than where Colin is today. Of course, then he'll find himself in competition with homebrew PGP+S3 scripts, just like IDA would quickly be replaced by a web UI on "objdump" if Ilfak jacked the price up to $20,000 (which is kind of where it belongs, value-wise).
I'm also wary of the history of "premium" command-line backup tools; remember Bru?
Unless he's not out to make money. Some people aren't. He's a FreeBSD dev, after all. Sucker. :P
I started with *nix and a command-line interface for two reasons: 1. This is what I know, and 2. a CLI can be far more easily used as a component of a larger system.
I'm following a fairly standard startup course here: Build something people want, then build something more people want. I expect a GUI to happen in the future (probably using Qt). I expect a Windows version to happen in the future. I expect tarsnap to be included in web server management interfaces in the future. The name might change in the future, or "tarsnap" might just end up being one of the names like "google" which start out looking dumb but end up sounding normal.
But that's all "easy" stuff -- the place to start is with a solid and secure foundation, which is what I'm doing.
See also: github
How fast is your internet connection? On a decent CPU the tarsnap code can easily push 50 Mbps -- the largest part of its time is spent in zlib, compressing data before it is encrypted and uploaded -- so the limiting factor is almost certainly going to be bandwidth.
I wonder if you could make this into a simple off-site backup system for databases.
Tarsnap isn't likely to be useful for "real time" replication, but if you get your database to write a transaction log you might get interesting results by having tarsnap loop creating archives containing that one file.
On modern CPUs, somewhere in the 20-50 MB/s range.
Do you keep a local cache of block checksums or something to avoid having to check the server?
Yes.
How about an option to not examine the data if the file size and mtime haven't changed? (like rsync does)
Tarsnap already does this for unmodified (file name, inode number, file size, mtime) tuples.
edited for clarity
I saw the "well-respected" part before, but didn't notice the "yc-er" part. To avoid any confusion: I'm not funded by YC, I just happen to have been on news.yc for a long time.
481 days ago. http://news.ycombinator.com/item?id=35083
No hard feelings, I hope.
More than anything else, I'm amused that people here care so much about the Putnam -- I personally consider winning the Putnam to be a relatively minor accomplishment.
Rather than allowing in Canadians but worrying about making sure that I figured out how to deal with GST before I hit the limit, while still keeping BCers out, I figured that it was simpler just to keep all Canadians out.
It looks like cool technology, but the packaging is all wrong. A command line tool?
I'd build a seamless front-end a la JungleDisk and bill it as an online safe deposit box -- nobody but you has the key.
Just my $0.02.
The per-transfer and per-storage fee sounds like tarsnap also stores back to s3.
You have at least one entrenched, successful competitor with lower prices and more features. This proves there's a market, but it means you're also going to have to be good at marketing to succeed. Especially because the product is something people are very risk-averse about and the switching cost of re-uploading everything is a big pain.
You might enjoy the book The Knack: How Street-Smart Entrepreneurs Learn to Handle Whatever Comes Up by Norm Brodsky and Bo Burlingham. There's a lot of war stories from author Brodsky about his document-storage business (a similar market to yours) and how he differentiated it from competitors.
How would this differ (other than the price)?
2. Snapshotted backups. With tarsnap you can take a backup every day, but only pay for each unique block of data once -- which is useful if you don't want your nightly cron job to "synchronize" the fact that you just accidentally deleted some files to S3.
3. I don't know all the details of how s3sync works, but how efficient is it at handling files which have had small changes made to them? (Or, in the case of log files, data appended to them?) Tarsnap doesn't have to re-send the entire file.
4. Does s3sync compress data before storing it? Tarsnap does (and you pay for the bandwidth and storage used, post-compression).
5. When looking at the price, keep in mind that S3 has a per-request fee which can get pretty expensive if your average file size is small.
While we're giving marketing advice, shouldn't that be "source-based de-dupe"? :-)