Why did we launch the iAnonym project?

We started working on iAnonym because most of our previous projects had been stopped by new forms of censorship imposed by major internet companies.



Our goal is to provide a solution that is both reliable and completely independent. It draws on the Web experience we have gained through our previous projects and the work we have done as contributors and members of various standards groups (W3C, TC39, WHATWG) and projects (node.js, webkit, fixed and mobile browsers). From a technical viewpoint, the solution is based on extensive research and testing as summarised in the Technical details section

Introduction and summary

Most people tend to associate anonymiser projects with dubious or malicious activities. This is a bit simplistic since anyone can fall victim to invasions of privacy and everyone has the right to surf the web anonymously. This paper attempts to provide an easy-to-follow explanation of the issue and looks at a possible universal solution.



We've tried to keep it simple but the project description is long and some technical details might look daunting to some people. The aim is to highlight the fact that surfing anonymously is not just for a handful of people who want to conceal their activities. It can interest anyone who is concerned by the proliferation of tracking methods, by invasions of privacy and by how to protect young people who now access the web at a very early age. It shows that it is possible for people to know what you're doing, what you're buying, where your kids go to school, etc. without actally knowing you, and that web specifications are not really evolving to protect you.



Do you think you’re not affected because you don't do anything illegal or have nothing to hide? You’re wrong. Some services are not only tracking you but are also facilitating access to your private information and helping to intercept it.



If you don't believe us, just try this Mozilla add-on : Collusion which clearly shows that the "whole world" is aware of what you are doing as soon as you start surfing.





Our proposed solution is a universal one that works in any modern browser without the need to install anything. It is based on the principle that you only trust yourself. It allows all information to be encrypted - even for sites that don’t support encryption - and hides the real name of the sites that you visit (my_bank.com becomes abcdefg.com) with the help of an anonymiser network. The anonymiser network, which is accessed independently, hides your real IP address and adds other levels of encryption.



It is important to grasp what we mean by "you only trust yourself". It means that absolutely nothing and no one outside of the browser has any clue about what you are doing, where you are going and what data is being sent or received. Only the browser (i.e. yourself) is able to decrypt and understand this information.



What does it look like? See the video:





What do you use it for?

You can use it to do anything you see fit:



- hide your real IP address

- hide the domains you visit

- hide the information exchanged between you and those sites

- avoid trackers and ads

- avoid intrusive or dangerous scripts

- bypass censorship policies

- download things anonymously



Don't want to read everything? Then just go straight to the conclusion:

Summary, pros

- nothing to install

- available everywhere from any modern browser

- https used even to access sites that don't support it (extending the HTTPS Everywhere concept)

- destination hidden even during the https handshake

- no third party software

- relies on the fact that you only trust yourself - even potentially malicious components inside the browser cannot compromise you

- very difficult or impossible to block since the js code and the pac file can be distributed everywhere and you only need this to run the js OP

Summary, cons

- None. We had some doubts about performance but the initial successful communications inside the browser are showing that it is quite fast.

The problem: the Web and anonymity

Unfortunately the web has not been designed to safeguard your anonymity and privacy. It's actually the complete opposite. You can’t imagine the time spent by websites and major companies trying to track you and profile you (trackers, ads, analytics, safebrowsing, etc.) in order to build databases of personal information so that they can correctly target their ad campaigns. In addition to collecting identified personal information that they might have difficulty retrieving, they can correlate what you are doing and profile you without knowing you. Have a look for yourself – go to my fingerprint and you will probably discover that you are unique and therefore easy to distinguish (at least for a short period of time since your fingerprint might change for another unique one), see also for more information/examples Pixel Privacy.



The aim here is to give you an overview, not to provide details on the technical aspects of anonymity.

What can you do to counterattack?

Not much, except for deleting your cookies and browsing history as often as possible, not staying logged in to your usual accounts and changing your IP address from your ISP periodically. If you care about privacy, you're better off using Mozilla Firefox as your browser. Web techniques allow personal information related to your activities to be sent out quite easily without you knowing/noticing it. Browsers do propose some options (e.g. "do not track") for more private browsing but you cannot rely on such features since they depend on whether the websites actually comply with them or not (see the current debate about the long-awaited "do not track" w3c specifications or IE10 policy, and Yahoo!'s reaction, etc., showing the global consensus to kill it). Even some secure options like safebrowsing are dangerous since they send information out.

And there's more

In addition, what you are doing can be intercepted (by your ISP, your local authority, a hacker), recorded and/or used against you (e.g. attacks to retrieve your bank session cookies).

And more

Censorship: some sites or networks can decide to restrict access depending on your location, the frequency of your requests, where you are going, or whatever criteria they choose to use.

What if you are using https?

HTTPS is secure enough for normal browsing but does not prevent someone from knowing where you are going because the initial handshake contains the destination server name. For example, if you are visiting https://mybank.com/my_account, mybank.com and my_account will be encrypted after the handshake but mybank.com can be read clearly during the initial handshake. Browsers are not very transparent regarding certificates handling and do not really follow the revocation checks. It is therefore not unlikely that someone would be able to send you a certificate that looks correct and then intercept and decrypt your communications (a man in the middle style attack). A simple example is a company (or a government, browser company(??), etc.) that makes both security and interception devices using their "security" resources. You might install things on your browser and confirm that you trust the company – you will then not notice when their devices intercept your information.

So do you have to use an anonymiser network?

It's up to you but you have to be careful. Most anonymising solutions do not anonymise anything, and in some cases the use of an anonymiser network can facilitate interception. In all cases, you must at least use https or another encrypted protocol over what you are sending to the anonymizer network.

More details

The first requirement of a good anonymising solution is to locate in your device the secure system that allows you to access the anonymiser network. In the case of the Tor network, this is called the Onion Proxy (referred to hereafter as OP). Otherwise, anybody between your device and the anonymiser network can see what you are doing. It means that you have to install something on your device and therefore that you trust the provider of the solution. This is the first issue. Another issue is that the said provider has to maintain versions for all platforms (PC, Mac, smartphones, etc.) and sometimes cannot offer a version for locked systems like iOS, iPhone, iPad (which, by the way, could be sending out things you absolutely don't know about). Tor network protocol for example is known to be strong but you still need to rely on what the OP part is doing, and it cannot be used from any device.



For more details about the principles of an anonymiser network like Tor go to: node-Tor

The solution: the OP inside the browser in javascript

A good solution would consist in not having to install the OP and having it as close as possible to the browser. Therefore, it seems reasonable to imagine the OP as a javascript program inside the browser. Unlike other options (flash, java), javascript is universal and already integrated in the browser, so you don't have to install anything and can trust it.

Why should you trust the browsers and javascript?

Browsers are developed by companies that have an interest in profiling you too. But browsers are so widely used that any defect, security leak or suspicious behavior is immediately detected by the community, reported publicly and corrected by browser vendors. They cannot afford to ignore it.This is valid to a certain extent - see above note regarding non-transparent certificates handling. In addition, some browsers do activate by default some tracking options/add-ons. You need to check your configuration and deactivate them but in any case the fake_domain principle will counter these malicious practices. Same goes for javascript. In addition, javascript code cannot be hidden so what the OP is doing is more transparent than something that comes with an installation package, even from open source projects. The less outside modules you use, the better as it prevents an attacker from infecting the outside modules (windows for example) and then compromising you when you think you have done your best to secure your application. This is the case with javascript here - only browser implementation mistakes can affect the js OP.

But you read a lot of things about security problems with browsers and javascript

Yes, but they are common knowledge and there are basic techniques to avoid them. Javascript standards include specific mechanisms to make applications secure (see more details here).

The proposed solution

Take a look at the project and the project (bis) These are supposed to be simplified diagrams of the proposed solution. Basically the js OP behaves like a "man in the middle". When a URL is entered it turns it into another one (a fake domain… mybank.com becomes abcdefg.com) and asks the browser to load https://abcdefg.com. So even if you are using http the messages will be encrypted. The browser does this via the standard SOCKS proxy interface which is connected to a node in the anonymiser network. This node is connected to the OP via secure websockets. When it receives messages from the browser it relays them to the OP which processes them via the anonymiser network. Therefore communications between the OP and the browser are encrypted and communications between the OP and the destination server are encrypted by the anonymiser network (+https if used). Throughout the whole process the OP is the only one to know the destination and to understand the messages (along with the destination server of course).

What if censors block the sites delivering the javascript code?

Censors cannot block the whole web. They could block, say, ianonym.com, but if we rely on partner sites that simply host a tag allowing retrieval of the js code, it's unlikely that they would all be blocked.

Ultimately, the code could be registered directly in your browser, via a bookmark or in the future: Webcrypto Use Cases - data integrity.

Proxy configuration

This is available in all browsers and all devices: simply set the proxy settings to a PAC file (Proxy Auto Config) such as http://ianonym.com/proxy.pac. If the requested host is different from the site hosting the file this will set up the socks proxy interface with an anonymiser router. If ianonym.com is blocked or you don't trust it, you can configure it to a partner site. If you still don't like it you can use your own pac file (at your own risk, see the requirements in Details).

What if censors block the SOCKS interface nodes?

This issue is not specific to this project. Censors could block known nodes but again it's unlikely that they would block all nodes.

Also, studies are underway into new ways of fixing this, such as flash proxies (not to be confused with Adobe flash plugins – there is no connection). It shows how partner sites (i.e. "normal" sites) could be used to relay anonymised traffic through browsers using websockets.



Similarly, as part of this project, the plan is to implement the anonymising nodes (OR) inside the browsers, so the server nodes would just have to relay the information between websockets.

What if censors block Websockets?

Websockets implement a specific protocol so are easy to recognize and could be easily blocked. But websockets are one of the most interesting features of HTML5 with loads of promising applications so we can expect websocket traffic to increase a lot thus making it very difficult or even impossible to censor.

Browser security

The page and the OP will control everything that goes outside of the initial domain (mybank.com) and make everything look like requests to the fake domain. This will counter most known attacks (there is no point in attacking you on a fake domain) and ensure that the final destination is not revealed by outside messages (analytics, trackers, ads, etc.). Cookies, cache and history management will be performed on the fake domain name and it will be separate from the real domain name. From a javascript standpoint, the OP code will not be accessible from other local js code. When messages are received, the OP and the page will modify them if needed for security purposes (change urls to fake domains, control cookies, forbid scripts, iframes, objects, etc.).



This might look a little bit restrictive but it will remove everything that is usually a nuisance to you. For example, cookies will be removed from responses from unknown sites, so "bad" scripts will not be able to do the job, "good" ones will.

Will it really work?

Yes! See 9th February 2013 and the first page loading (in black, the OR console and in white, the OP inside the browser and messages from the web console):







And implementation details: node-Tor (OP and router implementation in javascript), fake domain test (page loading with the fake domain concept) and implementation details and Live test where the latest and future techniques are being considered. Some technical concerns could be raised but they actually tend to be advantages:

- warning at the browser level because the js OP cannot have valid certificates: this is not a defect since it tells you that you are talking to someone trustable (yourself!). No warning means you definitely have a problem. You just have to validate the warning once to navigate.

- Evil 1 attack: a simple way to counter this is for the page to retrieve the certificate details using javascript and to compare them with the OP certificate (the page and the OP can communicate inside the browser). This is done using the tool Interception Detector. As with the previous point, this really ensures that you are talking to yourself and that there is nobody in the middle intercepting your information.

- you need the right js code and pac file (you can get this from ianonym.com or partners): there are ways of checking it and this is also part of the W3C Webcrypto topics Use Cases - Signed web applications and Webcrypto Use Cases - data integrity.



Which anonymiser network?

Probably Tor or a Tor-like network. The access points must understand the js OP protocol. They can be separate dedicated routers.

Why should you trust the anonymiser network?

You shouldn’t unless there is clear evidence that the protocol implemented is strong (like Tor protocol) and that the choice of routers in the path is secured (i.e. several routers in the path are not controlled by the same person or by dubious people – this is ensured by the js OP).



See here for the theory. Basically you cannot avoid someone controlling the first and the last node to correlate the traffic and that entity therefore knows who you are and where you are going/what you are doing. iAnonym routers implement access to the anonymiser network, not the exit function. It’s therefore unlikely that the first and the last nodes belong to the same person.

Packet inspection

The traffic on the SOCKS interface is supposed to look "normal" (i.e. it won’t be recognised as anonymised traffic). The traffic on the websoscket interface can be obfuscated by the OP if needed.

Won’t these concepts soon be obsolete?

No - see implementation details and live test again here. One of the ideas is to let the browser do its job without interfering, that's why the SOCKS proxy interface is used. There are not many ways to implement the OP inside the browser with this concept (and almost none without it). There is nothing to suggest that future trends in standards will bring changes that could improve the overall proposal except in terms of security and performance.

Wouldn't it be easier to build a customized browser or use extensions/plugins?

No. Even if projects like webkit, chrome or mozilla do allow you to build browsers, it's unrealistic to think that they could compete with major internet company teams. Extensions are not standard and not available everywhere - both are platform-dependent, which means maintaining different packages

Then maybe a major browser vendor or internet company will one day implement anonymity?

It's unlikely... and it definitely would not be available everywhere, from any device.

Summary, pros

- nothing to install

- available everywhere from any modern browser

- https used even to access sites not supporting it (extending the HTTPS Everywhere concept)

- destination hidden even during the https handshake

- no third party software

- relies on the fact that you only trust yourself - even potentially malicious components inside the browser cannot compromise you

- very difficult or impossible to block since the js code and the pac file can be distributed everywhere and you only need this to run the js OP

Summary, cons

- None. We had some doubts about performance but the initial successful communications inside the browser are showing that it is quite fast.

Interlude - you are probably sketching something over-exaggerated here...

...and you should get some help for your paranoia problem.

Not really. This paper does not mention every threat and we certainly cannot expect the trend to be reversed. The risks remain invisible to unsuspecting users and even webmasters that do not really know what the modules they are using are doing.