Je n’aime pas trop la tournure des commentaires sur tous les sujets traitant de ce passe sanitaire, mais je me doute que tout le monde s’en moque…
Je voulais juste porter à votre connaissance, pour ceux qui insinuent qu’il faut discriminer les personnes selon qu’elles soient vaccinées ou non, à cette résolution européenne. Je vous laisse la lire et l’interpréter vous-même, puisque quel que soit mon opinion, il sera vraisemblablement attaqué par l’un ou l’autre de manière plus ou mois agressive.
Vous pouvez vous arrêter principalement sur l’article 7.3, mais bien évidemment tout le contexte importe.
Encrypter les adresses mail dans une BDD ça se pratique ou pas ? (performance, robustesse, aspect pratique)
Non, pour la même raison qui a été donné pour les mots de passe, si c’est chiffré alors c’est déchiffrable. Avec la clé par exemple dans le code. D’un certain coté cela obligerait à pirater la base de données et le code source (ce qui semble avoir été le cas ici).
Donc ça ne serait donc pas robuste (car c’est juste plus difficile, pas impossible), et surement pas pratique…
Le
22/07/2013 à
09h
40
C’est fou tout ce débat sur les mots de passe. Blablabla ils sont salés, blablabla il ne faut pas crypter, blablabla je suis un boulet. Le mec s’en branle de voler le mot de passe de geeks poilus qui doivent tous en utiliser un différent par sites.
1,82 millions de compte c’est surtout 1,82 millions d’adresses email qui pourront être exploitées, vendues. C’est bien pour Canonical de rassurer les utilisateurs pour leur mot de passe, mais l’adresse email est dans la nature, ce qui n’est pas tout le temps souhaitable. Prochaine étape, faire des stats sur les adresses emails et cibler les noobs auto-hébergés pour rooter leur serveur.
Le problème est que les logiciels IRC n’ont pas su tirer profit du protocole DCC. Un échec avec DCC Canvas, des tentatives avec DCC Voice et DCC Video, sans parler de TDCC (Turbo-DCC).
Le NAT a sûrement du être un frein au DCC, d’où la création de RDCC (Reverse DCC, pour que ce soit l’autre qui écoute), puis sûrement aussi mIRC en position dominante qui a empêché d’autres d’innover (même si à un moment donné il y avait eu une sorte de regroupement entre les principaux client IRC pour standardiser les choses, dont DCC Canvas) (et ceux qui innovaient ont fait de la “merde” aussi).
Après il y a aussi eu l’arrivée des webchats qui ne supportaient pas le DCC, donc cela n’a pas aidé.
Bref, le DCC, Direct Client Connection, quelque chose de magique n’a pas sû être exploité entièrement. Quant au support SSL, appelé SDCC, pour mIRC c’est la galère il me semble pour l’activer (il faut soi-même installer OpenSSL, cf:http://www.mirc.com/ssl.html ), et encore une fois, cela n’a pas aidé sa propagation.
Par contre dans KvIrc, on peut choisir son certificat SSL, et au moment de l’établissement de la connexion, celui-ci s’affiche, et il est possible de scripter un trousseau de clés (avec \(dcc.getSSLCertInfo), et donc pouvoir s'assurer de l'identité des interlocuteurs en DCC.
En poussant le vice, le protocole CTCP aurait pu servir à vérifier l'identité d'un interlocuteur sans avoir à établir de SDCC. Après, être seul dans son coin à faire ça n'a pas trop d'intérêt, ce n'est resté qu'au stade d'idée pour KvIrc (mais on peut le scripter avec \)str.evpSign et $str.evpVerify)
Pour résumer, le potentiel était là, un protocole en parallèle de l’IRC, très basique dans sa première version, qui aurait pu évoluer et être standardisé, mais tout a été raté xD Ceci dit, l’IRC classique juste avec du texte c’est quand même pas mal dans bien des cas encore aujourd’hui ^^
6 commentaires
Crise sanitaire : mineurs, faux passes, exceptions… ce que prévoit le projet de loi adoptée en commission
21/07/2021
Le 21/07/2021 à 22h 02
Surement l’un des commentaires les plus utile.
Ce qui attire mon attention est aussi le point 7.1.5:
Par exemple au Québec, il y a ce genre de programme:
Il y a-t-il quelque chose en France là dessus ?
Une procédure d’indemnisation est prévue en cas de préjudice lié à la vaccination obligatoire, mais la Covid n’en fait pas partie (https://www.service-public.fr/particuliers/vosdroits/F13284).
Liens entre Orange et la DGSE : vers des poursuites pénales ?
23/04/2014
Le 23/04/2014 à 18h 17
1,82 million de comptes utilisateurs du forum d’Ubuntu dans la nature
22/07/2013
Le 22/07/2013 à 10h 11
Le 22/07/2013 à 09h 40
C’est fou tout ce débat sur les mots de passe. Blablabla ils sont salés, blablabla il ne faut pas crypter, blablabla je suis un boulet. Le mec s’en branle de voler le mot de passe de geeks poilus qui doivent tous en utiliser un différent par sites.
1,82 millions de compte c’est surtout 1,82 millions d’adresses email qui pourront être exploitées, vendues. C’est bien pour Canonical de rassurer les utilisateurs pour leur mot de passe, mais l’adresse email est dans la nature, ce qui n’est pas tout le temps souhaitable. Prochaine étape, faire des stats sur les adresses emails et cibler les noobs auto-hébergés pour rooter leur serveur.
Patrick Sébastien rage contre « ces enculés qui sont sur le Net sous pseudo »
09/04/2013
Le 09/04/2013 à 15h 05
Patrick sébastien c’est un développeur java ? “et on fait tourner les servlets”…
Les utilisateurs d’IRC sont de moins en moins nombreux
08/01/2013
Le 08/01/2013 à 21h 21
Le problème est que les logiciels IRC n’ont pas su tirer profit du protocole DCC. Un échec avec DCC Canvas, des tentatives avec DCC Voice et DCC Video, sans parler de TDCC (Turbo-DCC).
Le NAT a sûrement du être un frein au DCC, d’où la création de RDCC (Reverse DCC, pour que ce soit l’autre qui écoute), puis sûrement aussi mIRC en position dominante qui a empêché d’autres d’innover (même si à un moment donné il y avait eu une sorte de regroupement entre les principaux client IRC pour standardiser les choses, dont DCC Canvas) (et ceux qui innovaient ont fait de la “merde” aussi).
Après il y a aussi eu l’arrivée des webchats qui ne supportaient pas le DCC, donc cela n’a pas aidé.
Bref, le DCC, Direct Client Connection, quelque chose de magique n’a pas sû être exploité entièrement. Quant au support SSL, appelé SDCC, pour mIRC c’est la galère il me semble pour l’activer (il faut soi-même installer OpenSSL, cf:http://www.mirc.com/ssl.html ), et encore une fois, cela n’a pas aidé sa propagation.
Par contre dans KvIrc, on peut choisir son certificat SSL, et au moment de l’établissement de la connexion, celui-ci s’affiche, et il est possible de scripter un trousseau de clés (avec \(dcc.getSSLCertInfo), et donc pouvoir s'assurer de l'identité des interlocuteurs en DCC.
En poussant le vice, le protocole CTCP aurait pu servir à vérifier l'identité d'un interlocuteur sans avoir à établir de SDCC. Après, être seul dans son coin à faire ça n'a pas trop d'intérêt, ce n'est resté qu'au stade d'idée pour KvIrc (mais on peut le scripter avec \)str.evpSign et $str.evpVerify)
Pour résumer, le potentiel était là, un protocole en parallèle de l’IRC, très basique dans sa première version, qui aurait pu évoluer et être standardisé, mais tout a été raté xD Ceci dit, l’IRC classique juste avec du texte c’est quand même pas mal dans bien des cas encore aujourd’hui ^^