SurfEasy maintains a secure proxy network which is intended to provide a secure and anonymous browsing session to their subscribers (yes you have to pay for the service). It is a great tool to use if you are looking to do some “legal” browsing in places where you traffic might be listened to or you are concerned about maintaining privacy. We use ours on any open wireless network we are on and it does come in handy (of course we also use a virtual machine running a Live-CD OS if things are really bad) if you need to browse to places that you want to keep private. According to SurfEasy this proxy network is segmented and redundant to make sure that your sessions remain fast and secure. On the 8th this portion of the network actually remained up despite indications to the contrary.

At 10am on the 8th the server that hosted the SurfEasy.com website went down, but as we mentioned it did not affect the actual private network. This server also was responsible for a couple of other key services including the new customer registration engine and the Private Network Visual Identifier service. The latter is responsible for talking to the private network and letting the end user know that it is still active. If there is no response from the private network then the SurfEasy browser will display an unencrypted icon on the left hand side of the address bar. Because this service was down with the web server existing sessions simply showed as unencrypted despite the fact that they were still secure. SurfEasy has stated that they will be moving this critical service to a separate server so that issues with their website will not impact it.

We were happy to hear that user sessions were never exposed during the outage of these services, but we are still left wondering why we were unable to connect to the private network at all during the outage. When we tried we were given a service unavailable error. Now we could speculate that the Private Network Visual Identifier is responsible for making sure that the network is online and available. If this is the case then we would not have been able to access that service (as it was down) which prevented us from gaining access to the private network. If this is the case then our inability to logon is actually a good thing as SurfEasy was preventing us from connecting to a potentially unsecure network.

In the end we can fault SurfEasy for putting a critical service on a front end webserver, but we have to give them credit for identifying the issue and working to resolve it as well as their efforts at disclosure of the events that occurred during the outage. It is refreshing to see a company willing to identify and correct issues and to follow that up with keeping their customers (existing and potential) aware of what is going on. With SurfEasy’s quick response and willingness to talk about the what happened and what they plan to do to prevent future problems  we can still highly recommend this product and plan to continue using ours. Let us know what you think about this in our Forum.