Sites porno : Docaposte (La Poste) teste une solution béton pour garantir l'anonymat des internautes et protéger les mineurs

Alexandre Boero
Chargé de l'actualité de Clubic
10 novembre 2023 à 10h36
24
L'accès aux sites porno devrait bientôt pouvoir être enfin régulé © Artie Medvedev / Shutterstock.com
L'accès aux sites porno devrait bientôt pouvoir être enfin régulé © Artie Medvedev / Shutterstock.com

La filiale numérique du groupe La Poste, Docaposte, a annoncé vendredi expérimenter une solution visant à fournir une preuve d'âge sécurisée, pour garantir l'accès aux sites pour adultes aux utilisateurs majeurs exclusivement.

Pour empêcher les plus jeunes d'accéder aux sites pornographiques et garantir l'anonymat de ceux qui s'y promènent, Docaposte teste une solution unique au sein du Laboratoire de la protection de l'enfance, porté par le gouvernement. Elle doit répondre à trois enjeux majeurs : la protection des mineurs, le respect de la vie privée des utilisateurs, et un système ouvert proposant divers moyens d'identification.

La plateforme, composée d'une application mobile et d'une interface internet, doit assurer un double anonymat, sans transmission d'informations sensibles, avec un hébergement souverain dans des datacenters situés en France.

Les utilisateurs disposeront de plusieurs moyens de prouver leur identité

La solution de vérification d'âge de Docaposte semble posséder plusieurs avantages. D'abord, elle garantit le double anonymat, assurant la sécurité et l'absence de traçabilité des sites visités. Concrètement, la plateforme internet agit comme un intermédiaire. Elle confirme l'âge sans divulguer d'informations personnelles, tandis que l'application mobile récupère une preuve d'âge anonymisée. Cette approche respecte en tout cas les principes de la CNIL, le gendarme des données personnelles, conciliant protection de la vie privée et protection de la jeunesse.

Opérée donc par Docaposte et hébergée en France, la solution prévoit de garantir la sécurité des données via un stockage compartimenté. La plateforme, conçue dans une logique ouverte, donne aux utilisateurs le choix entre divers moyens d'identification. Les utilisateurs pourront passer par L'Identité Numérique La Poste, leur pièce d'identité ou bien en utilisant un numéro de carte bancaire Mastercard.

Mais des négociations sont menées pour intégrer de nouveaux partenaires et ainsi élargir les options d'identification, pour offrir davantage de flexibilité aux utilisateurs. Docaposte jouit aujourd'hui d'une vraie crédibilité dans le paysage de la protection des données, en ce que l'entreprise est certifiée par l'ANSSI (Agence nationale de la sécurité des Systèmes d'information), outre la gestion de 45 millions de dossiers médicaux, ce qui en fait le premier opérateur en la matière.

La vérification de l'âge sur les sites porno va-t-elle devenir une réalité ? © Shutterstock
La vérification de l'âge sur les sites porno va-t-elle devenir une réalité ? © Shutterstock

Une expérimentation qui pourrait être étendue à d'autres domaines dans lesquels les mineurs sont actifs

Comment cela fonctionne, en pratique ? Lorsqu'un utilisateur souhaite accéder à un site nécessitant une vérification d'âge, il se connecte à la plateforme de Docaposte. Celle-ci confirme son âge auprès du site porno en autorisant l'accès, transmettant uniquement une preuve d'âge sans divulguer d'informations personnelles. De même, le moyen d'identification utilisé ne connaît pas le site consulté avec la preuve d'âge, assurant ainsi une confidentialité totale. Sur le site de Docaposte, on peut retrouver davantage de détails techniques sur la solution, si vous voulez en savoir plus.

L'expérimentation est en cours depuis plusieurs semaines avec des sites pour adultes. Elle devrait prendre fin d'ici le début de l'année 2024, et enfin offrir une réponse aux autorités, qui font pression depuis de longs mois sur les grandes plateformes pour adultes. La solution de Docaposte pourrait en plus, dans le cas où elle suscite entière satisfaction du côté du gouvernement et de l'ANSSI, être généralisée et dépasser le cadre des sites pour adultes.

Elle pourrait en effet répondre aux besoins de protection des mineurs dans des domaines réglementés comme les jeux vidéo ou l'achat en ligne d'alcool et de tabac. Face à l'évolution rapide du numérique, Docaposte est décidée, tout comme sa maison-mère La Poste, à s'inscrire au service de l'intérêt général, en favorisant le développement d'un numérique éthique.

Alexandre Boero

Chargé de l'actualité de Clubic

Chargé de l'actualité de Clubic

Journaliste, chargé de l'actualité de Clubic. Reporter, vidéaste, animateur et même imitateur-chanteur, j'ai écrit mon premier article en 6ème. J'ai fait de cette vocation mon métier (diplômé de l'EJC...

Lire d'autres articles

Journaliste, chargé de l'actualité de Clubic. Reporter, vidéaste, animateur et même imitateur-chanteur, j'ai écrit mon premier article en 6ème. J'ai fait de cette vocation mon métier (diplômé de l'EJCAM, école reconnue par la profession), pour écrire, interviewer, filmer, monter et produire du contenu écrit, audio ou vidéo au quotidien. Quelques atomes crochus avec la Tech, certes, mais aussi avec l'univers des médias, du sport et du voyage. Outre le journalisme, la production vidéo et l'animation, je possède une chaîne YouTube (à mon nom) qui devrait piquer votre curiosité si vous aimez les belles balades à travers le monde, les nouvelles technologies et la musique :)

Lire d'autres articles
Vous êtes un utilisateur de Google Actualités ou de WhatsApp ? Suivez-nous pour ne rien rater de l'actu tech !
google-news

A découvrir en vidéo

Rejoignez la communauté Clubic S'inscrire

Rejoignez la communauté des passionnés de nouvelles technologies. Venez partager votre passion et débattre de l’actualité avec nos membres qui s’entraident et partagent leur expertise quotidiennement.

S'inscrire

Commentaires (24)

clubic_er
Quand on fait un titre affirmant que la solution technique est béton<br /> il serait pertinent sur un site de tech de faire un peu plus que 2 lignes pour expliquer en quoi c’est béton …<br /> car en l’état l’article ne réponds comment techniquement en s’assure que la société intermédiaire ici «&nbsp;docaposte&nbsp;» (#humour on est a une faute de frappe de do capote)<br /> n’a pas d’information sur les habitudes du consommateur<br /> comment on s’assure qu’un mineur n’utilise pas le compte des ses parents<br /> On imagine aussi que ce service ne sera pas gratuit et il est bien connu que ce n’est pas la vache qui paye la taxe sur le lait , sous quel forme allons nous payer ce service (parce que on peut tres vite retomber dans le business model des gafam je dis ça je dis rien …)<br /> bref on dirais presque un publi repotage
xryl
De même, le moyen d’identification utilisé ne connaît pas le site consulté avec la preuve d’âge, assurant ainsi une confidentialité totale.<br /> Donc ma CI ne sait pas que je vais voir des hamsters? Ouf, je suis sauvé.<br /> Attends…<br /> Mais Digiposte lui le sait du coup. En quoi c’est anonyme si la poste récupère tout l’historique de navigation «&nbsp;louche&nbsp;» d’une personne. C’est pas un peu pire que le mal, ça?<br /> Au lieu que seul le site final soit au courant, maintenant, on a, à la fois le site final, docaposte, et potentiellement google (via google analytics, parce que, bon, il faut bien savoir combien d’utilisateurs on a fait le mois dernier pour se la péter sur les camemberts Excel à la prochaine réunion de service). Génial comme solution, non ?
xryl
À la limite si Docapote te donnais un code (type QRCode ou simplement une séquence de texte) sans te demander pourquoi, et que tu donnais ce code au site final, ça pourrait fonctionner. En gros, Docapote signe un «&nbsp;cet utilisateur &lt;pseudo&gt; est majeur&nbsp;» avec sa clé privée. Le site final valide la signature, vérifie le pseudo entré et c’est bon.<br /> Mais je suis persuadé, au vu de nos chers développer Webpointzéro que s’il y a pas un callback OAuth2 quelque part, histoire que le site final appelle Docapote pour se faire valider la signature, c’est mort né.
Jetto
J’aimerais avoir plusieurs détails sur l’implantation.<br /> J’identifie un premier bias qui est que Decaposte sait qui a fait la demande d’une preuve d’age. Comme ce système n’est utilisé que pour les sites X, il faut faire confiance à ce tiers pour ne pas divulguer l’information.<br /> J’avais proposé une solution, qui ne corrige pas ce biai :<br /> C’est applicable a toutes les entités qui connaissent la date de naissance de l’utilisateur.<br /> Le site X vous qui demande une preuve d’age fourni un Id non traçable (c’est pour qu’une autre personne ne puisse pas utiliser la preuve).<br /> L’utilisateur communique un hash de l’Id au tiers qui génère preuve nulle de divulgation de connaissances de l’age &gt;18, il concatenne le hash de l’Id, signe le tout et publie l’info dans une chaîne de block.<br /> Le site scute la chaîne en recherchant le hash. Quand il le trouve, qu’il a vérifié la signature et la preuve, il accorde l’accès à l’utilisateur.
MattS32
xryl:<br /> Mais je suis persuadé, au vu de nos chers développer Webpointzéro que s’il y a pas un callback OAuth2 quelque part, histoire que le site final appelle Docapote pour se faire valider la signature, c’est mort né.<br /> Pour info, extrait de la FAQ :<br /> La CNIL a défini quelques grands principes afin de concilier protection de la vie privée et protection de la jeunesse par la mise en œuvre de systèmes de vérification de l’âge en ligne pour les sites. L’application « Jeprouvemonage » respecte l’ensemble de ces principes.<br /> • D’une part, l’émission de la preuve de l’âge : la mise en place d’un système destiné à valider l’information sur l’âge de la personne, en émettant une preuve d’âge.<br /> • D’autre part, la transmission de cette preuve de l’âge certifiée au site visité pour que ce dernier donne accès ou non au contenu demandé.<br /> « Jeprouvemonage » confie ces fonctions à des acteurs différents ce qui permet un double anonymat et la protection de la vie privée des utilisateurs. Ainsi :<br /> • Celui qui fournit la preuve d’âge (plusieurs possibilités à ce jour pour Jeprouvemonage : L’identité Numérique La Poste ou le Service de Vérification d’Identité à Distance de Docaposte) connaît l’identité du demandeur mais ne connait pas le site consulté ;<br /> • Le site Jeprouvemonage.fr qui transmet la preuve d’âge au site peut connaître le site ou le service que l’internaute consulte mais ne connaît pas l’identité de l’internaute ;<br /> • Le site ou service connaît uniquement l’attribut de majorité (+15 /+18), mais ne connaît en aucun cas l’identité de l’internaute ni, même le service de vérification de l’âge utilisé que l’internaute a utilisé pour récupérer cet attribut de majorité<br /> D’autre part pour la fonction de transmission d’une preuve de l’âge validé à un site, la CNIL recommande le passage par un tiers de confiance et indépendant. "L’application "Jeprouvemonage «&nbsp;est développée et opérée par Docaposte, filiale du groupe La Poste et référent de la confiance numérique et de la sécurité&nbsp;».<br /> Donc en résumé :<br /> le site qui fournit la vérification d’identité (par exemple L’Identité Numérique) atteste à Jeprouvemonage (Docaposte) que l’utilisateur demandeur a +15 ou +18 ans, sans que Jeprouvemonage connaisse l’identité du demandeur,<br /> Jeprouvemonage atteste au site demandeur que l’utilisateur demandeur a +15 ou +18.<br /> Dans l’affaire, le seul qui connait l’identité de l’utilisateur demander, c’est le fournisseur de vérification d’identité. Lui n’a pas connaissance du site demandeur.<br /> À priori, le service fournisseur d’identité ne sait même si le site demandeur a demandé +15 ou +18, le fournisseur d’identité fournit simplement la «&nbsp;meilleure&nbsp;» preuve d’âge possible, donc +15 si l’utilisateur a entre 15 et 18 et +18 sinon, ce qui fait que le fournisseur d’identité ne peut même pas «&nbsp;deviner&nbsp;» que la demande est pour un site porno (surtout que de toute façon, y a pas que le porno qui est interdit aux moins de 18).
bizbiz
J’avais lu «&nbsp;décapote&nbsp;» … rhooo <br /> Toniglandyl … c’est du béton
pecore
J’aimerai croire à cette solution mais expliqué comme cela et comme dis plus avant, on voit mal les internautes faire confiance à cette solution qui ressemble juste à donner son identifié à un «&nbsp;tiers de confiance&nbsp;» plutôt qu’aux sites pornographiques eux-même.<br /> Les réticences resterons les mêmes, hélas, tant que les consommateurs auront l’impression que l’on peut remonter jusqu’à eux et savoir quels genre de vidéos ils consultent, en quelle quantité et à quelle fréquence.
somoved
pecore:<br /> on voit mal les internautes faire confiance à cette solution qui ressemble juste à donner son identifié à un « tiers de confiance » plutôt qu’aux sites pornographiques eux-même.<br /> Bof, le nombre de tiers de confiance que les internautes acceptent pour beaucoup plus que juste leur identité…
bennukem
Le projet sera enterrée sous une dalle de béton. C’était la bonne lecture.
Duben
Cool, je vais pouvoir vendre des clés d’accès à des sites porno aux ados
xryl
Bien résumé. Note que Jeprouvemonage ne spécifie pas comment il transmet son attestation. Vu que tu ne demandes pas, lorsque tu as moins de 18 ans si tu sais que ça ne marchera pas au final, la «&nbsp;preuve&nbsp;» de la minorité ou majorité n’a aucun intérêt. Si tu dois passer par jeprouvemonage, c’est forcément que tu es majeur, personne ne se prendra la tête à demander de valider la minorité.<br /> Au final, le point faible de cette chaîne, c’est, comme je l’écris plus haut, la «&nbsp;méthode&nbsp;» de transmission de cette attestation au site final. Si JPMA utilise les «&nbsp;tech&nbsp;» web classique, alors, du point de vue du site demandeur, on a:<br /> Bob (IP X.X.X.X) se connecte<br /> Requête à JPMA pour valider le token de majorité<br /> JPMA rapelle le site avec son token valide<br /> Le site dépose un cookie chez Bob pour pas avoir à refaire la validation ultérieurement.<br /> Bref le site sait que Bob (IP X.X.X.X) est majeur et qu’il le consulte. Il connait le token de Bob. Il peut vendre le token de Bob à un data broker.<br /> Mais JPMA sait aussi que le site porno est consulté pour le token de Bob (sans savoir que c’est Bob). Bref, le token de Bob, c’est Bob pour JPMA. Tous les sites que Bob consulte, JPMA est au courant, il ne sait pas que c’est Bob, mais il sait qu’il a consulté «&nbsp;coquinesaparis.com&nbsp;», «&nbsp;milfenchaleur.fr&nbsp;». Voire, une fois généralisé, «&nbsp;google.com&nbsp;», «&nbsp;assurancemoto.com&nbsp;», «&nbsp;meilleurtaux.com&nbsp;», etc…<br /> Pareil, chacun des sites peut vendre le token de Bob à un data broker qui lui fera la connexion.<br /> Pire, il y a de forte corrélation entre ta connexion à JPMA (pour créer ton token) et la connexion au site porno qui va insister pour que tu utilises JPMA et aussi sur l’identité numérique pour créer l’attestation pour JPMA. Bref, un service DGSI (ou simplement Cloudflare ou n’importe quel CDN d’amazon) va simplement consulter les logs pour ton IP sur les 3 sites, recouper par horodatage et tu es identifié direct.<br /> Si par contre le token que JPMA était dématérialisé et stockable hors connexion (genre un «&nbsp;code secret signé par l’identité numérique&nbsp;» que tu stockes sur ton mobile comme une image d’un QRCode or une note), alors JPMA ne pourrait pas tracker Bob, vu qu’il n’est pas prévenu de l’utilisation du token de Bob.<br /> J’ai de gros doute que ce soit la dernière solution qui soit implémentée, mais la première donc non anonyme mais seulement pseudo-anonyme.
xryl
C’est excellent ce lien. Merci.<br /> Ça montre encore une fois combien ça sent l’enfumage du poisson ces sites de «&nbsp;vérification&nbsp;». Si tu regardes l’argumentaire, en gros on a «&nbsp;Nous c’est ISO truc muche, forcément vérifié par un humain, on a 250 ans d’expérience dans le langage Bidule et la norme Machin&nbsp;», en italique en petit: faisez nous confienssssssse<br /> [mode sarcasme]<br /> En gros, tu vas avoir des sites qui vont vendre des photo de CI de vieux, avec une photo issue de leur page Facebook et avoir la certification. Mais c’est vérifié par un humain et ISO 24375927936.<br /> [/mode sarcasme].
MisterDams
La solution en double aveugle, ça existe déjà. Donc oui, il y a moyen de s’assurer que Docaposte ne stocke pas qui demande quoi, et que ClubX n’ai pas le détail de l’âge ou de l’identité non plus.<br /> Pour autant, tout le sujet est autour de la démocratisation du système pour ne pas que chaque demande se retrouve de fait associée à une activité de site porno.<br /> Mais sachant qu’il faut normalement appliquer les mêmes dispositions aux sites de jeu en ligne, aux sites d’alcool &amp; co, il faut juste faire une loi intelligente autour pour que cette demande se banalise. On pourrait même imaginer le Drive d’un supermarché qui vérifie l’âge pour autoriser l’achat d’alcool, voire des solutions de contrôle physiques via le même système (accès aux discothèques, etc) sans devoir révéler son identité.
MattS32
xryl:<br /> Vu que tu ne demandes pas, lorsque tu as moins de 18 ans si tu sais que ça ne marchera pas au final, la « preuve » de la minorité ou majorité n’a aucun intérêt.<br /> C’est pas une preuve de majorité ou de minorité, c’est une preuve d’âge &gt;15 ou &gt;18. Parce que ça peut aussi être utilisé pour des sites interdits seulement aux moins de 15 ans («&nbsp;majorité numérique&nbsp;», légalement nécessaire par exemple pour s’inscrire sur un réseau social sans l’accord des parents).<br /> Cela dit, ça pourrait tout a fait être étendu à une notion de «&nbsp;preuve d’âge&nbsp;» quelque soit l’âge, et donc y compris de preuve de minorité, qui n’est absolument pas sans intérêt : un site dédié aux ados pourrait par exemple tout a fait exiger une preuve de minorité, pour éviter de devenir un terrain de chasse pour pédophiles comme le sont aujourd’hui hélas beaucoup d’espaces destinés aux mineurs…<br /> xryl:<br /> Il connait le token de Bob. Il peut vendre le token de Bob à un data broker.<br /> Le token est anonyme et à usage unique, ce n’est pas le token de Bob. Si Bob revient le lendemain, il aura un token différent. S’il va sur un autre site, il aura un token différent.<br /> Et ce n’est d’ailleurs probablement même pas le même token qui passe du service de vérification d’identité à JPMA et de JPMA au site (parce que le site attend logiquement un token signé par JPMA, avec qui il a un accord, pas un token signé par un service tiers avec lequel il n’a pas d’accord direct).<br /> xryl:<br /> C’est excellent ce lien. Merci.<br /> Sauf que c’est pas le bon. C’est le lien vers leur service de vérification d’identité (donc où le site demandeur connait l’identité de l’utilisateur et demande à l’attester). Pas vers leur service de vérification d’âge.<br /> xryl:<br /> En gros, tu vas avoir des sites qui vont vendre des photo de CI de vieux, avec une photo issue de leur page Facebook et avoir la certification. Mais c’est vérifié par un humain et ISO 24375927936.<br /> Sauf que non, les sites de vérification d’identité ne marchent en général pas avec une simple photo de la carte d’identité. Ils demandent en général en plus un selfie pris en direct (avec leur appli / site), voire un selfie vidéo, et parfois même en tenant en plus la carte d’identité en main.<br /> xryl:<br /> Si par contre le token que JPMA était dématérialisé et stockable hors connexion (genre un « code secret signé par l’identité numérique » que tu stockes sur ton mobile comme une image d’un QRCode or une note), alors JPMA ne pourrait pas tracker Bob, vu qu’il n’est pas prévenu de l’utilisation du token de Bob.<br /> Par contre Toto, 19 ans, pourrait générer plein de QR codes pour les vendre à Rifi, Fifi et Loulou, moins de 15 ans…<br /> Alors que JPMA ne peut pas tracker Bob, puisqu’il ne sait pas qui est Bob. Il voit des requêtes passer, mais sur 3 requêtes, ça peut tout aussi bien être Bob 3 fois de suite que Alice, Bob et Eve, sans que JPMA n’ait de possibilité de le savoir… Sauf s’il dépose lui même des cookies de tracking. Ce qu’il n’a pas le droit de faire sans accord…<br /> Alors oui bien sûr, on peut aussi être parano et partir du principe que JPMA n’est qu’un enfoiré qui cherche à tracker les gens et faire de l’argent avec ça, en mentant sur tout la ligne. Mais bon, à ce compte là, on fait rien en ligne, et on va surtout pas sur des sites pornos, parce que c’est sans doute pas eux les plus à cheval sur le respect de la législation sur les données personnelles et la vie privée… Bien moins en tout cas qu’une entreprise qui monte un business sur ça justement, et qui perd tout si ça se sait qu’elle a menti sur toute la ligne.
Joeee
pecore:<br /> J’aimerai croire à cette solution mais expliqué comme cela et comme dis plus avant, on voit mal les internautes faire confiance à cette solution qui ressemble juste à donner son identifié à un « tiers de confiance » plutôt qu’aux sites pornographiques eux-même.<br /> Tu as peut être un compte Google et tu t’y connectes en permanence<br /> mais le nombre de fois que l’on m’incite à m’y connecter pour consulter un site quelconque, pour m’inscrire à un site au lieu de fournir mail + mdp est incroyable.<br /> Si j’en vois autant, il doit y avoir pas mal d’amateur de ce système d’authentification Google pour se connecter ensuite partout.
xryl
MattS32:<br /> Le token est anonyme et à usage unique, ce n’est pas le token de Bob. Si Bob revient le lendemain, il aura un token différent. S’il va sur un autre site, il aura un token différent.<br /> Non, il n’y a rien d’anonyme ici. Le token est celui de Bob pour la simple raison que le site connait Bob (X.X.X.X). Même si Bob revient le lendemain, il présentera le cookie de session que le site n’aura pas oublié d’installer sur son navigateur (ou l’un ou l’autre des méthode habituelle de browser ID/fingerprint, ne serait-ce que l’IP). Le site gagne de l’argent avec les données de ses utilisateurs, jamais il ne réinitialiserait ses informations.<br /> MattS32:<br /> Et ce n’est d’ailleurs probablement même pas le même token qui passe du service de vérification d’identité à JPMA et de JPMA au site (parce que le site attend logiquement un token signé par JPMA, avec qui il a un accord, pas un token signé par un service tiers avec lequel il n’a pas d’accord direct).<br /> Oui c’est certain, sinon il n’y a rien d’anonyme entre l’identité de Bob (via identité numérique.fr) et JPMA. Mais le problème c’est purement mathématique. Le token fourni par identité numérique.fr ne peut pas être renouvelé par JPMA si, réellement et je n’en doute pas, JPMA ignore l’identité de Bob. Donc le token de l’identité numérique est statique chez JPMA (en d’autre terme, il est signé par identité numérique, il aurait tout aussi bien pu être donné au site final).<br /> JPMA dans ce cas, reçois une demande du site porno. L’utilisateur va être redirigé vers JPMA (process classique car les cookies cross domain ne fonctionnent plus, c’est la seule méthode possible). Le but étant que l’utilisateur se connecte sur JPMA pour autoriser la requête. Le site porno fourni un identifiant à JPMA (une sorte d’ID). JPMA a alors l’IP de l’utilisateur, et doit la conserver car c’est une obligation légale.<br /> Une fois autorisée (et souvent stocké sous forme d’un cookie de session sur le navigateur de l’utilisateur), JPMA appelle (en backend) une URL du site porno (avec l’ID fourni et/ou un token d’accès à fournir pour les prochaines visites), avant de rediriger l’utilisateur vers le site initial.<br /> L’ID fourni est obligatoire, sinon le site ne peut pas savoir à qui JPMA autorise l’accès, il peut y avoir 40 demandes en cours. Et vu que l’ID est fourni par le site lui même, c’est donc Bob. Le token d’accès est (quasi) obligatoire pour éviter d’avoir à faire ces requêtes à chaque ressource demandée.<br /> Donc JPMA est obligé de stocker ce token dans une BDD. Et tant que la session est vivante, le token représente Bob (même si JPMA ne sais pas qui est Bob). Et vu que l’utilisateur s’y est connecté pour l’avoir, JPMA a l’adresse IP associée.<br /> Le même token fourni par un autre site à JPMA sera tout aussi validé sans même passer par la page de login de JPMA car c’est son rôle. Un site actuellement peut avoir de multiple adresse IP et DNS, le token est indépendant de l’origine de l’émetteur.<br /> Par la suite, le site peut soit stocker un cookie de session sur le navigateur de Bob (et éviter d’avoir à reparler à JPMA) soit stocker le token d’accès dans sa BDD et l’associé au browser ID de Bob. Dans les 2 cas, c’est un identifiant unique associé à Bob: c’est Bob.<br /> Tu vends ce token à un data broker, et le site hamster.com l’achète. Bob, s’il va sur le site hamster.com est identifié via son browser ID et le token est utilisé (en backend) pour valider direct la resource sur JPMA.<br /> Bref, c’est game over.<br /> MattS32:<br /> Sauf que c’est pas le bon. C’est le lien vers leur service de vérification d’identité (donc où le site demandeur connaît l’identité de l’utilisateur et demande à l’attester). Pas vers leur service de vérification d’âge.<br /> J’avais bien compris. Je remarque simplement qu’un service que je pensais fiable est en réalité truffé de faiblesses (la vérification humaine par exemple, c’est certainement pas un avantage AMHA). En gros, c’est assez falsifiable comme service. Il n’y a aucune description technique sur JPMA, évidemment, mais je parie que c’est du même acabit.<br /> MattS32:<br /> Par contre Toto, 19 ans, pourrait générer plein de QR codes pour les vendre à Rifi, Fifi et Loulou, moins de 15 ans…<br /> Alors que JPMA ne peut pas tracker Bob, puisqu’il ne sait pas qui est Bob. Il voit des requêtes passer, mais sur 3 requêtes, ça peut tout aussi bien être Bob 3 fois de suite que Alice, Bob et Eve, sans que JPMA n’ait de possibilité de le savoir… Sauf s’il dépose lui même des cookies de tracking. Ce qu’il n’a pas le droit de faire sans accord…<br /> Très juste. C’est pour ça qu’il n’existe aucune solution fonctionnelle à ce problème.<br /> Soit c’est offline et donc il peut y avoir un business de vente de token d’identité d’adulte mais on garantit à 100% l’anonymat.<br /> Soit c’est online et comme vu plus haut, JPMA et le site peuvent tracer l’utilisateur, rien n’est anonyme. Après, connaissant la négligence des gens, rien n’empêchera Toto de fournir ses identifiants JPMA à Riri fifi ou Loulou non plus, voire enregistrer le mot de passe de JPMA en remplissage automatique afin que Riri, Fifi ou Loulou n’aient qu’à cliquer sur «&nbsp;Remplir les champs&nbsp;».<br /> Finalement, une des erreurs fondamentales ici, c’est de croire qu’un site X à besoin de savoir commentoutapel. Il s’en balance. Il veut savoir ce que tu fais, ce qu’il peut te vendre, où tu es, combien tu dépenses, etc… Ton nom, il s’en balance, il ne t’enverra jamais de carte postale.<br /> Ton ip, c’est ton adresse (suffisamment proche en tout cas), ce que tu fais, voir plus haut comment c’est collecté, et ce qu’il peut te vendre, c’est en estimant un profil, donc en croisant ton historique de navigation et les différents sites que tu visites (bonus point si tu cliques sur les pubs).<br /> C’est sûr que c’est un peu mieux que «&nbsp;Entrez votre nom ici et votre âge là&nbsp;», mais ça ne résout aucun problème, ça ne fait que complexifier la route d’accès.<br /> Un mineur saura rapidement utiliser un VPN pour contourner ce genre de restrictions. Ou il utilisera le PC du père ou de la mère. Ou…
MattS32
xryl:<br /> Le token est celui de Bob pour la simple raison que le site connait Bob (X.X.X.X)<br /> Le site connait l’IP. Il ne sait pas à qui elle appartient. Et si il peut le savoir, alors de toute façon il peut déjà le savoir aujourd’hui, token ou non. La seule info supplémentaire que lui apporte le token, c’est que le mec derrière l’IP X.X.X.X semble être majeur.<br /> xryl:<br /> Mais le problème c’est purement mathématique. Le token fourni par identité numérique.fr ne peut pas être renouvelé par JPMA si, réellement et je n’en doute pas, JPMA ignore l’identité de Bob. Donc le token de l’identité numérique est statique chez JPMA (en d’autre terme, il est signé par identité numérique, il aurait tout aussi bien pu être donné au site final).<br /> À chaque requête à JPMA, il y a une requête vers le site d’identité choisi par l’utilisateur. Il n’y a donc aucune raison de renouveler quoi que ce soit.<br /> xryl:<br /> Le but étant que l’utilisateur se connecte sur JPMA pour autoriser la requête.<br /> Non, l’utilisateur ne se connecte PAS sur JPMA. Il n’y a pas de comptes utilisateurs sur JPMA.<br /> Simplement, quand JPMA reçoit une requête d’authentification, il demande à l’utilisateur quel service d’identité il veut utiliser pour certifier son âge et émet une requête vers ce service, puis en fonction de la réponse de ce service, répond au site demandeur.<br /> xryl:<br /> JPMA a alors l’IP de l’utilisateur, et doit la conserver car c’est une obligation légale.<br /> Depuis quand conserver l’IP de quelqu’un qui visite une URL HTTP est une obligation légale ? La CNIL et le RGPD préconisent même l’exact inverse en fait, une IP ne doit être conservée que si c’est techniquement nécessaire pour rendre le service (avec une tolérance sur les logs techniques)<br /> xryl:<br /> Une fois autorisée (et souvent stocké sous forme d’un cookie de session sur le navigateur de l’utilisateur), JPMA appelle (en backend) une URL du site porno<br /> Non, pas nécessairement… Renseigne toi sur le fonctionnement d’OAuth2 ou des JWT, ça ne passe jamais en back, toutes les requêtes sont faites par le navigateur du client (pour info, sur les applis web que je développe actuellement, on fait du OAuth2 / JWT avec des fournisseurs d’identité externes, comme Google et Microsoft, sur des services dont les serveurs n’ont aucune exposition sur Internet… et ça marche… parce que tout transite par le navigateur du client).<br /> En gros, de façon simplifiée :<br /> Bob envoi une requête à SitePorno, SitePorno initie une session et stocke son id dans un cookie de Bob et dans son session store,<br /> SitePorno redirige bob vers JPMA/?agereq=18&amp;id=&amp;callback=SitePorno/authenticated/<br /> JPMA initie une session et stocke son id dans un cookie de Bob et sans son session store. Dans le session store, il associe «&nbsp;random A&nbsp;», «&nbsp;18+&nbsp;» et «&nbsp;SitePorno/authenticated/&nbsp;» à la session de Bob.<br /> JPMA renvoi l’utilisateur vers ServiceIdChoisiParBob/?id=&amp;callback=JPMA/check_age/, il associe également «&nbsp;random B&nbsp;» à la session de Bob<br /> ServiceIdChoisiParBob vérifie l’identité de Bob, génère un token, par exemple «&nbsp;18+202311101625&nbsp;» et le signe puis redirige Bob en vers JPMA/check_age avec le token quelque part (ça peut être dans les headers HTTP, dans l’URL en GET ou dans le body en POST)<br /> JPMA reconnait que c’est la session de Bob, valide le token avec sa signature, et comme dedans il y avait «&nbsp;random B&nbsp;», il sait que c’est bien un vrai token que vient de générer le service d’ID pour cette requête de Bob (point important, car JPMA n’a pas d’autre moyen de vérifier que le navigateur de Bob a réellement appelé le service d’ID…)<br /> JPMA vérifie que l’âge dans le token est conforme à l’âge requis, qu’il avait associé à la session dans son session store<br /> JPMA génère un nouveau token «&nbsp;18+20231110_1626&nbsp;» qu’il signe avec sa signature<br /> JPMA redirige Bob vers SitePorno/authenticated/ avec le nouveau token quelque part dans la requête et supprime la session de Bob de son sessions store<br /> SitePorno reconnait la session de Bob et vérifie que le token correspond bien à «&nbsp;random A&nbsp;».<br /> On a bien :<br /> à aucun moment SitePorno ou JPMA ne sait qui est Bob, seul ServiceIdChoisiParBob le sait,<br /> à aucun moment ServiceIdChoisiParBob ne sait que Bob visite SitePorno, ni même qu’il visite un site 18+. Il sait juste qu’il visite un site nécessitant un contrôle de l’âge.<br /> Maintenant si SitePorno vend le token à JeuDArgent, JeuDArgent ne peut rien en faire (bon du coup, il est pas con, il va pas l’acheter en fait)… Parce que quand Bob va aller sur JeuDArgent, JeuDArgent ne pourra pas savoir que le token correspond à Bob. Et même s’il le savait, il ne peut pas envoyer lui même le token à JPMA pour valider l’âge de Bob. Parce que ce n’est pas comme ça que ça marche… JPMA n’attend pas le token en entrée, il attend un nombre aléatoire qu’il va intégrer dans le token qu’il va générer…<br /> xryl:<br /> Donc JPMA est obligé de stocker ce token dans une BDD.<br /> Absolument pas.<br /> xryl:<br /> Et vu que l’utilisateur s’y est connecté pour l’avoir, JPMA a l’adresse IP associée.<br /> Non plus : même s’il log les IP des requêtes HTTP, et même s’il enregistrait les token en base (ce qu’il n’a pas besoin de faire, je le répète), il n’a aucun obligation d’associer le token à l’IP dans sa base.<br /> xryl:<br /> Le même token fourni par un autre site à JPMA. Un site actuellement peut avoir de multiple adresse IP et DNS, le token est indépendant de l’origine de l’émetteur.<br /> Un autre site ne fournira pas le même token, ce sont des token à usage unique. Si le site porno ne veut pas que son utilisateur ait à réauthentifier son âge à chaque nouvelle session sur le site, c’est au site de le gérer en demandant à l’utilisateur de créer un compte, compte qui pourra être marqué comme ayant été vérifié pour l’âge.
pecore
Joeee:<br /> Tu as peut être un compte Google et tu t’y connectes en permanence<br /> Non et non.
xryl
MattS32:<br /> À chaque requête à JPMA, il y a une requête vers le site d’identité choisi par l’utilisateur. Il n’y a donc aucune raison de renouveler quoi que ce soit.<br /> Alors ce n’est pas anonyme et c’est contraire à ce qui est décrit plus haut. Du coup, JPMA connait le site que tu consultes + ton identité (pas directe, mais avec un identifiant unique, forcément).<br /> Il ne sait pas que c’est Bob, mais il sait que c’est ID(Bob). Ce qui revient au même pour le tracking.<br /> Je ne pense pas que ce soit le cas sinon c’est encore pire que ce que j’imaginais. Ce tiers de confiance devient la plaque tournante de toutes les connexions chelou des internautes, autant dire que c’est le meilleur endroit pour y installer une sonde (DGSI ou autre).<br /> MattS32:<br /> Non, l’utilisateur ne se connecte PAS sur JPMA. Il n’y a pas de comptes utilisateurs sur JPMA.<br /> Simplement, quand JPMA reçoit une requête d’authentification<br /> Bien sûr que l’utilisateur se connecte sur JPMA. Pas volontairement, mais le site X te redirige vers JPMA où tu vas autoriser le site X à accéder à l’information qu’il demande, soit ta preuve de majorité. L’utilisateur a un compte JPMA soit pour stocker l’attestation de majorité soit pour stocker l’URL du site de vérification de sa majorité. Le site demandeur est recontacté uniquement lorsque le challenge JPMA est terminé, c’est à dire lorsque tu as validé la demande d’accès sur le site. Soit c’est en backend (JPMA émet une requête vers un callback URL sur le site X, typiquement en SAML), soit en frontend (tu es redirigé vers une URL spéciale sur le site X avec un token dans l’URL, typiquement OAuth).<br /> Cette danse de la redirection est obligatoire car il n’y a plus de communication cross-serveur possible via ton browser (c’est fini les cookies crossdomain, et les hack avec des iframes)<br /> MattS32:<br /> Depuis quand conserver l’IP de quelqu’un qui visite une URL HTTP est une obligation légale ?<br /> Regarde le code des postes et des communications et le code de la sécurité intérieure. En gros tu dois conserver les métadonnées pendant un an.<br /> Par dérogation au principe d’anonymisation, prévu à l’article [L. 34-1, I et II du code des postes et des communications électroniques](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000028345210/2013-12-20) , les dispositions des[ articles R. 10-13 ](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000025622766/) et [R. 10-14 du même code](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000006466370/2006-03-26) obligent les opérateurs de communications électroniques à conserver les données de connexion de leurs utilisateurs : données d’identification (adresses IP, identité attachée à un numéro de téléphone), nature du trafic (date, heure, nature des pages consultées, des sites visités), caractéristiques techniques des terminaux, informations relatives à la facturation et au paiement etc.<br /> Ces données doivent être conservées pendant une durée d’un an.<br /> L’objet même des obligations de conservation précédemment exposées est de permettre à un certain nombre d’autorités publiques d’exploiter les données de connexion.<br /> En effet, en aval de cette obligation, plusieurs dispositifs juridiques, détaillés aux articles L. 851-1, L. 851-2, L. 851-3 et L. 851-4 du code de la sécurité intérieure permettent aux services de renseignement d’accéder à ces données. Ainsi, ces services peuvent recourir, non seulement à l’extraction des données à une échéance donnée, mais encore procéder à leur collecte en temps réel : par exemple lorsqu’il est question de suivre à la trace les déplacement d’un individu donné, au jour le jour.<br /> En vertu de l’article L. 811-3 du même code, dont il a déjà été question, les services de renseignement ont le droit d’accéder aux données de connexion, en vertu d’un certain nombre de motifs, notamment le respect de l’intégrité du territoire national, les intérêt majeurs de la politique étrangère de la France, la prévention du terrorisme, la lutte contre la criminalité organisée, ainsi que les intérêts économiques, industriels et scientifiques majeurs de la France.<br /> Pour le détail de l’authentification/authorization, j’ai implémenté plusieurs proxy OAuth2 (dont Authelia) et il y a plein de modes possibles. Celui que tu décris en est un (c’est pour l’authorization). Mais ça n’a aucun sens ici pour implémenter cette fonction d’anonymisation.<br /> Dans ton exemple, tu considères JPMA comme un proxy d’autorisation. C’est possible, mais pour ça, à l’étape 4, il faut que JPMA connaisse Bob. Il a donc soit mis une page de login + password pour identifier bob (authentification), car sinon, le «&nbsp;ServiceChoisiParBob&nbsp;» est inconnu.<br /> JPMA a donc Bob + le SitePorno =&gt; Game over pour l’anonymat. Encore une fois, il ne sait pas que Bob s’appelle Robert Dupont, mais il a son IP + son historique de navigation (SitePorno) + un identifiant unique.<br /> Si c’est implémenté comme ça, c’est la pire solution possible.<br /> Rien ne prouve que l’étape 9 soit vraie (et ça ne le sera pas, pour la simple raison que personne ne supprime une session Oauth avant un timeout assez long, vu qu’il y a souvent plusieurs itérations d’autorisation à la suite, on garde le résultat en cache).<br /> Et le fameux token de l’étape 8 c’est le token qu’il faut vendre pour SitePorno, puisque ce token = Bob.<br /> Tes conclusions sont fausses, car tu ignores le browser fingerprinting (ou browser ID). Pour les databroker, si tu identifies en navigateur/utilisateur avec une confiance suffisante (ce que fait le browser ID), c’est encore meilleur que l’identité elle-même.<br /> browserID + token = accès à JPMA = pas de process pénible pour Bob = meilleure conversion donc + de ventes<br /> L’autre solution, c’est que JPMA ne soit pas un proxy d’autorisation mais d’authentification uniquement (comme je l’ai décris plus haut). Dans ce cas, un seul serveur est impliqué. C’est un poil meilleur (au moins, il n’a pas le lien entre Bob et son identité numérique).<br /> MattS32:<br /> Un autre site ne fournira pas le même token, ce sont des token à usage unique.<br /> Faux. Un token a une durée de validité, et durant toute la durée de validité JPMA évitera de rediriger l’utilisateur sur la page de login. Il est impossible que le token soit à usage unique, pour la simple raison qu’il faut le token pour le détruire (le disconnect).<br /> Le site porno peut difficilement faire confiance au cookie store car la majorité des utilisateurs navigues en mode privé (et donc le store est vidé après chaque visite). Donc pour éviter que le process JPMA soit à réaliser à chaque session (ce qui ruinerait l’expérience de navigation), c’est forcé que le token ait une validité assez longue.<br /> Attention, je ne dis pas que le SitePorno sait qui est Bob. Ni JPMA.<br /> Par contre avant ce système seulement le SitePorno connaissait Bob (du moins, son IP).<br /> Après ce système, à la fois JPMA et le SitePorno connaissent Bob (et probablement identité numérique aussi si c’est implémenté comme tu le décris).<br /> Pire, JPMA sait que Bob consulte SitePorno!<br /> Et ça c’est rédhibitoire car, tu peux tourner le problème dans tous les sens, c’est une atteinte à la vie privée et l’anonymat. Quitte à avoir un process chiant, autant démarrer un VPN ou définir un proxy étranger.
MattS32
xryl:<br /> Bien sûr que l’utilisateur se connecte sur JPMA. Pas volontairement, mais le site X te redirige vers JPMA où tu vas autoriser le site X à accéder à l’information qu’il demande, soit ta preuve de majorité. L’utilisateur a un compte JPMA soit pour stocker l’attestation de majorité soit pour stocker l’URL du site de vérification de sa majorité.<br /> Non. Il n’y a pas besoin d’avoir un compte sur JPMA pour ça. L’attestation d’âge transmise par le vérificateur d’identité n’est pas conservée par JPMA sur son serveur, elle est conservée sur le téléphone de l’utilisateur.<br /> xryl:<br /> Regarde le code des postes et des communications et le code de la sécurité intérieure. En gros tu dois conserver les métadonnées pendant un an.<br /> Quand tu es FAI (" obligent les opérateurs de communications électroniques à conserver les données de connexion de leurs utilisateurs") . Pas un service disponible via Internet, qui n’est pas un opérateur (dans les textes de lois, ils sont qualifiés d’«&nbsp;éditeur de service&nbsp;» en général). Un service Internet par défaut ne doit PAS stocker les IP (il y a une tolérance pour les logs techniques, et uniquement pour ça).<br /> xryl:<br /> Rien ne prouve que l’étape 9 soit vraie (et ça ne le sera pas, pour la simple raison que personne ne supprime une session Oauth avant un timeout assez long, vu qu’il y a souvent plusieurs itérations d’autorisation à la suite, on garde le résultat en cache).<br /> Pure spéculation de ta part parce que tu as décidé depuis le début que Docaposte sont des grands méchants menteurs qui veulent fliquer les gens qui vont sur des sites pornos.<br /> xryl:<br /> Et le fameux token de l’étape 8 c’est le token qu’il faut vendre pour SitePorno, puisque ce token = Bob.<br /> Quel intérêt ce token a à la vente ? Aucun. Un autre site ne peut l’utiliser pour rien, il n’a aucune valeur ce token, tout ce qu’il dit c’est que l’utilisateur pour lequel SitePorno avait généré l’id Random A a plus de 18 ans. Aucune information personnelle. Et quand Bob va aller sur JeuxDArgent, même si JeuxDArgent a en sa possession ce token, il n’a aucun moyen de l’associer à Bob… Sauf par des moyens qui n’ont rien à voir avec le token et avec JPMA, moyens qui peuvent déjà être mis en œuvre aujourd’hui sans. Acheter ce token n’apporte strictement rien.<br /> xryl:<br /> Le site porno peut difficilement faire confiance au cookie store car la majorité des utilisateurs navigues en mode privé (et donc le store est vidé après chaque visite). Donc pour éviter que le process JPMA soit à réaliser à chaque session (ce qui ruinerait l’expérience de navigation), c’est forcé que le token ait une validité assez longue.<br /> En navigation privée, le token saute aussi après chaque visite, ça ne change rien… Tous les moyens de stocker des informations dans le navigateur sautent.<br /> xryl:<br /> Attention, je ne dis pas que le SitePorno sait qui est Bob. Ni JPMA.<br /> Si, c’est bien ce que tu disais au début :<br /> xryl:<br /> . En quoi c’est anonyme si la poste récupère tout l’historique de navigation « louche » d’une personne.<br /> Alors oui, par contre JPMA sait que telle IP va sur SitePorno (et non, comme je le décris, Identité Numérique ne le sait pas, il sait juste que l’utilisateur est allé sur un site faisant un contrôle d’âge, ce qui ne dit pas forcément que c’est un site porno et encore moins lequel… cela dit, ma description ne semble pas correspondre tout a fait au fonctionnement de JPMA, où le lien avec le service d’identité n’est pas synchrone, le service fournit un certificat conservé dans le téléphone de l’utilisateur, donc il n’y a pas une requête vers ce service à chaque accès à un site demandant une vérification d’âge, après la première utilisation et pendant un an, c’est le téléphone de l’utilisateur qui devient le fournisseur d’identité).<br /> Mais ça tu peux pas faire autrement sans permettre un trafic de jetons si ça marche en étant totalement déconnecté : c’est le fait d’être connecté qui permet de fonctionner avec des jetons jetables ayant une très courte durée de vie (pas besoin de plus de quelques secondes)… Et à partir du moment où JPMA n’enregistre pas ces IP, il n’y a pas de problème particulier. Or il n’a aucune obligation de les enregistrer.<br /> En fait, sauf à accuser JPMA de mentir ou de ne pas respecter la loi, on peut même affirmer que JPMA n’enregistre PAS ces données. Parce que la législation française impose d’indiquer à l’utilisateur quand son adresse IP est enregistrée, et la politique de confidentialité de JPMA ne mentionne aucune collecte d’adresse IP.<br /> Reste au final un truc à vérifier, c’est si, après le scan de QR et la validation par l’utilisateur de l’autorisation de partage, JPMA notifie SitePorno en back, comme tu le supposes, ou en front, comme je le suppose.<br /> En gros, on a deux possibilité pour cette étape :<br /> smartphone → back JPMA → front JPMA → front SitePorno<br /> smartphone → back JPMA → back SitePorno → front SitePorno<br /> (EDIT : après réflexion, la seconde ne me parait pas possible, ça doit forcément passer par le front JPMA : quand il scanne le QR, l’utilisateur a le front JPMA sur son navigateur, plus le front SitePorno, donc pour que la redirection vers SitePorno se déclenche, il faut forcément que front JPMA soit notifié du succès du scan… on pourrait envisager la 2ème solution avec une double notification par back JPMA à la fois vers front JPMA et back SitePorno, mais ça aurait peut d’intérêt, puisqu’à partir du moment où front JPMA redirige vers front SitePorno, la notification peut passer par là…)<br /> Dans le premier cas, ça peut se faire sans même que le back JPMA ne stocke l’URL de callback (il la voit forcément passer dans la requête GET ou POST initiale, mais peut tout a fait ne pas la stocker, puisque c’est uniquement le front qui en a besoin, une fois que le back l’a notifié que c’est OK), dans le second cas ça implique un stockage temporaire de l’URL de callback côté back JPMA (mais toujours pas besoin de l’associer à une IP dans une bdd).<br /> Pour vérifier ce point, j’ai essayé de trouver une liste des sites partenaires de JPMA, mais je n’en ai pas trouvé ^^
kroman
Tout ce bazar alors que certains sites ont déjà une solution béton en place pour garantir notre anonymat :<br /> Avez-vous 18 ans ? oui/non.<br /> Un petit cookie pour garder la réponse, et voilà c’est plié !
PPano
Moi je pense que les D"jeuns devrait pourvoir choper un vieux Playboy du grand père au grenier pour coller les pages… bien plus simple et rapide… LoL
Mel92
Je ne dois pas bien comprendre le problème car la solution semble terriblement évidente : J’ai plus de 18 ans, je m’identifie et m’inscris sur le site de la capote puis je vends mon accès à qui le veut pour 1€ (je prends Paypal, pas besoin d’aller chercher les bitcoins ou autre truc de margoulin).<br /> Ça marche car il n’est pas question dans l’article de lier l’identification à un élément matériel comme un portable ou un numéro de téléphone par exemple. Si jamais ça devait devenir le cas, je propose le même service mais un peu plus cher car je devrais vendre l’accès à mon portable…<br /> C’est bien sûr parfaitement légal car les sites pornos ne sont pas tenus de vérifier que le détenteur de l’accréditation de la capote est valide (et en plus elle l’est), ni que l’accréditation correspond à la personne physique qui se connecte. Par ailleurs, je ne vois pas où le fait de vendre mon âge est interdit. D’ailleurs, si vous ne voulez pas de mon âge, je vends aussi celui de ma mère
JohnLemon
Ce n’est pas comme si ça faisait au moins un an qu’on crie dans les oreilles du gouvernement que c’est la meilleure solution pour tout le monde : blocage réellement effectif pour les mineurs et anonymat garanti pour les adultes.<br /> Donc oui, j’y suis vraiment favorable pour une fois.<br /> Reste à savoir comment ça sera mis en œuvre et surtout si ça sera fiable.<br /> Moi et les applis d’authentification ça a tendance à faire deux, à chaque fois il y a un problème complètement random et imprévisible qui m’empêche de la faire fonctionner. (C’est le cas pour l’identité numérique de la Poste par exemple.)
Voir tous les messages sur le forum
Haut de page

Sur le même sujet