Secure browsing on open Wi-Fi hotspots

I frequently connect to insecure Wi-Fi networks on my iOS devices and my Mac. Aside from the risk of eavesdropping and malware when connecting to these hotspots, they frequently block access to services, insert advertisements in web pages, or worse.

To work around these problems, I’ve tried numerous virtual private network (VPN) services. My experience with most of them has been awful. They tend to connect slowly or not at all, and I frequently can’t access anything on the Internet once the VPN connection is made. Many services don’t offer automatic connections, particularly on iOS. The software tends to be clunky and confusing.

Cloak VPN is an exception. I’ve been using Cloak for several months, and it’s been rock solid. It’s also affordable, at $3/mo for 5GB of data transfer or $10 for unlimited transfer. If you don’t want a subscription, Cloak also offers the ability to buy non-renewing, unlimited passes for a week, a month, or a year.

Cloak automatically detects when you’re connecting to insecure Wi-Fi and protects your connection. One account can be used to protect all your computers and iDevices.

Cloak released version 2.0 today for iOS, which is a significant upgrade. You can now identify trusted networks, such as your home or cellular network, and Cloak will stay out of the way when you use those networks. This means you can set it up and pretty much forget about it. (Cloak for Mac already offers this capability.)

Like any VPN, using Cloak can cause issues. Cloaked connections are sometimes misidentified by servers as coming from a “bot” instead of a human. This isn’t Cloak’s fault, but a consequence of well-intentioned but misguided system administrators. Some sites won’t let you connect at all, while others, such as Wells Fargo, may ask an extra question when you sign in.

With a few clicks or taps, you can disable Cloak and connect to problem sites. In practice, I’ve only found one or two websites that were completely blocked while using Cloak. I’ve also had outgoing iMessages get blocked sporadically. In all, the issues have been minor, and far outweighed by the benefits of the service.

Cloak has very responsive customer service and is sometimes able to work around blocks by re-routing traffic for certain websites.

I highly encourage you to learn more about Cloak and get started with a free 30-day trial. You don’t need to hand over a credit card to get stared.

Cloak provides small data kickbacks to users who tout them on Twitter. I don’t spam my followers so that I can get free stuff. I’m posting this because I rely on Cloak, and I think everyone should check it out.

Use Dropbox to host public files on your own domain name

I’ve been using a Dropbox public folder and some Apache trickery to share files directly from Dropbox on my own domain at Dropbox is drag-and-drop file sharing at its finest, and by sharing my files on instead of on, my files are accessible to corporate folks who would otherwise find themselves blocked by an over-zealous web filter. Last but not least, if one of my files becomes too popular, Dropbox won’t shut down my account.

product logos

Dropbox doesn’t offer a custom hosting service, so I had to build it. I already have an Apache server, so I created a new virtual host and added some reverse proxy magic. I set up my virtual host as the origin server for the Amazon CloudFront content distribution network, ensuring a minimal load on my own server and the ability to handle virtually unlimited amounts of traffic.

Here’s a recipe for Apache 2.2, mod_proxy, and mod_rewrite:

DirectoryIndex disabled

ProxyRequests off

RewriteEngine on
RewriteRule ^/(.*)$1 [P,L]
ProxyPassReverse /

Header unset cache-control
Header unset Pragma
Header merge cache-control max-age=3600
Header merge cache-control must-revalidate
RequestHeader set User-Agent Mozilla

The cache-control settings dictate that CloudFront should cache my content for an hour (3600 seconds). CloudFront currently ignores the specified max-age for 404 results, instead preferring to cache them for about 10 minutes. I’d prefer a shorter lifetime for failed requests, but that’s not easy with Apache 2.2; With 2.4, it’s do-able.

The requesting User-Agent override is necessary because Dropbox blocks requests from the Amazon CloudFront User-Agent.

Using mod_rewrite makes it possible to host overlapping content outside of Dropbox. If it exists on the server, it gets served locally; If it’s missing, Apache tries to fetch it from Dropbox. I locally host the favicon, robots.txt, a 404 handler, and a couple of other things.

If you want to use your own 404 handler, you’ll need this:

ProxyErrorOverride On
ErrorDocument 404 /path/to/404.html

Before you deploy something like this, carefully consider the security implications and make the necessary adjustments. Do you want PHP code in a Dropbox folder running on your server?

Dropbox public folders are not available to users who signed up for Dropbox after July 31, 2012.