2 points par GN⁺ 22 시간 전 | 2 commentaires | Partager sur WhatsApp
  • F-Droid critique Android Developer Verification (ADV), déjà déployé sur les appareils sous Android 8 et versions ultérieures, en estimant qu’il pourrait devenir un mécanisme de contrôle centralisé empêchant l’exécution d’apps de développeurs non approuvés par Google
  • Google met en avant la lutte contre la propagation des malwares, mais F-Droid considère qu’ADV sert surtout à augmenter le coût de réinscription des développeurs récidivistes, plutôt qu’à bloquer la distribution initiale
  • L’inscription des développeurs exige la création d’un compte, le paiement de frais, la fourniture de données personnelles et d’une pièce d’identité émise par l’État, l’enregistrement des identifiants d’apps et des clés de signature, ainsi que l’acceptation des conditions d’utilisation de l’Android Developer Console
  • La principale inquiétude est qu’en l’absence de définition claire des malwares dans les conditions, Google puisse élargir les motifs de blocage pour des raisons commerciales ou sous la pression de gouvernements
  • Le dispositif s’appliquera à partir du 30 septembre 2026 au Brésil, en Indonésie, à Singapour et en Thaïlande ; l’impact réel sur l’app F-Droid, les apps installées, les données des apps et la télémétrie de vérification de Google reste encore incertain

Pourquoi F-Droid compare ADV à un malware

  • F-Droid estime que Android Developer Verifier (ADV) est installé sur les appareils sous Android 8 et versions ultérieures, et qu’il attend d’être activé à distance
  • ADV aurait déjà été déployé sur jusqu’à 4 milliards de téléphones et tablettes Android, avec l’estimation qu’environ la moitié de la population mondiale pourrait être concernée
  • Ce service système s’exécute en arrière-plan, et F-Droid affirme ne pas pouvoir le bloquer, le désactiver ni le supprimer
  • Play Protect est un service qui détecte les malwares courants et y répond sur les appareils Android Certified, mais F-Droid critique ADV comme étant diffusé et installé via Play Protect
  • Une fois activé, ADV viserait selon F-Droid à empêcher l’exécution de logiciels de développeurs qui n’ont pas reçu l’approbation centralisée de Google

Réponse à l’argument de la lutte contre les malwares

  • F-Droid a soulevé pour la première fois ses inquiétudes concernant Android Developer Verification en septembre 2025 dans F-Droid and Google’s Developer Registration Decree
  • L’obligation d’enregistrement centralisé des développeurs imposée par Google est présentée comme une mesure de prévention de la propagation des malwares, mais F-Droid estime que ce système ne bloque pas la distribution initiale par des acteurs malveillants
  • Son effet réel serait plutôt de ralentir les récidivistes déjà identifiés lorsqu’ils tentent de continuer à diffuser des malwares avec une nouvelle clé de signature, puisqu’ils doivent alors créer ou acheter un nouveau compte
  • Des alternatives moins coercitives seraient également possibles
    • Play Protect pourrait examiner de plus près les nouvelles apps installées disposant de privilèges élevés ou les apps obtenues via des canaux suspects
    • Un modèle de vérificateurs fédérés, dans lequel les utilisateurs choisissent eux-mêmes les vérificateurs et autorités auxquels ils font confiance, serait aussi possible, comme dans DCM: A Developers Certification Model for Mobile Ecosystems
  • F-Droid reproche à Google de vouloir redessiner l’écosystème Android au nom d’un vecteur de menace étroit, et de devenir l’unique gatekeeper décidant quelles apps peuvent exister

Procédure d’inscription des développeurs et risques liés aux conditions

  • Contrairement aux recommandations de F-Droid, un développeur qui s’inscrit auprès de Google comme développeur « vérifié » doit passer par les étapes suivantes
    • Création d’un compte et paiement de frais
    • Fourniture de données personnelles détaillées
    • Téléversement d’une pièce d’identité émise par l’État
    • Enregistrement des identifiants et clés de signature des apps distribuées aujourd’hui et à l’avenir
  • Le principal point de débat est l’obligation d’accepter les Android Developer Console Terms of Service
  • La clause 6.5 indique que Google peut mettre fin à l’accès à l’ADC si un développeur enfreint les conditions ou distribue un malware ou une application harmful
  • F-Droid souligne que ce document ne contient nulle part de définition officielle, de critères ni de lignes directrices concernant le terme « malware »
  • Si la définition reste vide, un « malware » devient un logiciel que Google désigne comme tel, et son périmètre peut varier selon des motivations commerciales ou de fortes pressions gouvernementales

Le cas des ad blockers illustre le problème du périmètre de blocage

  • F-Droid avertit qu’il est dangereux de laisser une partie aux intérêts divergents définir les termes du débat
  • L’exemple emblématique cité est celui des ad blockers, des outils personnels de filtrage de contenu
  • F-Droid s’inquiète de voir Google désigner tous les logiciels de blocage publicitaire comme des malwares, empêcher leur installation sur les appareils Android Certified dans le monde entier et classer leurs développeurs comme créateurs de malwares
  • Cette possibilité correspondrait, selon F-Droid, aux motivations commerciales de Google dans l’adtech et à la formulation des conditions de l’Android Developer Console

Arguments sur le taux d’adoption et mouvements d’opposition

  • Google a récemment déclaré que plus de 99 % des apps de développeurs Play avaient été enregistrées, mais F-Droid conteste que cela constitue une preuve d’acceptation généralisée d’ADV
  • Selon F-Droid, ces développeurs étaient liés par leurs contrats Play Store existants et ont donc été inclus automatiquement sans consentement préalable suffisant
  • L’opposition à ADV se poursuit également
    • Des centaines de milliers de personnes ont signé une pétition contre ADV
    • L’Open Letter de keepandroidopen.org a été signée par plus de 70 organisations dans le monde, dont l’EFF, la FSF, la FSFE, l’ACLU et Forbrukerrådet
    • F-Droid affirme que, dans une vidéo de table ronde de développeurs visant à défendre le programme, 90 % des spectateurs ont enregistré un dislike
  • F-Droid indique que les législateurs et les régulateurs n’ont jusqu’à présent pas répondu à ces réactions
  • F-Droid estime que son modèle de sécurité fondé sur la transparence open source entre fondamentalement en conflit avec le modèle de confiance des app stores commerciaux fermés

Incertitudes restantes avant l’application du 30 septembre

  • On ne sait pas encore précisément sous quel mode de défaillance l’activation d’ADV se manifestera le 30 septembre 2026
  • Selon le calendrier public de Google, les premiers pays concernés seront le Brésil, l’Indonésie, Singapour et la Thaïlande
  • Ces quatre pays compteraient 580 millions d’habitants
  • Le déploiement mondial est prévu « en 2027 et au-delà »
  • Pour les utilisateurs des régions concernées, plusieurs questions restent sans réponse
    • On ignore ce qui se passera lorsqu’ils tenteront d’installer ou de lancer l’app F-Droid
    • Il est incertain que les apps installées via F-Droid soient désactivées ou supprimées
    • On ne sait pas s’il sera encore possible de récupérer les données contenues dans une app dont ils dépendaient si celle-ci disparaît soudainement
    • On ignore quelles informations de télémétrie seront incluses lorsque toutes les installations et exécutions de logiciels seront signalées pour vérification par Google
  • F-Droid indique avoir envoyé des demandes à ce sujet, et promet de fournir des informations et une assistance supplémentaires aux utilisateurs concernés dans les semaines et les mois précédant l’entrée en vigueur du verrouillage

2 commentaires

 
ndrgrd 5 시간 전

En réalité, dire que ce n’est pas grave parce qu’il existe des OS alternatifs n’a pas vraiment de sens… Rien que pour installer un autre OS sur un Galaxy, il faut désactiver la puce de sécurité matérielle, et dans ce cas on ne pourra probablement plus utiliser Samsung Pay, les applis bancaires, etc.

 
Avis de Hacker News
  • Cela ne résout pas le problème actuel, mais si cette tendance ne peut pas être stoppée, il est bon de savoir qu’il existe plusieurs véritables OS Linux pour mobile
    SailfishOS est basé sur Linux et sa communauté semble assez accueillante, mais sa pile UI est propriétaire. C’est le seul à pouvoir exécuter officiellement des apps Android par émulation ; il existe depuis longtemps, est léger et semble être le plus stable et le moins bogué de cette liste
    Ubuntu Touch est entièrement open source et porté par la communauté ; il utilise des paquets snap pour la sécurité et peut aussi éventuellement exécuter des apps Android. La dernière fois que je l’ai essayé, il était déjà assez stable
    PureOS est entièrement open source et centré sur la protection de la vie privée. À ma connaissance, parmi ce qui a été lancé avec le Librem 5, c’est le seul à permettre d’éviter les blobs binaires propriétaires pour l’intégration matérielle. Il semble moins stable que SailfishOS ou Ubuntu Touch et, pour l’utiliser, il faut acheter un Librem 5, assez cher même d’occasion
    PostmarketOS est entièrement open source, met l’accent sur la légèreté et la remise en service d’anciens téléphones, prend en charge un très grand nombre d’appareils testés et est basé sur Alpine
    Mobian est la version mobile de Debian et, dans cette liste, c’est un projet relativement récent. Il existe d’autres OS Linux mobiles, mais à ma connaissance ce sont les principales options ; certaines ont été testées il y a longtemps, donc il peut y avoir des inexactitudes, et je n’ai jamais utilisé les deux dernières en conditions réelles

    • Ces OS ne sont pas compatibles avec la plupart des apps et services que les gens veulent utiliser, et la situation risque de s’aggraver. Les couches de compatibilité proposées par certains offrent une compatibilité très limitée, même au prix de la désactivation du modèle de sécurité Android et du sandboxing des apps
      Les apps qui tournent dessus sont moins, et non plus, isolées du noyau Linux. Si la vie privée et la sécurité comptent pour vous, ces OS sont nettement moins privés et nettement moins sûrs que l’Android Open Source Project. Ils n’ont ni sandbox d’applications complet et fonctionnel, ni modèle de permissions complet, ni mécanismes modernes d’atténuation des vulnérabilités, ni fonctions sérieuses de chiffrement matériel nécessaires pour empêcher l’extraction des données
      Contrairement à un OS basé sur AOSP sur du bon matériel, qui peut être une alternative à l’iPhone, ceux-ci ne sont pas des alternatives sérieuses du point de vue de la vie privée et de la sécurité. Cet avertissement est ajouté aux OS Google Mobile Services et n’a pas d’impact négatif sur les autres OS basés sur l’Android Open Source Project
      Linux ne signifie pas forcément GNU/Linux ou systemd/Linux, et n’implique pas l’utilisation de glibc, systemd, GNU coreutils, Bash, GNOME, etc. Les OS basés sur Android, y compris AOSP et GrapheneOS, sont aussi des distributions Linux. Alpine n’utilise pas glibc, et SailfishOS a aussi sa propre combinaison de logiciels ouverts et propriétaires. Le fait d’utiliser ou non la pile d’espace utilisateur typique de Linux de bureau ne détermine pas si c’est Linux ; même sur desktop, les configurations d’usage ne sont pas uniformes
    • J’utilise un Librem 5 comme téléphone au quotidien. PureOS est activement développé et basé sur Debian ; les mises à jour mensuelles de développement sont publiées ici : https://puri.sm/posts/tag/advanced-readers/
      Personnellement, je n’utilise pas d’apps Android sur le Librem 5, mais Waydroid est présent dans les dépôts de PureOS. Waydroid est une approche basée sur des conteneurs qui démarre un système Android complet sur un système GNU/Linux classique utilisant un environnement de bureau basé sur Wayland
      PureOS propose aussi la convergence via Phosh. Ici, la convergence signifie utiliser les mêmes apps sur téléphone et sur grand écran, avec une interface graphique qui s’adapte à la taille d’écran disponible
      Phosh vise à fournir un environnement graphique robuste et simple, utilisable au quotidien sur des appareils mobiles exécutant un Linux mainline. Il a été lancé à l’origine par les développeurs de Purism pour le Librem 5, mais il est désormais utilisé sur divers appareils — smartphones, tablettes, convertibles — et a même été vu sur des ordinateurs portables
    • Côté utilisabilité, on n’atteint même pas Android et iOS, ni même leurs versions d’il y a 5 ans
      L’UI/UX coûte cher, et la plupart des projets libres et open source ont du mal à bien le faire sans investissements importants d’entreprises ou soutien de startups. Par exemple, les designers UX de Red Hat ont beaucoup contribué à GNOME, et il y a aussi des exemples de startups comme Zed, Element ou Bluesky
      Les projets qui n’ont pas ce type de soutien sont, du moins du point de vue de la génération Z, généralement difficiles à utiliser
    • Si l’on ne peut pas utiliser les apps bancaires indispensables ou les apps d’identité gouvernementales, tout cela devient inutile
    • La sécurité est catastrophique. La seule alternative acceptable à Android grand public est GrapheneOS
  • Les utilisateurs d’Android devraient passer à Graphene
    Quelqu’un devrait créer une fondation pour un OS mobile basé sur Linux. La domination de Google va aussi à l’encontre des intérêts de nombreuses grandes entreprises, et en approchant des sociétés comme Meta, elles pourraient donner beaucoup d’argent pour des raisons d’intérêts stratégiques.

    • GrapheneOS est aujourd’hui dans une position d’enfant béni. Comme CyanogenMod autrefois, son accès à Google Play Services est autorisé parce que le travail de durcissement d’Android profite actuellement à Google.
      Quand Google estimera avoir obtenu une stabilité et une compatibilité suffisantes avec son allocateur mémoire renforcé et la mémoire taguée, et qu’il pourra obliger Qualcomm à les prendre en charge sur toute sa gamme, il rendra Graphene de plus en plus difficile à maintenir, puis finira par le rendre impossible.
      C’est un vieil article, mais d’après [1], Android de Google et les membres de l’Open Handset Alliance sont contractuellement interdits de fabriquer des appareils non approuvés par Google.
      Pour rivaliser, il faudrait aussi créer des Google Play Services compatibles et trouver des fabricants prêts à les prendre en charge. Samsung a exploité pendant un temps ses propres apps et son propre store [2] avec Tizen, peut-être pour gagner du poids dans les négociations ou en vue d’une transition théorique. Mais l’entreprise a ensuite abandonné cet effort.
      [1] https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on...
      [2] https://arstechnica.com/tech-policy/2021/07/google-bought-of...
    • GrapheneOS ne prend-il pas actuellement en charge uniquement les smartphones Google Pixel ? Pour la plupart des utilisateurs, cela signifie qu’il faut d’abord changer de téléphone.
      Beaucoup d’utilisateurs ordinaires, surtout hors des États-Unis, ne peuvent pas se le permettre. En plus, acheter un téléphone Google revient à nourrir Google, ce que je préfère personnellement éviter.
    • AOSP est un OS mobile basé sur Linux. Il fonctionne aussi très bien sur un noyau Linux standard sans modifications en aval.
      Supprimer le besoin de pilotes propriétaires en espace utilisateur pour des composants comme les GPU Mali récents est possible avec AOSP, et c’est ce qui profiterait au plus grand nombre. Si de nombreuses entreprises et autres acteurs unissaient leurs forces, ce serait possible dans AOSP.
      Cela pourrait aussi se produire via une intervention publique en raison des violations du droit de la concurrence par Google, mais si c’est mal fait, cela pourrait être traité d’une manière nuisible à l’open source.
    • J’ai essayé, mais je n’ai pas pu accéder à des services essentiels comme ma banque ou des ressources de l’État.
    • Je continue d’espérer quelque chose de plus radical, comme une percée de Jolla et SailfishOS, ou que postmarketOS devienne une vraie alternative, mais au vu de la tendance actuelle, il me semble plus probable que d’ici dix ans les lunettes connectées remplacent les téléphones et qu’on abandonne complètement ceux-ci.
  • Je comprends la frustration. J’utilise aussi intensivement fdroid sur plusieurs appareils. Mais cet article paraît puéril à cause de formulations comme virus, cheval de Troie et « éditeurs de logiciels malveillants ».
    Ce genre de texte donne à beaucoup de gens, peut-être même à Google, une raison d’écarter ce que dit fdroid comme des « accusations puériles qu’il n’est pas nécessaire de prendre au sérieux ». Par exemple, un média réputé ne publierait pas ce texte.
    À ce propos, https://keepandroidopen.org/ est un exemple mieux réalisé.

    • Au début, je pensais la même chose, mais en réalité il y a du vrai. L’objectif affiché ne couvre qu’une infime partie des fonctionnalités. Le contrat renvoie aux conditions d’utilisation, et quand je les ai consultées pour la dernière fois, elles indiquaient que le service pouvait être résilié à tout moment sans justification.
      Rien ne garantit que ce ne sera pas utilisé à des fins autres que la sécurité. Et il est aussi vrai que cela n’apporte pas grand-chose à la sécurité en pratique.
      Si l’on demande à Google Search, l’IA explique qu’un malware est un logiciel conçu pour un accès non autorisé, la perturbation, l’extorsion d’argent ou la prise de contrôle d’un appareil. Si vous pensez malgré tout que le terme ne convient pas, imaginez que quelqu’un crée une app dotée de la même fonctionnalité. Google la supprimerait immédiatement en la qualifiant de malware. Il la considérerait comme un malware évident.
    • Le point central semble être que Google se réserve dans ses conditions le droit de définir lui-même ce qu’est un malware. L’idée est donc de montrer les risques qui apparaissent quand Google peut arbitrairement qualifier quelque chose de malware.
    • L’article présente suffisamment d’éléments pour justifier cette étiquette. À l’inverse, Google peut arbitrairement qualifier n’importe quoi de malware. Le texte semble vouloir mettre en évidence ce contraste.
    • Je vois les choses exactement à l’inverse. Google fait toutes sortes de saloperies au nom de la « sécurité » ; il est donc temps de jouer selon ses propres règles et de signaler le contrôle de Google sur Android comme une faille de sécurité.
  • La raison pour laquelle j’utilise Android, c’est que je peux installer ce que je veux sur mon téléphone, et cela ne devrait pas être sujet à controverse. Mon téléphone m’appartient, ou il ne m’appartient pas. Je ne veux pas de la protection de Google. Surtout si je ne peux pas la refuser.

    • Il est possible d’exécuter Android sans Google. Le problème, c’est que des services de sécurité indispensables exigent un appareil Apple ou Google, et qu’en tant que membre de la société, il faut utiliser ces services de sécurité.
  • En informatique, un cheval de Troie est un type de malware qui se fait passer pour un programme normal afin de tromper l’utilisateur sur ses véritables intentions [1]
    Google est un cheval de Troie jusque dans ses moindres détails. Quelle est la véritable intention de presque tous les produits Google ? La récolte de données.
    Tous ses produits sont, sous une forme ou une autre, des spywares. L’entreprise subventionne les fabricants pour qu’ils intègrent ses spywares, et elle a même transformé les téléviseurs en chevaux de Troie.
    [1] https://en.wikipedia.org/wiki/Trojan_horse_(computing)

  • Pour donner quelques ordres de grandeur, le sideloading n’est utilisé que par moins de 1 à 2 % des utilisateurs Android dans le monde, soit au maximum autour de 50 millions de personnes. Google a en quelque sorte laissé la porte ouverte avec seulement un délai de 24 heures, donc c’est plutôt un geste de bonne volonté. Ça aurait pu être pire, mais pour l’instant ce n’est pas grand-chose dans le loisir éternel qui consiste à bidouiller les options développeur. Personnellement, je suis reconnaissant envers Google
    GMS apporte une commodité énorme aux développeurs d’apps qui ont besoin d’un contrôle fort, y compris les gouvernements. Cela permet de protéger une app contre des utilisateurs de tous bords. Si l’on ajoute à cela la possibilité de portes dérobées cachées facilitant la surveillance, ainsi que le lobbying direct de Google dans l’UE, il est très difficile de se passer de GMS même si l’UE actuelle prend une orientation anti-américaine, et ce sera la toute dernière chose à être remplacée en Europe
    Il existe plusieurs degrés de « dégooglisation ». Le spectre va de l’installation d’un OS entièrement ouvert, avec ou sans microG, jusqu’au simple fait de ne pas se connecter à un compte Google sur Android de base. Mais les personnes à l’extrémité libre de ce spectre n’auront jamais les mêmes droits que celles qui se trouvent à l’extrémité carcérale
    La certification des développeurs n’a pas pour but d’empêcher le blocage des publicités. Il existe une méthode simple et gratuite pour bloquer ce que l’on veut au niveau DNS. Il suffit de choisir Private DNS et d’y mettre une URL adaptée, par exemple chez controld.com, pour bloquer pubs, traqueurs et porno. Il faudra trouver un autre prétexte. Par exemple un contrôle fort des utilisateurs pour continuer à coucher avec les gouvernements, ou l’arrivée prochaine de la vérification d’identité des enfants qui mènera à la surveillance ultime des utilisateurs

    • Il est vraiment stupéfiant de voir le chemin parcouru : de l’époque où IBM voulait verrouiller le PC jusqu’au vrai matériel ouvert, pour en arriver maintenant à remercier Google de ne limiter « que la plupart » des choses que l’on peut faire avec un appareil que l’on a acheté et que l’on possède
      Tout le reste n’est qu’une autre forme d’apologie de Google. Honnêtement, c’est profondément décourageant, d’autant plus de voir ce genre de réaction sur « Hacker » News
  • La vérification de l’origine est une arme puissante pour lutter contre les logiciels malveillants, mais préserver la capacité d’installer et d’exécuter des logiciels anonymes est indispensable pour résister aux régimes autoritaires et aux systèmes corrompus
    Si l’on accepte que seuls des logiciels signés et autorisés puissent être installés et exécutés sur le téléphone des utilisateurs, alors la démocratie et la liberté sont mortes. Que ce soit en Occident ou en Orient, ou face à des suzerains IA, c’est la même chose

  • Nous ne pouvons pas modifier arbitrairement une grande partie du matériel et des logiciels dont nous dépendons. Nous ne pouvons pas en examiner la conception, ni la reproduire, ni parfois même la réparer
    Parfois, nous ne pouvons même pas savoir s’ils ont été conçus contre nos intérêts, et même si nous le savons, nous ne pouvons rien y faire. On nous force à choisir entre prix et protection de la vie privée, entre interopérabilité avec des systèmes propriétaires ou officiels et liberté
    Qu’Android fasse un pas de plus dans cette direction est une mauvaise chose. Mais ne nous racontons pas d’histoires. Nous baignons jusqu’au cou depuis des décennies dans un servage cyberpunk. Même si nous gagnons cette bataille autour d’Android, ce ne sera qu’une petite victoire
    Je ne dis pas cela par défaitisme, mais pour ne pas oublier le combat plus vaste. Comment ce Goliath féodal prendra-t-il fin ? Quand dira-t-on que trop, c’est trop ?

  • Pendant ce temps, au Luxembourg, Google a perdu son recours contre l’amende Android de 4,7 milliards de dollars infligée par l’UE
    https://www.msn.com/en-us/money/other/google-loses-fight-aga...

  • Je reste un peu perplexe quant au fait que l’UE ne prenne pas de mesures sur ce dossier. C’est clairement un abus de pouvoir d’un acteur monopolistique, et cela devrait être bloqué dès le départ

    • Elle l’a déjà fait. L’UE autorise officiellement ce type de mesures de Google au nom de la « sécurité », comme l’explique le quatrième paragraphe de l’article 6, paragraphe 4, du Digital Markets Act
      https://www.eu-digital-markets-act.com/Digital_Markets_Act_A...
    • Exact. Je me demande aussi si cela ne contrevient pas au droit du travail. Les listes noires sont illégales, et les listes blanches, c’est-à-dire les certifications, sont généralement confiées à plusieurs organismes certificateurs tiers concurrents
    • Si l’UE voulait agir, elle aurait probablement dû commencer par Apple, encore plus verrouillé et doté d’un pouvoir de marché comparable. Les fans d’Apple s’agitent déjà chaque fois qu’une loi accroît la compatibilité, dès qu’Apple explique dans son marketing à quel point ce serait horrible
      Pendant des décennies, nous avons accepté que les fournisseurs d’OS puissent faire ce genre de choses. Je pense que c’était une erreur : dépendre de Google comme seul fournisseur possible. On ne peut pas écrire une loi pour punir Google au motif qu’il a été ouvert jusque-là
      Bien sûr, comme d’autres hackers de HN, je suis favorable à ce qu’Apple soit aussi forcé de s’ouvrir, mais les pouvoirs qui dirigent actuellement l’UE et une grande partie des électeurs semblent assez favorables à l’attestation DRM à distance pour leurs projets d’identité numérique, qui seront bientôt nécessaires pour tout ce qui n’est pas adapté aux tout-petits et inaccessible via le dark web
    • L’UE aimera ce genre de choses. Cela fait partie de la tendance à la « transparence » qui consiste à s’exposer à tout le monde
      Les utilisateurs de HN, surtout les Américains, ont la naïveté de voir l’UE comme un bastion de liberté. Pas du tout. L’UE veut simplement devenir un immense État nounou, et c’est juste une manière plausible de permettre n’importe quoi, pourvu que ce soit approuvé