AeroFS (YC S10) exits private beta
blog.aerofs.com
blog.aerofs.com
I've been using it for ~a year or two in beta, as well as all the other alternatives. I still use Dropbox for interoperating with other people who use Dropbox, and for a couple mobile devices which don't support anything else, and I use iCloud for mainly Apple app sync (although it seems to suck for most non-Apple apps) between OSX and iOS, but AeroFS is my preferred option for general file sharing use.
The only downside I've found is dealing with Java on certain OSes (OSX and Windows 7 at times), but generally OS-level Java is fine, it's browser Java which sucks.
See my response here: https://news.ycombinator.com/item?id=5484566
Any chance to open the protocol so other people can work on different clients?
Either one or two lines in the initial part of each post or preferably in an easily noticeable sidebar.
I had to go to the main site before I could figure out what aerofs was.
The grabpoint "AeroFS encrypts your data end-to-end, and only shares your files with those who you invite. Files are never stored in the public cloud." is good, you should stick that into the header, especially for a press release / HN submission where you will be getting attention.
EDIT: heh, that was fixed 46 minutes ago.
1) Launch 2) Onboarding employee 3) Firing employee 3.5) Firing cofounder(s) 4) Getting hacked 5) Trolled 6) M&A offers 7) Running out of cash 8) Raising (per type of round) 9) Board meetings 10) Annual reporting etc.
A lawyer's input would be really helpful for some areas; I'm pretty confident from an entrepreneur's perspective, and from a technical perspective, but while I generally am aware of the laws which apply to me, I'm not qualified or credentialed to give anything approaching legal advice.
It would almost make more sense to do in the Founders at Work style, where you have a domain expert work on each checklist/chapter.
Well, this is actually a relatively different service compared to Dropbox and plethora of other store-your-files-in-the-cloud types. There is no storing of files in the cloud. However, it does the machine-to-machine sync very fast.
a) One of its goals is privacy, but it asks for my first and last name. Why is this needed? I could always lie, but I'd much prefer a single field (e.g. display name) that doesn't explicitly ask for this.
b) It tries to download a .deb file if I'm using Linux. I'd much rather click this myself, and I suspect it does this regardless of whether my system is Debian-based.
c) When signing up, I got no notifications at all. This may be due to NoScript, but I had no indication that my signup was completed. I thought perhaps my password wasn't valid or something along those lines, but I eventually tried to sign in-- it worked.
d) "Non-Ubuntu users can also download the tgz archive." .deb files are specific to all Debian-based systems, not just Ubuntu. Is it fine to install the .deb (which you've tried to download for me) on other Debian-based systems or just Ubuntu? It's unclear.
AeroFS is potentially great, but this isn't the first time I've reported concerns over a, b, and d.
Edit: added d, modified last sentence for clarity
The other problem is the pricing model. If I host everything and use my own bandwidth, what do I pay for ? Software development and upgrade ? This is very expensive for a user with a non profit activity who just want to stay in control with its own data.
Java seems to be a nice way to provide consistent experience across different platforms, I don't even want to think of installing OwnCloud on Windows. And with OwnCloud I'm even more concerned about security as it's written on PHP, but I may be biased here.
Pricing is for Teams only which makes sense, for everyone (teams of up to 3) its free, which is awesome!
Since AeroFS never stores the files, the upload speed must be determined by the upload speed of every team member who is sharing the file, yes?
At the moment, how good is AeroFS at chopping up the bandwidth to get good speeds among, say, four users with upload caps of 1 mbps? How close will it get to 4 mbps?
Do external collaborators help upload on folders they are sharing?
.
P.S. for Ubuntu Unity users: after setup, as with Dropbox, there is one tweak. You need to run the old:
gsettings set com.canonical.Unity.Panel systray-whitelist "['all']"1) I kinda feel like AeroFS has taken so long to come out that Dropbox occupies a huge chunk of mindshare. It's almost as if AerosFS will need to spend a bunch of time answering the "why should I switch" question. That said, I would love to see AeroFS succeed as I am less than keen on Dropbox less than stellar handling of security in the past as well as their general security model.
2) This leads to my second point. AeroFS, please please work with 1Password to do whatever you need to get 1Password+AeroFS working. If this is available, I'm switching right away.
3) Mobile support. Yes, please.
If the target market is enterprise, companies like Box compete there and supposedly have more controls. That said, Box does not have filesystem integration, the last time I checked.
Can't wait to start playing with the team server version! It would be great if I were able to get ad-hoc access to files on the team server from, say, the android app (the same way I do with Dropbox).
AeroFS uses AES-256 with 2048-bit RSA to create secure
connections directly from one device to another. Because
encryption is end-to-end, even we can't see your data or
even file names.
But this does not actually tell me in plain terms if you encrypt my data when it's sitting on your servers or not and that's actually a more important question to answer. Everyone expects data to be encrypted in transit. You don't get extra points for that. Would you mind clarifying if the data is ever on your servers in an unencrypted form?In some scenarios (when two clients are both behind aggressive firewalls, for instance) the data may be _relayed_ by our servers, but in those cases it is encrypted (end-to-end) between the devices syncing using their respective public/private keys, so we can't eavesdrop.
I really hope it's not a homebrew solution but something based off existing protocols. In either case, since the security and privacy is your primary feature, a full disclosure of hos it works inside is a must.
Passwords: we apply scrypt() before any use or storage. We never store the plaintext.
Device-to-device: standard PKI. We have a CA, and the CA's cert is bundled with the client software. Devices generate 2048-bit RSA keys at setup time. They then generate a PKCS10 CSR which our CA signs, provided you give a valid username/password. When peers wish to communicate, they establish a DTLS connection (we use OpenSSL's DTLS implementation, and AES-256-CBC as the default ciphersuite), verifying that the other device:
* is certified by our CA to represent the claimed user and device (identity)
* is not using a certificate with a revoked serial number
* is trusted to send and receive information about the relevant shared folder (authorization)
Device-to-server: Everything between your machine and our servers uses TLS. Where possible, we trust only our own CA. Implementation-wise, we use Java's crypto providers for TLS.Revocation: When you unlink or remote-wipe a device, we mark the certificate associated with that device as revoked, and notify each of your clients either immediately (if they're online) or as soon as they come online and reconnect to our push notification service that the revoked device is no longer to be trusted. (This is one of the other tasks that our servers provide - prompt delivery of device revocation information.)
We update our libraries promptly and are subscribed to the appropriate mailinglists.
Finally, if you believe you have discovered a vulnerability in some part of the AeroFS system, please contact us at security@aerofs.com (PGP key 6E1DC9F9, if you prefer encrypted email).
It has nothing to do with that. Cert pinning is used to mitigate man-in-the-middle attacks whereby an attacker somehow obtains a valid certificate for peer's ID further down the road. If the certificate is not pinned, then the client will swallow a new cert without a peep, because it tracks back to a trusted CA.
Cert pinning is an equivalent of ~/.ssh/known_hosts. It allows me to pin specific public key to a peer and be notified if that key ever changes.
In your case, you might've gone with self-signed peer certs, but that would've obviously require manual verification of the peer's key on 1st contact. This is a bit of UX issue, because few people would bother to actually verify a string of hex numbers between two computers. So, naturally, you introduce a chaperon entity - your CA - that vouches for peer's credentials. I am willing to trust it, but consider it a "weak" trust that I put in place only for convenience purposes and to get stuff going quickly. Later on I may look and compare the key hashes (one provided by peer in an out of band fashion and the other I compute from my own copy of the key) and if they match only then I will know that I have a truly secure connection with the peer and that you didn't lie in your initial peer introduction. At this point I want to pin peer's key, so to be notified to repeat the manual verification process if/when the key changes.
tl;dr - Just add the cert pinning and display cert's public key hashes (mine and peers) somewhere in the UI.
What we've done in the Windows installation is bundle a minimal JRE as a light-weight library. The JRE is loaded by AeroFS at runtime and is otherwise completely isolated, so no dependency exists on Java in Windows. Based on how well that has worked out so far, we'd like to do a similar approach for OSX and Linux soon.
Congrats by the way :)
Do you have ETA for os X and Linux of this "java free" versions?
It's a minor detail, but it seems odd to me.
Now I'd like to know what the MAFIAA can do about that? This is where it's headed anyway, what the world needs is a mass-market darknet software and this sort of thing just might be it, given Dropbox's popularity.
The main reason is because one of my linked computers is a Linux computer. I've tried on both Ubuntu, through the deb package, and Arch, through AUR, and the synching either never happens or happens after a few hours. For the former, restarting the service a few times somehow fixes it, but it's never clear why.
Officially, we only support Ubuntu, but in general we like to have things work for any setup that's not too exotic. Indeed, some of the more helpful bug reports I've looked at and fixed have come from Arch users.
Thanks for the feedback anyway, and let us know if there's anything else we can do. :)
Perhaps it's best not to wait for them to go into public beta in order to report it publicly.
Tahoe-LAFS is a secure storage system (protocol and free software implementation). It does not handle synchronization between devices (only RAID-like replication).
AeroFS is a sync service (proprietary software only). It does not provide any storage, but only syncs data between your devices.
So id need some central always-on server to sync my stuff to, to habe it all synced and secure all the time.
Get dummy html in json request...