Blog Jaune

Le degré de confiance que j'accorde à la source est relativement faible, mais le sujet est tellement sensible que laisser passer l'information serais dommage.

Il semblerait que les iPhones envoient le trajet GPS quotidien des utilisateurs à Apple.

Mais, ce n'est actuellement qu'aux états-unis, ce qui empêche de confirmer l'information par des amis ayant l'engin…

Évidemment, Apple annonce que c'est anonymisé, que c'est écrit dans les conditions d'utilisation de l'appareil, et que de toutes façon, il n'y a pas à se faire de soucis, ils sont les seuls à utiliser l'information.

Ces parcours seraient à mettre en corrélation avec le service de publicités de la grande firme.

Effectivement, quoi de plus beau que de proposer sur une belle carte d'une grande ville, les trajets les plus fréquents des utilisateurs, et vendre les emplacements de pubs.

L'iPhone était l'appareil le plus privateur au monde. Il devient la plus triste invention humaine après les armes de guerres.

Il y a des jours où j'ai envi de créer un collectif qui lute contre l'iPhone… Car en plus, personne n'en a rien à foutre.

Source : http://www.numerama.com/magazine/16389-les-trajets-des-utili(...)

Première partie :

Alors que je suis dans le train en train de développer une jolie feuille de style pour un site web, je remarque que Chromium est un espion à la solde des méchants.

En effet, je développe en local avec un serveur web local, ce qui ne demande pas de connexion internet. Ce qui tombe bien, puisque je suis dans un train.

La première surprise arrive quand l'on tape localhost dans Chromium, il fait une recherche de localhost sur google… Pour ceux qui ne le savent pas, localhost est un nom correspondant à l'adresse locale de l'ordinateur. C'est la première chose que l'on utilise quand on commence la programmation réseau. Bon, une fois que l'on fait bien attention à taper http://localhost/, on peut visiter son site en local.

Mais cette fois là, il me répond que le réseau est indisponible pour accéder à localhost… Le détail de l'erreur explique que le nom n'a pas pu être résolu. Faute de serveur de noms à disposition certainement. Cela peut faire penser que Chromium ne connait pas le fichier /etc/hosts, qui est prioritaire sur n'importe quel serveur de nom, surtout quand ils sont injoignables.

Mais je décide alors d'écrire directement l'adresse ip, pour ne pas utiliser de serveur de nom, puisque ce navigateur est trop con. Je tape alors http://127.0.0.1/ l'adresse qui renvoi vers la boucle local, et qui est celle correspondant au nom localhost, comme décrit dans le fichier /etc/hosts . Et là, c'est assez intéressant, puisque j'obtiens exactement la même erreur. Le nom n'a pas été résolu, puisque le serveur de nom est introuvable.

À ce stade, il y a trois possibilités qui s' envisagent selon moi. Il est tout simplement possible que les développeurs de google aient réécris des librairies de bas niveau, et qu'étant très mauvais, ils font des requêtes DNS même pour les adresses ip. Ce serait étrange venant d'une équipe qui a écrit un navigateur web si performant en réécrivant certains composants…

Une autre possibilité est que c'est totalement volontaire de faire des requêtes dns pour une adresse ip, et que le but serait de connaître sur quels sites l'on visite, même quand c'est à partir de l'adresse ip. Ce serais à relier avec leur service DNS à l'adresse ip si simple à retenir : 8.8.8.8 . Mais il ne faut pas voir le mal partout, et cette possibilité serais aussi étrange, je ne vois pas trop ce qu'ils peuvent en tirer, à part la possibilité de censurer une adresse ip.

La dernière possibilité est que le navigateur souhaite communiquer avec un autre serveur à chaque visite d'une page, et que ce serveur soit identifié à l'aide d'un nom de domaine. Mais ce serais très étrange, car un coup de wireshark suffirait pour remarquer des échanges anormaux avec des serveurs inconnus, et jusqu'à maintenant, personne n'a vu ça.

Ne comptez donc pas sur Chromium pour développer en local.

Deuxième partie :

La version Chromium de développement sur Ubuntu est légèrement pénible avec les fichiers PDF. Google Chrome intègre un lecteur de ces documents, et la version que j'utilise ne le fait pas, et affiche une erreur au lieu de télécharger le fichier.

J'ai lu sur le web que l'on pouvait télécharger la librairie PDF de Google Chrome pour la mettre dans Chromium. Effectivement, après avoir récupéré Google Chrome pour Ubuntu, on trouve bien la librairie, ce qui permet d'afficher directement les PDF dans Chromium. Au passage, c'est mal fait, mais c'est encore tout neuf.

En fouillant dans l'archive de Google Chrome à la recherche de la librairie, je suis tombé sur un script sh destinés à être exécuté chaque jour (cron.daily). Son unique but est réactiver le dépôt apt de mises à jour de Google Chrome, si il est désactivé. Un dépôt de mises à jour est un élément très important au niveau de la sécurité d'un système, car il peut remplacer tout les logiciels de la machine par des versions modifiées.

Le script n'est pas trop méchant, car si l'utilisateur a supprimé le fichier, au lieu de désactiver le dépôt, il ne le rajoute pas, mais il reste cependant étrange de vouloir réactiver ce qui est désactivé.

Il faut donc bien différencier la version Google Chrome la version libre Chromium.

Troisième partie :

Je suis tombé sur Google Native Code, permettant d'utiliser du code natif X86 dans un navigateur web. De manière sécurisée, certes. Faire du code natif dans un navigateur web, je ne comprends pas. Le SDK fournit un bon nombre de librairies dont cairo, imagemagick, ffmpeg, boost… et propose de coder tout ça en C++. Ça ressemble à une très grosse usine à gaz.

Qu'ils utilisent ça pour leur OS qui va faire un flop, d'accord. Mais d'avoir ça sur Chromium, c'est aussi étrange.

Heureusement que Chromium est libre. Qu'est-ce que ça serais sinon…

Lorsque je développe une application web, je trouve pratique de voir le résultat en temps réel. Une solution simple dérivée d'une astuce de linuxfr permet de recharger la page automatiquement à chaque enregistrement d'un fichier.

Les outils nécessaires sont :

• inotifywait
• xdotool

Le script est simple. Il se lance en passant comme argument une partie du titre de la fenêtre à actualiser, pour l'identifier. Ensuite, il actualise la page, à l'aide du raccourcis clavier de base…

#!/bin/bash

while true; do
    inotifywait --event modify $(find . -type f -not -path \*/.\*)
    focus=$(xdotool getwindowfocus)
    navigateur=( $(xdotool search --title --onlyvisible "$1") )

    xdotool windowfocus $navigateur
    xdotool key "Control_L+R"
    xdotool windowfocus $focus
done