Journal Firefox/Iceweasel se connecte silencieusement lors du survol d'un lien

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
31
16
août
2015

Bonjour Nal,

J'ai appris sur Slashdot que désormais, lors du survol d'un lien, Firefox s'y connectait silencieusement.

J'ai effectivement pu constater ce comportement chez moi grâce à Wireshark sur Iceweasel 38.2.0.

Mozilla refuse même d'ajouter une option dans les paramètres pour le désactiver, le bug 814169 ayant été marqué WONTFIX.

Il est néanmoins possible de le désactiver directement dans about:config, en passant la valeur de network.http.speculative-parallel-limit à 0.

Si on ne peut même plus faire confiance à son navigateur pour ne pas se connecter silencieusement n'importe où…

  • # Et s'il n'y avait que ça !

    Posté par  . Évalué à 10.

    En fait, quand on commence à creuser la question, on s'aperçoit qu'il y a beaucoup de choses à désactiver pour se sentir un peu à l'aise avec Firefox :
    https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections

  • # lire la doc

    Posté par  (site web personnel) . Évalué à 10.

    Ce n'est pas pour l'ensemble des liens sur n'importe quel site web :
    - https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections

    To improve the loading speed, Firefox will open predictive connections to sites when the user hovers their mouse over thumbnails on the New Tab Page or the user starts to search in the Search Bar, or in the search field on the Home or the New Tab Page. In case the user follows through with the action, the page can begin loading faster since some of the work was already started in advance
    

    Et si on continue les commentaires, il semble que ce soit seulement la connexion TCP qui est initialisée :

    And looking closer at the API description [mozilla.org], speculative connect isn't supposed to actually make the HTTP request, just set up the TCP connection. No headers, no URL, just an IP address at the network layer.

    Chrome fait aussi ce genre de chose, par exemple il précharge complétement le premier résultat de la barre d'adresse lors d'une recherche.

    • [^] # Re: lire la doc

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      Ah c'est quand même beaucoup mieux. L'URL en particulier est la partie dangereuse car elle peut donner des informations. Typiquement le premier exemple qui me vient à l'esprit sont les adresses dans les spams (en considérant que beaucoup de gens regardent leurs emails par webmail donc dans le navigateur) qui contiennent souvent un identifiant quelconque (soit votre adresse email en clair, soit un hash abscons qui vous identifie dans la base du spammeur et leur permet de savoir qui a encore une adresse active par exemple, et sûrement bien plus!). Si le simple fait de survoler un lien (quelque chose que je fais typiquement régulièrement, justement pour voir où ça mènera et si ça a l'air d'un lien clairement frauduleux ou relativement sûr…) envoyait des données (HEADER, URLs…), alors ce serait une terrible faille de sécurité.

      Il faut donc espérer que cette partie reste toujours ainsi.

      La première partie (limiter l'ouverture spéculative à certaines ressources) est bien aussi, ceci dit. Même seulement une connexion TCP sur n'importe quel serveur, on sait jamais. Autant que le navigateur ne s'amuse pas à ouvrir des connexions avec n'importe quel lien qui traîne…

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: lire la doc

      Posté par  (site web personnel) . Évalué à 7.

      Ce n'est pas pour l'ensemble des liens sur n'importe quel site web :

      Firefox will open predictive connections to sites when the user hovers their mouse over thumbnails on the New Tab Page or the user starts to search in the Search Bar, or in the search field on the Home or the New Tab Page.

      Quoi qu'en dise la doc, en pratique ce comportement concerne tous les liens (testé sur les liens de journaux linuxfr).

      il semble que ce soit seulement la connexion TCP qui est initialisée

      Tout-à-fait, il fait le SYN, SYN-ACK, ACK et attend. Il s'agit tout de même d'une connexion qui peut informer le serveur que tu as été sur une page (puisque tu as survolé un lien qu'elle contenait).

      blog.rom1v.com

      • [^] # Re: lire la doc

        Posté par  (site web personnel) . Évalué à 10.

        C'est cool, avec l'IPv6 la connexion sur le serveur permettra d'identifier le lien (donc l'e-mail dans le cas des spammeurs) :)

        Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

      • [^] # Re: lire la doc

        Posté par  . Évalué à 1.

        Lier une connexion tcp a un utilisateur est quand meme tres loin d'etre simple.

        Pas d'url, pas de hostname, pas de cookie, et les apis de serveurs web font un bon boulot a masquer les details tcp. Sans compter que ca ne te mene qu'au load balancer qui ne s'occupe que tres rarement de la logique de tracking (oui, tres rarement, je suis certain qu'ils existe des tares qui ont transforme f5 en webapp). Bon courage pour correler ca a une personne physique.
        Bref, ca me parait un compromis tres raisonnable performance/vie privee.

        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

        • [^] # Re: lire la doc

          Posté par  (site web personnel) . Évalué à 1.

          Pas d'url, pas de hostname, pas de cookie,

          Exact.
          Uniquement @IP source, @IP destination, date/heure, durée, volume.
          Un peu comme les fadettes téléphoniques donc.

          Sans compter que ca ne te mene qu'au load balancer qui ne s'occupe que tres rarement de la logique de tracking

          Tout est donc question de volonté de celui qui veut tracker.

          Bref, ca me parait un compromis tres raisonnable performance/vie privee.

          Je me demande donc pourquoi des gens (et des hébergeurs) ont hurlé avec la loi sur renseignement 2015 en France, car du fait du passage en tout chiffré (HTTPS Everywhere), ce sont les seules informations qu'une sonde étatique chez le FAI ou hébergeur peut récupérer.

          La raisonnabilité du compromis doit être une question de point de vue.

          Note : je ne me prononce pas sur le bien fondé ou pas de ce que fait Mozilla, je fais juste le rapprochement entre les données récupérables par deux projets.

          • [^] # Re: lire la doc

            Posté par  . Évalué à 8.

            Tout est donc question de volonté de celui qui veut tracker

            Question de cout surtout. Tracker avec toutes les metadata http sur un serveur web, et tracker une connexion ip sans meme savoir ce quelle cherche a obtenir, c'est pas la meme difficulte, et donc le meme cout. Sachant que les gens font ca pour le pognon, si ca leur coute plus cher de devoir mettre une webapp qui expose la stack tcp en frontal, ils le feront pas. Et ya des grandes chances que ca soit le cas.

            Toi qui d'habitude est le premier a hurler contre les arguments "il faut pas faire x parce que c'est pas efficace dans 0.1% des cas", tu tiens bizarrement un autre discours la.

            Je me demande donc pourquoi des gens (et des hébergeurs) ont hurlé avec la loi sur renseignement 2015 en France, car du fait du passage en tout chiffré (HTTPS Everywhere), ce sont les seules informations qu'une sonde étatique chez le FAI ou hébergeur peut récupérer.

            Les boites web font du DPI? Non? Bon alors?
            Le fait est que meme des mecs comme google sont probablement incapables de correler un conenxion tcp a un utilisateurs. Les agences gouvernementales elles le font, mais pas pour les memes raisons.
            Google le fait pour savoir a quel site web tu te connecte precisement, et ont besoin des meta donnees http pour que ca marche raisonnablement.
            La nsa est interessee de savoir quelle ip tu visites, et peut donc travailler a un niveau bien plus bas.

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

            • [^] # Re: lire la doc

              Posté par  . Évalué à -3.

              Le fait est que meme des mecs comme google sont probablement incapables de correler un conenxion tcp a un utilisateurs.

              C'est assez facile de se trouver avec un gmail connecté, puis onglet fermé. Puis de s'apercevoir lors d'une recherche que le compte est connecté.
              D'ailleurs là, je pensais être déconnecté et non, bingo ! Navigateur fermé depuis vendredi (je ne me souviens plus de quand date ma dernière connexion à gmail).

              • [^] # Re: lire la doc

                Posté par  (site web personnel) . Évalué à 6.

                Depuis le début du fil on parle du fait que seule la connexion TCP est ouverte. Aucune requête (donc aucune URL ou aucun cookie) ne partent.

          • [^] # Re: lire la doc

            Posté par  . Évalué à 4.

            Uniquement @IP source, @IP destination, date/heure, durée, volume.

            La durée de quoi ? Le volume de quoi ?

            Tout est donc question de volonté de celui qui veut tracker.

            Non pas vraiment. Oui un facebook ou un google peut être, mais pour tout le reste, tu as trop peu d'informations pour faire du tracking.

            Je me demande donc pourquoi des gens (et des hébergeurs) ont hurlé avec la loi sur renseignement 2015 en France, car du fait du passage en tout chiffré (HTTPS Everywhere), ce sont les seules informations qu'une sonde étatique chez le FAI ou hébergeur peut récupérer.

            Parce que ça n'a rien avoir ? Tu compare :
            - un tiers qui récupère beaucoup de méta donnée sur une connexion voir qui lis la totalité de la connexion (non les connexions chiffrées ce n'est pas la majorité et HTTPS Everywhere ne va pas magiquement chiffrer une connexion)

            et

            • le fait d'initialiser une connexion vers un serveur

            Donc :

            • ce n'est pas un tiers
            • il transite beaucoup moins d'informations

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: lire la doc

              Posté par  . Évalué à 1.

              La durée de quoi ? Le volume de quoi ?

              Y'a des trucs marrant qu'on peut voir avec les "simples ouvertures tcp"
              Déjà la gestion des numéro de séquence, des gestion de la window, des champs "options" TCP/ip si il y en a, permet de discriminer entre certaines piles réseau (je me demande si on peut pas discriminer entre android et windows)

              Ensuite faire la cohérence entre la même IP qui se connecte au serveur, avec le timestamp précis, et le RTT effectué dans le syn/syn-ack/Ack peut te donner une indication de la distance, voir la durée de présence sur le site.

              • [^] # Re: lire la doc

                Posté par  . Évalué à 5.

                Déjà la gestion des numéro de séquence, des gestion de la window, des champs "options" TCP/ip si il y en a, permet de discriminer entre certaines piles réseau (je me demande si on peut pas discriminer entre android et windows)

                Si tu peux juste déterminer l'OS, c'est très loin d'être suffisant pour faire du tracking.

                Ensuite faire la cohérence entre la même IP qui se connecte au serveur, avec le timestamp précis, et le RTT effectué dans le syn/syn-ack/Ack peut te donner une indication de la distance, voir la durée de présence sur le site.

                Le RTT ne te donnera pas grand chose, c'est une distance "réseau" qui n'a pas de corrélation direct avec une quelconque distance physique (en fait la géolocalisation de l'adresse te donne probablement de meilleur résultat). Je sais pas ce que tu veux dire par durée de présence.

                Mais, même quel est ton taux de discrimination ? 1/10 000 ? C'est trop mauvais pour en tirer quelque chose.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: lire la doc

      Posté par  . Évalué à 1.

      Chrome fait aussi ce genre de chose, par exemple il précharge complétement le premier résultat de la barre d'adresse lors d'une recherche.

      Oui, Chrome fait pas mal de truc du genre pour avoir l'air super rapide.

  • # publicité

    Posté par  (site web personnel) . Évalué à -6.

    Je vois déjà les arguments publicitaires
    "Regardez comment on va plus vite que les autres"
    "C'est pour ton bien"
    "Ca change quoi ? "

  • # de la daube

    Posté par  . Évalué à -10.

    Cela fait 3-4 ans que Mozilla ne propose que de la daube…un navigateur pourri, qui rame, aux changements ergonomiques sans cohérence. Firefox connaîtra bientôt la fin…Je n'aime pas de toute manière les bobos qui vivent dans un château…

    • [^] # Re: de la daube

      Posté par  . Évalué à 2.

      Tu as certainement un navigateur alternatif à proposer, qui ne soit pas faire par "des bobos qui vivent dans un chateau".
      Sois sympa, donne nous le filon.

      • [^] # Re: de la daube

        Posté par  . Évalué à 5.

        Lynx est vraiment pas mal. Les pubs sont bloquées, le chargement des pages est super rapide. Que du bonheur.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.