What the fsck is up with removing tethering support for unauthorized carriers in iPhone os 3.1.2? Seriously, what could possibly excuse this lameass stunt? Oh wait, the Apple folks are probably making good on some backalley promise made to authorised carriers.

Maybe it’s time to try out the Nokia N900 with its sweet Qt support, even if it does look and feel like a brick.

So, without further ado, a summary of online backup solution privacy goodness (again, I would like to remind you that I am not a lawyer, simply a concerned luser):

Carbonite

The Carbonite privacy policy looks a lot friendlier than Mozys. Carbonite distinguishes between two types of disclosure. Disclosing (a) your personal information, presumably your name, address, phone number, etc, and disclosing (b) your backed up data.

With regard to (a), the privacy policy contains the following:

Carbonite is committed to protecting your privacy. Carbonite will not, under any circumstances, rent, sell, or give away your Personal Information nor does Carbonite trade or exchange mailing lists with any other organization. Carbonite maintains this information; but we may disclose your Personal Information to third parties if we believe that such action is necessary to (1) comply with the law; (2) protect and defend the rights or property of Carbonite; (3) enforce the Carbonite Terms of Use Agreement.

Although slightly rubbery, I guess that is what is to be expected, so we move on to (b), to which the following quote refers:

Carbonite will not share your encrypted files with any third party unless such action is necessary to comply with a government or court order legally compelling us to do so.

That’s more like it. As I’ve mentioned before, handing over data when ordered to do so by the courts are clearly a no-brainer.

So except for the fact that Carbonite, like Mozy, is situated in the US (which during the Bush administration has become an increasingly hostile environment with respect to legal rights), there really doesn’t appear to be much cause for concern.

In summary though, Carbonite appears to be a whole lot more privacy friendly than Mozy. Moving on to IBackup.

IBackup

The Ibackup privacy policy appears somewhat more fragmented than those of Mozy and Carbonite.

It appears that the following paragraph, taken from the IBackup terms of use, defines the cases in which Carbonite chooses to share stored data with third parties:

(…) In addition, Pro Softnet may be asked to provide user data and logs as a part of a legal issue in a third party case by a court order or a subpoena, discovery request or other lawful process that may override privacy rules.

As was the case with Carbonite, IBackup pledges not to share stored data with any third parties, unless ordered to do so by the courts.

Conclusions

Both Carbonite and IBackup provide reasonable terms of use with respect to sharing data with third parties. That is, according to their respective privacy policies, stored information is only divulged under court order.

This is in contrast with Mozy Inc. which allows itself to share stored information with any third party at any time that they deem fit.

As neither of the providers publicly disclose their encryption algorithm implementation, the privacy policy/terms of use of the providers are pretty much all that users can rely on for keeping their private data private.

He writes:

C’mon people, do you actually think a company would just hand over your data to anyone with a badge that walks in the door?

(…)

Of course Mozy’s TOS says that they will comply with a court order to hand over your data if subpoenaed. That’s the law.

That’s fine. Don’t make statements to the opposite at the top of your privacy policy then. If I was suspiciously inclined, I would suspect that the company bets that nobody bothers to ready beyond the first promising paragraph. Also, I find it interesting that this guy completely ignores this excerpt from the privacy policy:

Mozy, Inc. may disclose Personal Data, including the data you back up with the Service, with or without notice (…) (c) at our sole discretion, where we deem it necessary to protect the safety of any individual or the general public or to prevent violation of our User Agreement or the rights of Mozy, Inc. or any third party.

As far as I can tell, that allows Mozy, Inc to disclose your personal data under any circumstances, not just when subpoenaed to do so.

Finally, Ryan makes some rather clueless statements about cryptography:

• He states that “(blowfish is )impossible to decrypt”. No it is not. There are no known attacks on the the algorithm, except, obviously brute force. That is not the same as it being impossible to decrypt.
• To my knowledge, Mozy, Inc’s blowfish implementation is not publicly available, which makes it impossible to determine if trap doors have been placed in the algorithm implementation.
• Mozy, Inc. actively suggests (in fact it is the default configuration) that users allow Mozy to select the encryption key used. This obviously allows mozy to decrypt any sensitive information contained in user backups. Couple that with Mozy’s statement about disclosing backup data at their discretion, and you have an interesting definition of privacy.

All in all, I am hoping that Ryan is neither in charge of PR nor security at Mozy, Inc.

I must say, the Mozy client works beautifully, and the 2GB free storage plan makes it easy to test the service without spending anything except the time. It took me less than 2 minutes to download and configure the mozy client to do remote incremental backups of a few select directories on my mac book. No problems.

So there I was, pretty impressed, until I decided to ready the Mozy privacy policy. It starts with the following:

We will not sell or market the email addresses or other collected personal information of registered Users to third parties.

We will not view the files that you backup using the Service.

We may view your file system information (file extensions, sizes etc. but not your file contents) to provide technical support.

So far, so good. Further down, however, I encoutered this:

Mozy, Inc. may disclose Personal Data, including the data you back up with the Service, with or without notice (a) if required by a subpoena or other judicial or administrative order, (b) where required by law, or (c) at our sole discretion, where we deem it necessary to protect the safety of any individual or the general public or to prevent violation of our User Agreement or the rights of Mozy, Inc. or any third party.

Now, I am not a lawyer, but that seems to be in direct contradiction with the first set of statements. The way I understand is this: At our sole discretion we may violate the privacy of the data you choose to back up.

Hmm. I am not sure I like that.

Additionally, it turns out that Mozy is based in Utah in the US. Again, I am no lawyer, but from what I can tell, the US have all but abandoned the idea of due process in their precious war on terror. For all I know, any old US government agency could waltz into Mozy’s data center and make a copy of whatever data they damn well want to.

Whoops. I just uninstalled the Mozy client.

I am not even going to begin to enumerate the problems that I have encountered, but they have been mostly related to various WSDL formats, some of which are unsupported by .NET, and some of which are unsupported by various Java based web service frameworks.

So, admitting failure, I decided to look into SOAP alternatives, and I came across XML-RPC. Unlike SOAP/WSDL, XML-RPC is extremely simple: The specification is 8 pages including examples, and there are client and server implementations for pretty much any language you can think of. So, what’s the downside to XML-RPC compared to SOAP (taking into account that I was going to use SOAP over HTTP only anyway): Well, WSDL, basically. XML-RPC does not statically define its endpoints, instead it is up to the client to know what methods/parameters are supported by a given XML-RPC service. Also, SOAP supports a number of data types not supported by XML-RPC, but not really anything that causes problems.

Depending on the server implementation used, it is in fact possible to automatically generate clients (kindof). More on this in a little while.

During a semi-recent upgrade of Drupal (before making the switch to wordpress) I accidently forgot to migrate a data directory stored in the web root. After the upgrade, as everything related to the site appeared to work according to plan, I deleted the old drupal directory, including the data that I had forgot about.

Then, a few days ago, I received an email telling me that every download (and a few other things) on the site had stopped working. Realising that I probably made a booboo, I turned to by backups (made with rdiff-backup, and withing 2 minutes I had completely recovered the most recently backed up version of the lost data. Until now I’ve been a recovery virgin. Not any more I guess.

So, what is a guy to do? I recently came across a review of some homeplug products, and even though review concluded that performance varies widely, depending on the exact topology of the electrical grid, I decided to give it a shot (Buying stuff online in Denmark means that it can be returned within 2 weeks for any reason, if the buyer decides to do so). So, I recently went ahead and ordered a couple of PLE200 units from shg.dk. I’ve now had a chance to hook them up, and see for myself what they can do. So far I am getting mixed results. Having hooked both units up through outlet boxes (ie. not directly into wall sockets), I get a sustained transfer rate of 1 MB/s (~8 Mb/s).  While that is sufficient for streaming most current DivX encoded movies, it is not nearly good enough for HD streaming (which requires up to 20 Mb/s). However, moving the PLE200 unit at the XBOX end to a wall socket, increased the speed to roughly 1.5 MB/s or 12 Mb/s. I suspect plugging the router end PLE200 directly into the wall may yield a similar speed increase, although I haven’t had a chance to test that.

All in all, the PLE200 falls far short of its theoretical speed limit of 200 Mb/s, but it does provide sufficient bandwidth for streaming non-HD encoded movies, which is what I need right now. And opposed to the wireless network, the PLE200 units provide a reliable connection. So, for the time being I am satisfied.

Now, if only XBLM would get here …