i should be working (but i'm fixing my computer).

Cloud computing has inherent security issues that do not exist when you keep your computer and isolated from attack.  Just keeping some reasonable focus on the issues is a herculean task.

...

1. With free software, we do not actually know there is no malevolent code in the software -- we can only hope that there are enough security minded people looking at software we use and publicizing flaws that the flaws will become public before they do us in.
2. If we open up our computer as a "server" on the internet, we risk attack by hackers.  Odds are we may not have sufficient security skills to maintain the portal secure.
3. On the other hand, if we put the security task in the hands of someone else, we have to trust both that they are competent and that they are honest.  Not necessarily the case on either accounts.  (I have had a number of small corporate clients tell me that their comptrollers embezzled them into bankruptcy.  Employees and independent contractors are not necessarily trustworthy ...)
4. A fair amount of "free" software is reputed to have CIA or other intelligence agency venture capital in their portfolio.  A backdoor available for "legitimate law enforcement purposes" is likewise available to some group of individuals for nefarious purposes.  In this respect, "security" software could just as easily be a honeypot that directly channels information somewhere.
5. If we store our data on an ISP server, we get the benefit of full time security/programming/IT specialists and redundant backup to protect us from our mistakes.  But, is it secure?  What happens if a major "secure" storage provider has its clients' data compromised or subpoenaed (with or without notice to you, the end user)?

Ok.  So now that we are suitably aware that our data is totally compromised, how do we utilize cloud services?  For instance, I have documented my installation of iFolder elsewhere in this blog.  I like iFolder.

Except that it has a couple of significant drawbacks.  (1) no data rollback.  This is significant, because it is so easy to inadvertently delete something (or worse, a lot of somethings).  At one point I was using an online free software.  Unlike iFolder, it had a peer-to-peer mode.  In fact, although it was "server" connected to the internet, it was possible to prevent all of the internet communications and just synchronize "locally."

Of course, I was not satisfied with "locally."  I wanted to synchronize data to my ISP account, where I would not have to maintain it -- and where storage was comparatively "free."

This was possible.  I connected my ISP account via sshfs to one of my linux computers and Done!  Also, "unDone!"  Because, I had chosen to synchronize the directory to which I mounted the remote directory.  So, what did the synchronization software "see" when I lost my sshfs connection?  Correctomundo ... I had apparently "deleted" all of my files.  So, the sychronization software proceeded to delete the copies on ALL of my connected computers.

Fortunately, this was in my beta testing, so I realized the risk without major data loss.  But fortunately #2 -- the software had version rollback.  Now, with thousands of files, figuring out what needs to be rolled back can be an exercise in complete tedium and futility (as I learned), especially when there are multiple versions to consider.  But at least the data is "still there."

I have not been able to identify any sort of rollback protection in iFolder.  It is a feature on the feature request list.  One linux blogger-journalist also p ointed out this issue, noting that with files shared within a corporation in the iFolder, someone will shortly drag the file to his/her desktop for convenience -- whereupon it disappears to everyone else that intended to work on it.

Where am I going with all this?

Well, the "Dropbox" website is a convenient similar product to iFolder.  In fact, it is orders of magnitude easier to set up -- and does not have another iFolder drawback, that iFolder requires us to dedicate a computer as the server, which cannot then benefit from iFolder synchronization.  (There are other similar products/sites.)

Dropbox.com assures us that our data files are encrypted and secure -- their employees cannot read any of our data.  Of course, cynics like myself will immediately consider that if the universe of people who CANNOT read or data is limited to EMPLOYEES, by implication there are a lot of other people (and agencies) that MIGHT be able to read our data.

Well, not to worry, so long as we can make a distinction between data that needs to be secure and data that does not need to be secure.  For instance, I want to synchronize a lot of computer settings -- the sorts of things that might be found in ~/.[name]  files in my home directory.  Moreover, these are mostly text files, so won't take up much space.  But then again, do I really want to put my ~/.gnupg directory up there?  Hmmm.  What else.  Same issue with Firefox and/or google chrome synchronization.  Very useful and convenient , and for a lot of websites, who cares?  But then again, what if about the logins to places with which I do web commerce?  (This latter score concerns me with the google fleet of services, since the google checkout does not have a different login/password from my regular google account.) The more tools and the more often I log into my google account, the more possibility of my login info being compromised!(Which, thinking of that, there is no particular reason I could not create a separate google account explicitly for google checkout.  Thank you for helping me think of it.)

But back to dropbox.  So, it occurred to me that I could create a Truecrypt container and synchronize THAT via Dropbox.  But would it work?  Would I have to re-upload the entire container every time I made a change?  Would Dropbox recognize that I HAD made a change?  Would it promulgate changes via "delta" and therefore work efficiently?  (Of course, we don't know whether Truecrypt is backdoored, either, but at least we are creating layers of connundrums.)

The first go-round was a resounding "no."  My changed file did not propagate.  In fact, I ended up with the original version being downloaded back to my initial computer with the earlier version set as a "new" version.  Rather cumbersome, especially as with a container, you are using a relatively large file to store something pretty small.  We could eat up a lot of space this way.

I did not immediately give up.  I noticed f rom the dropbox icon that there was no activity when I made changes within the truecrypt volume.  However, there WAS activity when I dismounted the truecrypt volume.

So, it appears to me that it is, or may be, possible to  maintain self-encrypted files on dropbox.  But, since it requires manual intervention, it is fraught with potential disaster.  In other words, it seems necessary to dismount the truecrypt volume and then WAIT for synchronization before shutting down the computer.  (Or at least, before remounting the truecrypt volume on any computer.)  Easy to make a mistake somewhere.  And, the other issue is that it probably would not be possible to link a configuration file to the truecrypt volume, since that would mean keeping the volume open.  So, rather it would have to be a procedure where the latest synchronized version is copied in and out of the truecrypt volume.  Doable, but inconvenient.

It seems to me that if the truecrypt authors were to consider this issue, they could cause an occasional file write action or other action that would trigger dropbox synchronization while the volume is mounted.  But, since the programming of these features is over my head, I don't know whether that is a realistic hope.

Pages: 1· 2