À cette fin, nous testons un patch1 de Jonathan Mayer. Le patch de Jonathan correspond à la façon dont Safari fonctionne depuis des années et effectue les opérations suivantes :

  • Autorise les cookies provenant de sites que vous avez déjà visités.
  • Bloque les cookies provenant de sites que vous n’avez pas encore visités.

L’idée est que si vous n’avez pas visité un site (y compris celui sur lequel vous naviguez actuellement) et qu’il veut mettre un cookie sur votre ordinateur, le site n’est probablement pas un de ceux dont vous avez entendu parler ou avec lequel vous avez une relation. Mais ce n’est que probable, pas toujours vrai. Deux problèmes se posent :

Faux positifs. Disons que vous visitez un site nommé foo.com qui comprend du contenu paramétré par cookie d’un site nommé foocdn.com. Avec le patch, Firefox définit les cookies en provenance de foo.com parce que vous l’avez visité, mais il bloque les cookies de foocdn.com parce que vous n’avez jamais visité foocdn.com directement, même s’il n’y a en fait qu’une même entreprise derrière ces deux sites.

Faux négatifs. En attendant, dans l’autre sens, le simple fait que vous visitiez un site une fois ne signifie pas que vous êtes d’accord pour qu’il vous traque partout sur Internet sur des sites sans rapport avec lui, pour toujours en plus. Supposons, par exemple, que vous cliquiez sur une annonce par accident. Ou qu’un site dans lequel vous avez directement confiance commence à installer des cookies tiers dont vous ne voulez pas.

Toute la difficulté est de trouver un moyen de traiter ce genre de cas. Nous recherchons plus de granularité plutôt que de prendre des décisions automatiques et de nous baser exclusivement sur le fait que vous visitiez un site ou non, même si c’est souvent un bon indicateur à intégrer dans le processus de décision.

Nous avons l’intention d’expédier une évolution du patch « activé » par défaut, mais nous voulons faire tout d’abord des perfectionnements. Pour être sûr d’y arriver, nous avons besoin de davantage de données. Notre prochaine tâche d’ingénierie consiste à ajouter le code respectueux de la vie privée pour mesurer comment le patch affecte des sites réels. Nous demanderons également à certains de nos utilisateurs Aurora et bêta de choisir de participer à une étude avec collecte de données plus approfondie.

Il y a de nombreuses affirmations contradictoires sur la façon dont ce patch affectera Internet. Pourquoi débattre en théorie de ce que nous pourrions mesurer en pratique ? Nous allons en apprendre plus et rectifier le cap si nécessaire. C’est l’essence du cycle de versions de test.

Mardi, nous avons fait deux choses :

  1. Le patch a progressé vers le canal de version bêta pour Firefox 22, mais il n’y est pas « activé » par défaut. Cela permet à plus de personnes de tester le patch via l’interface utilisateur des « préférences » (alias « options ») de Firefox et permet d’éviter un changement brusque pour les propriétaires de sites tout en travaillant sur la gestion des cas difficiles.
  2. Le patch reste dans le canal Aurora pour Firefox, où il est « activé » par défaut. Cela donne au patch une meilleure couverture des tests en cours et facilite les tests A/B .

Nous avons entendu d’importants retours des propriétaires des sites qui sont inquiets. Nous nous sommes toujours engagés en faveur de la vie privée des utilisateurs et restons attachés à la publication d’une version du patch qui soit « activée » par défaut. Nous sommes conscients qu’il s’agit d’un changement important ; Nous avons toujours su que cela prendrait un peu plus longtemps que pour la plupart des patches car nous examinons celui-ci sous toutes les coutures.

Pour ceux qui interprètent ceci comme un moyen pour Mozilla d’adoucir sa position sur la protection de la vie privée et sur la priorité donnée à ses utilisateurs, en un mot : non. Les faux positifs dégradent les sites que les utilisateurs visitent intentionnellement (Heureusement, nous n’avons pas vu trop de ce genre de problèmes, mais des tests sur une plus grande échelle sont nécessaires). Les faux négatifs permettent le pistage là où il n’est pas voulu. Le patch en l’état nécessite davantage de travail.

Nous nous réjouissons du dialogue continu avec les collègues, collaborateurs, fans et détracteurs. Nous allons tenir au courant chacun d’entre vous dans les six semaines afin que vous puissiez comprendre notre façon de penser et comment nous allons procéder. Les commentaires2 sont bienvenus.

/be

P.-S. : Les cookies (nom, histoire) étaient initialement destinés à être éphémères (Windows 3.1 avait si peu de mémoire utilisable avec ses segments de mémoire de 64 K que les fondateurs de Netscape n’avaient pas le choix). Dans un premier temps, ils ont détenu seulement l’état de session pouvant être récupéré depuis le serveur en se connectant à nouveau (Un de ces jours, je vais vous raconter l’histoire de Montulli et de son idée de « twinkies » abandonnée à l’époque de Netscape 2).

C’est incroyable les progrès qu’a pu faire le Web ! Personne n’a prévu ce qui s’est réellement passé, mais avec plus de travail sur la politique des cookies dans Firefox et (je l’espère) dans les autres navigateurs, je crois que nous pouvons encore l’améliorer.


Relecture par Tristan Nitot, principal évangéliste de Mozilla


Note du traducteur 1 : Le terme patch, habituellement traduit par « correctif », a été préféré à ce dernier car il ne recouvre pas la réalité du morceau de code qui ici dépasse la simple correction.

Note du traducteur 2 : Pour être pris en compte, les commentaires doivent être déposés en anglais sous le billet original.

Options pour les cookies dans Firefox 22 bêta

« Accepter les cookies tiers » réglé par défaut sur « Toujours  » dans Firefox 22 bêta