GuiGui's Show

Que c'est beau le patriotisme forcené et forcé. Ça va résoudre les problèmes de cohésion sociale, c'est sûr. Ils ne savent vraiment plus quoi inventer... Après, le but premier de tout système, c'est de se maintenir donc de rappeler sans cesse son existence et sa nécessité à ceux/celles qui vont le légitimer par ce biais. Bon en même temps, quand tu vois Lefebvre et Ciotti dans la liste des co-auteur-e-s, tout est dit...

« II. – La charge pour l’État est compensée à due concurrence par la création d’une taxe additionnelle aux droits mentionnés aux articles 575 et 575 A du code général des impôts. »

Via https://twitter.com/agnes_europe/status/675351622164324353

« rfkill is a small userspace tool to query the state of the rfkill switches, buttons and subsystem interfaces. Some devices come with a hard switch that lets you kill different types of RF radios: 802.11 / Bluetooth / NFC / UWB / WAN / WIMAX / FM. Some times these buttons may kill more than one RF type. »

Ça fonctionne aussi avec les soft kill comme quand on désactive le WiFi avec network-manager : toutes les interfaces sont éteintes... et si on veut éteindre la puce WiFi interne et utiliser le dongle USB en ligne de commande ou autre ? « rfkill list » pour récupérer l'ID de la puce, « rfkill unblock <id> » pour débloquer le dongle. \o/

Vu que j'étais plutôt perdu pour faire un bilan de la consultation publique sur l'avant-projet de loi numérique de Lemaire entre ma participation, l'avis de la presse, les réponses du gouvernement et vu que la presse apporte des éclairages différents et partiels, j'ai décidé de me pencher plus en détail sur ce que contient (ou non) le projet de loi actuel. J'ai essayé de faire ça de manière synthétique mais c'est loin d'être facile.


Ce qui est passé (pas forcément en provenance ni en faveur des citoyen-ne-s, hein ;) ) :

Mesures sans importance àmha :

    * La CADA peut saisir la justice + hall of shame, sur son site web, des administrations qui ne respectent pas un de ses avis.

    * Transparence sur les algorithmes publics. « Dès lors qu’une décision individuelle fera « intervenir un traitement algorithmique », l’administration devra communiquer – sur demande – au citoyen visé « les règles définissant ce traitement, ainsi que les principales caractéristiques de sa mise en œuvre ». Sauf que :
        * La communication est personnelle suite à une requête.
        * Lemaire a déjà indiqué qu'il y aura des exceptions liées à la sécurité publique,...
        * Il faudra aussi voir si l'on sortira un code source, un algorithme incompréhensible ou une analyse du fonctionnement. Et à mon avis, il faudra aussi voir ce que mange l'algorithme, les données de travail qu'on y entre, surtout sur les algos prédictifs.

    * Uniformisation dans les licences de réutilisation des données publiques. Idée : réduire l'incertitude juridique (exemple : à part la GPL et les CC, aucune autre licence n'a été validée à ce jour par un tribunal français donc niveau jurisprudence, on est à poil). Sauf qu'une administration peut très bien faire homologuer une licence de son choix par l'État et l'utiliser...

    * Premier pas vers un rapprochement CNIL-CADA.

    * Loyauté des plateformes, et notamment des moteurs de recherche c'est-à-dire : fournir des infos sur comment marchent leurs algos de classement, référencement, déréférencement. L'idée est, par exemple, de voir si Google favorise ses services ou d'autres dans les résultats, par exemple... Ou voir les liens capitalistes entre des sociétés (Orange<->Dailymotion, Youtube<->Google). Ça va aboutir à un statut des plaforme additionnelle à celui applicable aux hébergeurs depuis la LCEN. Tout (des seuils à remplir pour être assujettis à des obligations supplémentaire aux sanctions en passant par le pouvoir d'enquête) est entre les mains du gouvernement.

    * Le pouvoir de sanction de la CNIL légèrement revu. Seuil « extrême urgence » pour laisser un organisme patcher une fuite de données persos en 24h. Mêmes sanctions. Nouvelle arme : ordonner à un contrevenant à la loi informatique et libertés de prévenir chaque personne lésée individuellement.

    * Droit à l’oubli pour les mineurs. Les nombreuses exceptions prévues dans la première version du texte sont maintenues, puisque ce droit ne pourra être activé lorsque le traitement des données litigieuses se révèle nécessaire « pour exercer le droit à la liberté d’expression et d’information », pour la constatation, l'exercice ou la défense de droits en justice, pour des « motifs d’intérêt public dans le domaine de la santé publique », etc. Les prestas auront 1 mois pour répondre.

    * Transparence sur les avis d’internautes pour éviter les faux avis. Informer des mécanismes de vérification des commentaires s'ils existent.

    * Information sur les débits pour l’internet fixe et mobile. Juste bien rien de neuf

    * Dons par SMS. Les opérations de paiement destinées à « la collecte de dons, par les organismes sans but lucratif », seront autorisées. Leur montant ne pourra excéder 50 euros par don, ni un total de 300 euros par mois, et sera imputé sur la facture dressée par l’opérateur.


Mesures importantes àmha :

    * Extension des missions de la CNIL : + promouvoir le chiffrement + elle sera tenue d'accompagner les déploiements de STAD au lieu de juste conseiller comme aujourd'hui + réfléchir aux problèmes éthiques futurs (intelligence articielle, implants NFC).


À voir l'intérêt ou l'application :

    * Open Data : « L'État, les collectivités territoriales et les personnes chargées d’une mission de service public (SNCF, IGN, Cité de la musique...) seront tenus de mettre automatiquement en ligne, « dans un standard ouvert aisément réutilisable », l’ensemble des documents administratifs qu’ils doivent aujourd’hui communiquer sur demande du citoyen en application de la loi CADA... ». C'est aussi valable pour les données produites grâce à des subventions et pour les DPS/régies. Mais de nombreuses exceptions :
        * Ça concerne uniquement ce qui existe déjà au format numérique ;
        * Ça concerne uniquement les administrations qui dépassent un nombre d'agents/salariés défini par décret, les données subventionnées avec plus de 23000€ et les DSP/régies dont les délégataires ne se seront pas opposés, de manière motivée et publiquement.
Pour contrebalancer ça, une proposition citoyenne de sanctions à l'encontre des administrations réticentes a été plus ou moins acceptée par le gouvernement...


    * Principe de « libre disposition de ses données à caractère personnel ». Le gouvernement affirme que les fameuses conditions générales d’utilisation de sites qui affirment détenir un droit de propriété sur les données mises en ligne par leurs utilisateurs pourront ainsi « être annulées ».

    * « Droit de « mort numérique ». Chaque internaute pourra laisser des directives concernant le devenir de ses données personnelles, en cas de décès. » Reste à voir comment cela va s'appliquer en vrai, vérification de l'identité de l'héritier, désacords familiaux & solitude, chiffrement,... Le Conseil supérieur du notariat a fait des propositions durant la consultation : tiers de confiance impartial, confidentialité,... Tout cela sera fixé... par décret. Je sens que les notaires vont encore se retrouver en situation de monopole...

    * « Reconnaissance de l’e-sport. Comme l’avaient souhaité un très grand nombre d’internautes, le gouvernement semble s’être résolu à reconnaître officiellement les compétitions de jeux vidéo. ». L'exécutif veut vérifier que ça n'est pas assimilable à des jeux d'argent avant de reconnaître définitivement ce principe. On notera que les citoyen-ne-s n'avaient rien de plus sérieux à proposer... :(

    * « De la traduction via Internet pour les sourds et malentendants + Accessibilité des sites et applications mobiles « publics » aux personnes handicapées.. D’ici cinq ans, les standards téléphoniques des personnes chargées d’une mission de service public (SNCF, Sécurité sociale, mairies...) devront être accessibles aux personnes déficientes auditives « par la mise à disposition d’un service de traduction écrite simultanée et visuelle ». Une obligation identique reposera sur les associations reconnues d’utilité publique – Croix-Rouge, ADMR, Restos du cœur... – dont le « montant annuel de ressources » sera supérieur à un seuil défini ultérieurement par décret.D’ici deux ans, les professionnels de la vente (dont le chiffre d’affaires sera lui aussi supérieur à un seuil défini par décret) devront proposer, dans le cadre de leur SAV, un service de traduction accessible depuis Internet. » Quand on regarde la non-application des lois précédentes au sujet du handicap et notamment celles ayant trait à l'accessibilité numérique des administrations, on doute que celle-ci le soit...

    * « Reconnaissance du recommandé électronique. De la même manière que dans sa version précédente, le projet de loi Lemaire reconnaît expressément que « la lettre recommandée électronique bénéficie des mêmes effets juridiques que la lettre recommandée postale, papier ou hybride » ». Les conditions font que ça ne va pas être du mail mais une vieille page web pourrie avec javascript voire applets proprios avec plein de trackers partout...

    * Droit à l’auto-hébergement. Les opérateurs vont répondre qu'ils n'entravent déjà pas l'autohébergement : on peut créer des règles de DNAT sur sa box, prendre une option payante pour avoir une IP fixe... Il ne reste que le blocage du port 25 (mail) en sortie par certains...

    * Protection du secret des correspondances sauf consentement de l'utilisateur... Donc ne sert à rien... Sans compter sur le gouvernement n'a pas voulu intégrer les données de connexion dans le secret (et on le comprend : sinon adieu la loi Renseignement qui prévoit des dispositions d'interceptions plus massives et moins contrôlées quand il s'agit des données de connexion). Il y aura aussi des exceptions pour les services ajoutés dont le seul bénéficiaire est l'utilisateur (ce qui, d'après Lemaire, exclu la pub, qui profite avant tout au presta mais permet aussi de ne pas tuer l'innovation comme un agenda qui note vos rendez-vous mentionnés dans un mail...).




Ce qui n'est pas passé (pas forcément en provenance ni en défaveur des citoyen-ne-s, hein ;) ) :

Mesures sans importance àmha :

    * Dégager HADOPI. Mineur sur l'impact tant qu'on ne vire pas la loi Création qui l'a créée ainsi que le défaut de sécurisation par contre ça ferait des sous en plus dans les caisses de l'État puisque plus gaspillés par cette administration bullshit qui n'a jamais rempli ses obligations concernant l'interopérabilité (souvenir de "l'affaire" VLC) ni sur l'offre légale.


Mesures importantes àmha :

    * « Le maintien de l’accès Internet des foyers en difficulté financière, le temps de l’instruction d’une demande d’aide auprès d’un fond de solidarité universel, est confirmé. Cette disposition, qui irrite l’industrie des télécoms, a néanmoins été modifiée par les internautes. Les opérateurs pourront proposer un accès « restreint » centré sur les services publics en ligne et l’accès au courriel. » Je note l'esprit de solidarité des citoyen-ne-s participant-e-s...

    * « Meilleur accès aux travaux de recherche financés par des fonds publics. Les éditeurs ne pourront plus s’opposer à ce que des écrits scientifiques ayant été financés « au moins pour moitié par des fonds publics » soient mis gratuitement en ligne par leurs auteurs, à condition que ceux-ci ne donnent lieu à aucune exploitation commerciale. Contrairement à ce qui était prévu par la V1 du projet de loi Lemaire, le délai à respecter avant que ce droit ne s’ouvre est dorénavant fixé à 6 mois – contre 12 – pour les publications relatives aux sciences « dures » (médecine, techniques...), et à 12 mois – au lieu de 24 – pour les travaux de sciences humaines et sociales. » Ça a l'air bien comme ça mais en vrai, les éditeurs scientifiques ont gagné :
        * Les auteurs ne sont toujours pas libres de faire ce qu'ils veulent avec LEUR travail ;
        * Le public est toujours aussi lésé alors qu'il a financé ces travaux de recherche ;
        * Une contrepartie est prévue pour les pauvres éditeurs : un programme d'accompagnement. Comprendre qu'on va encore maintenir des rentes sous perfusion ;
        * J'appréhende ce que va donner l'appréciation de l'exploitation commerciale ou non quand l'auteur diffusera sur son site web avec de la pub, du flattr ou autre.

    * Inscription du principe de neutralité du Net. On est aussi faible qu'au niveau de l'EU donc la neutralité des réseaux sera contournée de partout par les opérateurs via des mécanismes d'exceptions comme les services gérés.

    * Garantir la portabilité des données entre services en ligne. Ne s'appliquera qu’aux sites « dont le nombre de comptes utilisateurs ayant fait l’objet d’une connexion au cours des douze derniers mois est inférieur à un seuil fixé par arrêté conjoint des ministres chargés de la consommation et du numérique ». Des exceptions sont déjà prévues comme les messages privés. Et c'est bien un cp, pas un mv d'un prestataire à un autre : les données restent chez l'ancien. On a donc un droit d'usage sur *NOS* données, toujours pas un droit de propriété !

    * « L’article 8 sur le « domaine commun informationnel », promu par Axelle Lemaire elle-même, a été supprimé sous la pression du Conseil supérieur de la propriété littéraire et artistique (CSPLA) et du Syndicat national de l’édition (SNE). Il visait pourtant à favoriser la libre circulation des oeuvres tombées dans le domaine public. »

    * « L'usage obligatoire des logiciels libres par les administrations a été également rejeté par le gouvernement. « Ce n’est pas du domaine législatif », a déclaré Axelle Lemaire ». On va continuer à faire « de la promotion » comme ça, ça permettra toujours de signer de juteux partenariats avec MS ! Même chose pour la vente liée qui ne sera toujours pas explicitement interdite car la CJEU travaille dessus en ce moment.

    * Pas d'obligation du chiffrement : « Dans sa réponse, le gouvernement partage « l’objectif de développement de l’usage des techniques du chiffrement », cependant de son chapeau, il préfère amplement sortir la charte signée en octobre sous l’égide de l’ANSSI, avec cinq FAI (Bouygues Telecom, Free, La Poste, Numericable-SFR et Orange). Elle vise en effet à « activer les fonctions de chiffrement sur leurs serveurs de messagerie de manière à protéger les courriels véhiculés entre ces serveurs ». Elle n’intéresse donc que le seul chiffrement des flux, assurant toutefois des passages en clair chez ces intermédiaires afin de faciliter les interceptions de sécurité. Bref, nul besoin d'aller plus loin car « il convient d’attendre les premiers retours d’expérience sur cette initiative avant d’envisager un renforcement de ces mesures par voie législative, qui apparait prématuré. ». Pas de suppression de l'aggravation des peines lorsqu'il y a eu utilisation de la crypto (j'étais plutôt défavorable à cette proposition de LQDN mais en fait, il est difficile de savoir si la crypto a été utilisé pour cacher les preuves et faire obstruction ou si c'est un usage normal dans lequel se cache des actions répréhensibles).

    * Remettre le juge judiciaire dans la boucle dans la loi Renseignement.

    * Meilleure protection des données personnelles : l'UE bosse dessus donc on s'interdit d'avoir des idées et de faire des propositions constructives au niveau européen.

    * Loyauté des fournisseurs de cloud (informations sur la sécurité des données,...).

    * Régime d'exception de renoncement aux droits d'auteur (comme la CC0 mais inscrite dans la loi, pas besoin de démontrer devant un tribunal que la CC0 est bien applicable en France).

    * Action de groupe autorisée pour les atteintes à la neutralité des réseaux ou au traitement des données personnelles.

    * Droit de panorama (« diffuser librement toute photo ou vidéo de ce qui est visible depuis l’espace public ») ce qui va encore bien emmerder les contributeurs Wikipedia & co pour trouver des photos d'illustration.




Autres : d'autres propositions de citoyen-ne-s et organisations n'ont pas obtenues assez de suffrages positifs pour être considérées (et c'est parfois à raison àmha) comme la création d'atelier citoyens, encore et toujours l'apprentissage exclusif de la programmation à l'école, la promotion du numérique dans les bibliothèques publiques, l'identité numérique, NIR statistique, une obligation de résultat sur la sécurité de conservation des données personnelles,...).




Bilan :
« Comme le dit l’adage, « beaucoup d’appelés, peu d’élus ». De fait, quand on se repenche sur les idées soulevées lors de la consultation, la plupart sont aujourd’hui absentes du texte gouvernemental : ouverture du code source des logiciels développés par l’État, actions de groupe pour les litiges « numériques », liberté de panorama, priorité à accorder aux logiciels libres, création d’un registre gouvernemental de lobbyistes, maintien des cabines téléphoniques... On retiendra aussi qu’un article ayant obtenu un soutien appuyé, celui relatif à la définition positive d’un « domaine commun informationnel », a malgré tout été retiré – comme le souhaitaient certains ayants droit.

Même si l’exécutif se plait à souligner l'ajout d'une dizaine d’articles suite à cette opération, on constate d’abord qu’il a régulièrement édulcoré les mesures proposées par les participants, sur la transparence des algorithmes publics ou sur l’homogénéisation des licences de réutilisation des données publiques par exemple. »

Pour moi, cette consultation est un échec : les seules mesures dont on puisse être sûr quelles puissent être adoptées en l'état (sans se faire massacrer par un décret ou des conditions de déclenchement restrictives débiles) sont des mesures sans importance ni impact et proviennent minoritairement des citoyen-ne-s. A contrario, les mesures les plus recalées sont celles qui apporteront de vrais changements, qui traitent de problèmes de fond et qui ont été déposées par le Peuple... On ajoute à cela le fait que les réponses du gouvernement sont faibles dans l'argumentation (soit il se repose sur l'UE, soit il souhaite vérifier tel ou tel point, soit la réponse n'a aucun argument de fond qu'il soit d'ordre juridique ou moral).




Sources :
    * http://www.silicon.fr/loi-republique-numerique-lemaire-gouvernement-130940.html
    * http://rue89.nouvelobs.com/2015/11/06/axelle-lemaire-loi-numerique-naurais-pu-faire-loi-droite-261997
    * http://www.numerama.com/politique/133686-la-loi-numerique-ou-quand-le-gouvernement-repond-a-obi-wan-kenobi.html
    * http://www.nextinpact.com/news/97589-le-gouvernement-ne-veut-pas-imposer-chiffrement-bout-en-bout-dans-loi-lemaire.htm
    * http://www.nextinpact.com/news/97227-projet-loi-numerique-on-fait-point.htm

« Sur la consultation elle-même, Axelle Lemaire dit avoir eu des « sueurs froides » mais que, finalement, bah ça s’est plutôt bien passé. Les « internautes », une fois n’est pas coutume, ont été sages comme des images. Un de ces quatre il faudra que quelqu’un m’éclaire sur la différence entre un « internaute » et une personne, parce que j’avoue que ça m’échappe, bref. Elle nous explique que, sur les 8500 contributions, seuls « six commentaires » ont été placés dans la « corbeille », ce qui laisse entendre que l’on a tenu compte de toutes les autres. Si l’on considère que toutes les contributions non retenues – bonnes ou mauvaises – sont dans les faits poubellisées, ce sont donc près de sept cent articles et mille quatre cent propositions qu’il conviendrait de comptabiliser, pas six. Pour être vraiment honnête, il faudrait également tenir compte des milliers de contributions de la consultation organisée par le CNNum et de ses soixante-dix recommandations dont on ne retrouve que peu de traces dans le projet de loi. De la com’, c’est de bonne guerre, ok.

La ministre nous apprend ensuite que le prince Manuel, bah il est un tout petit peu à fond sur le concept. Bon, peut-être pas sur tous les « textes » législatifs, faut pas exagérer non plus. Tu m’étonnes. Tu fais travailler la foule gratos, tu ne retiens que ce qui t’arrange et, au passage, tu fais une opération de communication en faisant croire que c’était vraiment ultra-démocratique. Tout bénef.

Après la méthode, la ministre embraye sur les participants. Au niveau démagogie ça se pose là. Les « geeks et les spécialistes du droit numérique », on s’en fout. Ce n’est pas comme si c’était une loi sur le numérique et qu’on pouvait légitimement supposer que ceux-là savaient un brin de quoi ils parlaient, après tout. Ce n’est pas non plus comme si il existait une diversité d’opinion chez ces gens là, hein ? Et puis, de toute façon, ils sembleraient qu’ils aient participé majoritairement de manière « anonyme », preuve s’il en est de leur mauvaise foi. Les chercheurs, eux, avait un avis qui comptait. Malheureusement, ils n’ont pas l’habitude « d’être en interaction avec des responsables publics ». Comprenne qui pourra. Le contributeur idéal fût donc, par opposition, le citoyen tout court. Celui qui n’a pas trop de connaissances ou de compétences sur la consultation idoine, celui pour qui les questions abordées sont nouvelles. En clair, celui qui ne va probablement pas trop emmerder le monde, c’est tellement plus pratique.

[ NDLR : gros +1, je partage totalement ces sentiments. ]

Les lobbies ? Oui, il y en avait, bien sûr ! Et oulala, ils étaient « ultra-réticents », particulièrement ceux de la culture. Suprise-surprise. Mais ne vous inquiétez pas, le gouvernement a tenu bon. Enfin, suite à une réunion à Matignon, il a quand même vaporisé feu l’article 8, relatif aux communs. Et hop, l’acrobatique Axelle Lemaire nous déclare que c’est parce qu’il faut du temps, pour expliquer aux lobbies que la notion de communs « n’empiète pas sur le code de la propriété intellectuelle ». [...]

Autre sujet brièvement abordé, le libre accès aux publications scientifiques et, par réciproque, la possibilité pour les chercheurs de publier plus librement leur travaux. Là, notre ministre n’y va pas par quatre chemins : « c’est une victoire ».

C’est drôle, parce que si l’on y prête un peu d’attention, on a le sentiment que le résultat est beaucoup plus mitigé, et que le lobbies ont au contraire négocié des contreparties à la réduction des délais d’embargo sur les publications. Lesquels embargos sont maintenus, contrairement à ce que souhaitaient les chercheurs (et ceux qui les lisent, merci les copains).

[...]

Concernant le logiciel libre dans l’administration, la ministre nous précise qu’il est difficile d’en imposer l’utilisation, ou même d’élaborer un système de quotas. L’utilisateur a ses petites habitudes dans le logiciel propriétaire, l’argument peut s’entendre. Faudrait pas le brusquer. « Le choix qui a été fait », nous dit Axelle Lemaire, est donc tout naturellement « celui de la promotion ». Il vaut mieux un bon non-choix que rien du tout, me direz-vous. Oui.

[...]

Surtout, c’est envisager le logiciel libre sous le seul angle de l’utilisation, de la consommation. Au contraire, l’État pourrait ou devrait soutenir son développement. Caramba, encore raté.

[...]

Neutralité pas nette

La Quadrature du Net, qui maîtrise son sujet, a proposé un amendement visant à les définir plus finement, et à éviter que le principe de neutralité ne soit vidé de sa substance, que l’exception ne remplace la règle. [...] La proposition est limpide : la première partie (jusqu’à « une combinaison de ceux-ci ») vise à définir les services spécialisés, la seconde à en fixer les limites pour éviter les abus. C’est donc cette seconde partie qui garantit le principe de neutralité. L’amendement a été retenu par le cabinet de la ministre, mais dans la version du projet de loi, le second morceau s’est envolé[...] »

Alors-même que la loi d'Axelle Lemaire sur le volet « libertés numériques » n'a toujours pas été officiellement transmise au Parlement, Emmanuel Macron présentera dès cette fin d'année les grandes lignes de la loi sur l'économie numérique qu'il présentera en Conseil des ministres en janvier 2016.

[...]

Entouré par des intervenants venus prêcher la bonne parole, le ministre de l’économie a surtout profité de l’occasion pour poser les bases idéologiques de sa future loi Macron 2, qui sera la véritable loi sur le numérique du gouvernement.

Plus que jamais, celle d’Axelle Lemaire paraît aujourd’hui reléguée au rang de petit gadget destiné à attirer quelques sympathies avec son processus innovant de consultation publique qu’Emmanuel Macron ne paraît pas du tout prêt à imiter pour « sa » loi numérique, perçue comme beaucoup plus sérieuse.

[...]

Sur le fond, le texte du ministre socialiste sera conçu pour encourager l’auto-entrepreneuriat et libérer le financement des start-ups, pour injecter plus de flexibilité dans l’économie, et plus de réactivité face aux révolutions technologiques. »


« C'était déjà pressenti, c'est désormais certain. Le projet de loi sur le numérique qu'Axelle Lemaire dévoilera dans les prochains jours sera cantonné principalement aux questions de régulation des contenus, de protection de la vie privée et d'ouverture des données publiques, tandis que le volet économique de la régulation du numérique sera laissé à un autre texte, porté par Emmanuel Macron. "C'est ce scénario en deux temps qui a finalement été confirmé mercredi soir par Matignon au Figaro", indique le quotidien. » (http://www.numerama.com/magazine/33697-il-y-aura-deux-lois-pour-le-numerique-la-loi-lemaire-et-la-loi-macron-2.html)

Avec l'arrivée du support de TLS v1.2 dans OpenVPN >= 2.3.3, je me suis demandé si l'on pouvait changer les algos cryptos et la version de TLS utilisés sans pour autant dégager les vieux clients utilisateurs de notre VPN.

Commençons par le canal de contrôle, c'est-à-dire le canal primaire de communication entre un serveur et un client OpenVPN sur lequel sont échangées, entre autres, les clés de chiffrement symétrique. Ce canal est protégé avec toute la crypto asymétrique, TLS et les certificats x509 que l'on connaît. Que peut-on changer ?
    * Si l'on utilise easy-rsa (toolkit d'OpenVPN pour simplifier la création/gestion/maintenance des clés/certificats), les clés générées sont des RSA 2048 bits (sous Debian). L'ANSSI, via son référentiel général de sécurité (RGS, voir http://www.ssi.gouv.fr/entreprise/reglementation/administration-electronique/liste-des-documents-constitutifs-du-rgs-v-2-0/ document B1) indique que 2048 bits est le minimum aujourd'hui pour des clés RSA et que 3072 bits sont recommandés. On remarquera les mêmes conseils du côté de la NSA (https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml ÉDIT DU 30/05/2016 À 14H50 : la page a été effacée début mai 2016… Une copie chez archive.org : https://web.archive.org/web/20160420221628/https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml FIN DE L'ÉDIT.). Pour changer cela, c'est la variable « KEY_SIZE » dans le fichier « vars » d'easy-rsa. Ça se fait sans douleur pour les anciens utilisateurs du VPN qui continueront à utiliser leur matériel cryptographique actuel jusqu'à son expiration. Les nouveaux utilisateurs auront directement une clé RSA 3072 ou 4096 bits.

    * On voudrait SHA-256 comme fonction de hachage cryptographique utilisée pour la signature des certificats de nos utilisateurs VPN car SHA-1, même s'elle n'est pas cassé ne répond plus aux attentes standards et n'est d'ailleurs pas conforme au RGS. De plus, c'est ce que l'on observe sur le marché des certificats x509 : Microsoft et Google ne veulent plus de certificats signés avec SHA-1 à partir de 2016-2017. Easy-rsa signe déjà les certificats avec SHA-256 donc il n'y a rien à faire. \o/

    * Oui mais si on augmente la taille des clés des utilisateurs, ne devrait-on pas aussi augmenter celui de l'AC ? En effet, pour que ce soit cohérent, il faut aussi faire ça. Il faut, là aussi, changer la variable « KEY_SIZE » dans le fichier « vars » d'easy-rsa MAIS cela se fera dans la douleur puisqu'il faudra re-générer le certif' d'AC et donc resigner (ou regénérer) tous les certificats (server, utilisateurs) et transmettre les nouveaux certificats aux utilisateurs.

    * Pour garantir la confidentialité persistante (perfect forward secrecy u know), il est important de ne pas avoir des paramètres de Diffie-Hellman moisis. Normalement, on génère des paramètres (voir http://shaarli.guiguishow.info/?hCgBYQ) et on utilise la directive « dh » dans la config' OpenVPN. Il est nécessaire de le faire, surtout depuis logjam (voir http://shaarli.guiguishow.info/?S2CJMg pour un rappel). C'est toujours la même chose : lorsqu'on parle de RSA, l'ANSSI recommande 3072 bits et la NSA indique 3072 bits minimum. On peut facilement changer cela pour 3072 ou 4096 sans impact sur les utilisateurs mais en demandant un temps de calcul plus long côté serveur lors de l'initialisation. Dans son log, le serveur indiquera « Diffie-Hellman initialized with 4096 bit key » au tout début de son initialisation.

    * On voudrait utiliser TLS v1.2 au lieu de TLS v1.0. TLS v1.0 a un certain nombre d'attaques possibles en jouant sur la compression, le padding, la faiblesse des suites cryptographiques en mode bloc (CBC), les attaques par repli,... Tout cela est corrigé dans TLS v1.2. De plus, TLS v1.2 apporte de nouvelles suites cryptographiques plus balèzes. TLS v1.2 est pris en charge à partir d'OpenVPN 2.3.3. L'ennui, c'est que la version de TLS qui sera utilisée n'est pas négociée comme dans les autres usages de TLS (web, mail,...) : il faut préciser « tls-version-min 1.2 » dans la conf' du serveur ET du client (merci à http://www.timdoug.com/log/2014/05/30/). Les clients dont la version est inférieure à 2.3.3 auront un reset de la connexion et les logs côté serveur indiqueront « TLS_ERROR: BIO read tls_read_plaintext error: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol ». La négociation de la version de TLS revient dans OpenVPN 2.3.7 (voir https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23). En attendant, j'estime qu'il n'est pas possible d'utiliser TLS v1.2 sans perdre des utilisateurs.

    * On voudrait être sûr de ne pas utiliser des suites cryptographiques trouées. Par défaut, OpenVPN utilise cette liste quand il est utilisé avec OpenSSL : « DEFAULT:!EXP:!PSK:!SRP:!kRSA » (voir https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage, paramètre « --tls-cipher »). De cette liste, il convient de virer les suites moisies qui utilisent DSS comme méthode d'authentification ou DES/3DES/RC4 comme algos de chiffrement symétrique. Nous voulons activer la confidentialité persistante donc nous devons supprimer les suites cryptos qui ne reposent pas sur Diffie Hellman Ephémaire pour l'échange des clés. OpenVPN semble de pas utiliser les courbes elliptiques (voir le contenu pointé par ce shaarli). De plus, nous utilisons des clés RSA donc l'échange de Diffie-Hellman sera forcément de type RSA donc nous pouvons virer les suites cryptos qui utilisent ECDHE comme protocole d'échange de clés éphémères. Il reste donc 9 suites répondant à nos exigences que l'on peut lister comme suit : DEFAULT:!EXP:!PSK:!SRP:!kRSA:!DSS:!DES:!3DES!RC4!ECDH. En plus court : EDH+aRSA:!DES:!3DES . Si l'on n'a pas confiance, ou parce qu'AES est le seul accéléré matériellement de nos jours, on peut ne pas utiliser CAMELLIA et SEED comme algos de chiffrement symétrique et la liste de suites cryptos devient donc : « EDH+AES+aRSA ». Il nous reste donc 6 suites : DHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-SHA256 DHE-RSA-AES256-SHA DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES128-SHA256 et DHE-RSA-AES128-SHA. On ne peut pas virer les suites utilisant SHA-1 puisque les suites plus fortes arrivent uniquement avec TLS v1.2... qui n'est pas activable sans casse à l'heure actuelle, voir le point précédent ainsi que le contenu pointé par ce shaarli. Depuis que j'utilise OpenVPN depuis de nombreuses années, la suite cryptographique utilisée automatiquement a toujours été « DHE-RSA-AES256-SHA » qui, à part SHA-1, est clairement satisfaisante. Néanmoins, afin d'éviter tout problème, je précise désormais « tls-cipher EDH+AES+aRSA » dans mes confs client et serveur. Cette fois-ci, la liste est négociée de manière tout à fait standard donc on ne cassera très probablement aucun client qui arrivait à se connecter avant. Testé sous Debian GNU/Linux Wheezy et Android 4.2 avec OpenVPN for Android disponible sur F-Droid.


Résumons ce que nous pouvons, ou non, changer sur le canal de contrôle :
    * Utiliser des clés RSA >= 3072 bits comme le recommande le RGS : possible facilement sans impact sur les utilisateurs. On peut migrer doucement chaque utilisateur (ainsi que le serveur OpenVPN lui-même) lors de l'expiration de son certificat actuel. On peut fournir des clés >= 3072 bits aux nouveaux utilisateurs. Tout ça sans douleur.

    * Easy-rsa utilise déjà SHA-256 pour la signature des certificats donc nous n'avons rien à changer.

    * Utiliser des clés RSA >= 3072 bits comme le recommande le RGS pour l'AC : possible mais cela nécessite de casser tous les certificats de tous les utilisateurs actuels et donc de leur communiquer leur nouveau certificat.

    * Utiliser des paramètres de Diffie-Hellman >= 3072 bits comme le recommande le RGS : possible facilement sans impact sur les utilisateurs. Il suffit de générer de nouveaux paramètres.

    * Utiliser TLS v1.2 : pas possible à l'heure actuelle sans impacter les utilisateurs sauf à considérer qu'ils utiliseront tous une version >= 2.3.7 d'OpenVPN. Ce qui n'est pas le cas dans Debian Jessie, par exemple.

    * Être sûr de ne pas utiliser des suites cryptos trouées : possible facilement sans impact sur les utilisateurs. C'est déjà le cas par défaut mais pour être sûr qu'une mauvaise suite ne sera pas choisie, on peut toujours resteindre leur nombre.


Continuons avec le canal de données dans lequel circule le trafic à proprement parler. Ce canal est protégé par toute la crypto symétrique que l'on connaît. Que peut-on changer ?
    * L'algorithme de chiffrement symétrique utilisé. Même dans OpenVPN 2.3.X, c'est encore Blowfish qui est utilisé par défaut alors que son concepteur, Schneier (oui oui, c'bien lui) a déclaré, en 2007 (!) : « There weren't enough alternatives to DES out there. I wrote Blowfish as such an alternative, but I didn't even know if it would survive a year of cryptanalysis. Writing encryption algorithms is hard, and it's always amazing if one you write actually turns out to be secure. At this point, though, I'm amazed it's still being used. If people ask, I recommend Twofish instead. ». De plus, Blowfish utilise une taille de bloc de 64 bits alors que l'ANSSI préconise 128 bits minimum. Pour voir les algos disponibles, la commande est : openvpn --show-ciphers. Une fois qu'on vire les mauvais algos et ceux plus recommandés, il reste AES, CAMELLIA et SEED. Ma confiance va dans AES qui est plus utilisé (donc plus audité, scruté, attaqué, cryptanalysé, plusieurs implémentations,...). Pour changer d'algorithme, il faut utiliser la directive de configuration « cipher » (exemple : « cipher AES-128-CBC »). Cet ajout doit être fait sur le serveur ET le client car l'algo à utiliser n'est pas négocié entre les deux parties. C'est une contrainte forte : il faut poser un flag day et dire aux utilisateurs "à partir de tel jour, on utilisera ça et ça cassera votre VPN tant que vous ne ferez pas la modif' dans votre fichier de conf'". Ça ne dégage pas les vieux clients ni les clients multiplateformes : j'ai testé sur mon ordiphone (avec OpenVPN for Android disponible sur F-Droid sur un Android 4.2) et sur un Debian GNU/Linux Wheezy.

    * La fonction de condensation utilisée pour assurer l'intégrité des données transmises. Par défaut, SHA-1 est utilisée. Comme je l'ai écrit plus haut, même si elle n'est pas cassée, elle commence à être dépréciée un peu partout (l'ANSSI veut SHA256 minimum, la NSA veut du SHA384 minimum). Pour voir les algos disponibles, la commande est : openvpn --show-digests. Une fois qu'on a viré les algos troués (MD4/MD5/SHA) et les algos plus recommandés (SHA-1/RIPEMD160), il ne reste que la famille SHA-2 et whirlpool. Comme pour AES versus CAMELLIA/SEED, whirlpool étant moins utilisé, ma confiance va dans SHA-256. Pour changer de fonction de condensation, il faut utiliser la directive de configuration « auth » (exemple : « auth SHA256 »). Cet ajout doit être fait sur le serveur ET le client car l'algo à utiliser n'est pas négocié entre les deux parties. C'est une contrainte forte : il faut poser un flag day et dire aux utilisateurs "à partir de tel jour, on utilisera ça et ça cassera votre VPN tant que vous ne ferez pas la modif' dans votre fichier de conf'". Ça ne dégage pas les vieux clients ni les clients multiplateformes : j'ai testé sur mon ordiphone (avec OpenVPN for Android disponible sur F-Droid) et sur un Debian GNU/Linux Wheezy.

Résumons ce que vous pouvons ou non changer sur le canal de données :
    * Ne plus utiliser Blowfish comme algo de chiffrement symétrique car il n'est plus recommandé par son auteur et ne respecte pas les préconisation de l'ANSSI sur la taille des blocs : possible facilement mais cela nécessite d'imposer un flag day aux utilisateurs existants de notre VPN puisqu'ils doivent modifier leur configuration en même temps que celle du serveur.

    * Ne plus utiliser SHA-1 qui n'est pas cassée mais est dépréciée un peu partout : possible facilement mais cela nécessite d'imposer un flag day aux utilisateurs existants de notre VPN puisqu'ils doivent modifier leur configuration en même temps que celle du serveur.


Une dernière amélioration générale est de ne plus utiliser SHA-1 comme l'un des algos utilisés par OpenVPN pour générer des nombres pseudo-aléatoires. Il s'agit de la directive « prng » : « prng sha256 16 ». 16 représente le nombre d'itérations. C'est la valeur par défaut et il ne me semble pas intéressant de la changer. Ce changement s'effectue sur le client et le serveur, sans impact sur l'un comme sur l'autre.


Un gros résumé des directives de conf' :
    * Celles qui ne cassent rien :
        * « tls-cipher EDH+AES+aRSA ». Côté serveur et client.
        * « dh » + un fichier contenant des paramètres de Diffie-Hellman >= 3072 bits. Côté serveur uniquement.
        * « prng sha256 16 ». Côté serveur et client.

    * Celles qui nécessitent d'être changées sur le serveur et sur le client en même temps :
        * « cipher AES-128-CBC ».
        * « auth SHA256 ».

    * Celles qui cassent les vieux clients :
        * tls-version-min 1.2


Bon, OK, on a vu quoi changer. Mais ces algos plus sécurisés sur le canal de données ont un coût en performance (les changements sur le canal de contrôle affectent uniquement l'initialisation de la communication). Est-ce que ce coût est viable *dans la pratique* ?

Pour ce faire, j'ai monté une VM de test sur l'infra d'ARN, FAI associatif en Alsace. Même configuration : RAM, nombre de procs, Debian GNU/Linux Jessie que la VM VPN de production.

Je n'utilise pas les directives de configuration « fragment » et « mssfix » qui ont un impact sur les performances (voir https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux). C'est sur ce dernier point que mon test n'est pas conforme à ce que nous avons déployé chez ARN : nous utilisons fragment 1300 et mssfix afin de prendre en charge les abonnés pour lesquels la découverte de la MTU ne fonctionne pas (et il y en a) et qui ne peuvent donc pas utiliser notre VPN. Le reste de la configuration OpenVPN est conforme au VPN de production.

J'ai fait trois types de tests :
    * Latence aller-retour en couche 3 avec un bête ping -c 100 -i 0.2 sur l'IP de l'endpoint VPN (celle à l'intérieur du VPN hein).

    * Téléchargement d'une vidéo depuis deux gros hébergeurs français (Online et OVH) en IPv4, en utilisant le protocole HTTP, une seule connexion simultanée. Pas de CDN et autres.

    * Téléchargement de 25% de l'iso du premier DVD de Debian GNU/Linux Jessie amd64 en IPv4, via Bittorrent. Intérêt ? Le test HTTP dépend beaucoup de la qualité et de la saturation de l'interconnexion entre les prestataires (ici entre Online/OVH d'un côté et Cogent de l'autre car ARN est uniquement accroché sur Cogent à l'heure actuelle). Au contraire, Bittorrent suppose plein d'émetteurs du même contenu dispersés chez plein d'opérateurs réseau. On a donc plusieurs interconnexions et toutes ne sont pas mal entretenues / saturées en même temps.

J'ai effectué 2 tests de chaque (séparés de 30 minutes), depuis ma connexion Internet fixe habituelle chez NC, avec mon laptop habituel, tôt ce matin (8h-10h) pour éviter les congestions. Aucun autre trafic ne sort de ma machine durant les tests, of course (Netfilter veille au grain). J'ai changé d'IP de sortie entre chaque test Torrent. Pourquoi ? Car, lors de pré-tests, j'ai mis en évidence que les peers me reconnaissaient et ne sont pas enclins à me refiler les mêmes morceaux d'un même fichier x fois d'affilé d'où un débit artificiellement moindre.

Résultats :
    * Moyenne des tests latence avec Blowfish + SHA1 : 25,6 ms ; Moyenne des maximums : 29,8 ms ;
    * Moyenne des tests latence avec AES-128-CBC + SHA256 : 25,7 ms ; Moyenne des maximums : 33,9 ms ;
    * Note : la variation des minimums est infime, d'où leur absence dans ce shaarli.

    * Moyenne des tests HTTP avec Blowfish + SHA1 : 3,5 mo/s
    * Moyenne des tests HTTP avec AES-128-CBC + SHA256 : 5,3 mo/s

    * Moyenne des tests torrent avec Blowfish + SHA1 : 6,4 mo/s
    * Moyenne des tests torrent avec AES-128-CBC + SHA256 : 4,2 mo/s

    * Dans tous les cas, nous ne sommes pas CPU-limited. Ni sur mon laptop, ni sur la VM d'ARN. Cette dernière voit le taux d'occupation de son unique CPU virtuel passer de 40-45% avec Blowfish + SHA-1 à 25-35% (oui, c'est plus dispersé et plus faible) pour AES-128-CBC + SHA256.

Mon interprétation : AES a toujours été plus gourmand que Blowfish, c'est un fait. Sur des téléchargements depuis une seule source (HTTP), la fluctuation de la qualité des interconnexions est plus couteuse que l'impact du renforcement de la crypto compte tenu des interconnexions entre ARN et les autres opérateurs. En revanche, sur Bittorent, on voit que la crypto a un coût, qui peut être perçu comme étant non négligeable, selon les points de vue.

Comment expliquer la différence entre téléchargement over HTTP ou over Bittorrent ? Je n'ai pas de réponse.
    * De mes mesures (avec Wireshark, menu Statistics), à vitesse moyenne identique (rate-limite dans le client BT pour s'adapter à la vitesse de téléchargement over HTTP), le téléchargement HTTP fait une moyenne de 2065 paquets par seconde là où le téléchargement via Bittorrent fait 3094 pps. Au-delà d'un certain stade, les switchs entre userland et kerneland deviennent-ils trop consommateurs et brident-ils le débit ?

    * De mes mêmes mesures, le téléchargement HTTP a une taille moyenne de paquet de 810 octets là où le téléchargement via Bittorrent a une moyenne à 655 octets par paquet. Or, la taille des paquets, a un impact sur les algos de chiffrement : « The reason behind this is that by feeding larger packets to the OpenSSL encryption and decryption routines the performance will go up. » (https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux, encore).

Je ne suis pas inquiet pour les utilisateurs mobiles : les ordiphones/tablettes ARM disposent de l'accélération matérielle et vu les débits des connexions WiFi et mobiles, ça passera. Il faudrait faire des tests sous winwin, au cas où...

J'utilise le paramètre « mute n » d'OpenVPN car il permet de masquer les occurrences d'un même message (d'une même catégorie de messages, pour être précis) qui se produisent n fois consécutivement.

Mon constat : avec la version packagée dans Debian GNU/Linux Wheezy (2.2.1) côté client, c'était impeccable : ça filtrait les messages concernant les rejeux (qu'on peut filtrer séparément avec « mute-replay-warnings », btw), les duplicatas,... et autres messages pas super intéressants surtout sur des réseaux moisis tout en laissant passer des messages qui m'intéressent plus : ceux qui indiquent le renouvellement de la clé de chiffrement symétrique temporaire (toutes les 1h, par défaut).

Avec la version packagée dans Debian Jessie (2.3.4), OpenVPN filtre aussi les messages sur le renouvellement de la clé symétrique lorsque rien d'autre n'est écrit dans le log entretemps (ce qui est normal sur une connexion stable). C'est dommage et je n'ai pas trouvé d'autre solution que de désactiver le paramètre « mute » de ma conf' OpenVPN client. Je n'ai rien trouvé dans le changelog pointé par ce shaarli qui décrive ce changement de comportement.

« Plus problématique peut-être, il permet aussi à Microsoft d’intégrer ses solutions de suivi personnalisé de l’évolution de l’apprentissage de chaque élève avec des « algorithmes d’analyse » qui devront faire l’objet d’un « suivi éthique et juridique ». Il s’agira d’analyser les notes des élèves et les résultats détaillés aux différentes évaluations, pour être davantage capable de cerner les difficultés ou les forces, et d’aider à orienter les élèves en fonction de leurs domaines de compétences identifiés par le logiciel. « Un soin particulier sera apporté à la confidentialité et à la sécurité des données utilisées », promet le texte.

En pratique Microsoft déploiera ses API d’Adaptive Learning qui permettent de réaliser des outils d’apprentissage qui s’adaptent à chaque élève, en fonction de son rythme et de ses compétences. La question de l’exportation des données et de l’interopérabilité des algorithmes en cas de changement de fournisseur n’est pas évoquée dans le document. Se posera aussi la question de la place du ministère et des académies dans la détermination des critères d’évaluation et l’élaboration des matériels d’apprentissage, le travail de suivi traditionnellement dévolu à la puissance publique étant en partie délégué à l’entreprise privée.

[ NDLR : mais oui, continuez à ficher les élèves dans plusieurs bases nationales comme Base élèves. Continuez de filer la vie privée de la jeunesse aux géants d'Internet. Tout ça est très bien. ]

Interpellé par l’association Léa Linux qui signale qu’il « eut été préférable de faire un partenariat entre l’Éducation nationale et les logiciels libres », le cabinet de Najat Vallaud-Belkacem a renvoyé la balle dans le camp des éditeurs de logiciels. Il assure que le ministère « est neutre technologiquement », qu’il « travaille avec le libre », et demande aux éditeurs de proposer eux-aussi des accords — même s’il sera difficile pour eux de signer un aussi gros chèque :

[...]

Mais plusieurs internautes ont immédiatement rappelé au cabinet de la ministre de l’Éducation nationale que le libre n’est pas qu’une technologie, mais qu’il est aussi et surtout une philosophie et une spécificité juridique et pratique qui offre des avantages extra-technologiques.

[...]

D’autres ont proposé au ministère des listes à la Prévert de logiciels libres, sans comprendre peut-être que les enjeux du XXIe siècle étaient moins dans les logiciels eux-mêmes que dans les données et leur exploitation.

[ Gros +1. L'heure est aux services et données externalisés + analyse bullshit.

[...]

Or sur ce domaine clé les éditeurs de solutions libres peinent à rivaliser, à la fois pour des questions culturelles liées à une plus grande sensibilité à la protection de la vie privée, et à des questions de coût, l’exploitation des données demandant des serveurs et des capacités de traitement de haut niveau que les éditeurs de logiciels libres sont souvent incapables de proposer. C’est là un énorme défi pour ceux qui affrontent les logiciels propriétaires, dans le domaine de l’éducation comme dans d’autres (pensez à l’intelligence artificielle, la domotique, la reconnaissance vocale, la traduction en temps réel….).

[ NDLR : gros +1 changer de paradigme pour un modèle de société basé sur le partage de la connaissance, le respect de la vie privée et de toute liberté,...  sinon, ça ne passera pas. ] »

«  Lundi 30 novembre 2015, la ministre de l'Éducation nationale, de l’Enseignement supérieur et de la recherche Najat Vallaud-Belkacem a annoncé la signature d'un partenariat entre Microsoft et son ministère. Les organisations signatrices de ce communiqué dénoncent une collusion d'intérêts : ce partenariat prévoit de présenter une fois de plus aux élèves un logiciel privateur et des formats fermés comme seuls outils incontournables et par voie de conséquence la dépendance comme modèle à adopter. Tout cela tend à renforcer la position dominante de l'entreprise américaine, au détriment des logiciels libres et des formats ouverts, qui pourtant respectent les principes élémentaires de neutralité et d'interopérabilité.

Le texte intégral de l'accord, disponible sur le site de l'Éducation Nationale, présente plusieurs axes, dont la formation des enseignants à la maitrise des environnements Microsoft en classe, la mise à disposition d'un écosystème Cloud, d'une plateforme de formation à distance. L'apprentissage du code se fera aussi sous l'égide de l'entreprise américaine. C'est donc une véritable mise sous tutelle de l'informatique à l'école, réalisée de plus sans consultation des acteurs de l'éducation, y compris en interne.

[...]

De même, il n'est fait aucun cas de l'appel en faveur des formats ouverts dans l'éducation qui, pourtant, a été soutenu par des associations professionnelles d'enseignants, des syndicats, des entreprises, des individus, mais a été ici mis de côté.

Ce n'est pas la première fois qu'un tel partenariat est signé : déjà en 2005 un accord avait été signé. Mais ce partenariat apparaît d'autant plus navrant qu'il fait suite aux récentes révélations sur l'espionnage facilité par Microsoft et sa politique de collecte d'informations personnelles de l'utilisateur.

Ce partenariat est d'autant plus regrettable qu'il va à l'encontre des objectifs de l'école, et témoigne d'une absence de volonté politique de promouvoir la diffusion et l'appropriation par tous de la connaissance et des savoirs. Une volonté politique affirmée aurait pourtant pu mettre en avant des solutions en logiciel libre, respectueuses des libertés de chacun, des standards ouverts et de l'interopérabilité qui permettent aux élèves de progresser en informatique sans enfermement technologique. Cette proposition fait d'ailleurs partie des plus soutenues de la consultation sur l'avant projet de loi « République Numérique» d'Axelle Lemaire . L'école va devenir une fabrique d'inégalité, l'argent servant par la suite de discriminant dans le choix des logiciels et des services.

[NDLR : on comprend tout de suite mieux pourquoi le gouvernement a retoqué cette proposition de la consultation sur l'avant-projet de loi numérique. Fric fric fric. ]

Fin 2011, François Hollande avait fait de la jeunesse la « la grande cause de l'élection présidentielle »1. Visiblement, une nouvelle fois, la jeunesse et la formation des esprits sont sacrifiées au profit d'intérêts économiques de grandes firmes américaines. »

Gros gros +1. Qu'on ne vienne pas me dire que c'est technique donc très compliqué. Non, c'est une question de business versus libertés, appropriation des savoirs, progression par le partage,...

En supplément de http://shaarli.guiguishow.info/?C5GyUQ , la police et la gendarmerie ont décidé d'aller toujours plus loin dans la connerie sécuritaire bullshit histoire de pouvoir encore plus tabasser des manifestants innocents et saccager des résidences d'innocents.

« Le quotidien a en effet pu consulter un tableau édité en interne le mardi 1er décembre par la direction des libertés publiques et des affaires juridiques (DLPAJ), qui dépend du ministère de l’Intérieur de Bernard Cazeneuve. C’est elle qui prépare les projets de lois et de décrets relatifs aux libertés publiques et à la police administrative. C’est donc dans ce cadre, pour rédiger deux nouveaux textes législatifs — l’un sur l’état d’urgence, l’autre sur l’anti-terrorisme, que la DLPAG a dressé les mesures demandées par la police ou la gendarmerie qui pourraient être inscrites dans les textes attendus pour janvier 2016.

Parmi ces mesures qui ne sont encore que des hypothèses de travail figure une série de nouvelles restrictions aux libertés sur Internet :

    « Interdire les connexions Wi-Fi libres et partagées » et fermer toutes les connexions Wi-Fi publiques pendant l’état d’urgence, « sous peine de sanctions pénales ».

    « Interdire et bloquer les communications des réseaux TOR en France » : Même à supposer que ça soit techniquement possible, ce serait une mesure totalement disproportionnée qui enverrait un très mauvais signe à l’international, alors que le réseau d’anonymisation TOR est utilisé par de très nombreux activistes et dissidents de pays autoritaires. L’un des premiers pays à avoir bloqué Tor était l’Iran.

    « Identifier les applications de VoIP et obliger les éditeurs à communiquer aux forces de sécurité les clefs de chiffrement » : C’est la fameuse grande guerre du chiffrement à laquelle se prépare La Quadrature du Net, la France ayant sans aucun doute la volonté de se joindre à la Grande-Bretagne pour obtenir que les éditeurs de messagerie chiffrée fournissent des backdoors pour que les autorités puissent écouter les conversations interceptées. »

JE REFUSE, PAS EN MON NOM.