Monday, June 17, 2013

Refraction


Actually I was going to write a different post, but then Edward Snowden chose to show the World what the people with tinfoil hats have been saying all along.

After the revaluation of PRISM, many people have hit the keyboard suggesting to companies and individuals, what they can do to protect their privacy online. The suggestions that are appearing range from well considered ideas to the ridiculous. 
I've seen articles on IT news sites, that basically suggest you pull your data home from the cloud and tighten security for employee usage of computers. These people haven't really grasped the extent of PRISM and see it as an opportunity to bring on even more production restricting rules on their employees. This will in the best case do nothing to ensure privacy and in the worst case, send even more data in the direction of the NSA (see my other post).
Other people have sensibly suggested that you encrypt your traffic, use non-centralized services and hide your identity online.
These are all great suggestions, but I afraid that if people don't understand the scope of privacy, they might get caught in a trap of false security. A bit like locking your car with the windows open.

That's why I'm writing this post to give you a framework of privacy. Something, that can help you understand the risks, understand which privacy tools do what and help you decide which options are right for you. I want to use PRISM to refract privacy and break it up into it's constituent components.

This framework is an abstract. It's simple and it gives you a way of thinking about online communication. It does not provide any definite solutions, although I will try to give you some at the end.

Framework
For any online communication, there are four kinds of participants:

The initiator
The transporter
The facilitator, and
The receiver

There can be multiples of each and the facilitator isn't alway present.

The initiator is the person, software or device which initiates a communication. I deliberately don't use the word "sender", because a device sending a reply to a communication is not an initiator.

The transporter is the device, software or company, which transports your communication to either the facilitator or receiver, or both.

The facilitator is a device, software or company facilitating the kind of communication that is going on. Usually on the application layer or higher.

The receiver is the person, company, software or device receiving the communication.

To give you an idea of what I'm talking about I'll give you an example: You send an email to some friends.

The initiator is you or your email client, depending on your frame of reference.The transporters would be your ISP, their interconnect provider and your friends ISP. The facilitators is your SMTP server and their IMAP server. The receivers are your friends and whoever they have hanging out around their computers at the time they receive the mail.

I hope this example gave you a understanding of the framework. Remember, it's abstract, so you can view this in any way or at any level you want. 
The initiator could be you, your employees, the spyware on your computer, your operating system and many more. The transporters are the ISPs, mobile operators, wireless providers, networking equipment, the office network, anything that moves your communication. If your communication isn't directly with the receiver, the facilitator is anything that makes it possible. Like a FTP server, Facebook, Youtube, a web server, some cloud service, your VoIP operator, you cellular operator facilitating a SMS service. The receiver can be anyone you intended to view or read your communication and anyone they share it with. This can be someone you're chatting to, or all the people who viewed what you put on Pintrest.

How to use the framework
If you want to secure your privacy, you need to secure it with all participants. This is where most people leave the windows of the car open. They might be encrypting their traffic all the way to the FTP server, but then overlook, that the server it self has been compromised.

When you start thinking about your communication with this simple framework, you easily see, that implementing more restrictions on employees doesn't rely help.

Solutions
Now I promised you some solutions. I'll provide a few here, but these will also bee in the abstract. I'm not recommending any solution over another, since you have to decide which one best suits your situation and needs. Each solution can be implemented in many different ways.

Almost all solutions have a side effect, which you also must take into account. These include: Loss of bandwidth, loss of personalization, need for more computing power and loss of realtime backup. Just to mention a few.

Trust
Now you might not consider this a solution at all. I consider it the best solution of all, since it comes with no side effects at all. Unfortunately it is also the toughest to achieve. But if you can trust all participants in the communication, you have achieved 100% privacy. This is most likely never going to happen, but if you can trust one or two participants, you have already achieved a lot of privacy.

Hide
This is "the classic" solution to privacy. You encrypt your data, so no one other than the receiver can read it. While this goes a long way in privacy protection, your privacy is still vulnerable at the receiver. Furthermore, hiding your data, might prevent transporters and facilitators to see it, but it does not prevent them from getting access to your metadata. They can still see, who you are communicating with, when, how much and from where.

Anonymize
This is a really effective technique to secure your privacy. If you can disguise your identity (and maybe the receiver can to), you can prevent facilitators and transporters (and sometimes receivers) to collect the metadata on you. Anonymization can be done be relaying, proxying  or tunneling your data between various places. But remember a proxy or tunnel service is also another facilitator!

Overload
While technically not actual privacy, information or data overload makes it much more difficult for anyone eavesdropping on your communications to find the "real" communication and it significantly raises the cost of doing so. This is an easy way to keep "small fish" out of your communications, but won't do any good in protecting your privacy from the NSA, which has access to unlimited funding from the american taxpayers. 

Decentralization
Another option is to cut out the facilitator completely. If there is not central server hosting your service, then it can't collect your private information. Many P2P technologies exist, that allow you to share files, chat, transfer money etc. without a central facilitating server. One of the drawbacks is, that you have no server, to back your data up from.

All of the above
As I said in the beginning different solutions apply to different parties in the communication. If you can combine the best ones of the above (and others that I've forgotten?) to suit your needs you have a pretty good solution for your privacy.


So before you randomly start beefing up your privacy, take a look at it through this framework and see if your efforts really will make a difference.