Le 01/03/2016 à 13h 24

Bravo tu as gagné le commentaire le plus bas du front et populiste de la journée.

Le cas Apple vs FBI est une affaire complexe, la réduire à ta remarque est d’un simplisme digne d’un enfant.
Apple ne demande pas de ne pas être soumis aux lois, il conteste le fait de devoir torpiller ses propres produits et donc son business-model sous couvert d’une loi qui est interprétée de manière exagérément large dans un contexte totalement différent de l’époque où elle a été écrite.

Apple a déjà plusieurs fois collaborer avec les autorités pour rendre disponible des informations nécéssaires à une enquête et dont elle disposait sur ses servers.

Le 01/03/2016 à 11h 43

Non malheureusement, ça ne marchera clairement pas dans tous les cas et encore moins sur les iPhone. Il ne faut pas lire tout ce qui traine partout sur le net.

Le dispositif de déverrouillage de l’iPhone demande obligatoirement d’entrer le code de déverrouillage si pas de déverrouillage du téléphone depuis 48h. Hors lors d’une interpellation, d’une GAV ou plus généralement d’une enquête judiciaire (si mort), les données du téléphone ne sont pas la priorité immédiate et ne parviennent aux enquêteurs spécialisés que plusieurs jours après. Donc l’empreinte digitale ne sert plus à rien, il faut obligatoirement rentrer à la main de code de déverouillage. Dans le cas d’une personne morte, on voit que c’est fini pour l’enquête sur un iPhone. Et dans le cas d’un Gardé à vue, s’il est bien conseillé par son avocat il ne donnera pas son code, ce qui est une défense totalement recevable.

Le 25/02/2016 à 11h 10

Telegram a un protocole de chiffrement maison très très critiqué par la communauté des cryptographes. De ce que j’ai lu, on parle de code assez mal pensé et qui pourrait poser des problèmes à moyen terme.

Je ne l’utiliserai pas personnellement.

Je ne suis pas persuadé qu’avoir un logiciel qui tourne sur toutes les plateformes soit un bon point niveau sécurité. les OS étant très différents et les bibliothèques difficilement transposables, je crois que c’est plus du chipotage qu’autre chose.
Je pense que des softs différents sur mobile et Desktop serait de loin préférable pour le côté sécurité à l’heure actuelle.

Le 30/10/2015 à 11h 47

avec Tor + OTR il n’y a plus de dichotomie du tout vu qu’il y a anonymisation pour le contexte et vie privée (chiffrement) sur le contenu ! :)

Le 22/10/2015 à 21h 55

Si TU ne sais pas utiliser des finderprint c’est TON problème. Par contre évite de dire que le fait que personne ne les vérifie rend le système peu fiables pour ceux qui savent l’utiliser … :p

Le 21/10/2015 à 22h 58

Google n’a pas la clé vu qu’elle est stockée chiffrée (AES) sur le téléphone à l’aide du mot de passe de déverrouillage. Quand bien même Google aurait la clé chiffrée que ça ne lui servirait pas à grand chose non plus.

 

Le 21/10/2015 à 10h 28

Pour les appareils ne disposant pas de puce dédiée pour le traitement de AES oui le proco doit faire ça lui-même.
Bien pour ça que ce n’est OBLIGATOIRE et AUTOMATIQUE  pour Android 6.0 QUE sur les appareils disposant de cette puce qui permet d’être totalement fluide.

Les autres doivent l’activer volontairement “à la main” et assument les conséquences en cas de ralentissements.

Le 05/10/2015 à 20h 54

dualboot a écrit :

En gros ça veut dire :

       

-FAI : nous on chiffre vos  mails avec vos/nos clefs privées qu'on remettra aux Renseignements dès le premier coup de téléphone.      

       

- Michu : OK, je suis rassuré.

Non encore une fois il y a erreur sur ce que vous comprenez :
 
 - chiffrer un mail = chiffrement du contenu = chiffrement de bout en bout.
 
 - ici on parle de chiffrement de la couche de transport = chiffrement du flux via TLS.
 
Donc, il n’y a aucun mensonge, ni tentative de faire croire que les mails sont protégés des agences gouvernementales ou de la justice. La charte essaye juste de mettre en place plusieurs pratiques de sécurité de base en 2015, notament le chiffrement des flux entre les machines.
 
(Il y a en réalité d’autres points abordés dans la charte …)

Le 05/10/2015 à 18h 40

CryoGen a écrit :

En tout cas c’est bien que l’état veuille avancer dans le chiffrement… moi je propose d’ajouter le chiffrement (client) dans le chiffrement (transport) comme çà plus aucune interception de possible " />, responsabilité claire etc. " />


Même si c’est vrai qu’ils ne vont pas se tirer une balle dans le pied en le mettant en place, en imaginant même que ce soit possible politiquement, ça sera une toute autre chose de déployer le chiffrement sur le contenu (bout en bout) que sur le transport (TLS).
 

Même si un opérateur décidait de l’intégrer dans son webmail, le chiffrement de bout en bout automatique ne serait en place qu’entre correspondants de la même plateforme de mail. L’interopérabilité du chiffrement de bout en bout Mr/Mme Michu compatible est loin d’être techniquement faisable à l’heure actuelle … :)

Le 05/10/2015 à 14h 29

On en est à la 5e page de HS … et surement 10-12 commentaires RÉELLEMENT sur le sujet …
 

 Allo la modération ?

Le 05/10/2015 à 12h 41

ledufakademy a écrit :

C’est pour cela qu’ils (quasi tous les acteurs : états et boites) poussent pour que vous foutiez TOUS vos données sur un cloud … et pas chez vous sur un NAS !!!!

" /> " /> " />


Heu tu dis un pue n’importe quoi. Il n’y a aucun incitation des pouvoirs publiques à mettre tes données sur le Cloud …
 
 C’est juste que l’informatique, telle que développée par les techos eux-mêmes, est juste très compliquée à gérer en décentralisé et beaucoup plus simple à laisser administrer par des autorités centralisées …
 
Y voir une connivence ou un dessein longtemps préparé ou calculé est une affabulation totale. Les institutions publiques qui veulent se servir de nos données ont juste profité de la centralisation HISTORIQUE des dites-données …

Le 05/10/2015 à 12h 37

  Ça n’est en rien de sa responsabilité, ni son affaire …
 Il essaye au moins de rendre effectif le chiffrement des FLUX entre gros opérateurs de mail. Ce qui en 2105 me semble en effet être un minimum.
 

 Je ne vois pas trop le sens de ton post. Il n’est ni pour, ni contre le chiffrement de bout en bout. Disons même que l’ANSI recommande même son utilisation dans certains cas et notamment dans certains domaines professionnels. Donc beaucoup  de gens ici font un mauvais procès à cette proposition.
 

 De toute façon, le chiffrement de bout en bout “bien fait”, c’est UNIQUEMENT la responsabilité des utilisateurs finaux … Les fournisseurs de solution mail n’ont rien à voir la dedans et encore moins les autorités publiques …
 

 P.S.: Ca ne dérrange que moi les 20 derniers comms totalement HS par rapport à la News ???

Le 05/10/2015 à 10h 29

le TLS bashing n’a strictement aucun sens. Et je soupçonne ceux qui le font de ne pas bien comprendre tout l’intérêt qu’il peut y avoir dans le déploiement automatique du chiffrement des flux.
 
Il n’y a aucun sens de parler de backdoor étant donné qu’on ne crée pas une porte dérobée volontaire, on utilise simplement le fonctionnement normal du chiffrement TLS pour déchiffrer en local les flux qui arrivent chez les opérateurs.
 
 Il n’empêche que même si TLS, dans le cas des emails chez de gros opérateurs centralisés, peut permettre à des services de renseigment/justice français d’avoir accès aux flux en clair, il est de toute façon préférable de déployer de chiffrment de flux pour prévenir les oreilles indiscrètes de nombreux autres acteurs qui en veulent à notre vie privée !
 

 Cessez d’être manichéens. C’est un bon pas en avant. Celui qui crache sur le chiffrement de flux TLS et qui ne chiffre pas de bout en bout son contenu n’est qu’un troll …

Le 14/09/2015 à 18h 30

Heu chers amis @sscrit et @Haemy , le cracking ne se fait plus en ligne depuis très longetmps. Le cracking se fait chez soi après avoir récupéré la base de données (hashée + salée). Les sites ont depuis longtemps mis en place des solutions qui bloquent le compte après X tentatives. Et essayer un mdp par compte par jour prendrait probablement des millions d’années pour tomber sur des mots de passe un tant soit peu complexe …

Le 14/09/2015 à 17h 13

mouais t’as augmenter ton charset size mais t’es quand même à max 8 caractères … :p

Le 14/09/2015 à 16h 19

Bannockh a écrit :

Je vois pas l’interêt des majuscules/minuscule/accent/etc…. Pour un ordi ca reste un caractère donc ca ne rajoute aucune protection contre un ordi un tant soit peu puissant. Par contre plus c’est long, plus c’est bon ….


C’est des maths tout simplement, je t’explique : 
  L’ensemble des mots de passes contenant uniquement des minuscules est bien plus petit que l’ensemble des mots de passes contenant des minuscules+Majuscules+chiffres+symboles. Un calcul par force brute est donc en terme de probabilité plus compliqué sur l’ensemble le plus gros …
 
 Sans parler du fait que faire varier les types de caractères permet également de réduire la menace des attaques par dictionnaire.
 
 
 Autre information importante :
 

 UN GESTIONNAIRE DE MOTS DE PASSE EST OBLIGATOIRE EN 2015 !

Le 08/09/2015 à 11h 50

Si tu pouvais demander pour moi quand est-ce qu’ils comptent passer à Apache 2.4 ? Et aussi s’ils bossent pour intégrer la nouvelle CA Let’s Encrypt ? Merci :p

Le 25/08/2015 à 13h 20

Anthodev a écrit :

En tout cas ils l’utilisent de manière qu’il n’est pas possible d’envoyer des emails en PGP standard, il faut obligatoirement passer par leur interface web pour la personne recevant le mail (au lieu de simplement envoyer la clé publique et de déchiffrer le message).



 Je viens de tester et j’ai très bien pu m’envoyer à moi et à d’autres un mail chiffré PGP via Thunderbird+Enigmail sur des adresses @protonmail. Donc oui ils utilisent bien du OpenPGP standard. Il faut juste envoyer en inline message plutôt qu’en PGP/MIME. :)

Le 24/08/2015 à 16h 09

Anthodev a écrit :

La limitation principale de ProtonMail reste le non support d’OpenPGP  standard. Ils ont une implémentation perso qui empêche d’envoyer des emails au format PGP à d’autres adresses de services utilisant OpenPGP normal.
 
 Ils n’ont toujours pas répondu sur la possibilité de passer par OpenGPG standard au lieu de leur implémentation (ce qui fait que seul les mails entre utilisateurs de ProtonMail sont chiffrés). Il est possible d’exporter la clé publique de son compte ProtonMail mais ce n’est pas utile si on ne peut pas envoyer les mails en PGP (et non en ProtonMail PGP)
 
 


Je pense qu’il doit y avoir confusion quelque part. ProtonMail utilise bien du OpenPGP standard. Juste ils n’ont pas encore implémenté la gestion des clés manuellement pas les utilisateurs, y compris de sa propré clé privée.
 
En gros c’est comme si t’avais un GPG verouillé sur ton PC mais derrière il esst faux de dire que c’est un format PGP différent des autres … C’est bien du OpenPGP standard.

Le 16/07/2015 à 14h 52

js2082 a écrit :

Ha mais je ne critique pas Synology.
 
 Je constate juste qu’il y a de nombreuses failles et qu’au final, la techno des NAS n’est pas encore mature.
 
Ce sont des produits qui à mes yeux sont arrivés trop tôt et qui doivent encore corriger plusieurs problèmes importants de sécurité avant d’être exploitables.
 
(surtout que si je m’en sers, ce ne sera pas pour stocker des données à la con)


Tu devrais vraiment ne parler que sur des choses que tu connais. Tu ne te rends pas compte j’imagine mais tu viens de te ridiculiser !

 
Les NAS existent depuis de très nombreuses années et ont prouvé leur utilité dans certaines configurations précises.
 

 Après venir dire que parce qu’on corrige des failles sur des logiciels libres, c’est une preuve de non-maturité …. encore une preuve que tu caricatures et méconnais grandement le sujet.

Le 13/07/2015 à 17h 01

Dire que El capitan supporte des becanes de 2008 c’est pas être fanboy, c’est juste décrire la réalité …
 
Si t’as un problème avec ça, il existe des établissements adaptés qui te permettront d’arrêter de projeter sur les autres. :)
 

 Liste officielle Apple :
 

  iMac 2007 ou plus récent

· MacBook Air 2008 ou plus récent

· MacBook 2008 ou plus récent

· Mac mini 2009 ou plus récent

· MacBook Pro de mi/fin 2007 ou plus récent

· Mac Pro 2008 ou plus récent

· Xserve 2009 ou plus récent

Le 13/07/2015 à 16h 54

t’as pas remarqué que tu mélanges plusieurs postes peut-être ??? Je n’ai absolument aucun Mac Pro …

 

 

Le 13/07/2015 à 16h 34

Tu mélanges vraiment tout et n’importe quoi … t’essayes de tirer dans toutes les directions pour avoir raison on dirait …
 

 1) Ta phrase initiale sous-entendait qu’un Mac de 2011 ramerait sous 10.11 … ce qui est une connerie monumentale … pour l’avoir installé sur mon iMac de 2008, ça tourne comme une horloge !
 

 2) Tu dis Microsoft supporte encore Vista et Seven … Je te signale qu’Apple continue encore de supporter ces anciens système étant donné qu’ils continuent à bénéficier de mises à jour de sécurité. (Apple vient même de pousser une Maj du “Mathusalemiem” Java 6 par exemple … )
 

1. Le prix n’a strictement rien à voir dans ton post initial … tu parlais de pousser à racheter du matos en poussant à l’obsolescence … Apple fait du premium, ça sera toujours plus cher sans forcément avoir plus ! Tout le monde le sait normalement aujourd’hui non … ?
    
   
    4) Y’a aucun besoin de changer une pièce d’origine pour passer à El Capitan …
    
   
    (J’ai hate que tu répondes pour voir comment tu continues à creuser … " />
    )

Le 13/07/2015 à 08h 45

merphémort a écrit :

Pour Metal j’ai envie de te dire que c’était prévisible quand même avec un HD3000 (d’ailleurs maintenant que tu mets le doigt dessus Apple a publié une liste des Mac compatibles ou bien?…), et si (connaissant Apple) ton MacBook de 2011 a déjà droit à EL Capitan sans gros bugs ou problèmes de perfs ce sera déjà pas mal va " />



 Tu connais très mal le support des versions de OS X on dirait et tu continues les stéréotypes sur Apple à ce sujet …
 

 El Capitan supportent des macs jusqu’à 2008 donc bon venir dire qu’Apple pousse à racheter du nouveau matos via ses OS c’est quand même une belle fumisterie …

Le 25/06/2015 à 12h 50

Il n’y a pas de chiffrement par défaut et obligatoire sur openfire. Donc on n’est pas vraiment dans le même domaine …

Le 24/06/2015 à 11h 25

heu non …

 Un, le client complet est dispo sur Github :https://github.com/PeerioTechnologies/peerio-client
 
 Deux, le client est une application complète qui intègre le protocole miniLock et qui gère aussi le gestion des contacts et les envoies des messages et des fichiers chiffrés.
 

 Il vaut peut-être mieux essayer un soft avant de le commenter :p

Le 24/06/2015 à 08h 23

Il n’existe actuellement aucune solution aussi complète et aussi simple d’utilisation avec code dipsonible pour le client et le server. Ici le code client est au moins disponible et Les développeurs s’étaient engagés à publier du code server dans le futur.

Le 17/06/2015 à 08h 59

vampire7 a écrit :

Je tiens à te signaler que c’est toi qui a commencé avec le ad hominem : Il n’est pire aveugle que celui qui ne veut pas voir…
 
 Sinon toujours aucun argument crédible selon moi, comme le dit @k43l, quelques secondes (dans le pire des cas !!!) est très peu visible par des gens n’ayant pas des exigences comme toi.
 Et pour avoir une connexion THD et une bonne machine, venir dire qu’il y a une gène sur la différence entre une connexion HTTP et HTTPS même sur du 100Mbps … me semble particulièrement subjective.
 

 Et allons au fond des choses, si on laisse le choix comme tu le veux, ça veut dire qu’on laisse le HTTP par défaut sur la majorité des sites (donc non sensibles à TES yeux). Donc que 90% des utilisateurs n’essaieront même pas s’il y a du HTTPS vu qu’ils ne s’y connaissent pas assez souvent pour comprendre la différence entre les deux. Donc pour gagner quelques milisecondes chez beaucoup de gens aujourd’hui. Ta solution finit par casser un processus de protection de la vie privée qu’on tend à généraliser parce que tu veux gagner 2% de temps sur une connexion.

Le 17/06/2015 à 08h 35

Ho mais je vais répondre, pas de chance je m’y connais bien en TLS … " />
 

 Il n’y a aucun avantage sur les petites connexions à l’heure où tu l’as dit toi-même, dans les pays occidentaux et “développées”, l’immense majorité des gens ont des machines dotées de puces pour AES (ordis & iphones) et où les machines non-pourves ont des suites de chiffrement très rapides aussi (CHACHA20-POLY1305) sur les smartphones sous Android par exemple.
 
On faisait du SSL à l’époque du 56K et ça ne posait pas de problème particuliers non plus, au pire ça rajoute quelques secondes pour des connexions anémiques dans les pays en voie de développement.
 

 Pour la consommation des machines, là aussi, tu ne vas pas au bout de ton raisonnement parce que si tu retires les machines dotées de puces dédiées (on doit être dans une grosse majorité des machines accédeant au net aujourd’hui dans les pays développés) et vu que la puce ne consomme quasiment rien à côté du processeur, beaucoup d’études ont montré que TLS était un vrai coût négligeable côté client. En réalité un PC moyen aujourd’hui est capable d’agir en tant que server et de chiffrer plusieurs milliers de connexions TLS par seconde. Par pitié évitons de faire croire que TLS bouffe des tonnes, c’est juste une blague.

Le 17/06/2015 à 08h 16

la généralisation du HTTPS ce n’est en rien de la sécurité aveugle ! Ca permet simplement de ne pas permettre aux intermédiaires techniques de savoir ce que l’on consulte sur un site particulier. Et sur un site comme Wikipedia, je pense que c’est plutôt indispensable à l’heure du tracking permanent.
 

 Je ne vois aucun avantage pour le particulier aux connexions sans TLS non désolé. Pour les très grosses boites c’est surement un allègmement (léger en réalité vu le très faible cout en ressource de TLS aujourd’hui !) d’une partie de la charge server.
 

Le 17/06/2015 à 08h 06

Alors pour la millième fois dans les comms : Il n’y a pas de limite légale à la taille des cléfs. Que ce soit en Europe ou aux USA en tout cas.
 
 Enfin, la Loi pour la confiance dans l’économie numérique du 21 juin 2004 a totalement libéré l’utilisation des moyens de cryptologie : https://fr.wikipedia.org/wiki/Chiffrement#En_France

Le 17/06/2015 à 08h 01

Les vraies questions sont :
 1) quel intérêt vois-tu à avoir le choix ?
 2) Pourquoi priviligierais-tu le HTTP sans TLS à certains moments ?
 3) Crois-tu que c’est aux utilisateurs (souvent “ignares” sur les questions de sécurité) à devoir prendre ce choix ?

Le 02/06/2015 à 18h 44

Mouais. DKIM ça sert mieux pour lutter contre le phishing que contre le SPAM. Je connais des boites de SPAM qui ont du DKIM installé sur leurs servers. C’est pas très compliqué et ça passe partout. Les grosses boites qui font du SPAM s’y sont mis depuis un moment …

Le 02/06/2015 à 13h 20

Vser a écrit :

Ce n’est pas tant pour  y donner de la publicité mais pour que nxi l’utilise lors de l’envoi de mail.


Déjà qu’ils veulent pas mettre du TLS sur la consultation du site (ce qui est ultra simple à faire vie Cloudflare chez qui ils sont clients ) … t’es pas près de voir des mails chiffrés avec GPG …

Le 02/06/2015 à 09h 10

90% de la population utilisant internet n’est pas foutue de se créer un mot de passe correct.
 
 
Vous voulez leur faire utiliser un mécanisme qui demande l’utilisation d’une phrase de passe et qui demande de gérer de manière sécurisée le stockage d’une clé privée ?! Revenez sur terre. PGP/GPG est destiné à une toute petite tranche de la population et le restera encore de nombreuses décennies.
 

 La seule solution est d’apprendre à gérer une phrase de passe. Cette étape est faisable. A partir de là on peut utiliser des système de chiffrement asymétrique avec dérivation des clés via une phrase de passe. Si vous voulez vraiment faire gérer localement une clé privée c’est déjà mort pour une énorme majorité de gens.

Le 02/06/2015 à 09h 41

le lecteur multimedia de la mini 4k est tout bonnement merdique pour l’instant. Il ne prend pas en charge le son multupistes (adieu AC3, DTS, DTS-HD, etc …), il ne lit pas certains sous-titres, et la liste est longue.
 

 En gros il lit assez peu de fichiers …
 

 Produit pas fini comme à son habitude avec Free !

Le 21/05/2015 à 15h 54

Pour avoir testé sur le mon NAS Synology (DSM 5.2 mis à jour), je peux vous annoncer que le server web n’est pas tuché par la faille logjam mais que le server mail lui l’est vu qu’il accepte les suites de chiffrement Export avec DHE.

Si vous voulez testez par vous-même, il existe cette commande pour openssl :

openssl  s_client -starttls smtp -connect smtp.exemple.com:25 -cipher “EXP”


N’hésitez pas à contacter Synology par les moyens que vous préférez pour les faire bouger sur la partie mail. ;)

Le 21/05/2015 à 14h 34

cyrano2 a écrit :

J’espère que tout ce qui est “vieux” dans TLS va disparaitre pour http2. Cela serait dommage d’avoir des algo pourris dés le début, alors que l’on change la base de communication.


Tu peux vérifier par toi-même mais la liste des ciphers blacklistées est assez importante :https://tools.ietf.org/rfcmarkup?doc=7540#appendix-A & https://httpwg.github.io/specs/rfc7540.html#BadCipherSuites

Le 20/05/2015 à 14h 57

@Cedrix @janiko

Vous m’avez mal compris en plus. Retirer DHE ne signifie certainement pas ne plus être compatible avec des anciens clients. (D’ailleurs si on parle vraiment de vieux client, ceux sous Windows XP notamment, DHE n’est presque pas supporté non plus donc bon … ) Supprimer DHE signifie juste rendre les clients les plus récents compatible uniquement avec ECDHE (et donc voir sur du plus long terme).
Rien n’empêche, et c’est ce que tout le monde fait d’ailleurs, moi y compris, de laisser RSA en fin de list de ciphersuites pour toujours rester accessible aux “vieux clients”.

Les GAFA sont une toute autre question, pour certains ils développent carrément un navigateur à eux et quasi tous ont des bibliothèquent TLS patchées avec des modifs maison …

Le 20/05/2015 à 14h 25

des boites qui ont des millions de clients sur le net on en compte 1000 dans le monde entier à tout casser, et je doute que les seniors chargés de la sécu informatique postent des comms sur NXi … " />

Donc non, mon commentaire ne se destinait pas aux sys admins de Amazon, Paypal, Google, Apple, etc … " />

Le 20/05/2015 à 14h 23

Pourtant si le site ne supporte plus du tout DHE, tu devrais avoir ce message :

 

Good News! This site is safe from the Logjam attack. It

       supports ECDHE, and does not use DHE.

Le 20/05/2015 à 14h 14

Edtech a écrit :

Au taff :



C’est rare qu’on soit au point ! Etrangement, c’est le seul serveur géré par un collègue développeur et pas par le sys admin " />

On est carrément en ECDHE !


Le mieux est encore de retirer DHE complètement et de ne laisser que ECDHE. Ca permet d’avoir le top actuellement et de n’être compatible qu’avec des clients modernes et récents (plus souvent mis à jour).

Le 16/04/2015 à 07h 58

Qwantcom a écrit :

Bonjour Kisame,

il faut activer le javascript pour naviguer sur le site. C’est la raison pour laquelle votre page est blanche.

Qwant Team 


Non toutes les pages blanches que je vois c’est lorsque les cookies sont désactivés.
 
Que les utilisateurs inscrits aient besoin des cookies pour stocker les réglages d’accord, mais que les viviteurs occasionnels non-inscrits et n’ayant touché à aucun réglage doivent obligatoirement accepter les cookies sur le site est un problème sur mon choix à protéger ma vie privée.

Le 14/04/2015 à 16h 35

je connais des sites de recherche qui permettent de faire des recherches sans AUCUN cookie et ça marche très bien. Donc selon moi, pour un site qui met en avant la protection de la vie privée, je pense qu’il serait évidemment souhaitable qu’une recherche sans cookie soit évidemment posssible !

Le 14/04/2015 à 16h 19

Suis-je le seul à avoir une page blanche sur ce site si je désactive les cookies sur mon navigateur ?

Pour un moteur de recherche qui dit respecter nos données et notre vie privée … c’est plutôt cocasse !

Le 10/04/2015 à 13h 47

Ben visiblement tu es donc soit un peu naïf, soit assez mauvais sur le plan technique  pour gober si facilement  le baratin de comm du gouvernement et du raporteur du texte …

Et tu as bien parlé de ne se contenter QUE des metadonnées, ce qui est évidemment faux ce qui est juste de la propagande pour faire passer la pilule du DPI (non contrôlable puisque boite noire avec algo non publique … )

Le 10/04/2015 à 13h 33

carbier a écrit :

Je crois que tu confonds beaucoup de choses dans le projet de loi.
Les boites noires ne s’intéressent “qu’“aux méta-données et encore elles feront le tri sur place et n’enverront que les données de connexion en concordance avec ce qui est surveillé.
Ce sont ces méta données de connexion qui seront ensuite analysées plus profondément pour savoir s’il s’agit d’un faux positif ou d’une vraie tendance.
Et c’est seulement après que l’arsenal de la pêche aux infos de contenu sera engagée sur des “cibles” bien définies.

Je ne dis pas que c’est bien, juste que les gens ont l’impression que la totalité de ce qu’ils consultent / publient / envoient sera analysée en permanence… Et cela, je ne suis même pas sur que la NSA sache le faire, alors la France…


Je crois que tu n’as pas lu le texte, pas suivi les débats en commission, ni bien compris l’intention de cette loi. 
Plusieurs fois les intervenants pour ce texte ont bien parlé de savoir quelles étaient les URL consultées en temps réels dans l’infrastructure des FAI via les boites noires. Or pour connaître les URL il faut évidemment aller plus loin que les méta-données. Les URL font partie du contenu d’un paquet. Il n’y a aucun besoin d’une URL pour router les paquets entre les routeurs.

On parle donc bien ici de DPI dans les boites noires donc d’analyse de contenu sur l’ensemble des communications. avec tout ce que cela entraine …

Le 08/04/2015 à 10h 42

Ricard a écrit :

Quand on dit qu’elles sont là, elles sont donc réputées sûres et, par corolaire, ne sont plus probables.


Je ne sais pas les autres mais moi je ne comprends pas ta phrase. Le dev c’est pas de la philo. Essaye d’objectiver tes propos.

Le 08/04/2015 à 10h 19

Certaines failles sont parfois théoriquement possibles mais extrêmement difficiles à mettre en place en réalité. Donc l’existence d’une faille ne veut pas forcément toujours dire que la menace est réellement applicable. C’est pour ça que les failles ne sont pas considérées comme majeures.

Le 31/03/2015 à 08h 44

Merci pour cet articles très intéressant qui retrace bien le parcours de ce phénomène bien trop peu connu (et soutenu ! ) en France.

Je vous recommande d’utiliser Peerio tant il est simple et facile à prendre en main.