Anonymity inside your browser, everywhere from any device

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.

L'anonymité dans votre navigateur, partout, à partir de n'importe quel équipement

Pourquoi ce projet ?

Nous avons démarré ce projet après avoir subi une nouvelle forme de censure provenant des compagnies internet majeures ayant pour effet tout simplement de stopper/tuer la quasi totalité de nos projets.

Le but est de fournir une solution réellement indépendante et fiable, notre expérience du web provient de nos projets antérieurs et de notre participation au titre de contributeurs ou de membres à differents groupes de spécifications (W3C, TC39, WHATWG) et projets (node.js, webkit, navigateurs, fixe et mobile), sur le plan technique le projet est basé sur de nombreuses recherches et a fait l'objet de nombreux tests, un résumé des caractéristiques techniques est disponible dans la section "Technical details"

Nous avons tenté une campagne de financement participatif, infructueuse, il reste cependant conseillé de visiter en premier le lien ici avant d'éventuellement lire ce qui suit.

Introduction et résumé

Généralement, le simple fait d'évoquer une éventuelle anonymité sur internet provoque des réactions souvent agressives tendant à associer cette volonté aux pires maux, négligeant ainsi le droit à chacun d'y avoir recours pour préserver sa vie privée. Cet article présente un résumé des risques et une solution.

Bien qu'un effort de vulgarisation ait été tenté, l'article est un peu long et probablement certains détails techniques (même si simplifiés) échapperont aux personnes non initiées. L'impression qui doit s'en dégager est que le fait de s'anonymiser sur internet n'est pas un luxe réservé à des personnes particulières désirant cacher leurs activités mais que tout le monde est concerné tant les moyens de vous tracker se sont développés et deviennent de plus en plus préoccupants quant au respect de votre vie privée et de celle des plus jeunes qui ont accès désormais très tôt à internet. Ainsi l'article montre par exemple que l'on peut savoir ce que vous faites, où vous achetez, où vont vos enfants à l'école, etc sans même vous connaître, et que les spécifications du web ne vont pas du tout dans le sens de vous protéger.

Pas grave si vous ne faites rien de mal ou n'avez rien à cacher ? Pas sûr, car certains services peuvent en plus collaborer pour non seulement vous pister mais aussi vous intercepter.

Pour vous en convaincre, essayez l'extension Mozilla : Collusion qui montre clairement que le monde entier est au courant de ce que vous faites dès que vous commencez à surfer sur le net.

La solution proposée est une solution universelle qui fonctionne dans tous les navigateurs sans rien avoir à installer, elle se base sur le principe que vous ne faites confiance qu'à vous-même et permet selon ce postulat de chiffrer toutes vos communications même quand vous accédez à des sites qui ne le supportent pas et de cacher le nom du site auquel vous accédez (ma_banque.com devient abcdefg.com) en s'aidant d'un réseau anonymisant dont vous décidez comment vous y accédez qui masquera aussi votre adresse IP réelle et ajoutera une couche de chiffrement aux échanges.

Par "vous ne faites confiance qu'à vous même" il est important de comprendre qu'absolument rien à l'extérieur du navigateur ne sait ce que vous faites, où vous allez ni quelles données vous échangez, seul le navigateur (donc vous) est en mesure de déchiffrer et de comprendre ces informations.

A quoi cela ressemble ? Voir la vidéo :

Pour quels usages ?

Ceux que vous estimez légitimes :

- Cachez votre adresse IP réelle.
- Cachez les domaines et sites que vous visitez.
- Cachez les informations que vous échangez avec ces sites.
- Evitez les trackers et les publicités.
- Evitez les scripts malvenus ou dangereux.
- Court-circuitez les moyens de censure.
- Téléchargez ce que vous voulez.

Pas envie de tout lire ? Voici les conclusions :

Résumé, pros

- rien à installer
- disponible partout à partir de n'importe quel navigateur moderne
- utilisation d'https même pour accéder à des sites qui ne le supportent pas (donc étendant le concept de HTTPS Everywhere )
- destination cachée même durant l'établissement de la connexion https
- pas d'applications tierces
- fondé sur le principe que vous ne faites confiance qu'à vous même, même des imperfections (suspectes ou non) au niveau des navigateurs ne sauraient vous compromettre.
- compte tenu du fait que le code js et le fichier pac peuvent être distribués partout et que vous n'avez besoin que de cela pour utiliser l'OP js, le mécanisme est très difficile à bloquer, voire impossible.

Résumé, cons

- Aucun, nous avions un doute sur les performances mais les premiers essais dans le navigateur montrent que c'est rapide.

Un problème : le Web et la vie privée

Malheureusement (ou fortuitement) le web n'a pas été spécifié pour protéger l'anonymité et la vie privée. C'est en fait tout le contraire dans des proportions que l'utilisateur commun aura du mal à imaginer, la majorité des sites web et compagnies internet font tout leur possible pour vous pister et établir votre profil (trackers, publicités, statistiques, safebrowsing, etc) dans le but de populer leurs bases de données avec vos informations personnelles pour cibler leurs campagnes publicitaires et autres produits dérivés. Mais plus que de collecter vos informations personnelles parfois difficiles à obtenir, ils peuvent corréler ce que vous faites sur internet sans même vous connaître. Essayez par exemple ceci : mon empreinte, vous allez probablement découvrir que vous êtes unique, donc facile à distinguer, au moins pendant un certain temps puisque votre empreinte peut changer pour une autre probablement unique aussi (ceci ne marche que dans un seul sens, le fait d'avoir une empreinte unique ne signifie pas que l'on puisse vous identifier, par contre vous êtes facilement repérable).

Le but ici n'est pas de présenter en détails les aspects techniques liés à la vie privée sur internet mais une vision générale.

Que pouvons nous faire contre ceci ?

Pas grand chose, à part supprimer fréquemment vos cookies, cache et historique, ne pas rester connecté à vos comptes habituels, changer votre adresse IP de votre fournisseur internet périodiquement. Si la protection de la vie privée vous préoccupe il vaut mieux utiliser le navigateur Firefox de Mozilla. Les techniques web permettent très facilement d'envoyer des informations de votre navigateur vers l'extérieur (personnelles ou liées à ce que vous faites) sans que vous en soyez averti ni même puissiez vous en rendre compte. Les navigateurs proposent certaines options ("do not track" par exemple) pour une navigation plus sécurisée mais il est improbable de leur faire confiance dans la mesure où leur efficacité dépend de la volonté des sites à les respecter (cf la polémique actuelle sur les spécifications w3c du "do not track" qui tardent à venir et le consensus commun de saboter apparemment l'ensemble du processus (la décision de Microsoft de l'activer par défaut dans IE10, puis la contre-réaction de Yahoo! donc de ne pas le respecter, etc)). Même certaines options dites sécurisées comme le safebrowsing sont dangereuses dans la mesure où elles envoient des informations à l'extérieur dont vous n'avez ni connaissance ni ne pouvez vérifier.

Ce n'est pas tout

Ce que vous faites peut aussi être intercepté par certaines personnes (votre fournisseur d'accès, un service étatique, des hackers), enregistré et/ou utilisé contre vous (attaques pour récupérer votre cookie de connexion à votre banque par exemple)

Et encore

La censure : certains sites ou réseaux peuvent décider de restreindre vos accès, selon votre localisation, selon où vous voulez aller, selon la fréquence des requêtes que vous émetez, ou bien selon n'importe quel critère qui leur soit seillant.

Quid de l'utilisation d'https ?

HTTPS est suffisamment sécurisé pour une navigation normale mais n'empêche pas quelqu'un de savoir où vous allez. En effet le processus de connexion fait passer en clair le nom du serveur sur lequel vous vous connectez. Par exemple si vous utilisez https://ma_banque.com/mon_compte, ma_banque.com et mon_compte seront chiffrés après établissement de la connexion mais ma_banque.com apparaitra en clair lors de l'établissement de celle ci. Les navigateurs manquent de transparence dans la gestion des certificats utilisés pour établir ces connexions et oublient de suivre les protocoles de révocation, il n'est pas improbable que quelqu'un réussisse à vous envoyer un certificat qui semble correct et intercepte ensuite vos communications (attaque du type "man in the middle"). Un exemple simple est une entité qui exerce à la fois une activité de sécurisation mais aussi d'interception (sociétés privées, états, navigateurs(??),...), en utilisant leurs fonctionnalités sécurisées vous pourriez être amené à installer dans votre navigateur des éléments lui indiquant que vous lui faites confiance, ainsi vous ne vous rendrez pas compte quand cette entité vous interceptera.

Donc faut il utiliser un réseau anonymisant ?

Cela dépend de vous mais il faut être prudent, la plupart des solutions anonymisantes n'anonymisent rien du tout et peuvent même faciliter votre interception. Dans tous les cas vous devez au moins utiliser https ou un autre protocole chiffré au-dessus des informations que vous envoyez vers le réseau anonymisant.

Plus de détails

Pour qu'une solution anonymisante soit fiable, la première des choses est que l'interface d'accès au réseau anonymisant soit localisée dans l'équipement que vous utilisez pour vous connecter. Si l'on fait référence au projet Tor cette interface se nomme "Onion Proxy" (appelé OP dans la suite de cet article). Sinon quiconque placé entre vous et le point d'accès peut voir ce que vous faites. Cela signifie donc que vous devez installer la fameuse interface sur votre équipement, donc que vous faites confiance à celui qui la propose. C'est un premier point gênant, un autre est que ledit fournisseur doit maintenir des versions pour toutes les plateformes (PC, MAC, mobiles, etc) mais cependant ne peut fournir cette interface pour des systèmes fermés (iOS, iPhone, iPad, dont par ailleurs personne ne sait ce qu'ils peuvent bien envoyer vers l'extérieur...). Le réseau Tor par exemple est connu pour être robuste mais il s'agit de faire confiance à ce que fait l'OP, et il n'est pas utilisable à partir de n'importe quel équipement.

Vous trouverez plus de détails sur les principes d'un réseau anonymisant tel que Tor ici : node-Tor

Une solution plausible : un OP en javascript directement dans le navigateur

La solution idéale consisterait donc à être le plus proche possible du navigateur sans avoir quoique ce soit à installer. Il parait donc logique d'envisager l'OP comme un programme javascript directement dans le navigateur. Contrairement à d'autres possibilités (flash, java), javascript est un langage universel déjà intégré dans les navigateurs, donc sans installation et fiable.

Pourquoi devrions nous faire confiance aux navigateurs et à javascript?

Les navigateurs sont développés par des sociétés qui ont pour la plupart un intérêt évident à vous profiler. Par contre les navigateurs sont utilisés par tellement de personnes que le moindre défaut de sécurité ou comportement suspect est immédiatement détecté par la communauté, reporté publiquement et corrigé par les fournisseurs, ils ne peuvent pas se permettre de les ignorer. C'est valable jusqu'à un certain point, cf les précédentes remarques concernant la gestion opaque des certificats, d'autre part certains navigateurs activent par défaut des options de tracking, il est conseillé de vérifier sa configuration et de les désactiver, quoi qu'il en soit le principe de domaine factice expliqué ci-dessous rendra ces méthodes douteuses inopérantes. Il en va de même avec javascript, de plus le code javascript ne peut pas être dissimulé, il est donc plus transparent qu'une quelconque installation sur votre poste, même s'il s'agit d'un projet libre. D'autre part le moins vous installez de modules externes, le mieux c'est, en effet les méthodes classiques d'attaques consistent à infecter des modules périphériques (windows par exemple) pour vous compromettre alors que vous pensez votre application parfaitement sécurisée oubliant qu'elle fait appel à ces modules infectés. L'OP javascript ne peut pas être atteint par ce genre d'attaques, à moins que le navigateur lui-même présente de telles failles.

Pourtant il se dit pas mal de choses sur les problèmes de sécurité liés à javascript...

Oui mais ils sont connus et il y a des techniques de base pour les éviter, les standards javascript incluent des mécanismes spécifiques pour sécuriser les applications, plus de détails ici.

La solution proposée

Vous pouvez regarder ici le projet et le projet (bis) (censés être des diagrammes simplifiés de la solution proposée...). Basiquement l'OP js se comporte comme un "man in the middle" avec la complicité des routeurs anonymisants, il transforme l'adresse saisie en une autre (un domaine factice, mybank.com devient abcdefg.com) et demande au navigateur de charger https://abcdefg.com (donc même si vous vous connectez sur un site qui ne supporte pas https, la communication sera chiffrée). Le navigateur utilise pour ceci l'interface standard SOCKS proxy qui est connectée à un noeud du réseau anonymisant. Celui ci est lui même connecté à l'OP js via l'interface sécurisée websockets, quand il reçoit des messages du navigateur il les renvoie à l'OP js qui les prend en charge via le réseau anonymisant. Donc les communications entre le navigateur et l'OP sont chiffrées, celles entre l'OP et le serveur distant le sont également via le réseau anonymisant (+https si le serveur distant le supporte), pendant tout le processus l'OP est le seul à connaître la véritable identité du serveur de destination.

Et si les censeurs bloquaient les sites qui délivrent le code javascript ?

Les censeurs ne peuvent pas bloquer tout le web. Ils pourraient par exemple bloquer ianonym.com, mais c'est improbable qu'ils bloquent tous les sites partenaires qui hébergent un lien permettant de charger le code javascript.
En dernière extrêmité le code pourrait être contenu directement dans le navigateur via un marque-page par exemple ou pour plus tard : Webcrypto Use Cases - data integrity.

Configuration du Proxy

Disponible dans tous les navigateurs et équipements, il s'agit de configurer le proxy en utilisant un fichier PAC (Proxy Auto Config), par exemple http://ianonym.com/proxy.pac, si le serveur cible est différent de celui qui héberge le fichier l'interface proxy sera établie avec un noeud du réseau anonymisant. Si ianonym.com est bloqué ou que vous ne lui faites pas confiance, le proxy peut être configuré avec un site partenaire, si cela ne vous convient toujours pas vous pouvez utiliser votre propre fichier pac (à vos risques et périls), voir les spécifications ici : Details.

Et si les censeurs bloquaient les noeuds d'entrée du réseau anonymisant ?

Cette possibilité n'est pas spécifique à ce projet, les censeurs pourraient bloquer les noeuds connus mais à nouveau c'est improbable qu'ils les bloquent tous.
De plus de nouveaux moyens sont étudiés pour contourner ceci, comme flash proxies (rien à voir avec Adobe flash) qui montre comment des sites partenaires peuvent être utilisés pour relayer le trafic anonymisant via des navigateurs en utilisant les websockets.

D'autre part de manière analogue il est envisagé dans le cadre de ce projet d'implémenter les noeuds anonymisants dans les navigateurs, les serveurs ne servant plus alors qu'à relayer les informations entre websockets.

Et si les censeurs bloquaient les websockets ?

Les websockets implémentent un protocole spécifique, donc sont faciles à détecter et à bloquer. Maintenant il s'agit d'une des fonctionnalités majeure de HTML5, il est donc logique d'espérer voir le trafic websockets augmenter dans des proportions qui rendent un blocage impossible.

Sécurité des navigateurs

La page web et l'OP contrôlent tout ce qui pourrait aller à l'extérieur du domaine initial (mybank.com) et font en sorte que toutes les requêtes ressemblent à des requêtes vers le domaine factice, rendant de facto la plupart des attaques connues inopérantes (car il n'y a aucun intérêt à vous attaquer/pister sur un domaine factice) et assurant que la destination finale ne soit pas révélée par les messages vers l'extérieur (statistiques, trackers, publicités, etc). La gestion des cookies, du cache et de l'historique s'opère sur le domaine factice, donc séparément du vrai domaine. D'un point de vue javascript, le code de l'OP ne sera pas accessible d'autres codes js, l'OP et la page modifieront les messages reçus de manière adéquate pour des raisons de sécurité (transformation des urls sur le domaine factice, contrôle des cookies, interdiction des scripts, iframe, objects, etc).

Cela peut paraitre quelque peu restrictif mais éliminera en fait tout ce qui vous ennuie habituellement (pub, iframes, objects), par exemple les cookies seront enlevés des réponses reçues des sites externes, donc les scripts corrects seront capables de faire leur travail, les autres non.

Est ce que cela va vraiment marcher ?

Oui! Voir la première communication réussie du 9 Février 2013 (en noir la partie OR, en blanc l'OP dans le navigateur avec les messages de la console web) :

Et les détails de l'implémentation : node-Tor (implémentation en javascript de l'OP et des routeurs anonymisants) et ici experimentation (chargement de page avec le concept de domaine factice), voir aussi les détails techniques pour l'implémentation et les tests live ici où les techniques récentes et futures du web sont considérées. Quelqu'un d'averti pourrait déceler des inconvénients techniques qui en fait se trouvent être des avantages :
- avertissement au niveau du navigateur car l'OP js ne peut pas avoir de certificats valides, plus qu'un défaut c'est une sécurité supplémentaire car cela vous indique que vous discutez bien avec vous-même. Si aucun message d'avertissement n'apparait vous êtes alors certain d'avoir un problème. Il suffit de valider une fois l'avertissement pour ensuite naviguer normalement.
- attaque "Evil 1" : un moyen simple pour l'éviter est de permettre à la page de vérifier que le certificat reçu est bien celui de l'OP (la page et l'OP peuvent communiquer à l'intérieur du navigateur), c'est ce qu'assure cet outil Interception Detector, comme le point précédent cela vous indique de manière certaine que vous discutez bien avec vous-même et qu'il n y a personne qui vous intercepte.
- être certain que le code js et le fichier pac reçus sont bien les bons : il y a des moyens pour le vérifier, considéré également dans les sujets W3C Webcrypto Use Cases - Signed web applications et Webcrypto Use Cases - data integrity.

Avec quel réseau anonymisant ?

Probablement Tor ou un réseau équivalent, les points d'accès doivent comprendre le protocole de l'OP js, ils peuvent être des routeurs dédiés.

Pourquoi devrions nous faire confiance à un réseau anonymisant ?

Vous ne devriez pas, à moins qu'il soit notoire que le protocole utilisé est robuste (comme le protocole Tor) et que le choix des routeurs dans le chemin utilisé est sécurisé (ie que plusieurs routeurs ne soient pas contrôlés par la même entité ou des entités douteuses, c'est ce que l'OP js assure)

Voir ici pour la théorie, basiquement vous ne pouvez pas empêcher quelqu'un qui contrôle le noeud d'entrée et celui de sortie de corréler le trafic entre les deux et de déterminer ainsi qui vous êtes et ce que vous faites, les routeurs iAnonym n'implémentent pas la fonction exit, ainsi il est improbable que le premier et le dernier noeud soient contrôlés par la même entité.

Inspection des paquets

Le trafic sur l'interface SOCKS ressemble à un trafic normal (non décelable comme un trafic anonymisé), celui sur l'interface websocket peut être obfusqué/camouflé par l'OP si besoin.

Est ce que ces concepts ne deviendront pas obsolètes rapidement ?

Non, voir les détails de l'implémentation et les tests à nouveau ici, une des idées est de laisser le navigateur faire son travail normalement sans interférer, c'est pourquoi l'interface SOCKS proxy est utilisée, il n y a pas des milliers de façons d'implémenter l'OP dans le navigateur avec ce concept (et quasiment aucune sans). Les évolutions futures du web ne laissent pas entrevoir d'améliorations possibles conséquentes sauf en terme de sécurité et d'optimisations/performances.

Est ce qu'il ne serait pas plus facile de construire un navigateur spécifique ?

Non, même si des projets comme webkit, chrome et Mozilla permettent de construire des navigateurs, il parait utopique de maintenir des navigateurs parallèles avec les mêmes niveaux de performances, idem pour les extensions/plug-in qui ne seraient pas standard ni disponibles partout, les deux dépendant des équipements et nécessitant de maintenir différents packages.

Peut être alors un acteur important du web implémentera un jours l'anonymisation ?

C'est improbable...et de toute manière ce ne serait pas disponible partout de n'importe quel équipement.

Résumé, pros

Résumé, cons

- Aucun, nous avions un doute sur les performances mais les premiers essais dans le navigateur montrent que c'est déjà rapide.

Intermède - probablement vous esquissez un tableau exagéré...

...et vous devriez urgemment consulter pour votre problème paranoïaque.

Pas vraiment, cet article ne détaille pas tout et la tendance ne risque pas de s'inverser, les risques restent invisibles et insoupçonnés pour l'utilisateur non (extrêmement) averti, tout comme pour les webmasters qui ne mesurent pas vraiment ce que font les modules qu'ils incluent dans leurs pages web.

Specs summary :

The user goes to ianonym.com or a partner site (which can be a node of the anonymizer network).
Partners must be trustable and do retrieve the code (ianonym.js) and the proxy file (proxy.pac) periodically from ianonym.com.
ianonym.com updates dynamically proxy.pac according to the status of routers.
Browsers dns resolution for socks requests must be disabled.
If connected to a partner site, the user clicks on ianonym tag, this does execute the ianonym js code :

the tag looks like : <div onmousedown="(send xhr to ianonym.js;eval(result)) or (insert a script src="ianonym.js")">Anonymity everywhere </div>

#fake_domain_prefix generation

The OP generates a fake_domain_prefix and sends a xhr to proxy.pac, then executes the function FindProxyForURL with fake_domain_prefix to retrieve the OR parameters :

FindProxyForURL(url,host,bool) {
  if (bool) {
    return {ip:ip,port:port,server:name,fingerprint:fingerprint,modulus:modulus};
  };
}

The OP starts testing if it can establish a websocket connection with the OR :

ws = "ws://fake_domain_prefix.com:port"
If not already done the user sets the browser socks v5 proxy to ianonym.com/proxy.pac, next websocket messages from the OP will be processed via the socks interface to the OR.

If ianonym.com is blocked, the user sets the proxy to partner/proxy.pac.

The pac file looks like :

function FindProxyForURL(url, host) {
if ((dnsDomainIs(host, "ianonym.com" or partner site)) &&(url.indexOf('ianonym.com') or partner site !==-1)) {return 'DIRECT'}; //no proxy is used when you go to ianonym.com or a partner site
return "SOCKS5 OR:port"; //where OR is (randomely) chosen based on the value of fake_domain_prefix in host
}

Websocket requests via socks interface are intercepted and answered by the OR, one websocket connection is set (called 'Websocket' in the following), if possible (OR certificate is valid) the OP sets a tls secure websocket (TLS1) with the OR.
The OP does establish circuits with the OR inside the network :
if this fails the OP chooses another fake_domain_prefix to get another OR and restarts the process.
circuits are created via Websocket which acts as the usual tls socket between the OP and the OR.
An encryption key K (used by crypt below) is generated (by the system or chosen by the user).
The user enters an URL http(s)://www.example.com (real_domain).

#socks processing

The OP associates the real_domain to :

fake_domain=[fake_domain_prefix+crypt(real_domain).com]

and asks the OR to associate fake_domain to Websocket (with RELAY_ASSOCIATE/RELAY_WS encrypted messages, see Websockets Tor extension protocol).
The OP asks the browser to load https://fake_domain.
The OR receives the CONNECT socks message to fake_domain from port x, it checks that remote IP is the IP of Websocket and that fake_domain is known, if so it replies OK right away and associates [request on port x] with fake_domain/Websocket, if not it closes the connection on port x.
The OR receives a Client Hello message with a server name set to fake_domain from socks interface on port x, it sends the message (RELAY_WS) to the OP with socks incoming port x indication via Websocket.
The OP replies to the OR (RELAY_WS) with messages (Server Hello, etc) and port x indication.
The OR sends the responses on socks interface on port x, for subsequent messages on port x the OR sends it to the OP via websocket and vice-versa (RELAY_WS).
Once the handshake is complete (TLS2), the OP should check with the page that it was indeed its certificate that was used during the handshake, the OP and the page can communicate inside the browser.
The OP chooses a circuit/stream_id and sends a connect message to the network (RELAY-RELAY_BEGIN).
Once connected (RELAY-RELAY_CONNECTED) the OP processes the header of the initial socks request (restore fake_domain to real_domain or other_domain (see below) and change some other parameters (remove Referer, Cookie for other_domain, etc)) and sends the request to the OR (RELAY-RELAY_DATA - if the user entered https://www.example.com, the OP performs a TLS negociation with www.example.com and checks its certificate (TLS3)).
The OP receives the responses (RELAY-RELAY_DATA), according to the Content-Type field of the header different operations might occur :

- remove/add what is required in headers
- add a script to "tame" the page and transform urls (indicating to the page K and real_domain)
- transform urls :

'test.png' --> test.png
'x://real_domain/rest' --> 'https://fake_domain/rest'
'x://other_domain/rest' --> 'https://fake_domain/crypt(x://other_domain/rest)

The OP sends the response to the OR via Websocket (RELAY_WS) with the socks incoming port x indication, the OR sends the response message on socks interface port x.
The page loads resources, the OR receives socks connect requests from ports x,y,z, if the target domain is a known fake_domain, it does send the requests to the OP via Websocket with incoming port indication (RELAY_WS), the OP restarts the process as explained above : target domain resolution, request modification, then RELAY_BEGIN (if not already connected) or RELAY_DATA. If the target domain is unknown, requests are discarded.
If for a given socks request the target domain does not resolve to real_domain, is not an ajax request and the Content-type field of the response contains "text/html", the OP does intercept the answer and replies instead with a "Moved Permanently" response with Location field = [fake_domain_prefix+crypt(new_domain).com].
If for a given socks request the response contains the field "Location" the OP substitutes it with a "Moved Permanently" response with Location field = [https://fake_domain/crypt(Location)].
For this last case the OP associates new_domain to the new fake_domain and asks the OR to associate the new fake_domain to Websocket (RELAY_ASSOCIATE), it closes the RELAY stream (RELAY_END) and asks the OR to close the initial socks requests after the "Moved Permanently" message has been sent, the browser does resend a request with the new fake_domain. This is to insure that while navigating a new fake_domain is allocated each time the user changes domain.
If for a given socks request the response contains the field "Location" the OP substitutes it with a "Moved Permanently" response with Location field = [https://fake_domain/crypt(Location value)].

Notes :

- the pseudo random number generator algorithm used does not depend on the OS or on the browser, this is a specific algorithm taking entropy from the unexpected events occuring inside the network and their associated values while establishing circuits not catchable or predicatble by an observer.

- the OP chooses a dedicated reduced circuit to stream websocket instructions to the OR (RELAY_ASSOCIATE/RELAY_WS see Websockets Tor extension protocol, the OR does the same and associates [list of fake_domain_prefix+crypt(real domain).com]/[dedicated CID (ie Websocket)]. Non OP/Browser data are streamed among other circuits available (via Websocket too).

- the K key can be chosen by the user and is used for the fake_domain_prefix generation, so data can be cached as long as the key does not change.

- the browser thinks that all urls are toward fake-domain then tries to stream all the requests among a few socks connections, the OP keeps memory of open connections and streams the requests according to the target domain's open connections. When the target domain changes for a given socks connection, the OP may ask the OR to close the initial socks connection and the browser will open new socks connections to continue sending requests. But to avoid establishing numerous TLS connections, the system must keep alive the initial connections as long as it can.

- Security and same origin policy : as mentionned above the design choice for now is to transform all the urls so they seem to belong to the same origin. The urls could be transformed according to their origin but then loading of other origins ressources will silently fail while using SSL/TLS with non valid certificates. Then to recover the same origin protection, all active contents and iframes from different origins will be disabled, cookies are not passed to outside origins and cookies from outside origins are removed too. In practice this will not load or make fail all usual means used for ads and tracking. In addition a script is inserted into the page ton control that nothing in the page could create things going toward outside origins, and more globally script/active content/iframe injections are forbidden (after page loading for scripts).

- two users behind the same NAT navigating on the same site could have the same fake_domain (same fake_domain_prefix, same K), this situation is unlikely but could happen, in that case after receiving a second RELAY_ASSOCIATE on an existing fake_domain the OR will cancel it and ask both OPs to restart the process from fake_domain generation.

- even if for now this possibility is forbidden, a corollary of preceeding point is that it's not uninteresting to note that the anonymized traffic for a given user could go through the browser of another one (a bit like flash proxies).

- another corollary is that it is possible to envision the OR inside the browser too while the server is just relaying messages between browsers via websockets.

Anonymity inside your browser, everywhere from any device

Why did we launch the iAnonym project?

Introduction and summary

What do you use it for?

Summary, pros

Summary, cons

The problem: the Web and anonymity

What can you do to counterattack?

And there's more

And more

What if you are using https?

So do you have to use an anonymiser network?

More details

The solution: the OP inside the browser in javascript

Why should you trust the browsers and javascript?

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

The proposed solution

What if censors block the sites delivering the javascript code?

Proxy configuration

What if censors block the SOCKS interface nodes?

What if censors block Websockets?

Browser security

Will it really work?

Which anonymiser network?

Why should you trust the anonymiser network?

Packet inspection

Won’t these concepts soon be obsolete?

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

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

Summary, pros

Summary, cons

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

L'anonymité dans votre navigateur, partout, à partir de n'importe quel équipement

Pourquoi ce projet ?

Introduction et résumé

Pour quels usages ?

Résumé, pros

Résumé, cons

Un problème : le Web et la vie privée

Que pouvons nous faire contre ceci ?

Ce n'est pas tout

Et encore

Quid de l'utilisation d'https ?

Donc faut il utiliser un réseau anonymisant ?

Plus de détails

Une solution plausible : un OP en javascript directement dans le navigateur

Pourquoi devrions nous faire confiance aux navigateurs et à javascript?

Pourtant il se dit pas mal de choses sur les problèmes de sécurité liés à javascript...

La solution proposée

Et si les censeurs bloquaient les sites qui délivrent le code javascript ?

Configuration du Proxy

Et si les censeurs bloquaient les noeuds d'entrée du réseau anonymisant ?

Et si les censeurs bloquaient les websockets ?

Sécurité des navigateurs

Est ce que cela va vraiment marcher ?

Avec quel réseau anonymisant ?

Pourquoi devrions nous faire confiance à un réseau anonymisant ?

Inspection des paquets

Est ce que ces concepts ne deviendront pas obsolètes rapidement ?

Est ce qu'il ne serait pas plus facile de construire un navigateur spécifique ?

Peut être alors un acteur important du web implémentera un jours l'anonymisation ?

Résumé, pros

Résumé, cons

Intermède - probablement vous esquissez un tableau exagéré...

Specs summary :

tbd