Archive for July, 2012 Review… I give up

July 30, 2012 1 comment

This is a review I posted on a VPN review forum. I’ve been battling with Overplay to try and get some live, UK-orientated Olympics coverage (rather than put up with the locally orientated coverage), but after some experimentation, I concluded that the problem WAS with Overplay, not my ISP or the distance in general, and gave up on them.

After I tried Overplay support, they contacted me immediately – their support was immediate and very detailed; can’t fault them for that. They directed me to their SmartDNS service, that I understand re-routes selected traffic via a UK PoP, which is basically less load for them than a full encrypted VPN, but also should be faster.


The difference was remarkable – less congested, and faster. I was now able to watch some iPlayer at reasonable speeds, sometimes. TVCatchup was, as always, savvy, and rejected me.


I then tried Expatshield; I hate their native app and ads, so I ran it on a VM rather than have its nasty stuff all over my laptop. Expatshield worked faster and better than Overplay. So, still not great. TVCatchup still rejected.


Finally… I sent a plea out to friends on Facebook. One of them offered a VPN login to their home router and broadband connection, so I could log in via their home network on both my laptop and iPad via PPTP.



Suddenly…. everything worked. Streaming video was clunky, but continuous and worked. TVCatchup, of course, couldn’t tell the difference, and had no complaints at all. Right now, I’m watching the Olympics Eventing on my iPad.


Moral of the story? Friends will always help you more than almost any paid service, if you can impose. And Overplay have some cool services and support…. great features. They just don’t have enough capacity to work worth a damn.

Categories: Uncategorized

Sugarsync are removing their Folder sharing links

July 20, 2012 Leave a comment

I just received an interesting mail from Sugarsync

As part of this change, we are removing the ability to share a universal link to a shared folder (the “Get Link” feature). The universal link is less secure since you can’t control who might gain access to the link (e.g., an intended recipient might accidentally forward the link to other unintended recipients). We’re also removing the password option since the new model is inherently more secure by allowing only specified recipients to accept the folder, preventing a password from being shared without your consent. And don’t forget that you can add or remove folder members at any point in time. 

Now – call me a cynic, but this sounds more like Sugarsync trying to increase its registered user base by forcing everyone you send folders to, to sign up for an account, than to improve security.

I’ve found the flexibility of being able to send a link to a person very useful… simply because it requires less inconvenience for the person I’m sending it to, but is still a bit more secure than generating a completely public link. Everyone I know has ‘Web 2.0 account fatigue’, and if I’m sending a file to a customer, I’d rather just be able to include a quick link in my email to them, rather than send them a blaring bannered service invite via a proxied service requiring them to sign up for an online account, before they get the file I was sending them. There’s still plenty of branding and sign-up options at the other end of the download link, without sending them that mail. And what if his enterprise decides Sugarsync is out of policy, and blocks all emails from the site?

Folder passwords are also very handy against the threat of someone accidentally discovering a public link, since they still need the password to access it. Sending the password out of band (ie. in a text message, rather than in the same email/invite as the link itself) gives some insurance against data leakage, and makes the recipient feel more personally responsible for the security of that data: they can’t say “oh, nothing to do with me, someone must have stumbled across that link on the internet”, if they’re the only one with the password. Losing this feature, for me, is a step backwards for Sugarsync against some of its competitors, such as Dropbox.

Now… I’m not completely adverse to getting recipients to sign up for accounts. Let’s face it, viral spread is core to the business model. I keep singing the praises of Sugarsync to my colleagues, and I’ve managed to refer 28 people, most of whom I’d only met once, by sending them documents that required signup. I’m not entierly adverse to it. But I would like to have the option.

If we want to improve security, how about auditing access? That’s something I would really rather see. If we’re scared of who might be able to see our folders without our knowledge, then what I’d really like is to be able to run an audit report to see who read/wrote which file, at which time, using which link/password, from which IP address. It lets me see that people are using the links I send them. It lets me see who accessed a public link. It lets me detect if someone has tried to access files from unlikely/suspicious IPs.

OK – a big proviso here; this is my kneejerk reaction. I’ve not fully explored how this will change things, and there may be some benefits. I’ve also only just jumped into the forums here, which I visit very occasionally, and perhaps this has been discussed to death elsewhere. But I thought it might be a useful discussion kickstarter to vent here and now, and gauge different viewpoints 🙂


Categories: Uncategorized

Another idea for Truecrypt backups on NAS

July 10, 2012 Leave a comment

You may have read my previous post about my pains in trying to get Truecrypt on my laptop to mount a Truecrypt volume on my ‘NAS’. It complains about network issues. To be fair, considering my ‘NAS’ is actually an NTFS USB drive, plugged into a Mac Mini, running NTFS drivers… I’m not too surprised that there’s a glitch somewhere in the stack.

So… I was thinking of getting a NAS to take care of the issue for me. However, it turns out my favoured NAS, Synology – can’t. It uses eCryptFS, but on a file level; this disables access via NFS/CIFS (ie. Windows fileshare), since there’s no way of configuring the encryption on the PC you’re trying to backup from.

I guess there could be a way to enable eCryptFS on the PC you’re backing up, by exporting a key from the Synology (which you can do), and importing it to your PC, so that the PC  writes the files to the NAS directly in the encrypted form. That might work on a Linux laptop, but try getting Windows to do that! Via a backup client!?!

And anyway, even if you did that, two problems:

  • it disables the NAS interface for those shares anyway
  • The key is stored on the NAS – so if it’s configured to be mounted on startup, then it’ll be decrypted anyway with no need for a password

So… what’s the plan?

The plan is this.

Firstly… don’t get the Synology, at least not for this reason. It doesn’t fix the encryption problem itself, although it may at least allow Truecrypt to mount that volume over the network without complaining.

Secondly… set my backup script to run this following process:

  1. SSH into the Mac Mini (ie. get the script to do this automatically)
  2. Run Truecrypt natively on MacOS on the Mac Mini. This could potentially include a very strong password or hash in the command – which is stored and run solely from my laptop in the SSH session, and so is not stored locally on the Mac (where someone could find and use it to access the volume, if they stole both Mac and Drive)
  3. Get it to mount the backup volume
  4. Get it to share the volume as a network share, so that my laptop can see it as a plain CIFS share
  5. Run SyncBackSE to backup my laptop drive to this ‘temporarily decrypted’ shared drive
  6. Once backup has completed, unmount the truecrypt volume

So… this has the following benefits

  • SyncBackSE allows commands (inc scripts) to be run before/after backups, and so this SSH command can be part of that
  • The Truecrypt volume is mounted locally on the Mac, so it present as a standard share, and won’t suffer any of the weird network connectivity issues from trying to mount the same volume remotely from my laptop
  • The credentials or key to open the volume are stored in the script on my laptop.. .which is itself drive-encrypted. So, if someone steals the Mac and Drive, they do not have the password to decrypt the backup. If they steal my laptop, they would need the Windows password to log in and gain access to my drive to get the Truecrypt password…. in which case, since they’re already in my laptop, they already have access to all the data on its drive; no need to decrypt the backups after all.

So – it’ll be some faff with the script, but the payoff is hopefully a more reliable and secure backup.

Categories: Uncategorized