Le 21/07/2021 à 22h 02

kickinz1 a dit:

Bonjour a tous,

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.

https://pace.coe.int/en/files/29004/html

Kick.

Surement l’un des commentaires les plus utile.

Ce qui attire mon attention est aussi le point 7.1.5:

7.1.5 put in place independent vaccine compensation programmes to ensure compensation for undue damage and harm resulting from vaccination;

Par exemple au Québec, il y a ce genre de programme:

quand on accepte de se faire vacciner, on protège la société, c’est normal que la société offre un programme d’indemnisation

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).

Le 23/04/2014 à 18h 17

psn00ps a écrit :

Posté par https://nextinpact.com " />



Surtout que le certificat https de nextinpact appartient à CloudFlare, Inc., on peut donc considérer que tout est intercepté :-)

Le 22/07/2013 à 10h 11

v1nce a écrit :

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 09/04/2013 à 15h 05

Patrick sébastien c’est un développeur java ? “et on fait tourner les servlets”…

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 ^^