‏ICI on dit des BANALITÉSﾠ‏ ؜⁠឵⁤؜؜𝅴؜؜𝅹؜⁤؜⁤؜𝅴؜‌؜឵؜͏⁤؜⁠؜឵؜⁤؜⁠؜឵؜⁡؜​؜⁣

Le 10 juin 2022 à 18:48:40 :

Le 10 juin 2022 à 18:44:32 :

Le 10 juin 2022 à 18:42:06 :
Je remets ma réponse au khey Clochardisation, sur le topic effacé sans raison par JVC.

Le but de ce genre d'initiative, c'est de réussir à transmettre une information en passant sous le radar de JVC et sans faire un JVC-like (car là on parle d'un changement complet de plateforme).
Transmettre une information en soit c'est bidon via Internet, il faut cependant que chaque participant ait un module (ou assimilé) capable de la décoder et de la transmettre. Tu en déduis la question critique : où stocker l'information ?

• Tu peux la stocker sur un autre site. Ensuite. chaque participant, via son module (par exemple un userscript) récupère les informations de l'autre site et les intègre dans l'interface JVC, idem dans l'autre sens pour ajouter de l'information, au lieu de la déverser sur JVC tu le fais sur l'autre site. C'était le modèle de JVC parallèle. Le souci c'est qu'un autre site, c'est une belle proie immobile pour toute action en justice ou autres rétorsions.
• Variante du modèle précédent, c'est le module lui-même qui stocke localement l'information selon le modèle P2P. Avantages : c'est très difficile à censurer sauf par un immense acteur déterminé (on parle d'un Etat qui voudrait censurer des secrets d'Etat donc, et pas le dernier risitas à la mode), les informations sont dupliquées chez tout un tas de participants. Inconvénients : la pile d'information va vite devenir immense (même en texte), ça va inciter les participants à faire du tri (automatisé ou manuel) ; au final seules les informations fréquemment utilisées seront gardées, les autres disparaîtront par sélection naturelle, de plus si un participant quitte le réseau, il emporte avec lui une copie de données et quand il est offline, les données sont aussi indisponibles. C'est aussi bien plus complexe à coder.
• L'approche ici est un peu plus originale : tu restes 100% sur JVC, mais le module va essayer de planquer l'information dans un message à l'apparence banale, par stéganographie. Il pourra ensuite décoder cette information cachée. C'est très élégant mais le besoin d'un module dédié limite la massification, et le site peut prendre des mesures pour détecter et éliminer cette information.

Merci pour le 3eme point c'est ce que je voulais savoir.
Il serait possible pour l'equipe d'administration de mettre a jour quelque chose cote serveur pour rendre impossible ce tour de passe-passe ? En tout cas c'est une approche originale, tu vois des vulnerabilites sur lesquelles webedia pourrait attaquer ?

L'information est chez eux, donc oui ils peuvent tout à fait étudier le script pour voir comment il fonctionne, et bloquer l'insertion d'informations qui ne sautent pas au yeux de l'équipe de modération.

Après en soit tu peux imaginer une version très primitive d'un tel script qui remplace "femme" par "pute" par exemple ( ) mais il y a des limites à la complexité de ce que tu peux encoder dans un message visible sans que ça se voie.

D'ailleurs tu peux aussi imaginer un "chiffrement" primitif type Cesar et utiliser un module pour décoder le message. Le souci là encore c'est que ça donne un message apparent qui ne veut strictement rien dire, donc sujet à 410 par la modération, surtout si elle comprend ce qui se passe derrière.

+ Je salue surtout le générateur de messages aléatoires de cet userscript, ils sont variés et réalistes.