Pas besoin d'être paranoïaque pour se méfier de Google Chrome
Par Clochix le lundi 15 septembre 2008, 23:01 - Technoweb - Lien permanent
Le cas est fréquent: vous développez un site web pour un client, et pour lui permettre de le tester, vous déposez le site sur un serveur connecté à la vaste toile. Le client n'arrivant pas à se dépatouiller avec l'authentification HTTP, vous la désactivez, en vous contentant de protéger le site avec une adresse difficilement devinable. Et quelques jours avant la mise en production, vous vous apercevez qu'il y a déjà des visiteurs sur le site. Une rapide analyse des logs vous apprend que c'est Google qui les a menés là, et qu'il indexe déjà tout le nouveau site. C'est gênant à plus d'un titre:
- les contenus sur un site de pré-production ne sont pas toujours "corporate". Bien que cela m'ait déjà joué de vilains tours, je continue à utiliser des photos de Tux jusqu'en pré-prod. Ennuyeux si vos contenus de test se retrouvent indexés;
- si le site devait accompagner un lancement, l'info est éventée avant l'annonce officielle, et le client pas content. Et quand client pas content...
- une fois le site en ligne, il vous faudra gérer des re-directions propres pour que Google indexe la bonne adresse.
Les fora regorgent de théories pour pour essayer de comprendre comment Google a pu découvrir ces adresses. Est-ce la faute au navigateur du client sur lequel est installé l'indiscrète barre d'outil Google ? Via des referer ? L'activation trop précoce de Google Analytics ? un test de la sitemap ? ou une preuve de plus du complot et de l'omniscience de Big Google... Le débat continue.
Désormais, un risque de plus existe: Google Chrome. En effet, sous prétexte
de minimiser l'interface, Google a fusionné la barre d'URL et la barre de
recherche. Or les barres des recherche des navigateurs modernes proposent une
fonctionnalité de suggestion: chaque caractère que vous tapez est envoyé au
moteur de recherche de votre choix qui vous suggère en retour des recherches
parmi les plus courantes. En fusionnant la barre de recherche et la barre
d'adresse, cette fonctionnalité est étendue à tout ce que vous tapez dans la
barre d'adresse, que ce soit une recherche ou l'adresse d'un site
web[1]. Ainsi donc, par défaut, si vous saisissez
preprod.monclient.com
, Google aura connaissance de cette adresse, et il
pourra envoyer ses robots l'indexer. Même punition par exemple pour l'adresse
de l'interface d'admin, et tant pis si en pré-production vous n'avez pas choisi
de mot de passe assez sécurisé.
Bref, grâce à Chrome, Google pourrait bien se mettre à indexer à votre insu bien des contenus que vous pensiez masqués. Bien sûr, il y a toujours moyen de désactiver l'auto-complétion, ou de choisir un autre moteur que Google. Mais qui le fera ?
Une solution pour essayer d'empêcher l'indexation prématurée d'un site est
de penser à créer un fichier robots.txt spécifiques à vos sites de test pour en interdire l'accès
aux araignées, ou, plus radical, de gérer cela dans un htaccess à
coup de règles de ré-écritures basées sur HTTP_USER_AGENT.
M'enfin, pensez-y, un chat échaudé en vaut deux.
(source: Google Chrome privacy worse than you think via Tristan)
Notes
[1] apparemment sauf si vous tapez explicitement
http:
Commentaires
+1 avec toi ! J'ai eu la même réflexion personnelle en utilisant Chrome à contre coeur aujourd'hui...
C'est exactement pour tout ce que tu décris que je ne l'utilise pas, sauf peut-être pour tester mes futurs développements !
Une solution radicale, reste quand même de mettre le site de pré-prod dans un dossier sécurisé, après si le client ne sait pas utiliser ce genre de chose, peut-être faut-il lui expliquer qu'internet n'est pas pour lui !
Une alternatifve intéressante au .htaccess avec lequel certains clients ont des difficultées est l'utilisation de la directive Allow [1] qui permet de ne donner accès à une ressource qu'à une liste d'IP autorisée. Certes ça ne protège pas la "vue" du site par un moteur de recherche, mais tout ce qu'il obtiendra sera une erreur 403, ce qui est un moindre mal. Parfois mieux vaut un demi pain que pas de pain du tout.
1. http://httpd.apache.org/docs/2.2/mo...
@Jérôme: oui, il y a bien sûr pas mal de possibilités de blocage dans le .htaccess, mais bloquer sur l'IP n'est pas forcément la meilleure idée, parce que justement, le Big Boss va vouloir tester de chez lui et pas apprécier de tomber sur une 403. A priori, dans le cas dont je parle ici, le seul "risque" vient du moteur de recherche que tu définis par défaut. Et les bots des principaux moteurs sont relativement bien identifiés, donc un filtrage sur leur user-agent me semble suffisant.
+1
Et ce qui est d'autant plus effrayant c'est la combo AdSense + Analytics + Search + Chrome + Gmail (je m'arrête là)
Si avec ça Google n'a pas de quoi savoir où tu en es avec ton client...
À la limite ils pourraient sortir une fonctionnalité de "rappel" quand tu es à la bourre sur ton projet ;]
> en vous contentant de protéger le site avec une adresse difficilement devinable
C'est mal, et de toute façon totalement insuffisant. Au pire, il faut placer un robots.txt à la racine pour éviter le crawling, mais c'est sans garantie. De toute façon un bon vieux referer loggué et accessible sur internet aura tôt fait de faire venir les curieux potentiels...
Pour moi, tout site en hors-prod doit être protégé d'accès (accessible uniquement sur (V)PN ou éventuellement via une authentification HTTP...)
@NiKo : on est d'accords, en informatique l'obscurité n'est jamais qu'apparente, et en aucun cas une sécurité. Mais d'expérience j'ai vu bon nombre de sites librement accessibles quelques jours avant leur ouverture officielle, parce que rien ne devait gêner l'accès des pontes qui en avaient la primeur. Espérons qu'à l'avenir je saurai convaincre de l'intérêt de contrôler l'accès.