Dès lors que j'ai un compte sur un réseau social comme Twitter, Facebook ou autre, je peux publier des messages. Quiconque veut me suivre peut se connecter à mon compte et voir mes messages. Je ne suis pas obligé de suivre cette personne en retour. Ainsi je peux donc suivre les comptes qui m'intéresse. Et les gens que j'intéresse me suivent. Ce fonctionnement est assez simple et compréhensible par tout utilisateur de ces réseaux.
Dans le cas de Diaspora, c'est un peu différent... C'est ce que ce billet va vous expliquer.
Diaspora
Rappel : Framasphère repose sur le logiciel Diaspora et est donc un pod du réseau Diaspora
Je cite une dépêche Diaspora sur Linuxfr.orgUne des choses importante à comprendre, c'est que diaspora propose des échanges asymétriques. Dans le cas d'un échange symétrique, il faut que les deux participants (appelons les Alice et Bob) acceptent d'échanger pour pouvoir voir les posts de l'autre. Dans le cas de diaspora, même si Bob n'accepte pas Alice, il peut voir les posts d'Alice, si elle le souhaite. Concrètement, supposons que Bob soit la star de l'information sur Linux. Tout le monde le suit. Alice suit Bob, qu'elle a classé dans les aspects info et Linux, mais elle ne poste que des images de kitten, avec quelques informations sur Linux. Bob, qui n'aime pas les kittens, ne veut pas suivre les messages d'Alice, pour ne pas pourrir son flux. Par contre, il suit le tag Linux. Lorsqu'Alice décide de partager une information à propos de Linux avec son aspect Linux, Bob aura accès au message via le tag, même s'il n'est pas public.
Quelles conséquences ?
Dès lors que j'ai un compte Diaspora, je dois partager ma clef avec d'autres pour que ces personnes aient accès mes messages. Là où sur les autres réseaux sociaux je m'abonne à d'autres personnes pour les suivre et celle que j'intéresse s'abonne à moi, sur Diaspora, on doit définir les utilisateurs vers lesquels on partage du contenu en les ajoutant dans un cercle (public, amis, privés), cette notion de cercle étant ensuite utilisé lorsque l'on rédige un message (on choisit dans quel cercle on diffuse ce message).
Pour qu'un message que je publie de façon publique arrive sur le fil/stream/mur des personnes que je peux intéresser, il aura donc fallu que pour chaque compte de ces personnes, je les ajoute dans un cercle (en coulisse, il y a un échange de clefs, cf la documentation). Ou que cette personne suive/s'abonne à un tag que je vais utiliser dans mon message (ce qui aura pour conséquence, si le post est dans le cercle public, qu'il soit visible de toutes personnes suivant ce tag).
Ce mode de fonctionnement permet de la sécurité et de la vie privée (vu que les échanges de messages entre pod sont chiffrés), mais comme à chaque fois qu'on souhaite plus de sécurité/vie privée, il y a donc une contrainte assez forte (celle d'ajouter les comptes) qui peut s'avérer un frein réel à l'adoption de ce réseau (surtout si on est dans la course au nombre d'abonné, vu que là il faut aller les chercher un par un...).
Pourquoi Diaspora m'affiche plusieurs fois les mêmes messages
Dans le cas de Twitter par exemple, quand quelqu'un retwitt un twitt, il est filtré. Diaspora affiche tous les messages ainsi que les repartage de message que l'on aura déjà pu lire, sans les filtrer. On a donc dans son flux X fois le même message, la même image etc. Si vous avez bien compris le principe de Diaspora et d'échange de clefs, mettre en place un filtre de message déjà lu sera très difficile car on est face à plusieurs canaux différents et non communs...
Diaspora et la sécurité
Diaspora est par nature décentralisé avec un ensemble de serveurs (pods) qui interagissent entre eux. Donc, pour plus de sécurité, on choisira de s'inscrire sur un pod dont on connait l'administrateur et dans lequel on a confiance. Ou alors on lancera son propre pod. Ainsi, on aura la contrôle sur son compte, l'accès à ses données...
Si un pod est saisi, les autres pods sont en relative sécurité et on dilue donc le contrôle qu'un attaquant peut avoir sur ce réseau / les serveurs vu qu'ils sont décentralisés...
Par contre dès lors que les données (messages textes ou autres) sont diffusées à quelqu'un, on perd d'une certaine façon le contrôle dessus (rien n'empêche la personne de faire un copier-coller ou une capture d'écran) et le fait d'utiliser Diaspora ne changera rien de ce point de vue là....
Des voies critiques s’élèvent régulièrement contre les risques encourus par l’utilisation de Github par les projets du Logiciel Libre. Et pourtant l’engouement autour de la forge collaborative de la startup Californienne à l’octocat continue de grandir.
L’octocat, mascotte de Github
Ressentis à tort ou à raison comme simples à utiliser, efficaces à l’utilisation quotidienne, proposant des fonctionnalités pertinentes pour le travail collaboratif en entreprise ou dans le cadre d’un projet de Logiciel Libre, s’interconnectant aujourd’hui à de très nombreux services d’intégration continue, les services offerts par Github ont pris une place considérable dans l’ingénierie logicielle ces dernières années.
Quelles sont ces critiques et sont-elles justifiées ? Nous proposons de les exposer dans un premier temps dans la suite de cet article avant de peser le pour ou contre de leur validité.
1. Points critiques
1.1 La centralisation
L’application Github appartient et est gérée par une entité unique, à savoir Github, inc, société américaine. On comprend donc rapidement qu’une seule société commerciale de droit américain gère l’accessibilité à la majorité des codes sources des applications du Logiciel Libre, ce qui représente un problème pour les groupes utilisant un code source qui devient indisponible, pour une raison politique ou technique.
De plus cette centralisation pose un problème supplémentaire : de par sa taille, ayant atteint une masse critique, elle s’auto-alimente. Les personnes n’utilisant pas Github, volontairement ou non, s’isolent de celles qui l’utilisent, repoussées peu à peu dans une minorité silencieuse. Avec l’effet de mode, on est pas « dans le coup » quand on n’utilise pas Github, phénomène que l’on rencontré également et même devenu typique des réseaux sociaux propriétaires (Facebook, Twitter, Instagram).
1.2 Un logiciel privateur
Lorsque vous interagissez avec Github, vous utilisez un logiciel privateur, dont le code source n’est pas accessible et qui ne fonctionnent peut-être pas comme vous le pensez. Cela peut apparaître gênant à plusieurs points de vue. Idéologique tout d’abord, mais peut-être et avant tout pratique. Dans le cas de Github on y pousse du code que nous contrôlons hors de leur interface. On y communique également des informations personnelles (profil, interactions avec Github). Et surtout un outil crucial propriétaire fourni par Github qui s’impose aux projets qui décident de passer chez la société américaine : le gestionnaire de suivi de bugs.
Windows, qui reste le logiciel privateur par excellence, même si d’autres l’ont depuis rejoint
1.3 L’uniformisation
Travailler via l’interface Github est considéré par beaucoup comme simple et intuitif. De très nombreuses sociétés utilisent maintenant Github comme dépôt de sources et il est courant qu’un développeur quittant une société retrouve le cadre de travail des outils Github en travaillant pour une autre société. Cette fréquence de l’utilisation de Github dans l’activité de développeur du Libre aujourd’hui participe à l’uniformisation du cadre de travail dudit développeur.
L’uniforme évoque l’armée, ici l’armée des clones
2. Validité des points critiques
2.1 Les critiques de la centralisation
Comme dit précédemment, Github est aujourd’hui la plus grande concentration de code source du Logiciel Libre. Cela fait de lui une cible privilégiée. Des attaques massives par dénis de service ont eu lieu sur plusieurs jours les 27 mars, puis le 25 août 2015. De même, une panne le 15 décembre 2015 a entraîné l’indisponibilité de 5% des dépôts. Idem le 15 novembre. Et il s’agit des incidents récents déclarés par les équipes de Github elles-mêmes. On peut imaginer un taux d’indisponibilité moyen des services bien supérieur.
2.2 Les critiques relatives à utiliser un logiciel privateur
Cette critique, avant tout idéologique, se heurte à la conception même que chacun des membres de la communauté se fait du Logiciel Libre, et en particulier d’un critère : contaminant ou non, qu’on résume en général par GPL versus MIT/BSD.
Les défenseurs du Logiciel Libre contaminant vont être gênés d’utiliser un logiciel propriétaire car ce dernier ne devrait pas exister. Il doit être assimilé, pour citer Star Trek, car il est une boîte noire communicante, qui met en danger la vie privée, détourne nos usages à des fins commerciales, gêne ou contraint la liberté de jouir entièrement de ce qu’on a acquis, etc.
Les pendants d’une totale liberté sont moins complexés dans leur utilisation des logiciels privateurs puisqu’ils acceptent l’existence desdits logiciels privateurs au nom d’une liberté sans restriction. Ils acceptent même que le code qu’ils développent aboutissent dans ces logiciels, ce qui arrivent bien plus souvent qu’on ne le croit, voir à ce sujet la liste à couper le souffle des produits commerciaux reposant sur FreeBSD. On peut donc voir dans cette aile de la communauté du Logiciel Libre une totale sérénité à utiliser Github. Et ce qui est cohérent vis-à-vis de l’idéologie soutenue. Si vous êtes déjà allé au Fosdem, un coup d’œil dans l’amphithéâtre Janson permet de se rendre compte de la présence massive de portables Apple tournant sous MacOSX.
FreeBSD, principal projet des BSD sous licence MIT
Mais au-delà de cet aspect idéologique pur et pour recentrer sur l’infrastructure de Github elle-même, l’utilisation du gestionnaire de suivi de bugs de Github pose un problème incontournable. Les rapports de bugs sont la mémoire des projets du Logiciel Libre. Il constitue le point d’entrée des nouveaux contributeurs, des demandes de fonctionnalités, des rapports de bugs et donc la mémoire, l’histoire du projet qui ne peut se limiter au code seul. Il est courant de tomber sur des rapports de bugs lorsque vous copiez/collez votre message d’erreur dans un moteur de recherche. Mémoire précieuse non seulement pour le projet lui-même, mais aussi pour ses utilisateurs actuels et à venir.
Github propose d’extraire les rapports de bugs via son API, certes, mais combien de projets anticiperont une éventuelle défaillance de Github ou un retournement de situation arrêtant brusquement le service ? Très peu à mon avis. Et comment migrer vers un nouveau système de suivi de bugs les données fournies par Github ?
L’exemple de l’utilitaire de gestion de listes de choses à faire (TODO list) Astrid, racheté par Yahoo! il y a quelques années reste un très bon exemple de services ayant grandi rapidement, largement utilisé et qui a fermé du jour au lendemain, proposant pendant quelques semaines seulement d’extraire ses données. Et il s’agissait là d’un simple gestionnaire de tâches à faire. Le même problème chez Github serait dramatiquement plus difficile à gérer pour de très nombreux projets, si on leur laisse la possibilité de le gérer. Certes le code reste disponible et pourra continuer de vivre ailleurs, mais la mémoire du projet sera perdue, alors qu’un projet comme Debian approche aujourd’hui les 800000 rapports de bugs. Une vraie mine d’or d’informations sur les problèmes rencontrés, les demandes de fonctionnalités et le suivi de ces demandes. Les développeurs du projet CPython qui passe chez Github ont anticipé ce problème et ne vont pas utiliser le système de suivi de bugs de Github.
Debian, l’un des principaux projets du Logiciel Libre avec autour de 1000 contributeurs officiels
2.3 L’uniformisation
La communauté du Logiciel Libre oscille sans cesse entre un besoin de normes afin de réduire le travail nécessaire pour l’interopérabilité et l’attrait de la nouveauté, caractérisée par l’intrinsèque besoin de différence vis-à-vis de l’existant.
Github a popularisé l’utilisation de Git, magnifique outil qui aujourd’hui touche des métiers bien différents des programmeurs auxquels il était initialement lié. Peu à peu, tel un rouleau compresseur, Git a pris une place si centrale que considérer l’usage d’un autre gestionnaire de sources est quasiment impossible aujourd’hui, particulièrement en entreprise, malgré l’existence de belles alternatives qui n’ont malheureusement pas le vent en poupe, comme Mercurial.
Un projet de Logiciel Libre qui naît aujourd’hui, c’est un dépôt Git sur Github avec un README.md pour sommairement le décrire. Les autres voies sont totalement ostracisées. Et quelle est la punition pour celui qui désobéit ? Peu ou pas de contributeurs potentiels. Il semble très difficile de pousser aujourd’hui le contributeur potentiel à se lancer dans l’apprentissage d’un nouveau gestionnaire de sources ET une nouvelle forge pour chaque projet auquel on veut contribuer. Un effort que fournissait pourtant tout un chacun il y a quelques années.
Et c’est bien dommage car Github, en proposant une expérience unique et originale à ses utilisateurs, taille à grands coups de machette dans les champs des possibles. Alors oui, sûrement que Git est aujourd’hui le meilleur des système de gestion de versions. Mais ça n’est pas grâce à cette domination sans partage qu’un autre pourra émerger. Et cela permet à Github d’initier à Git les nouveaux arrivants dans le développement à un ensemble de fonctionnalités très restreint, sans commune mesure avec la puissance de l’outil Git lui-même.
Centralisation, uniformisation, logiciels privateurs et bientôt… fainéantise ?
Le combat contre la centralisation est une part importante de l’idéologie du Logiciel Libre car elle accroît le pouvoir de ceux qui sont chargés de cette centralisation et qui la contrôlent sur ceux qui la subissent. L’aversion à l’uniformisation née du combat contre les grandes firmes du logiciel souhaitant imposer leur vision fermée et commerciale du monde du logiciel a longtemps nourri la recherche réelle d’innovation et le développement d’alternatives brillantes. Comme nous l’avons décrit, une partie de la communauté du Libre s’est construit en opposition aux logiciels privateurs, les considérant comme dangereux. L’autre partie, sans vouloir leur disparition, a quand même choisi un modèle de développement à l’opposé de celui des logiciels privateurs, en tout cas à l’époque car les deux mondes sont devenus de plus en plus poreux au cours des dernières années.
L’effet Github est donc délétère au point de vue des effets qu’il entraîne : la centralisation, l’uniformisation, l’utilisation de logiciels privateurs comme leur système de gestion de version, au minimum. Mais la récente affaire de la lettre « Cher Github… » met en avant un dernier effet, totalement inattendu de mon point de vue : la fainéantise. Pour les personnes passées à côté de cette affaire, il s’agit d’une lettre de réclamations d’un nombre très important de représentants de différents projets du Logiciel Libre qui réclament à l’équipe de Github d’entendre leurs doléances, apparemment ignorées depuis des années, et d’implémenter de nouvelles fonctionnalités demandées.
Mais depuis quand des projets du Logiciel Libre qui se heurtent depuis des années à un mur tentent-ils de faire pleurer le mur et n’implémentent pas la solution qui leur manquent ? Lorsque Torvald a subi l’affaire Bitkeeper et que l’équipe de développement du noyau Linux n’a plus eu l’autorisation d’utiliser leur gestionnaire de versions, Linus a mis au point Git. Doit-on rappeler que l’impossibilité d’utiliser un outil ou le manque de fonctionnalités d’un programme est le moteur principal de la recherche d’alternative et donc du Logiciel Libre ? Tous les membres de la communauté du Logiciel Libre capable de programmer devrait avoir ce réflexe. Vous n’aimez pas ce qu’offre Github ? Optez pour Gitlab. Vous n’aimez pas Gitlab ? Améliorez-le ou recodez-le.
Logo de Gitlab, une alternative possible à Github
Que l’on soit bien d’accord, je ne dis pas que tout programmeur du Libre qui fait face à un mur doit coder une alternative. En restant réaliste, nous avons tous nos priorités et certains de nous aiment dormir la nuit (moi le premier). Mais lorsqu’on voit 1340 signataires de cette lettre à Github et parmi lesquels des représentants de très grands projets du Logiciel Libre, il me paraît évident que les volontés et l’énergie pour coder une alternative existe. Peut-être d’ailleurs apparaîtra-t-elle suite à cette lettre, ce serait le meilleur dénouement possible à cette affaire.
Finalement, l’utilisation de Github suit cette tendance de massification de l’utilisation d’Internet. Comme aujourd’hui les utilisateurs d’Internet sont aspirés dans des réseaux sociaux massivement centralisés comme Facebook et Twitter, le monde des développeurs suit logiquement cette tendance avec Github. Même si une frange importante des développeurs a été sensibilisée aux dangers de ce type d’organisation privée et centralisée, la communauté entière a été absorbée dans un mouvement de centralisation et d’uniformisation. Le service offert est utile, gratuit ou à un coût correct selon les fonctionnalités désirées, confortable à utiliser et fonctionne la plupart du temps. Pourquoi chercherions-nous plus loin ? Peut-être parce que d’autres en profitent et profitent de nous pendant que nous sommes distraits et installés dans notre confort ? La communauté du Logiciel Libre semble pour le moment bien assoupie.
Qui dit logiciel libre dit partage libre du code source. Pour cela il existe plusieurs plateformes en ligne, la plus célèbre étant Github. Joli paradoxe quand on sait que Github est un logiciel propriétaire, qui héberge lui même des logiciels libres. Dans cette article nous nous intéresserons à une alternative libres à Github, qui permet d'héberger son propre front web dédié à git.
Parmi ces alternatives il existe Framagit, qui est une instance du logiciel libre GitLab. Mais pour cet article j'ai installé un serveur git et un front web sur un Raspberry Pi, qui tourne sous l'OS Raspbian. Je n'ai pas fait le test, mais la procédure décrite ci-dessous devrait aussi fonctionner sous Debian et Ubuntu.
J'utiliserai Gitphp en tant que front web. Celui-ci n'a pas les fonctionnalités ni l'ergonomie d'un GitLab ou d'un GitHub, mais a l'avantage d'être très léger, ce qui est un prérequis important pour un Raspberry Pi. Néanmoins il est tout à fait adapté à une utilisation personnelle ou bien au sein d'une école ou d'une association.
Avant toute chose, il faut commencer par installer un serveur web. Je recommande NGINX pour ses performances et sa légèreté. Pour simplifier l'installation de NGINX et de PHP-FPM, j'ai adapté pour le Raspberry Pi un script de Nicolas HENNION. Pour en connaître d'avantage sur ce script je vous invite à lire cet article. Si vous êtes sous Debian, récupérez le script orginal de Nicolas sur son Github. Si vous êtes sous Ubuntu, j'ai adapté un autre fork spécialement pour cette distribution.
Une fois notre serveur web installé, nous devons installer git, créer un utilisateur, créer les répertoires qui vont accueillir les projets git et le client web, et enfin affecter l'ensemble des droits nécessaires au fonctionnement de l'ensemble.
sudo apt-get install git-core
# création d’un user git et du répertoire qui contiendra les projets Git
sudo adduser git
mkdir /git
chown git:git /git
# on change le répertoire par défaut de l'utilisateur git
usermod -d /git git
# création du répertoire qui accueillera le client web
sudo mkdir /var/www/gitphp
sudo chown www-data:www-data /var/www/git
sudo chmod 770 /var/www/git
Ensuite, il est nécessaire de paramétrer php-fpm, comme indiqué ci-dessous.
sudo vim /etc/php5/fpm/pool.d/www.conf
# remplacer
listen = /var/run/php5-fpm.sock
# par
listen = 127.0.0.1:9000
Installation et configuration
Rentrons dans le vif du sujet. Ci-dessous j'ai décrit l'ensemble des commandes permettant d'installer et de configurer la partie serveur et la partie front. Toutes les commandes sont à réaliser sur le serveur.
# dans le fichier gitphp.conf.php décomenter et modifier la ligne ci-dessous
$gitphp_conf['projectroot'] = '/git/';
# affectation des droits et redémarrage sur serveur web
sudo chown -R www-data:www-data /var/www/
sudo chmod -R 770 /var/www/
sudo service nginx restart
# création d'un projet git
su - git
cd /git
mkdir nom-projet.git
cd nom-projet.git
git --bare init
Configuration SSH
Avant de commencer à pouvoir utiliser notre serveur git, il faut configurer SSH sur le serveur et sur l'ordinateur qui servira à vos développements (le client git). Ce paramètrage vous permettra d'envoyer vos modifications au serveur en vous authentifiant par échanges de clés, ce qui permet d'éviter la saisie systématique d'un mot de passe utilisateur.
Sur le serveur, on crée le fichier qui contiendra les clé SSH des clients autorisés à se connecter :
su - git
touch /git/.ssh/authorized_keys
Sur le client, on crée une clé SSH puis on l'envoie au serveur :
Le serveur et le client web sont maintenant prêt. Les commandes ci-dessous sont à réaliser sur le client git. Elles permettent de créer un répertoire de travail qui pourra interagir avec le serveur git, ainsi qu'une branche "dev".
# création d'une branche
git branch dev
git commit -a
git push origin dev
Modification du prompt
Afin de rendre l'utilisation de git plus simple, il est possible de modifier le prompt dans le but d'afficher la branche git sur laquelle on développe. Pour cela il faut éditer le fichier .bashrc se trouvant à la racine du répertoire par défaut de l'utilisateur et ajouter la variable $(__git_ps1)
vim /home/nom_utilisateur/.bashrc
# modification du paramètre PS1 sans la gestion des couleurs :
PS1='${debian_chroot:+($debian_chroot)}\\u@\\h:\\w$(__git_ps1)\\$ '
# modification du paramètre PS1 avec la gestion des couleurs :
PS1='${debian_chroot:+($debian_chroot)}\\[\\033[01;32m\\]\\u@\\h\\[\\033[00m\\] \\[\\033[01;34m\\]\\w\\[\\033[00m\\]\\[\\033[ 0;31m\\]$(__git_ps1)\\[\\033[00m\\] \\[\\033[01;34m\\]\\$\\[\\033[00m\\] '
# quitter l'éditeur de texte et appliquer les changements :
. /home/nom_utilisateur/.bashrc
Thème
Il est possible d'avoir un rendu plus moderne du client web en installant un "thème", qui en réalité est une simple feuille de style CSS.
Pour l'appliquer, il suffit de télécharger sur votre serveur web, le fichier gitweb.css et de la placer dans /var/www/gitphp/css. Ensuite il faut éditer le fichier /var/www/gitphp/config/gitphp.conf.php en ajoutant la ligne ci-dessous :
Bruce Schneier est un spécialiste reconnu de la sécurité informatique auquel nous donnons souvent un écho sur ce blog. Il chronique régulièrement les avancées et les risques de l’Internet des objets dont la montée en puissance semble irrésistible. On peut présager que dans un délai sans doute très rapproché ces objets vont centupler le volume des données collectées sur nous, puisque non seulement ils nous environnent ou vont le faire, mais ils participeront à notre propre construction sensorielle et mentale du monde, jusqu’au plus secret de notre intimité. (1)
La vitesse de développement de ce marché en fait le nouveau Far-west des géants comme Intel, Cisco, Microsoft ou HP, et bien sûr des fabricants d’électronique. L’espoir de profit qui les anime les fait franchir sans scrupules la barrière de la vie privée (2) : non seulement l’implémentation de la sécurité sur ces objets est minime voire inexistante, mais ils sont aussi de parfaits petits espions programmés pour moucharder.
Nous n’échapperons pas plus à l’Internet des objets que nous n’avons échappé à l’ubiquité des smartphones. Faut-il cependant renoncer définitivement à notre vie privée au profit de ces objets intrusifs ? Quelles limites poser et comment ? Au fait, existe-t-il des objets connectés libres et éthiques ?
Voici l’Internet des objets qui parlent derrière votre dos
Traduction Framalang : r0u, goofy, teromene, et un anonyme
SilverPush est une startup indienne qui essaie de lister les différents appareils que vous possédez. Elle embarque des sons inaudibles dans des pages web que vous lisez et dans les publicités télévisées que vous regardez. Un logiciel secrètement embarqué dans vos ordinateurs, tablettes, et smartphones récupère ces signaux, et utilise des cookies pour transmettre ces informations à SilverPush. Au final, cette société peut vous pister d’un appareil à l’autre. Elle peut associer les publicités télévisées que vous regardez avec les recherches web que vous effectuez. Elle peut relier ce que vous faites sur votre tablette avec ce que vous faites sur votre ordinateur.
Vos données numériques parlent de vous derrière votre dos, et la plupart du temps, vous ne pouvez pas les arrêter… ni même savoir ce qu’elles disent.
Ce n’est pas nouveau, mais cela empire.
La surveillance est le business model d’Internet, et plus ces sociétés en savent sur les détails intimes de votre vie, plus elles peuvent en tirer profit. Il existe déjà des dizaines de sociétés qui vous espionnent lorsque vous surfez sur Internet, reliant vos comportements sur différents sites et utilisant ces informations pour cibler les publicités. Vous le découvrez quand vous cherchez quelque chose comme des vacances à Hawaï, et que des publicités pour des vacances similaires vous suivent sur tout Internet pendant des semaines. Les sociétés comme Google et Facebook font d’énormes profits en reliant les sujets sur lesquels vous écrivez et qui vous intéressent avec des sociétés qui veulent vous vendre des choses.
Le pistage entre tous les appareils est la dernière obsession des commerciaux sur internet. Vous utilisez probablement plusieurs appareils connectés à Internet : votre ordinateur, votre smartphone, votre tablette, peut-être même votre télévision connectée… et de plus en plus, des appareils connectés comme les thermostats intelligents et consorts. Tous ces appareils vous espionnent, mais ces différents espions ne sont pas reliés les uns aux autres. Les startups comme SilverPush, 4Info, Drawbridge, Flurry et Cross Screen Consultants, ainsi que les mastodontes comme Google, Facebook et Yahoo sont tous en train de tester différentes technologies pour « régler » ce problème.
Les revendeurs sont très intéressés par ces informations. Ils veulent savoir si leur publicité télévisée incite les gens à rechercher leurs produits sur internet. Ils veulent corréler ce que les gens recherchent sur smartphone avec ce qu’ils achètent sur ordinateur. Ils veulent pister les positions des personnes grâce aux capacités de surveillance de leur téléphone, et utiliser cette information pour envoyer des publicités ciblées géographiquement sur leur ordinateur. Ils veulent que les données de surveillance des appareils connectés soient reliées avec tout le reste.
C’est là que l’Internet des objets aggrave le problème. Comme les ordinateurs sont de plus en plus embarqués dans les objets que nous utilisons au quotidien, et pénètrent encore plus d’aspects de nos vies, encore plus de sociétés veulent les utiliser pour nous espionner sans que nous soyons au courant et sans notre consentement.
Techniquement, bien sûr, nous avons donné notre accord. Les accords de licence que nous ne lisons pas mais que nous acceptons légalement quand nous cliquons sans y penser sur « J’accepte », ou lorsque nous ouvrons un colis que nous avons acheté, donnent à toutes ces sociétés les droits légaux de procéder à cette surveillance. Et quand on voit la façon dont les lois sur la vie privée aux États-Unis sont actuellement écrites, ils sont propriétaires de toutes ces données et n’ont pas besoin de nous laisser y accéder.
Nous acceptons toute cette surveillance internet parce que nous n’y pensons pas réellement. S’il y avait des dizaines de personnes provenant d’entreprises publicitaires avec leurs stylos et leurs carnets qui regardent au-dessus de notre épaule lorsqu’on écrit un mail sur Gmail ou tout simplement quand on navigue sur Internet, la plupart d’entre nous s’y opposeraient. Si les sociétés qui fabriquent nos applications sur smartphones nous suivaient réellement toute la journée, ou si les sociétés qui collectent les plaques d’immatriculation pouvaient être vues lorsque nous conduisons, nous exigerions qu’elles arrêtent. Et si nos télévisions, nos ordinateurs et nos appareils mobiles parlaient de nous à voix haute et se coordonnaient d’une manière qu’on peut entendre, nous serions épouvantés.
La commission fédérale du commerce (FTC) est en train d’examiner les technologies de pistage d’un appareil à l’autre, avec la volonté de pouvoir les réguler. Mais si nous nous fions à l’histoire récente, toute résolution prise sera mineure et inefficace pour s’occuper du plus gros du problème.
Nous devons faire mieux. Nous devons avoir un débat sur les implications du pistage entre appareils sur notre vie privée, mais, surtout, nous devons réfléchir à l’éthique du marché de la surveillance. Voulons-nous vraiment que des entreprises connaissent les détails de notre vie, et qu’elles puissent garder ces données éternellement ? Croyons-nous vraiment que nous n’avons pas le droit d’accéder aux données collectées sur nous, de corriger les données erronées, ou de supprimer celles qui sont trop intimes ou embarrassantes ? Au minimum, nous devons mettre des limites sur les données comportementales qui peuvent légalement être récoltées, savoir pour combien de temps, avoir le droit de télécharger les données collectées sur nous, et pouvoir bannir le pistage par des publicités de parties tierces. Le dernier point est crucial : ce sont les entreprises qui nous espionnent de site en site ou d’appareil en appareil qui causent le plus de dommages à notre vie privée.
Le marché de la surveillance d’Internet a moins de 20 ans, et a émergé parce qu’il n’y avait pas de régulation pour limiter son comportement. C’est désormais une industrie puissante, et qui s’étend au-delà des ordinateurs et téléphones, dans tous les aspects de nos vies. Il est grand temps que nous posions des limites sur ce que peuvent dire et faire avec nous dans notre dos depuis longtemps les ordinateurs et les entreprises qui les contrôlent.
(1) Un article parmi d’autres pour en savoir plus sur les objets connectés et comment ils altèrent sensiblement notre mode de vie : Objets connectés : allons-nous tous devenir idiots ?
(2) Voici un article très récent sur les espoirs et les craintes qu’on peut éprouver : « Rapport de l’UIT sur Internet des objets : un grand potentiel de le développement mais des risques pour la confidentialité et l’interopérabilité » (source)
Quelques passages (ma traduction) :
L’UIT (Union Internationale des Télécommunications, un organisme qui dépend de l’ONU) a publié aujourd’hui son rapport [pdf] « Exploiter l’internet des objets pour le développement mondial », produite en collaboration avec Cisco Systems.
Les appareils connectés qui communiquent les uns avec les autres et avec les êtres humains pourraient résoudre les grands défis mondiaux et être un vecteur pour le développement mondial(…) Toutefois, des questions demeurent, telles que les stratégies visant à protéger la vie privée, et l’interopérabilité entre les dispositifs et systèmes.
(…) des défis importants persistent, selon le rapport, en particulier le fait que « la même infrastructure qui permet aux gens de créer, stocker et partager des informations peut également mettre en péril leur vie privée et leur sécurité »
« Ces mêmes techniques peuvent être utilisées pour la surveillance, qu’elle soit ciblée ou à grande échelle », dit le rapport.
(0)Ferme-la !
(0)
SilverPush est une startup indienne qui essaie de lister les différents appareils que vous possédez. Elle 
