n0on3

I apologize but there is no such thing as "it is (ALWAYS|NEVER) a good idea" no matter how many blog posts people wrote about that.

It just depends on which are the tradeoffs between the antithetic goals that you have when you do any kind of security hardening.

Aside from that, since many already mentioned port knocking as another layer in the pile of this game, let me point out that not all port knocking (-like) implementations are that weak, look e.g. at knockknock [ http://www.thoughtcrime.org/software/knockknock/ ].

Nice piece; unfortunately it's not just about MS Word. It's pretty common for inferior/hurtful-in-the-long-term products to get leading positions in the market and become "unavoidable". The first easy guess is that marketing people are doing a great job for these products; the second one would be that the majority of us are too stupid/busy/unwilling-to-consider-long-term-consequences to spot their game and go for smarter choices. TL;DR: Please run humanity.upgrade(), we would think about their word processors l8r (:

Think about this: iOS7 brand new interface sucks so much that on previous iPhones it lags EXACTLY like poor Android-based devices

yes, right, the world definitely need another linux distro that fails at pretending being even close to the reasons why people actually buy and use Macs and PCs. Bah.

you know the kind of solution you come up with when you just realized you made some terrible mistake and adrenaline keeps flowing no matter how much you try to stay calm? this is exactly how this post looks like to me. Don't get me wrong, you are damned right. But unfortunately it's nothing new, we saw similar trends in the past with other media and you know what.. people will read your piece, say you are brilliant, then forget about it and keep doing what feel more comfortable to them, which in the end it's just the way they learned to live. Nodejs, HTML5 and CSS3.. seriously? Well done catching the problem in its n-th instance, but encouraging people to develop tech skills to avoid something they don't fully understand is not really going to help. unfortunately.

Good question, difficult answer.

We are doing our best. So far, the performance and usage-of-resources are not the fields where we put the most of our effort. Additionally, there are two main issues to consider:

The first is about our security features: encryption and integrity check require some computation, hence our clients will have an higher load compared to Dropbox. Moreover, some of the magic performed by Dropbox to improve performance, cannot be combined with some of the security measures that we enforce.

The second is about the firepower of and age of the products you are comparing. Dropbox has a quite large and amazing team ( https://www.dropbox.com/about ) as well as few years of product development and testing on a large and impressively growing user base. The comparison with our team ( http://blog.filerock.com/founders/ and http://blog.filerock.com/dev-team/ ) and our time on this project so far, would be like throwing a cobble to the Ayers Rock and see who moves.

We are aware of the feature you mentioned: for instance, we already went for the filesystem monitoring using the API provided by the different platforms, but it turned out that they didn't behave as we expected on all platforms, in particular they made hard to get correct results needed by our integrity check technology. So we had to choose where to concentrate our effort and decided to put it on our distinctive features. So we switched to a simpler (and inefficient) approach that currently guarantees the correctness we need on each supported platform. As soon as possible, we plan to mix our current approach with the aforementioned usage of the different platform APIs to increase performance but still keeping our integrity check mechanism working properly.

Of course in the long term we aim to be as efficient as possible, and Dropbox is definitely the one to run after on this perspective. However, this will need time and resources. The good news is that having an open source client, anyone can contribute suggesting an improvement, or even implementing features that are not yet in our short-time roadmap (e.g., on-LAN files sync).

"[…] You might not trust Companies with your data either, and you shouldn't be forced to in order to store it in the cloud". That is exactly our goal: we don't like to be forced to trust companies for the security of data, so we are developing a service where users actually don't have to trust even us… although some trust in the encryption algorithms used will be required, given that you can see the implementation of course.

you might want to look at this ( https://news.ycombinator.com/item?id=5033540 ) comment on why the PBKDF2 is sent for the authentication rather than the password.

As far as concerns the usage of TLS, your guess is correct, right now we allow the usage of the most common cipher suites, with some of them not providing PFS.

However, the negotiation of cipher suite is just a matter of configuration, and we might take a closer look pretty soon on which ones we want to allow or not.

Apologies if the title of the post is not clear, I should have specified that it was only about the client. You are right, one of our main goals is to prove that our security is "for real". However, we also hope that our open source client might be useful to other projects, as well as for developers to fork it and implement themselves what is out of our scope.

the point is that in FileRock, several things depend on your password, and some of them must be kept confidential and never sent even to the FileRock servers.

You are right, from the only point of view of the authentication, using a password gives you the same level of security as using one of its derivations (given a deterministic generation of the derivations and a password with same length and randomness of its derivations).

The mechanism that actually protects your credentials from being sniffed and used to get the first level of access to your account, is the industry standard SSL/TLS.

But even if someone discovers which is the derivation that you use to authenticate with the FileRock servers, they won't be able to know your password. And that means that the other derivations of your password (for example, the one used to protect the encryption keys for your data) are not disclosed as well. Therefore, even the people managing the FileRock servers will not know them, and they will not be able to access your encrypted data.

I hope this will solve your doubts.

PS: I see now that evv and notimetorelax also replied and they are correct.

good point. For different things we kept it quite simple, but soon we are certainly going towards these refinements and your suggestion sounds pretty good imho

Just in case the slashdot effect strikes, direct link to the source code on GitHub is: https://github.com/filerock/FileRock-Client

In the spirit of the service it's the only "stuff" that matters: when it comes to security checks, the FileRock client does not trust our servers :-)

Re-implementing crypto functions is generally a terrible idea, unless you really know what you are doing (and most likely you don't). There are so many different relevant factors to consider, that single individuals or organizations are really unlikely to be able to cover reasonably close to completely. That's why standards and "well known" algorithms are a good choice.

Also, "security through obscurity" is well known as a worst practice for crypto (probability that the algorithm will be reverse engineered or disclosed is all but negligible), so definitely not a good reason to implement any new algorithm.

The thing is: (blogging|writing)-about-/publishing- code takes time. And time is really what people doing amazing stuff are short on the most. Don't get me wrong, both discussing and publishing are amazing, but often life is just too short for the blah blah blah, unless you have good reasons for doing that.

Hackers love complexity. Others just don't. Understanding differences between two (especially "difficult") things means at least having a vague idea of what each is about. And regardless how you find that interesting, almost any non geek/curious/techie will not give anything about both "what (general-purpose) programming is" and "what whatever-complicated-thing-you-do is instead". Unless they have any specific reason to put some effort in it.

"I've never seen this kind of reaction for the death of any famous person who isn't a [...] community leader." < Fact is, he was :) ..at least sort of..

The whole CA trust model is a complete mess. I suggest interested people to google for the work from moxie marlinspike (@moxie__), e.g., presentation from last BH (http://bit.ly/rbqMCq) and convergence (http://convergence.io/).

Cool :) nice work!

By the way, on safari 5.0.5 inserting the map widget into the iphone leads to a blank page, while the browser widget is unremovable when inserted.

Take a look at point 5.2 of the Term of Use. Link: http://amzn.to/eeSaB3 Quote: " 5.2 Our Right to Access Your Files. You give us the right to access, retain, use and disclose your account information and Your Files: to provide you with technical support and address technical issues; to investigate compliance with the terms of this Agreement, enforce the terms of this Agreement and protect the Service and its users from fraud or security threats; or as we determine is necessary to provide the Service or comply with applicable law." ... not that encouraging imho.

Be direct, honest and keep it simple. That means, (1) be very clear on your abilities and expectations, (2) don't make them loose time, and (3) if you want to know whether they are looking for / would be interested in someone like you for an internship or not, just ask.