• Facebook #Messenger : ce graphique montre à quel point l’app espionne votre #vie_privée
    https://www.phonandroid.com/facebook-messenger-ce-graphique-montre-a-quel-point-lapp-espionne-votre

    Apple est parvenu à mettre #Facebook et #WhatsApp face à leurs responsabilités avec cette obligation d’afficher les droits d’accès des applications sur l’App Store. Soudainement, les utilisateurs ont pu constater que WhatsApp et Messenger récupèrent vos #contacts, vos #données commerciales lorsque vous utilisez les services Facebook, votre #adresse_IP et votre #localisation, ou encore vos #enregistrements vocaux.

    Dans la foulée, WhatsApp a essayé tant bien que mal de justifier la collecte d’une si grande quantité de données : “Nous devons collecter certaines informations pour fournir un service de communication mondial fiable […] Par principe, nous prenons des mesures pour restreindre l’accès à ces informations”, assure l’entreprise.


    forbes whatsapp apple
    Crédits : Forbes

    #espionnage #RGPD

  • Politique de confidentialité du navigateur Firefox — Mozilla
    https://www.mozilla.org/fr/privacy/firefox/#telemetry

    Statistiques d’utilisation :
    Statistiques d’utilisation (également appelée « #Télémétrie » dans les versions autres que la version générale de #Firefox)
    La fonction Statistiques d’utilisation ou « Télémétrie » de Firefox transmet à Mozilla les statistiques d’utilisation, de performances et réactivité concernant l’interface utilisateur, la mémoire et configuration matérielle. Votre #adresse_IP est également recueillie, faisant partie du journal Web standard. Les statistiques d’utilisation sont transmises via SSL et nous permettront d’améliorer les versions ultérieures de Firefox. Une fois transmises à #Mozilla, les #statistiques_d’utilisation sont rassemblées et mises à la disposition d’un grand nombre de développeurs, y compris les employés de Mozilla et les contributeurs publics. Lorsque la télémétrie est activée, certaines expérimentations à court terme peuvent permettre de recueillir des informations à propos des sites visités.
    Cette fonction est activée par défaut dans les compilations Nightly, Aurora et Beta de Firefox pour que leurs utilisateurs puissent faire part à Mozilla de leurs commentaires. Dans la version générale de Firefox, cette fonction est désactivée par défaut.
    Vous pouvez en savoir plus sur la Télémétrie ici et comment l’activer ou la désactiver.

    et

    Recherche par défaut :
    Pour choisir le meilleur moteur de recherche par défaut pour votre lieu, Firefox envoie à Mozilla une demande pour rechercher votre emplacement au niveau du pays en utilisant votre #adresse_IP. Nous renvoyons alors à Firefox ces informations au niveau du pays, où elles sont stockées localement. Ensuite, #Firefox choisit le moteur de recherche à utiliser par défaut en fonction des informations de pays stockées localement.

    « Statistiques d’utilisation activées par défaut », « envoi d’une demande à Mozilla en précisant l’IP »... décidément le mirage de l’eldorado du #bigdata frappe partout...
    Même si pour l’instant on peut encore désactiver l’option d’envoi des rapports (cf https://support.mozilla.org/fr/kb/envoyer-rapports-performance-firefox) quand on voit comment a évolué la possibilité d’utiliser des extensions non-signées (cf « Timeline > Firefox 48 » sur https://wiki.mozilla.org/Add-ons/Extension_Signing) on peut se poser des questions sur le devenir du modèle de développement de la #fondation_Mozilla...

    #surveillance #vie_privée #NSA

  • La #Cnil épingle Numericable, pour un abonné dénoncé à tort
    https://www.mediapart.fr/journal/france/080316/la-cnil-epingle-numericable-pour-un-abonne-denonce-tort

    En raison d’un simple bug informatique, le fournisseur d’accèsa attribué à l’un de ses abonnés toute une série d’infractions. Signalé 1 531 fois auprès de l’Hadopi pour téléchargement illégal, l’homme a également été accusé de pédopornographie, a vu son domicile perquisitionné et son matériel informatique saisi.

    #France #Adresse_IP #Hadopi #Numéricable #Numérique #SR

    • Un abonné de Numericable soupçonné à tort de centaines de délits
      http://www.lemonde.fr/pixels/article/2016/03/08/un-abonne-de-numericable-soupconne-a-tort-de-centaines-de-delits_4878730_440

      La Commission nationale informatique et libertés (CNIL) a sanctionné d’un avertissement public la société Numericable, pour avoir à de multiples reprises transmis par erreur aux services de police et à la Haute Autorité pour la diffucion des œuvres et la protection des droits sur Internet (Hadopi) les coordonnées d’un même internaute innocent.

      Pendant près de deux ans, cet abonné a ainsi été « identifié 1 531 fois pour délit de contrefaçon et inculpé 7 fois », et soupçonné dans une affaire de pédopornographie, écrit la CNIL dans un communiqué publié le 8 mars. Il a « en outre fait l’objet de nombreuses perquisitions à son domicile et de plusieurs saisies de ses équipements informatiques ».
      A l’origine de ce dysfonctionnement majeur, une erreur informatique dans le logiciel mis en place par Numericable pour traiter de manière automatisée les demandes qui lui sont transmises par la Hadopi et par les services de police et de gendarmerie. « Lorsque l’application ne parvenait pas à associer une adresse IP à une personne, elle ne générait pas de message d’erreur et renvoyait par défaut à un même abonné », détaille la CNIL. Ce même abonné a donc été accusé de l’ensemble des délits pour lesquels Numericable ne parvenait pas à identifier le « réel » utilisateur de l’adresse IP signalée.

      oh la vache, espérons que Numéricable ait un max de dommages et intérêt à payer après un tel traitement.

  • La #Cnil épingle Numericable, pour un abonné dénoncé (1531 fois) à tort
    https://www.mediapart.fr/journal/france/080316/la-cnil-epingle-numericable-pour-un-abonne-denonce-1531-fois-tort

    En raison d’un simple bug informatique, le fournisseur d’accès à Internet a attribué à l’un de ses abonnés toute une série d’infractions. Signalé 1 531 fois auprès de l’Hadopi pour téléchargement illégal, l’homme a également été accusé de pédopornographie et a vu son domicile perquisitionné et son matériel informatique saisi à plusieurs reprises.

    #France #Adresse_IP #Hadopi #Numéricable #Numérique #SR

  • RFC 7513 : SAVI Solution for DHCP

    Le cadre #SAVI (Source Address Validation Improvement), décrit dans le RFC 7039, vise à rendre plus difficile l’usurpation d’adresses IP. SAVI fournit un cadre général et plusieurs solutions techniques concrètes sont ensuite développées selon le type de réseau et selon le niveau de sécurité qu’on désire et qu’on est prêt à « payer ». Ainsi, le RFC 6620 décrivait un mécanisme où le réseau d’accès assurait que le premier titulaire d’une adresse IP puisse la garder. Ce nouveau #RFC décrit un autre mécanisme, où c’est via l’utilisation de DHCP qu’on contrôle les adresses : le réseau d’accès va empêcher l’utilisation d’adresses qui n’ont pas été allouées par le serveur DHCP. (Ce mécanisme est largement déployé depuis des années, sous divers noms, comme « #DHCP_snooping », mais n’avait pas été formellement décrit dans un RFC.)

    http://www.bortzmeyer.org/7513.html

    #sécurité_Internet #adresse_IP

  • RFC 7039 : Source Address Validation Improvement Framework

    Une des choses agaçantes sur l’Internet est qu’il est trivial de tricher sur son adresse IP source. Une machine qui a comme adresse 2001:db8:1:2::42 peut parfaitement émettre un paquet où l’adresse IP source est 2001:db8:9fe:43::1 et, là plupart du temps, ce paquet arrivera à destination (le routage ne se fait que sur la destination, pas sur la source), trompant le récepteur sur la vraie source de l’envoi. Cette faiblesse a donc des tas de conséquences pour la sécurité. Il existe des bonnes pratiques documentées pour empêcher l’émission de tels paquets (RFC 2827 et RFC 3704) mais elles sont peu déployées en pratique. Le projet #SAVI (Source Address Validation Improvement) vise à propose des mécanismes pour rendre plus difficile l’utilisation d’adresses IP usurpées. Ce document est son cadre général, exposant les principes.

    http://www.bortzmeyer.org/7039.html

    #sécurité_Internet #adresse_IP #RFC

  • RFC 7020 : The Internet Numbers Registry System

    Le bon fonctionnement de l’Internet dépend de l’unicité de certains nombres, notamment les adresses IP. Comment ces nombres sont-ils alloués de manière à respecter cette unicité et d’autres propriétés souhaitables ? Ce #RFC remplace l’ancien RFC 2050 qui décrivait le système d’allocation des adresses IP en 1996.

    Comme son prédécesseur, ce RFC ne propose pas une nouvelle politique : il documente ce qui se fait actuellement. [...]

    http://www.bortzmeyer.org/7020.html

    #gouvernance_Internet #adresse_IP #IANA #ICANN #RIR #allocation

  • La #NSF (qui gérait le réseau académique états-unien qui formait une bonne partie de l’Internet à cette époque) affirme que les adresses IP allouées à cette époque (le « marais ») appartiennent bien à leurs titulaires et que le #RIR nord-américain, #ARIN, créé bien après, n’a aucun droit de les réclamer.

    http://www.internetgovernance.org/2012/09/22/its-official-legacy-ipv4-address-block-holders-own-their-number-

    Voir aussi http://seenthis.net/messages/39688

    #adresse_IP #RIR #gouvernance_Internet

  • RFC 6724 : Default Address Selection for Internet Protocol version 6 (IPv6)

    Lorsqu’une machine #IPv6 a plusieurs adresses et qu’elle va initier une communication avec une autre machine ayant elle-même plusieurs adresses, quelle adresse choisir pour la source ? Et pour la destination ? Ce #RFC donne deux algorithmes (un pour la source et un pour la destination) à suivre pour que la sélection d’adresse par défaut soit prévisible. Naturellement, il sera toujours possible, pour l’ingénieur système ou pour le programmeur, de passer outre ce choix par défaut et de choisir délibérement une autre adresse. Ce RFC remplace le très ancien RFC 3484.

    L’un des principaux changements est le fait que, désormais, une machine IPv6 est officiellement autorisée à donner la préférence aux adresses dites temporaires, qui assurent un meilleur respect de la vie privée.

    http://www.bortzmeyer.org/6724.html

    #adresse_IP

    • Plusieurs choses me semblent contestables dans ce RFC :-)

      D’abord le choix des adresses locales avant les adresses globales ne me semble pas optimal pour plusieurs raisons :
      – tout d’abord qu’est ce qui assure que les adresses soient vraiment locales ? Si des adresses fe80: :/10 se retrouvent annoncées par le DNS ou tout autre moyen de configuration, est-on sûr que ce soit vraiment sûr le même réseau ? Et si j’ai plusieurs interfaces, j’ai plusieurs fe80: :/64, je choisis comment la source ?? J’ai loupé quelque chose ?
      – Je suis administrateur système, est-ce que je tiens vraiment à avoir dans mes logs des adresses LL de serveur plutôt que mes adresses globales ou de site qu’évidemment je configure statiquement et avec un reverse DNS ? Ces adresses sont susceptibles de changer avec le hardware, ne parlons même pas de la virtualisation.

      Ensuite l’argument du monsieur qui a eu un problème me semble toujours valide, croire que deux adresses IP « plus proches » vont bien marcher ensemble c’est bien un truc de l’IETF ça ... Evidemment dans l’exemple il y a un /48 et un /32, c’est simple on est probablement chez le même FAI. Bref il aurait mieux valu écrire dans le RFC que la meilleure solution est de tirer au sort ...

      Drôle de RFC aussi ou l’on parle de sélection de la source avant celle de la destination, dont elle dépend fortement.

    • [Un avertissement, d’abord, je n’ai suivi que de loin le développement de ce RFC donc je ne peux pas parler pour ses auteurs, qui ont peut-être d’autres justifications pour leurs choix.]

      « Qu’est ce qui assure que les adresses soient vraiment locales ? Si des adresses fe80 : :/10 se retrouvent annoncées par le DNS ou tout autre moyen de configuration, est-on sûr que ce soit vraiment sur le même réseau ? »

      Un bon routeur IPv6 ne doit jamais router des paquets ayant une adresse source ou destination locale au lien, fe80 : :/10 (RFC 4291, section 2.5.6). Cela garantit normalement, si on voit un tel paquet, qu’il est bien local et si on l’envoie, qu’il ne sortira pas.

      « Et si j’ai plusieurs interfaces, j’ai plusieurs fe80 : :/64, je choisis comment la source ? »

      Les adresses locales au lien doivent être accompagnées de l’indication de l’interface. Publier fe80::1 dans le DNS ne donnerait rien.

      [Attention, SeenThis ne permet hélas pas de mettre du code, avec indentation respectée.]

      % ping6 fe80::21a:a0ff:feac:4a0c
      connect : Invalid argument

      % ping6 fe80::21a:a0ff:feac:4a0c%eth1
      PING fe80::21a:a0ff:feac:4a0c%eth1(fe80::21a:a0ff:feac:4a0c) 56 data bytes
      64 bytes from fe80::21a:a0ff:feac:4a0c : icmp_seq=1 ttl=64 time=0.018 ms
      64 bytes from fe80::21a:a0ff:feac:4a0c : icmp_seq=2 ttl=64 time=0.025 ms
      ...

      « Je suis administrateur système, est-ce que je tiens vraiment à avoir dans mes logs des adresses LL de serveur plutôt que mes adresses globales »

      Là, c’est simple : si l’admin’ ne veut pas avoir des adresses locales au lien dans ses journaux, il lui suffit de ne pas se connecter avec de telles adresses. Lorsqu’Alice se connecte à Bob, Alice trouve une liste d’adresses de destination possibles pour Bob (elle la trouve typiquement dans le DNS ou bien dans sa configuration statique). Si Bob ne veut pas voir d’adresses locales au lien dans ses journaux, il ne publie pas d’adresses locales au lien dans le DNS. S’il ne veut pas qu’Alice se connecte quand même par configuration manuelle, il configure son démon pour ne pas écouter sur les adresses locales au lien.

      « croire que deux adresses IP « plus proches » vont bien marcher ensemble c’est bien un truc de l’IETF ça »

      C’est un reproche qu’on pouvait faire au RFC 3484. Dans le nouveau RFC, c’est moins vrai.

    • Bonjour,

      Au sujet du DNS, j’aurais tendance à dire que c’est à ce moment qu’intervient le split-horizon DNS. On aura peut être tendance à publier les adresses site-local dans le DNS de l’entreprise pour s’assurer qu’en cas de changement du préfixe IPv6 de l’entreprise, seuls les clients distants seront impactés, ou alors pour éviter de faire passer les requêtes locales par le frontal de l’entreprise.
      De la même manière les adresses link-local peuvent avoir été transmises par un split-horizon DNS ou bien par du MDNS. Mais dans tous les cas, quelque soit la préférence donnée à telle ou telle adresse lors de la sélection des adresses source et destination, un PC situé dans un réseau correctement administré n’est pas sensé recevoir dans sa réponse DNS d’adresses sur lesquelles il ne peut joindre le serveur. C’est à l’administrateur de s’assurer de cela, en utilisant par exemple la technique précédemment cité.

      A propos des adresses link-local, la question à se poser est aussi quel serait l’intérêt de publier ces adresses dans un DNS. Je ne sais pas trop. Par contre, par MDNS cela peut avoir un sens.

      Cordialement.

      Emmanuel Thierry