ping, pong

Récemment, Darin Fisher a introduit dans mozilla le support de l'attribut ping pour les liens en html. L'attribut ping est une des propositions du groupe de travail WHAT dont l'objectif est de moderniser le HTML actuel afin d'arriver à un HTML5, tout en restant totalement compatible avec le HTML4.01 actuel. Ce groupe s'est créé pour pallier au fait que le W3C n'est plus intéressé par une évolution du HTML depuis plusieurs années, les membres de ce groupe sont essentiellement des développeurs Mozilla, Opera et Apple.

Ping, de quoi s'agit-'il ?

Le principe de fonctionnement de ce nouvel attribut pour les balises a est que si l'on clique sur un lien ayant un attribut ping, le navigateur effectuera une requête http vers les urls présentes dans cet attribut. Il s'agit donc d'un moyen d'informer des serveurs que le lien a été cliqué, serveurs pouvant être le serveur d'origine ou (surtout en fait) des serveurs externes qui collectent ces informations pour les étudier (liens les plus populaires, comptabilité des clics pour la rémunération des bannières publicitaires...). Il s'agit donc d'un procédé supplémentaire de pistage des clics des utilisateurs sur une page.

L'idée derrière l'ajout de l'attribut ping est de fournir une solution aux publicitaires pour comptabiliser les clics de leurs partenaires et récupérer des informations sur l'agent utilisateur utilisé sans avoir à effectuer une redirection sur le serveur et donc mettre une page intermédiaire à cet effet, concrètement, il s'agit de remplacer des liens du type : <a href="http://serveurpub.com/redirect.php?id=123">lien vers toto.fr</a>

par des liens comme celui ci :

<a href="http://www.toto.fr/" ping="http://partenairepub1 http://partenairepub2">lien vers toto.fr</a>

Pour être clair, actuellement les sites comptabilisant les clics actuellement travaillent de la manière suivante :

  1. clic sur un lien du type <a href="http://serveurpub.com/redirect.php?id=123">lien vers toto.fr</a>
  2. le navigateur fait un passage par la page http://serveurpub.com/redirect.php?id=123 qui s'occupe de comptabiliser le clic dans une base de données avec les entêtes http classiques envoyés par le navigateur (je viens de telle page, je suis tel navigateur, ma langue par défaut est le français...)
  3. la page ci-dessus vous redirige vers la page que vous voulez vraiment visiter, c'est à dire toto.fr

L'idée est donc de demander au navigateur de contacter directement le site, ce qui offre théoriquement les avantages suivants (avantages essentiellement mis en avant par Darin et Ian Hickson qui a eu l'idée de ping au départ) :

  • le chargement de page est plus rapide puisqu'on va directement sur la page de destination (les pings sont faits en arrière-plan en asynchrone)
  • il y a une plus grande transparence puisque l'on voit dans le code html quels sont les pages contactées et on peut donc prévoir un mécanisme pour l'afficher dans le navigateur. Dans le cas de la redirection côté serveur on ne sait pas quels sites collectent ces infos.
  • l'utilisateur pourra désactiver la fonction dans les préférences de firefox

Voici le message ayant lancé la création de l'attribut ping : <a href="" ping="">.

Pourquoi je pense que c'est une fausse bonne idée

Le principal problème de cette proposition de nouvel attribut est que les avantages pour l'utilisateur n'apparaîtront que dans un seul cas : si cette méthode remplace la méthode actuelle de redirection côté serveur. C'est une énorme hypothèse qui personnellement me semble tout à fait irréalisable pour les raisons suivantes :

  • la méthode actuelle fonctionne pour tous les navigateurs, 100% de réussite, puisqu'elle ne dépend pas de la configuration et des possibilités des différents navigateur mais uniquement du serveur publicitaire. Pourquoi un site commercial abandonnerait-il un système qui fonctionne parfaitement pour tous les navigateurs pour le remplacer par un système qui ne marchera que pour 10, 20 ou 30% des visiteurs ?
  • les utilisateurs pouvant désactiver les pings, pourquoi les annonceurs remplacerait une méthode qui permet de comptabiliser tout le monde à coup sûr par une méthode où le client final peut ne pas être comptabilisé?
  • même si firefox, opera et safari (tous membres du whatwg) intègrent cette fonctionnalité, Internet explorer ne l'intègre pas et la majorité des utilisateurs seraient donc invisibles pour tout annonceur sauf si... il conserve son système actuel de redirection serveur. Même dans le cas improbable ou le futur IE7 intégrerait l'attribut ping (sience-fiction), IE6 ne l'intègre pas, IE6 est encore là pour un bon bout de temps, ce n'est pas demain que l'on vera un IE6 à un taux inférieur à 5% de part de marché...

Est-il raisonnable de penser que les entreprises dont les revenus dépendent entièrement de la comptabilité des liens cliqués vont abandonner un système parfaitement fiable, dont personne ne se plaint vraiment, pour un système ne fonctionnant que chez très peu de gens et qu'ils ne pourront pas contrôler ? je ne pense pas.

Pourtant, ce sont les publicitaires eux mêmes qui ont demandé si un tel système pourrait être intégré à HTML5 :

> - Nobody would really make use of it.

The suggestion for this originally came to me from Web advertisers, so I'm not sure this is necessarily true.

(Ian Hickson répondant à une critique sur la liste de discussion)

Il est clair que des boîtes de pub sont intéressés par l'intégration d'un tel système, et comme commercial et codeur amateur je peux comprendre pourquoi. Ce n'est pas dans le remplacement de leur technique actuelle côté serveur que je vois un intérêt marketing, c'est en complément de celui-ci pour des usages nouveaux. Avoir la possibilité de comptabiliser les clics sans passer par une redirection serveur permettra de proposer des accords commerciaux avec des gens refusant de voir leur site promu par une direction passant par un serveur externe car cela nuit à leur stratégie de référencement. On peut aussi imaginer sans difficulté que faire effectuer le boulot côté client permettra de profiter des avantages d'un navigateur, à savoir la possibilité de manipuler ces liens avec attributs ping par javascript et de changer leur apparence par css. Il sera ainsi possible de proposer de nouvelles formes de partenariat pubicitaires à des sites à base uniquement de javascript et de css, un simple include d'un fichier javascript et d'une feuille de style dans les entêtes d'un portail et il sera possible de modifier tous les liens pointant vers le site partenaire du jour sans avoir à toucher au contenu (ajout des attributs ping sur les liens déjà existants par parcours du DOM) et en plus de les styler de manière "promotionnelle". Il ne faudra pas longtemps pour voir des feuilles de style insérées par les agences de pub dans leurs sites partenaite contenant des trucs du genre a[ping="alcatel.google.com"]:after {content:" (nouveau site!)"}.

En fait, c'est même assez génial comme technique puisque ça permettrait à un site d'ajouter un système de comptage des liens pour une opération commerciale et de les styler de manière à les distinguer des autres sans avoir à toucher à son contenu (très important quand le contenu est syndiqué et produit par une autre équipe). On peut imaginer de nouveaux types de liens promotionnels destinés à une nouvelle clientèle de gens qui trouvent les système d'affiliation à des programmes publicitaires trop lourds car soit trop intrusif dans leur site (bannières, google ads...), soit trop complexes à mettre en place (liens avec redirections nécessitant une modification du html+langage serveur). Un nouveau système de comptabilisation des liens, plus réactif, plus facile à mettre en place, liens stylables à distance sans intervention aucune sur le corps HTML, visant une cible de geeks (les utilisateurs de Firefox) c'est tout simplement toute une gamme de nouveaux services publicitaires à proposer.

Dans tout cela, les avantages pour l'utilisateur final sont minimes (s'ils existent) et dans le meilleur des cas, on aura des internautes beaucoup mieux informés certes mais aussi beaucoup plus pistés à mon avis.

Les autres problèmes possibles

Outre le problème central de la simple utilité de ce nouvel attribut html, il y a à moins avis plusieurs autres problèmes posés par cette nouveauté. Il est tard donc je les listerai rapidement :

  • Les attaques de sites pas deni de service (DoS). Darin a écarté assez rapidement cette possibilité dès le départ avec comme argument qu'il est déjà possible d'utiliser d'autres balises pour le faire (img, object et iframe en particulier) et donc que ce n'est pas une nouveauté. Oui mais... Le lien est la base du web, en fait le web ce sont les liens, il ne s'agit pas d'une balise quelquonque. La base de la plupart des outils de publication est la possibilité d'insérer des liens (blogs, commentaires, sites de nouvelles type digg, forums...), quand je lui ai signalé que si j'arrive à pousser un lien dans une série d'attributs ping en première page de slashdot je pourrais attaquer un site, il m'a dit que c'était de la responsabilité de slashdot de nettoyer la balise de lien avant publication; je veux bien mais ça veut dire que tous les systèmes de publication dans le monde vont devoir ajouter un système de nettoyage des liens insérés dans leurs pages parce que cet attribut n'existait lorsque leur CMS a été conçu? Et qu'est-ce qui se passe si un ver se propage et modifie les liens de milliers de sites en ajoutant des attributs pings sur tous les liens qu'il trouve ? Je veux bien croire que les attaques par DoS soit un fantasme mais alors pourquoi ça a été évoqué dans la discussion du WHAT lors de la création de l'attribut sans que personne ne démente formellement la possibilité ?
  • L'interface utilisateur. Ce nouvel attribut veut dire que d'une part il va falloir informer l'utilisateur sur les liens pingés (sinon ce n'est pas la pein de parler de transparence) et que d'autre part il faut rajouter la possibilité de le désactiver facilement, sans oublier que le minimum serait de pouvoir mettre certains sites sur liste noire. Pour la désactivation j'ose espérer que ce sera faisable depuis les préférences et pas depuis about:config, pour l'interface utilisateurs je n'ai aucune réponse claire à ce sujet. Comment informer l'utilisateur des liens pingués sans que ce soit pénible ? Si je dois voir une infobulle à chaque lien me présentant les liens pingués, à ce moment mon interface est moins agréable que mon Firefox actuel puisque pollué par des liens pseudo-informatifs (les annonceurs annoncent les pings qu'ils veulent après tout, rien n'empèche de pinger directement sur le site client d'autres sites différents...). Comment alourdir l'interface de Firefox pour rien...
  • Des implications légales ? Actuellement c'est le serveur de redirection qui se charge de pinger les sites, si c'est le client, ça veut dire que c'est la responsabilité du surfeur. Tous les utilisateurs de firefox ne vivent pas dans des démocraties après tout, je ne suis pas sûr que ça simplifiera la vie du surfeur qui vit dans une dictature si il doit se demander si sa machine ne va pas établir des requêtes avec des sites interdits dans son pays à chaque clic sur une page (genre des liens dans les pings vers des moteurs de recherche interdits en Chine). Si une attaque par déni de service utilisant ce nouvel attribut ping a lieu, est-ce que le projet mozilla ne pourrait pas avoir des problèmes et présenté comme seul responsable ? Finalement, on est en train d'implémenter quelque chose qui n'est pas encore standard, depuis une spécification d'un groupe de travail sans existence légale.
  • les dommages en termes d'image. Quoi qu'on en dise, même si les intentions sont bonnes, ce n'est qu'un système de tracking supplémentaire et si c'est implémenté dans Firefox, on verra rapidement les firewalls intégrer la possibilité de bloquer ping comme ils bloquent activex pour IE, ne serait-ce que pour ajouter un argument commercial ("nous bloquons les nouvelles menaces contre votre vie privée"). Ce n'est pour l'instant que dans des versions de travail de firefox et déjà on a eu droit à des articles extrèmement négatifs dans la presse technique à ce sujet et parmi les utilisateurs habituels de Firefox. Je n'ai aucun doute que la presse plus généraliste n'essaiera même pas d'analyser la fonction et criera au spyware, ça sera faux bien sûr, mais ça fait vendre et ça nous fait mal. Je vois déjà les titres du style "Firefox finance son développement par l'intégration d'outil destinés au publicitaires".

Finalement, la question est de savoir pour qui on fait un navigateur. Traditionnellement nous avons fait un navigateur pour deux cibles, les développeurs web et l'utilisateur final exigeant. Maintenant il faudrait aussi supporter les developpeurs web spécialisés dans la pub? On ne peut pas à mon avis courrir tous les lièvres à la fois, surtout quand les lièvres se battent pour la même carotte. Peut être aussi faut il reconnaître que les objectifs de nettoyage et de simplification du HTML sont peut être intéressants à long terme, mais qu'à court et moyen terme les redirections ne sont pas près de disparaître, ce n'est pas parce que c'est créé par le WHATWG qui a des projets d'amélioration du HTML à très long terme que c'est forcément bénéfique à Firefox qui a son propre ordre dui jour et des objectifs à court et moyen terme.

Personnellement, ping ne m'intéresse pas, je n'en vois vraiment pas l'intérêt comme utilisateur donc si un jour c'est intégré ma première réaction sera de le désactiver, c'est pas comme les cookies et javascript, ils peuvent être utilisés pour me pister mais ils ont aussi mille usages qui me sont bénéfiques. Pour ping je ne vois pas à quoi ça va me servir et d'ailleurs si c'était désactivé par défaut, personne ne s'en plaindrait ce qui prouve bien l'utilité de la chose... Je n'ai pas de désir particulier d'aider des gros portails et des boîtes de pub à enrichir leur offre commerciale en faisant le boulot depuis mon navigateur à la place de leurs serveurs, ou alors qu'ils me payent pour ça :).

Benoit

> serveurs pouvant être le serveur d'origine ou (surtout en fait) des
> serveurs externes qui collectent ces informations pour les étudier

Soit tu te trompes soit tu ne visites pas les mêmes sites que moi :)
Je trouve que l'exemple le plus flagrant de redirection est la liste des résultats de Yahoo (parfois celle de Google aussi, je crois qu'ils font des petites expériences à ce sujet). Il y a aussi toute la série des liens générés par les "portails" (*nuke) qui sont des redirections avec un numéro de lien. Chaque fois il s'agit d'une redirection passant par le serveur faisant le lien, et elle me gêne profondément. Je ne suis pas dérangé par le fait qu'on comptabilise mon clic mais par celui qu'on obscurcisse l'adresse où je vais me rendre ! Parfois l'URL de destination est visible en paramètre et des scripts Greasemonkey ou des Bookmarklets peuvent faciliter mon utilisation (et empêcher qu'on compte mon clic alors que ça ne me dérange pas...) mais c'est loin d'être toujours le cas. L'utilisation de l'attribut ping par ces seuls acteurs (les portails et moteurs de recherche) couvrirait 90% des cas où je rencontre des redirections.

Sinon, pourquoi penses-tu qu'une implémentation dans IE7 est de la science-fiction ? Ne viennent-ils pas d'annoncer (à mots couverts) que leur objet XMLHttpRequest sera dorénavant compatible avec la spécification du WhatWG ? Moi je pense qu'ils lisent très attentivement la liste en question et qu'ils prendront tout ce qu'ils trouvent bon pour eux dedans (et que leur absence de participation est juste une excuse pour ne pas implémenter ce qui est trop difficile et pour ne pas perdre la face).

Benoit mercredi 25 janvier 2006 - 07:56
YoGi

Cette fonctionnalité est à peine implémentée que l'extension NoScript l'a déjà boycotté :
addons.mozilla.org/extens...

je prédis que toute cette histoire est un joli coup d'épée dans l'eau.

YoGi mercredi 25 janvier 2006 - 08:21
Monk

C'est sans doute moi qui connait pas assez le sujet pour comprendre mais après lecture de l'article je ne pige absolument pas la différence essentielle entre a ping et la redirection.

Un article sur /. avec un lien contenant une redirection n'est pas aussi dangereux qu'un article avec un a ping ? pourquoi ?

Je n'ai pas non plus bien compris pourquoi la redirection était plus visible pour l'utilisateur que le a ping, on ne peut pas voir ds le code de la page vers ou renvoie le a ping ?

désolé si c'est questions parraissent stupides mais peut être que d'autres users de FireFox non-experts comme moi trouveront aussi les réponses intéréssantes.

En tout cas pour l'instant j'aurais tendance à me méfier quand même car si je ne vois pas le danger je sais d'où viens la demande et je sais que les intérêts des boites de pub et des usagers sont rarement compatibles...

Monk mercredi 25 janvier 2006 - 09:38
lordphoenix

Personnellement c'est le genre de fonctionnalité que je me dépécherai de bloquer. On est déjà assez tracé comme cela sur le web pour ne pas y rajouter des moyens supplémentaires.
D'ailleurs je pensai que la priorité de Mozilla c'était les utilisateurs et la on vient faire risette aux publicitaires .......
Pas glop pas glop
vont se faire taper sur les doigts à mon avis.

pascal

->Benoît

(je réponds rapidement, j'ai faim :) )

Effectivement on ne visite pas les mêmes sites (déjà quand je vois phpNuke comme CMS, je fuis ;) ). D'ailleurs, si tu relis la discussion whatwg, ce n'est pas du tout pour améliorer ce type de sites que ping a été ajouté mais bien les sites liés à des partenariat publicitaires pour l'essentiel. Donc effectivement, il peut y avoir des usages positifs, comme il y a des tas d'utilisations positives d'activeX mais ce n'est pas pour ça que je pense qu'intégrer activeX serait une bonne chose. Dans le cas de ton portail, pour quelle raison penses-tu qu'ils intègreraient cette nouvelle technique ? leur méthode actuelle marche avec tous les navigateurs alors que ping ne marchera qu'avec Firefox et peut être safari Opera. Et encore, ça ne marchera qu'avec les prochaines versions de Firefox. Il faudrait donc qu'ils fassent une version des liens pour les firefox équipés et une autre pour les autres navigateurs, ça n'en vaut probablement pas la peine.

Je ne pense pas qu'ils intègreront les specs du whatwg tout simplement parce que c'est beaucoup trop de boulot, dans le cas de XMLhttprequest, il y a une véritable nécessité pour eux, des tas de sites l'utilisent et il y a donc une demande forte dans le web actuel. Microsoft a été invité à participer au Whatwg et ils ont refusé, ça ne veut pas dire qu'ils n'implémenteront jamais rien du whatwg mais rien dans le IEBlog ne donne l'impression qu'ils en ont l'intention. Sans oublier que IE7 est pour dans peu de temps, donc si c'était intégré je verais plutôt ça dans IE8. Mais que ce soit intégré dans IE7 ou pas ne change rien, ce n'est pas dans IE6 et ce n'est pas demain la veille que IE6 aura disparu. Microsoft a une approche pragmatique et implémente/répare dans IE7 les choses pour lesquelles il s'est fait durement critiqué ces 5 dernières années, pas des trucs qui non seulement sont polémiques mais relèvent encore pour le moment du gadget.

pascal mercredi 25 janvier 2006 - 13:15
pascal

-> Monk

Dans le cas d'une redirection, il n'y a pas de risque d'attaque par déni de service puisque ce n'est pas la page finale d'une part, et que d'autre part il n'y a qu'une seule url atteinte par clic. Dans le cas de ping, il est possible de mettre plusieurs url à pinger pour le lien et ces urls peuvent représenter le même serveur. Imaginons que je veuille emmerder mon voisin en attaquant son site, je m'arrange donc pour par exemple publier une histoire sur un site très populaire genre slashdot, histoire contenant un lien vers un site que les lecteurs visiteront, je rajoute dans ce lien un ping vers le site de mon con de voisin ;) et ça provoquera une requête vers son site pour toutes les personnes qui cliqueront sur le lien. Si je sais qu'il a plusieurs noms de domaines pour le même serveur, je peux même les rajouter en ping. Donc en fait il va falloir que les outils nettoient les liens de cet attribut lorsqu'on poste, ce qui veut dire aussi que dans ces histoires publiées le seul moyen fiable de comptabiliser les clics restera de mettre une redirection serveur.

pascal mercredi 25 janvier 2006 - 15:40
Monk

Pascal => merci pour cette réponse, c'est tout de suite bcp plus clair, je n'avais pas compris cette différence essentielle à la lecture de l'article.

Monk mercredi 25 janvier 2006 - 17:03
Benoit

Pascal> Je me suis mal exprimé, je ne vais justement *pas* sur ces sites précisément à cause de ce type de redirections. Je ne fais *pas* mes recherches sur Yahoo *parce que* les liens sont obscurcis, pas parce que je pense que les résultats sont moins bons. Je fuis également les sites TrucNuke pour la même raison (entre autres, je te rejoins pour dire qu'il y a pas mal de choses à leur reprocher :p).

En fait j'avais une autre objection sur ton argument "Slashdot". Tu parles d'un risque d'attaque via les liens dans les commentaires qui ne seraient pas nettoyés par ignorance de l'attribut ping. Mais précisément ces systèmes fonctionnent (ou alors on peut dire qu'ils ne fonctionnent pas) en n'acceptant que ce qu'ils connaissent. Par exemple sur un lien, ils vont refuser "onclick", "style" ou "target" non pas parce qu'ils les reconnaissent mais parce qu'ils ne les reconnaissent pas. Ils voudront juste entendre parler de href et c'est tout.

Bon, ce que je dois peut-être préciser c'est que je ne suis favorable à cette utilisation que dans le cas où le ping se fait sur le site où se trouve le lien, c'est-à-dire le même traitement que pour les cookies. C'est en tout cas comme ça que je règlerais mon navigateur et ce que j'attendrais comme réglage par défaut dans Firefox.

C'est-à-dire suivre l'exemple donné dans cette ligne de la spécification : "Based on the user's preferences, UAs may either ignore the ping attribute altogether, or selectively ignore URIs in the list (e.g. ignoring any third-party URIs)."

Dans ce cas l'argument de l'attaque vers un site extérieur tombe de lui-même.

Benoit mercredi 25 janvier 2006 - 20:48
karl

Je veux réagir à la phrase: "Ce groupe s'est créé pour pallier au fait que le W3C n'est plus intéressé par une évolution du HTML depuis plusieurs années, les membres de ce groupe sont essentiellement des développeurs Mozilla, Opera et Apple."

C'est faux, cela s'appelle XHTML 2.0. Maintenant que tu dises, cela n'est pas intéressant, cela peut être débattu bien sûr.

Pour la spec du WHATWG, c'est un brouillon avec d'immenses lacunes et choses non spécifiées dedans. D'autre part, elle n'est éditée que par une seule personne et donc cela devient beaucoup plus facile que de faire un travail collectif.

Au moins, il y a un travail de coordination entre trois navigateurs, pour les desktops. Je ne sais pas si le travail de revue pour l'internationalisation, l'accessibilité et DI, est fait en revanche. Autre problème de cette spécification par exemple. Canvas a été créé par Apple. Apple implémente pour un usage spécifique Dashboard, mais pas pour les navigateurs à l'origine. Tout le monde trouve cela cool, les gens se ruent dessus. C'est implémenté dans Mozilla et ajouté dans le brouillon du WHATWG. Oui mais de façon différente que ce qu'Apple avait initialement fait. Résultat des courses, Apple a été *obligé* de modifier son implémentation. Toujours pas un travail de consensus.

J'espère juste que l'on va pouvoir tous travailler ensemble afin de garder une interopérabilité des navigateurs, et que cela va s'améliorer que ce soit au WHATWG ou au W3C ou les deux.

karl jeudi 26 janvier 2006 - 06:15
karl

A lire également:

"I’ve been playing around with some ideas that use XMLHttpRequest recently, but I keep on bumping up against implementation inconsistencies on IE vs. Safari vs. Opera vs. Mozilla. Although the interface exposed is pretty much the same, what it does in the background is very different, especially with regards to HTTP."

mnot.net/blog/2006/01/23/...

karl jeudi 26 janvier 2006 - 06:55
pascal

karl, oui le W3C travaille sur XHTML2 mais ils le pensent comme un remplacement à long terme du HTML, pas une évolution pour le court et moyen terme. dans mon esprit c'est pour ça que le WhatWG s'est créé, c'est un problème de décalage entre les besoins actuels des développeurs et les objectifs du W3C qui ne sont pas dans le même temps. Personnellement je ne crois pas à XHTML2 comme remplacement du HTML à terme, en tous cas pas avant de nombreuses années, donc je comprends la démarche pragmatique des créateurs de navigateurs, ils ont besoin de solutions applicables maintenant à des problèmes qui existent depuis des années, pas de solutions qui marcheront dans un avenir lointain et nécessitant le renouvellement complet du parc des navigateurs. Pour faire un petit parallèle avec mon boulot, j'ai un problème de livraison pour un client qui traîne depuis des semaines parce que le fabricant le juge comme non prioritaire et ne le voit que dans le cadre de sa logistique qui est en train de changer d'informatique au niveau national alors que moi et mon client avons besoin d'une réponse à un problème immédiat qui nous pourrit la vie et nécessite une adaptation de leur logistique actuelle. Donc ce fournisseur n'est pour moi pas intéressé par l'évolution de son système actuel parce qu'il s'est focalisé sur la refonte totale de son système, tout comme le W3C n'est pas intéressé par un HTML5 parcequ'il est focalisé sur son remplaçant à long terme, finalement, les colis et les pages web c'est pareil :)

pascal jeudi 26 janvier 2006 - 09:41
Thomas

Ce passage est la première chose à laquelle j'avais pensé quand j'avais eu vent de cette histoire :
"Quoi qu'on en dise, même si les intentions sont bonnes, ce n'est qu'un système de tracking supplémentaire et si c'est implémenté dans Firefox, on verra rapidement les firewalls intégrer la possibilité de bloquer ping comme ils bloquent activex pour IE, ne serait-ce que pour ajouter un argument commercial ("nous bloquons les nouvelles menaces contre votre vie privée"). Ce n'est pour l'instant que dans des versions de travail de firefox et déjà on a eu droit à des articles extrèmement négatifs dans la presse technique à ce sujet et parmi les utilisateurs habituels de Firefox. Je n'ai aucun doute que la presse plus généraliste n'essaiera même pas d'analyser la fonction et criera au spyware, ça sera faux bien sûr, mais ça fait vendre et ça nous fait mal. Je vois déjà les titres du style "Firefox finance son développement par l'intégration d'outil destinés au publicitaires"."

Cela pourrait gravement nuire à la réputation de Firefox :/ On ne peut pas faire en sorte que cette "fonction" ne soit pas inclus dans le prochaine Firefox ?

Thomas jeudi 16 février 2006 - 18:54

Fil des commentaires de ce billet

Ajouter un commentaire

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.