Petit pense-bête sécu. Grosso-modo on peut classer les vulnérabilités en catégories :
- les trucs intrinsèquement sûrs, généralement inimplémentable correctement : one time pad
- les trucs connus pour être possibles en théorie mais impossible physiquement : bruteforcer une clef
AES de 256 bits
- les trucs pétés sur le papier mais sans implem efficaces connues : factoriser une clef RSA
- les trucs pétés avec une implem connue mais pas exploité massivement dans la nature : poodle
- les trucs pétés et exploités : samba
Beaucoup ne s’occupent que de la dernière catégorie. Éventuellement de l’avant-dernière. Vous faites erreur.
La vraie catégorie à prendre en compte dans votre conception est l’ante-pénultième : les vulnés possibles sur le papier mais en pratique pas observées.
C’est en effet celle qui risque de passer exploitée dans la nature à la prochaine itération. Vous ne connaissez pas non plus l’état réelle des capacités des attaquants ou d’un État.
Vous devez donc déjà avoir une porte de sortie quand ça va exploser. Peut-être demain.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Petite anecdote marrante mais pas tant que ça. Qui montre aussi le problème UI/UX versus former les utilisateurs versus le back versus trop de choses. […]
On a une contrainte au niveau bdd dans une base sur un champ, qui est de ne pouvoir contenir que des valeurs correspondants à /^[a-z][a-z0-9]{0,29}$/
Niveau back, l’ORM fait donc sa vérif normalement avec cet regex.
Coucou @CNIL !
Peut-être serait-il intéressant d’expliquer/expliciter les modes de fonctionnement du traitement des plaintes reçues, parce que ça déprime quand même un peu ce type de réponse 😭
Là, j’ai plus l’impression de pisser dans un violon à faire des demandes d’accès et des plaintes. On n’arrive juste à rien, j’ai 0 ou presque dossier complet après 2 ans de démarches.
Je comprend d’autant moins que le RGPD ne suppose pas l’établissement de lignes directrices de votre part pour être applicable. C’est DÉJÀ un règlement contraignant et applicable.
@JeromeColombain Oui, parce que le vote suppose la résistance à la coercition, qui n’est pas réalisable en version dématéralisée. Tous les exemples que vous citez ne la nécessite pas.
@JeromeColombain Le vote à l’isoloir permet de s’assurer que le vote est fait sans contrainte aucune, passée, actuelle et future. La personne peut voter en toute sécurité, même menacée par exemple par son employeur.
@JeromeColombain Le vote à l’isoloir permet aussi *à n’importe qui* de s’assurer de la licéité du scrutin. Et de s’assurer que son vote personnel est parfaitement pris en compte dans toute la chaîne de vérification.
Vu que j’ai beaucoup tapé sur Raoult à cause de sa méthodo, soyons aussi honnête et parlons de l’étude positive sur HCQ : medrxiv.org/content/10.110…
Ici la méthodo est bonne et correspond tout pile à ce que j’avais décris auparavant.
2 groupes constitués en aléatoire, l’un en traitement conventionnel, l’autre en conventionnel et CHQ.
Ni les médecins ni les patients ne savaient s’ils étaient sous CHQ ou non.
C’est donc du bon double aveugle randomisé comme il se doit. Fait en 6 jours. Rep à ça Raoult… 😑