L'ICTA se propose donc de décrypter nos échanges avec Facebook, et il serait de bonne guerre pour nous de commencer par décrypter les récentes communications du régulateur.

Au vu des récents commentaires du public qui ont largement couvert l'impact social, ou plutôt antisocial, des mesures proposées, il n'y a pas lieu d'en rajouter une couche à ce niveau. Par contre se serait intéressant de se demander pourquoi le régulateur a publié une ébauche de projet avant même d'avoir eu l'avis du principal intéressé, c'est-à-dire Facebook. D'autant plus que le scenario proposé dans le document paraît impraticable tel quel.

Au départ l'ICTA fait la constatation que la prolifération des posts publics offensants sur Facebook ne peut être contrôlée pour deux raisons:

Problématique A - Cette pratique est souvent liée à de faux profils difficiles à retracer

Problématique B - Lorsqu'une plainte est soumise à Facebook pour enlever ces posts, très souvent aucune action n'est entreprise, car ceux-là ne dérogent pas à ses règles d'utilisation, selon Facebook.

L'ICTA nous propose donc une solution technique pour résoudre un problème société. Voyons pour commencer comment fonctionne cette solution.

Après avoir installé ses équipements l'ICTA décidera qu'à partir d'un moment déterminé, par exemple à minuit le 1er Mai 20XX, tout le trafic de Facebook passera par son serveur proxy. Donc à partir de ce moment si quelqu'un se connecte à Facebook, il sera automatiquement dirigé vers le serveur proxy de l'ICTA et ce serveur demandera à l'utilisateur d'installer un certificat (self-signed certificate) pour permettre à son navigateur internet (Google Chrome ou autre) de diriger son trafic Facebook vers l’ICTA, en apparaissant comme un traffic sécurisé. Cette manipulation est nécessaire uniquement à la première connexion. Ensuite l'utilisateur devra entrer son identifiant et mot de passe de Facebook pour reprendre ses activités sur le réseau social, alors que tous ses échanges transiteront désormais par le serveur proxy qui pourra stocker, analyser et utiliser ses données d'une façon ou d'une autre. Il est à noter que le serveur proxy pourra avoir accès à absolument tout ce qui est communiqué avec Facebook:

- Les commentaires publics

- Les échanges privés

- L'identifiant et le mot de passe de Facebook de l'utilisateur au moment du login

- Les 'metadata' qui englobe toutes les données de l'utilisateur glanées par Facebook, incluant l'adresse IP qui identifie le point d'accès internet

- Les Views, Likes, Shares etc Comment cela permettra-t-il de résoudre les deux problématiques identifiées au départ?

- Problématique A: On peut identifier l'utilisateur par son adresse IP, mais ce n'est pas toujours possible (par exemple dans le cas d'un accès WiFi public, ou à partir d'un pays étranger).

Cela permettra donc d'essayer de retracer les utilisateurs de faux profils à travers les adresses IP, sans aucune garantie que cela pourrait se faire dans tous les cas.

- Problématique B: L'ICTA nous dit seulement que l'utilisateur serait bloqué, ce qui est tout à fait possible, mais ne mentionne pas comment seront traités les posts offensants déjà en ligne. Si on continue à demander à Facebook d'intervenir, on n'aurait pas avancé d'un iota par rapport à la situation actuelle.

Ce manque de précision dans le document laisse certains doutes, car le serveur proxy de l'ICTA fournit au moins deux moyens, certes pas infaillibles, pour enlever des posts soumis par un internaute:

1. On peut mettre en place un filtrage de mots clés qui va bloquer en amont la soumission de tous les posts contenant ces mots

2. Avec les identifiants et mots de passe interceptés par le serveur proxy, on peut accéder au compte de l'utilisateur pour enlever les posts mis en cause. Cela devient plus compliqué si l'utilisateur utilise un "2- factor authentication" mais la grande majorité n'est probablement pas au courant de cette fonctionnalité.

La deuxième option est la plus facile à mettre en place mais pose de sérieux problèmes de confidentialité, car rien ne peut garantir que seuls les faux profils seraient sujets à une telle intrusion. Que fera l'ICTA?

Cependant le plus inquiétant c'est la légèreté avec laquelle on prétend pouvoir accéder aux données des utilisateurs de Facebook. L'internet est un réseau public par lequel on doit faire aussi passer les informations privées. Le fondement de la sécurité, chez Facebook et aussi beaucoup d'autres, repose sur deux critères: l'accès contrôlé par des mots de passe, et le protocole https qui sert à crypter les données échangées entre le fournisseur de service et son utilisateur. Et l'ICTA veut mettre en place un serveur proxy pour éliminer ces deux éléments de confidentialité! Techniquement c'est possible de le faire. Dans le dos de Facebook. Mais de là à espérer avoir l'accord de Facebook pour nos beaux yeux, est totalement inconcevable. Par contre on peut envisager une législation qui imposerait ces contraintes aux sites locaux qui devront s'y conformer, car la seule alternative pour les réfractaires serait de fermer boutique.

En fait aucun réseau social ne sera disposé à fournir les mots de passe de ses utilisateurs, et ils ont les moyens de refuser car ils ne peuvent pas être intimidés facilement. Le cas de Facebook est encore plus parlant. Imaginons un instant que Facebook commence à laisser des tierces parties accéder à ses données. Tout le business model de Facebook est basé sur la collecte de données pour en extraire des informations sur le profil de l'utilisateur. Laisser à quelqu'un d'autre accéder à ces données pourrait remettre en cause l'existence même de Facebook, car d'autres pays pourraient suivre la même voie, pour le profilage de leur population, et affaiblir le monopole de Facebook à moindre frais.

Mais l'aspect le plus grave qui devrait nous interpeller c'est l'utilisation d'un "self-signed certificate" sur le serveur proxy de l'ICTA, et il est extrêmement important de comprendre de quoi il en retourne. On aurait tort de penser que ce n'est qu'un artifice technique, et le Kazakhstan en a fait les frais.

Pour mettre en place le protocole sécurisé https entre un utilisateur et le domaine facebook.com, le serveur de Facebook va transmettre au navigateur de l'utilisateur, admettons Google Chrome, un certificat qui prouve que c'est bien un serveur de Facebook avec qui on communique. Mais il faut un moyen pour garantir que ce certificat est authentique afin d'éviter qu'un hacker ne fournisse un certificat pour se présenter comme Facebook. En pratique il y a un certain nombre de Certificate Authority qui sont reconnus pour signer ce certificat digitalement afin de l'authentifier, et garantir que le serveur qui émet ce certificat est bien de Facebook. C'est la seule façon pour Facebook de garantir son identité à l'utilisateur.

Toutefois il y a des situations où l'utilisation des "self-signed certificate" est de mise. Ces certificats sont gratuits, et peuvent par exemple être utilisés dans des environnements de développement de projets, ou alors a l'intérieur d'une entreprise non accessible de l'extérieur. Par définition ces certificats ne sont pas authentifiés par un Certificate Authority, mais par l'émetteur du certificat lui-même. Autant dire qu'ils ne garantissent en rien de l'identité de l'émetteur. Il n'y a rien qui techniquement empêche a quiconque de créer un "self-signed certificate" pour dire qu'il est du domaine facebook.com, et c'est ce que voudrait faire l'ICTA d'après son document. Ainsi lorsque votre navigateur voudra accéder à www.facebook.com le serveur proxy de l'ICTA lui transmettra un "selfsigned certificate" pour s'identifier comme un serveur de Facebook.

Cela soulève plusieurs questions:

1. Que se passe-t-il si un hacker se fait passer pour l'ICTA en utilisant un "self-signed certificate"?

2. Facebook est certainement un nom protégé. Peut-on créer un "self-signed certificate" pour le domaine de Facebook sauf si on a son accord?

3. Les navigateurs sont réfractaires aux "self-signed certificate" pour éviter des piratages. Que faire si le "selfsigned certificate" de l'ICTA est bloqué par les navigateurs de Google, Microsoft etc?

4. Quel sera l'impact de l'utilisation officielle de "self-signed certificate" par un régulateur? Surtout dans un pays qui veut promouvoir le secteur de TIC.

Certains peuvent penser que l'ICTA n'utilise pas les certificats authentifiés par un Certificate Authority pour minimiser les coûts. Mais la raison toute simple c'est que le certificat doit être établi pour le domaine facebook.com et seule Facebook peut posséder de tels certificats authentifiés par un Certificate Authority. Sinon cela voudrait dire que le Certificate Authority certifie que le serveur proxy de l'ICTA est un serveur de Facebook.

L'autre possibilité serait qu'au lieu du https, le serveur proxy utilise le http, qui n'a pas besoin de certificat. Mais cela ouvre un autre débat car on commencerait à avancer à reculons dans le monde des TIC. Le http est une large porte ouverte aux hackers.

Aussi l'ICTA met en avant son système de blocage de sites pédophiles, se proposant de l’étendre à Facebook. Mais ce n'est absolument pas la même chose de bloquer un site entièrement, ou de décrypter le protocole https pour accéder au contenu des échanges afin de bloquer certains échanges. C'est comme si au lieu de demander au facteur de ne pas délivrer une lettre à une adresse, on lui demandait de décacheter les lettres, les lire et enlever certaines pages avant recacheter et de livrer.

Tout ceci jette un flou sur le projet de l'ICTA car on se demande pourquoi il faut publier un document de consultation pour les échanges avec Facebook, avant même d'avoir confirmé avec le principal concerné que c'est un projet viable. Le plus grave serait de légiférer avant de clarifier avec Facebook car cela pourrait alors laisser croire qu'il y a d'autres objectifs, d'autant plus que c'est invraisemblable que Facebook puisse donner son accord pour la mise en place d'un tel serveur proxy.