Drobo

Who here wants dropbox for the DroboFS?

Hi everyone,

I think I have a way to get dropbox running on the FS. But for this I’m gonna need your help.

Here is the situation:

  1. Dropbox is awesome. Hands down the simplest and friendlier file sync tool out there.

  2. There is no ETA on an client for ARM. Although people are voting for it (and if you haven’t, you should), the dropbox developers seem to be dragging their feet about this port.

  3. There is, however, a linux client for 32-bit Intel chips. They even tell you how to configure it on a headless server (i.e. only shell access).

At this point, you may be wondering: couldn’t I just run the Intel version on the DroboFS? And the answer is no, yes, and then no again.

  • No, you can’t just run binaries from one platform (Intel) on another platform (ARM).

  • Yes, there is an open source software emulator that allows you to run binaries from one platform on another transparently. This is called user space emulation. At this point you should have a light bulb going on… “can’t we run dropbox using this qemu?” The answer is yes, we can. But then…

  • No, QEMU has a bug that breaks user space emulation on the specific CPU type of the DroboFS so badly that it does not work at all.

You can imagine that this solution is so close to work that I can almost taste it. I already have QEMU cross-compiled, I already know of all the libraries that the dropbox linux client needs, but unfortunately this bug is killing the dropbox process before it can initialize itself.

This is where you guys come in. The bug report can be found here. If you want dropbox on the FS as bad as I do, then please create an account on launchpad, and help me convince those guys to prioritize this bug.

Note: Please be nice to them. In our attempt to persuade them to fix this as soon as possible, we absolutely do not want to spite them.

OxygenCloud (as easy as DropBox in my estimation) has DroboFS support, have you tried it? The Drobo tool is only available to paid business accounts presently, but I heard it’ll be available later this year (unconfirmed)

I’ve been a long term dropbox user, but gave it up this year in lieu of the Drobo only (which is why I asked for Git support - thanks again!) Dropbox had a long adolescence, now (of course) has huge security issues, and ultimately is mucking with my data without my direct supervision. Anyhow …

I have OxygenCloud installed. In fact, you can beta test the whole package today if you have a private .com domain.

The problem with the Oxygen solution is that it is not nearly as transparent as the Dropbox solution. Dropbox integrates with the existing filesystem. Oxygen creates an opaque container (apparently encrypted) on top of the filesystem. In fact, the client I have for the Mac mounts the Oxygen space as another storage device, while the Dropbox client allows me to symlink all the folders that I want inside of it.

In other words: I could replicate the way Oxygen works with Dropbox by just creating a Truecrypt container inside the Drobpox. It would work about the same, just being a bit more tricky when files are being accessed at the same time on different machines (which is not my case).

Finally, the Dropbox business model is clear by now: they sell storage. The business model of Oxygen is still quite unclear, and no one is really sure how they are going to charge for it.

I’m not sure about the security issues that you mention. Is this what you are talking about? If it is, then keep in mind that this “flaw” has been utterly debunked. See here for a lot of good commentary.

Quick edit: I’m glad that Git is working for you, but I absolutely hate having to remind myself to “check-in”, “commit”, “merge”, “publish” or whatever the lingo is on today’s revision control systems is. If it is not automatic, running on the background, and event-based (i.e. happens only when a file is actually changed, not on a fixed schedule), then it is too much bother.

(I know, I know, this coming from the guy who cross-compiles stuff for a hobby…)

Thanks for the info, I’ll check that out.

[quote]Quick edit: I’m glad that Git is working for you, but I absolutely hate having to remind myself to “check-in”, “commit”, “merge”, “publish” or whatever the lingo is on today’s revision control systems is. If it is not automatic, running on the background, and event-based (i.e. happens only when a file is actually changed, not on a fixed schedule), then it is too much bother.
[/quote]

Previously I was using Drobox for all my projects. I jump between machines (a few laptops and a desktop) and would keep projects synced between them using DropBox. A few problems with this, one is that you don’t want ALL files synced in a project. Specifically project window configurations, for example. On the Macbook Air I want windows one way (small screen), and on the 17" macbook pro another (BIG). Desktop entirely another thing. After a while of running I would get large numbers of conflicting copy files running around - not good, not professional.

Finally I realized I was being dumb, that’s what VCS is for, precisely controlling file versions. If I was worth my salt I’d be doing all that with a real VCS, not a pseudo VCS system such as DropBox. The point being is that this is my work and I should be manually and precisely handling the changesets myself.

On reminding yourself to checkin/checkout I don’t know any systems that do that automatically. Oh - I see, you like the DropBox style ‘pick up every edit’. I get it, problem with that is a) you can’t really trust they’ll have all your history and b) you don’t really want all your history. Editing source code is my life, I gotta keep on it :slight_smile:

Fair enough. I don’t think that the dropbox guys ever tried to sell their thing as a VCS, but I can see how it is tempting to use it in that way.

You hit the nail in the head. The stuff in my dropbox is mostly working drafts for unpublished papers, a collection of PDFs of references, assignments from my students, and a small Eclipse workspace for my experiments. I do need a small history (used mostly in case of accidents), but certainly it makes no sense for me to store every single change ever made on any of these files.

Also, the fact that I can easily share a folder with someone else (for instance when co-authoring something) is a huge plus. I don’t think I could convince the Mac users around here to drop to a command-line… :frowning: and I value my sanity too much to try to coordinate these things over email.

I’m just going to put it out there and say that I too would love dropbox to sync on my DroboFS.

Then please go to that website, register and click the link on the bug page that says that the bug affects you, and subscribe to it.

By doing so you increase the “heat” on the bug, making it move visible to developers, and hopefully convincing them to fix it faster.

Added my vote to the launchpad and dropbox lists. Dropbox would be fantastic for DroboFS.

So, here’s an update on dropbox for DroboFS.

Apparently the bug has been solved. In fact, if I compile qemu-0.14.1 with the patch presented here (http://patchwork.ozlabs.org/patch/45206/ ) I get a version of the qemu binary that seems to “work”. And by “work” I mean it launches simple apps.

When I try to start dropbox, however, it goes to 100% CPU usage, and seems to get stuck. Launching it with -strace shows that the dropbox executable gets stuck in an infinite loop containing these calls:

10359 clock_gettime(0,1169900288,135693248,1,0,1169900372) = 0 10359 futex(0x081683c4,FUTEX_PRIVATE_FLAG|FUTEX_WAIT,1,0x45bb4300,0x081683f0,135693296) = -1 errno=110 (Connection timed out) 10359 gettimeofday(1169900364,0,0,1,142600008,1169900392) = 0 10359 futex(0x081683f0,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,0x081683f0,0x087fe748,142600008) = 0

Long story short, ‘futex’ is the dreaded syscall 240. This google query gives you an idea of the scope of this problem: https://encrypted.google.com/search?q=qemu+Unsupported+syscall:+240

It seems that this specific syscall (240) is not implemented for i386 targets, meaning that the futex syscall simply does not work. In other words, the executable that I have right now is able to run apps that use the threading library, but fails as soon as the apps actually try to share data between threads… :-/ It is a bit of a ridiculous situation, because it does not matter which host you are using: you simply cannot run i386 binaries because the target code does not support it.

I’ve searched around quite a bit, but I have not found a 3rd party patch that provides an implementation. Unless someone can find a patch that can be applied to the 0.14.x or 0.15.x versions of qemu, I guess this project is not going anywhere until the qemu guys actually implement syscall 240 on i386 targets.

A very short summary of the problem can be found here: https://bugs.launchpad.net/qemu-linaro/+bug/758424

It’ll need encryption implemented at some level. Dropbox is insecure, I wouldn’t trust any of my data with these guys.

Which is a completely orthogonal concern to actually making dropbox work.

Many people have suggested using a Truecrypt container to store data that you want to keep confidential. This is what I do and it works perfectly.

Not that I need to defend dropbox, but here is a reply to the “insecure” claim: http://www.pcworld.com/businesscenter/article/224857/dropbox_insecure_by_design.html

Edit: Here’s the official reply from dropbox: http://blog.dropbox.com/?p=735

I won’t go into the merit of the trust issue, since that is a can of worms that I’m not willing to open here. Let’s just say that if you use facebook or gmail, then your concerns about dropbox are at least hypocritical.

Not really, if you’re promoting something, then it’s advisable to disclose issues about a particular solution that followers may not be aware of.
You refer to DropBox as being “awesome”, and your response to the security issue is that it’s been “debunked”. However hash issue is a non-issue IMHO and you’re missing the point.

** For me, the fact that DropBox can access any of the files that I may store with them is my major issue. **

Giving your files to a 3rd party to store offsite who can have access in cleartext to them at any time without your knowledge is a scary proposition for many.

This is why I stated that you need encryption. Dropbox repeatedly use “Secure” throughout their website, attempting to give the illusion that your data is safe. You have to dig down for the real story that they have complete access to the data you store with them.

IMHO, you’ve missed the point. It’s your responsibility to maintain the security of the client.

This proves my point exactly. If you read it, you will see that it mentions they have total access to your data.

Calling me a hypocrite is really outside the realms of this forum, when you don’t know what technologies I use or don’t use.

Also completely orthogonal to bring Facebook and gmail into this. Insecurity on one platform /application has mainly different issues / concerns / risks to another. Besides I don’t have enough time in my day to Facebook (feel free to call me a luddite), however I do use mail servers, although anything secure is encrypted with PGP or conveyed via other means.

Trust of others is a big issue for most, kind of like giving your house keys to some random person and trusting them. I realize that you don’t wish to discuss how insecure DropBox really is, but pointing out the very big flaw in it needs a least a little discussion. Then it’s up to the end user if they wish to ignore the issue, do something about it or not use the service.

After all, they could have implemented it so that the data on their servers is stored encrypted and cannot be decrypted by them. The fact that they haven’t, raises these reasons, as having to have it decrypted to provide access to the metadata for technical reasons, is really a non-issue technically as we both know.

Either:

  1. DropBox wants access to your files or
  2. The government wants access to your files or
  3. They’re lazy and don’t care about your security

or some combination of the above.

Either are not good propositions, and “Trust Us, We’re The Good Guys”, doesn’t cut it in my opinion.

Quite frankly, zawie, your combative attitude towards theoretical issues is unproductive and quite annoying. Until we have Dropbox working in any capacity, the issues around security are moot. If you want to layer your own security on it after we have a client, feel free. Or do you refuse to use TCP/IP because there’s no security built into those protocols? Ricardo is doing some excellent work out of his free time. You’re being a whiny *****.

You don’t seem to have any interest in using Dropbox as you object to the security model, so I don’t see why you’re bothering to post in here. Troll elsewhere, such as the Dropbox forums.

All I said was that is that DropBox was insecure and I wouldn’t trust my data with them and if you’re going to use it, you should be encrypting.

For that I was then accused of being a hypocrite, and I responded to that. Now you’re accusing me of being a troll.

This mirrors responses I had to threads I’ve posted. Suggestions for alternatives or solutions and a whole lot of negativity in return. Meanwhile we’re all stuck with a broken product. What surprises me is that others in the forum dish it out, but can’t take when it’s directed at them.

Some people get their ego’s bruised too easily, there are many technically orientated people on this forum who all contribute.

So, if you don’t like the combative approach don’t start off by being combative or launching personal attacks when people offer advice / help.

You’ve now posted - by sheer volume - more off-topic than on. Problems with Dropbox (which I largely agree with) have nothing to do with the DroboFS.

Ugh, this is why I did not want to answer in the first place. But I guess I should clarify my position.

Which, as diamondsw pointed out, is a moot point until the thing actually runs on the FS. If you read my other posts, you’ll see that whenever I actually release an app, I make sure to include all the disclaimers I can think of. For example, I suggest you take a look at my post about netatalk 1.

I stand by that assessment. For non-techie people (i.e., the target demographic of Drobos), it is the best file synchronization tool there is. No contest, not even close.

I never said that. I said that dropbox qualified their statements about privacy, safety and security on their blog.

To address this point I have to refine the terminology. Safety is not the same as Security. Something is safe if it is protected from failures, and something is secure if it is protected against unauthorized access (although that is just one possible definition of secure, it is the one that applies best in this case).

In other words, yes, your data is safe with dropbox. Is it secure? It depends what do you consider unauthorized access. If you consider other dropbox users, then yes, your data is secure. If you consider the dropbox staff, then no, in principle they can have access to your data even if you don’t want them to.

Finally you don’t really have to dig that deep. On the features page 2, they do not make any claims about security, only safety. A simple search points to this FAQ page: “How secure is Dropbox?” 3 which explains in quite some detail what the security claims are.

I’m not sure I understand what you mean. Of course I am responsible for the security of my machine. Who else would be?

I’m sorry if I offended you by this statement. I meant hypocritical in the original meaning, i.e., as in a diminished amount of criticism. English is not my primary language, and sometimes direct translations are not as correct as I would hope.

For everyone else reading this thread: this is where the conversation get philosophical. You are free to skip to the next post.

I beg to differ. Do you send SMS? Do you have a cellphone? Do you use a credit card? Do you have one of these RFID things to pay for road tolls? Do you use an anonymous VPN to access the web? Do you use any of the various “check-in” apps (Google Latitude, Foursquare, etc)? Do you have a PlayStation 3 or Xbox 360? Have you ever purchased anything from Amazon, iTunes or any online store?

All of these services are currently collecting vast amounts of data about your day to day behavior, and could probably build a much more accurate picture of you than the files you give to dropbox. The best part of it is that you decide which files you give to dropbox or not, while most of these other services won’t give you this level of control (well, not you specifically, any user).

Do you know for a fact that the admins of all these other services are not currently snooping on your data? Or even worse, that access to your data is granted to anyone, not only for legal purposes?

The cellphone company knows who you talk to, when, and for how long. The credit card company knows where you spend every single cent and sells this data away. Divorce lawyers have used road toll payment data. ISPs are introducing Phorm systems that track every single page you visit to inject ads in your browsing stream. Google uses the Latitude data to give you coupons, and so on…

My point is, compare to pretty much everything else in our lives, dropbox is just as secure. And it can be more secure because you can take steps to increase the security, which is not the case for everything else. In fact, their own wiki tells you how this can be done 4.

My main contention is why this is such a big deal for dropbox while for everything else it is just dandy and fine. Fundamentally, the whole backslash against dropbox reeks of clueless self-righteousness. How dare dropbox store my unpublished papers in a way that some of their employees might possibly have a look into it, while Facebook is actively preventing people to see all the data they got on them, in direct violation of European privacy laws 5.

Or maybe implementing good security is hard. Really hard. That is the reason why pretty much every internet related protocol was created without any support for security (HTTP, SMTP, FTP, POP, …).

For what it is, dropbox offers a lot of security:

  1. The transport of data is secured with SSL
  2. Data is stored in an encrypted format
  3. The keys to the data are not stored securely, i.e., dropbox employees have access to them

As someone who is doing a PhD on confidentiality (just passed my proposal, yay!), I can tell you that the problem of confidentiality (which goes beyond basic security) is much harder to solve than just applying encryption. In fact, when you are talking about confidentiality, which seems to me to be your main point of contention, encryption is not sufficient. Encryption is just shifting the problem from confidentiality of the data to the problem of confidentiality of the keys.

If you want I can give a quick write-up about why confidentiality of keys is a huge pain in the a**, but I’ll finish with this quote from Peter G. Neumann (one of the world’s leading researchers in the area of secure computing):

“If you think cryptography is the answer to your problem, then you don’t know what your problem is.”

Edit: added a link to the dropbox wiki page on privacy.

Ricardo, seeing as we still appear to be doing this, I would also like to clarify some of your points.

Actually you did:

Regarding secure v. pivacy v. safety. I concede that if you don’t care about the security of your data and wish to permit others have access to your data, then you can have security with dropbox. Essentially security can be seen as a graduated scale, 0-100%, if you are happy at the 50% level and wish to call that security, then your definition is different than mine.

To me (and I believe I made it pretty clear by mentioning encryption), I wouldn’t store backups, my source code and my clients source code and IP on 3rd party machines that were accessible by 3rd parties without my knowledge. Personally I would lose too much by doing that. If clients found out that I was doing that, I would be sued for negligence. One bad employee at Dropbox could effectively steal IP. Armed with that knowledge I would have to personally encrypt anything stored with DropBox (if I were to use it).

I do have a problem with companies where they claim things are secure but then don’t take basic security precautions. Claiming something is secure when it isn’t is false advertising at worse and providing conflicting information at best.

As part of my business involves being a security consultant and also being involved in the past as a consultant in cases involving prosecution of corporate espionage / hacking, I do have awareness of cell phones, credit card vulnerabilities and other potential vulnerabilities. Bringing the universe of potential threats into this discussion is highly irrelevant, because different information is being managed in all of these services and they all contain different risks. Individual risks can be mitigated where possible and addition to aggregated risks.

The only one I was discussing here is DropBox and lack of encryption. Many people consider their files to be very important, which is why I mentioned that it isn’t encrypted. I assume that any service I use can be compromised and I plan for that/

The reason that http, smtp, ftp and pop was created without support for security was that back then, people didn’t see the risk as serious and to some extent we were correct, i.e. these services were not widely used for commerce, they were the domain of researchers. Additionally there wasn’t global connectivity and computers were the realm of Universities, Government and Military, each ensuring their own security.

That said there was some minimal security built into ftp (logins). As the need became more apparent https/ssl was developed, ssh / sftp, and SSL for POP, IMAP, SSL. I.E. It wasn’t because it was hard, it was because it wasn’t worth the effort. That has largely been corrected now, so it can’t have been that hard. Is it perfect? Of course not.

implementing good security is not hard. I’ve done it many times myself. Perfect security is hard to implement, but good security isn’t. Dropbox encryption I would class as a “Minimal Security”. Implementing basic security for everyone in dropbox would be as easy encrypting the files on the client side built into the Dropbox software. Would it be infallible security, no, but significantly better than nothing. I suppose the ability to do this depends if you have a programmer who does the minimum they can get away with, or someone who will complete the job and has some experience.

I realize that English is your 2nd language as you have pointed out. As you are a PhD Candidate, I’ll cut you some slack too, however I respectfully recommend that you be careful about misquoting others, misquoting yourself and misdirecting the issues, particularly when it comes to your PhD defense. Good luck with the remainder of your studies.

There’s an extremely good reason for Dropbox not to do so - data deduplication is a core part of their service, and this can’t be done for encrypted data.

Security is best handled as its own layer. The best internet protocols have been tightly focused on their task, whether it’s IP (addressing/routing), TCP (flow control, retransmission, connection stability), POP/SMTP/IMAP (e-mail service, sending of messages - but no handling of security or identity management), etc. Let the protocol (or service) deal with its problems best, and let the security experts (you) add your security as you see fit.

I don’t expect Dropbox - a service focused on providing drop-dead syncing of files across systems - to put a focus on security. Dropbox already provides encryption-in-transit. If you want encryption-at-rest, provide it yourself. Roll your own “private cloud” that works the way you want - not exactly hard with WebDAV and some local file caching. But complaining about Dropbox ad nauseum on the Drobo forums is pointless. Or shall we go and complain about Drobo’s poor product support on the Dropbox forums? It has the same effect.

If you build a lambo with an engine from a fiat 500 and then blame the lack of performance as being the limitation of the engine, then that’s a poor design decision. You’ve traded off cost against performance. At some point that tradeoff shows up as a deficiency in the model. Dropbox figured that their cost was more important than their users data security.

Deduplication is not the only design choice, other cloud backup providers take the security of your data more importantly and don’t use deduplication. Dropbox could take the decision tomorrow to encrypt your data at the cost of more storage to them.

They could have also chosen to do deduplication at the user level of granularity instead of all users, in which case they could have had client encryption and deduplication without having access to the users files, which would have provided security for the user with a halfway house on cost.

This link pretty much says it all, for all the non-crypto people:

How Dropbox sacrifices user privacy for cost savings

Okay folks, we’re well off topic here…