PROJET AUTOBLOG


Framablog

Site original : Framablog

⇐ retour index

À qui iront les clés de la ://Surveillance ?

jeudi 10 novembre 2016 à 22:12

Parmi les interrogations nombreuses et inquiètes qui ont accompagné l’élection du nouveau président des USA, nous retenons aujourd’hui la question de la maîtrise des armes les plus dangereuses dont va disposer l’exécutif. On pense bien sûr à l’arme nucléaire et au danger de son usage inconsidéré, mais une actualité tout aussi préoccupante nous invite à nous demander avec Cory Doctorow quelles conséquences la machine industrielle de la surveillance étatique peut avoir sur nos libertés, si elle tombe aux mains de… [mettre ici le nom de toute personnalité politique dont on peut redouter l’autoritarisme].

Cory Doctorow, qui est Canadien, réagit ici à la situation nord-américaine, mais la surveillance étatique est planétaire et nous sommes en France assez lourdement pourvus en outils de surveillance générale pour éprouver quelques inquiétudes : que deviendront par exemple le fichier TES (voir ce billet de Korben) et l’état d’urgence indéfiniment prolongé que veut imposer M. Cazeneuve si un gouvernement autoritaire accède au pouvoir bientôt ?

Au risque réel Doctorow répond par la nécessité de lutter avec nos armes, celles d’Internet. Cela suffira-t-il ?

On a donné à un cinglé les clés de la surveillance d’État

par Cory Doctorow

Article original A madman has been given the keys to the surveillance state

Traduction Framalang : Goofy, Framasky, Diane

Cory Doctorow CC-BY-SA J onathan Worth

Cory Doctorow par Jonathan Worth (CC-BY-SA)

Quand le Patriot Act a été promulgué aux USA le 26 octobre 2001, il a fait disparaître un grand nombre des contrepouvoirs vitaux qui s’interposaient entre le peuple américain et son gouvernement. Alors que les partisans de Bush applaudissaient le pouvoir sans précédent que leurs représentants à Washington détenaient désormais, les militants des libertés civiles les avertissaient : « Votre président vient de créer une arme qui sera utilisée par tous ceux qui le suivront ».

Lorsque les démocrates ont pris la Maison-Blanche en 2008, les Américains de droite ont tardé à se rendre compte qu’une nouvelle administration qui ne s’appuyait pas sur eux pour exercer son pouvoir avait la possibilité de surveiller tous leurs mouvements, pouvait pister toutes leurs communications, pouvait les soumettre à une détention sans mandat dans des « zones frontalières » qui couvraient la majeure partie de la population américaine, pouvaient saisir leurs biens sans les accuser d’aucun crime, et ils ont commencé à s’inquiéter sérieusement.

Lorsque l’administration Obama a doublé le programme Bush de surveillance de masse, en lui ajoutant de lois secrètes et une liste d’Américains et d’étrangers qui pourraient être carrément assassinés en toute impunité n’importe où dans le monde, ses partisans démocrates n’ont pas accepté d’entendre la moindre critique. Obama était un politicien expérimenté, le père tranquille de l’Amérique, un type avec tant d’équanimité qu’il avait besoin d’un interprète pour traduire sa colère. Il n’allait pas abuser de cette autorité.

Les sept années de G.W. Bush après le 11 Septembre nous ont donné les bases d’un État de surveillance auquel il manquait un fou dangereux pour devenir totalitaire. Ensuite, huit ans après la mise en œuvre concrète de cet État de surveillance, Obama a indiqué aux administrateurs compétents et aux divers intervenants — police locale, partenaires internationaux, entrepreneurs militaires et industriels avec de gros budgets de lobbying — que cette surveillance doit se maintenir indéfiniment.

Aujourd’hui, c’est à un cinglé qu’on a donné le contrôle d’un arsenal de surveillance qui inclut l’autorité légale pour nous espionner tous, tout le temps ; des offres commerciales des monopoles des télécoms qui transforment les dépenses d’un gouvernement impopulaire en affaires rentables avec de l’argent comptant qui servira au lobbying pour élargir leur clientèle ; et un stock de vulnérabilités technologiques mortelles dans les outils dont nous dépendons, que l’Amérique a transformés en armes pour attaquer ses ennemis, même si cela implique de laisser les Américains sans défense contre les criminels, les harceleurs nihilistes, l’espionnage d’États étrangers et l’espionnage industriel.

Le Royaume-Uni est sur le point d’adopter une loi de surveillance qui éclipse tous les pouvoirs de surveillance de Bush et Obama. Le cyber-arsenal que Theresa May veut déchaîner sur le monde ne permettra pas seulement de vous pister en temps réel avec un degré d’intrusion qui ne peut pas être surestimé, il va également amasser des stocks énormes de données de ce suivi qui seront inévitablement fuitées, à la fois publiquement — pensez au piratage de Sony — et en privé, ce que nous découvrirons seulement des années après les faits, quand nous verrons que des escrocs minables ont exploité nos moments de chagrin et de détresse les plus privés pour en faire leur profit.

Le dernier gouvernement canadien a adopté un projet de loi de surveillance qu’on pourrait facilement qualifier de fanfiction du Patriot Act. Le gouvernement actuel — dirigé par un homme charismatique auquel beaucoup font confiance pour prendre les bonnes décisions — a voté pour elle, parce que ses membres ne voulaient pas être considérés comme « mous sur le terrorisme » à la veille de l’élection, mais ils ont promis de régler la question plus tard. Jusqu’à présent, ils n’ont strictement rien fait du tout, et ils n’ont pas de feuille de route pour faire quoi que ce soit qui pourrait transformer cette épée en un soc de charrue(1). Ce qui est particulier avec les pouvoirs que donne la surveillance, c’est qu’ils sont terriblement jouissifs. Une fois que vous en disposez, ils sont si pratiques qu’il est très difficile de les jeter dans les poubelles de l’Histoire.

Le gouvernement allemand de Mme Merkel — elle-même est hantée par ses souvenirs personnels d’enfance sous la surveillance intrusive des espions de la Stasi — a été scandalisé d’apprendre que le gouvernement des USA enregistrait les conversations téléphoniques de la Chancelière elle-même. Mais en fin de compte, Merkel a conclu un accord entre ses espions et leurs homologues américains et elle a officialisé le complexe industriel de surveillance. L’Allemagne est maintenant à deux doigts d’un gouvernement néo-nazi d’extrême-droite qui pourrait s’installer au milieu de la toile que Merkel a permis à ses services secrets de tisser dans tous les coins de son pays.

Après les terribles attaques de Paris, François Hollande a renié sa promesse de démantèlement de la surveillance française. Il l’a plutôt radicalement étendue, créant une arme immortelle et pluripotente pour espionner et contrôler le peuple français. Hollande est sur le point de perdre le contrôle du gouvernement français au bénéfice des néofascistes de Marine Le Pen, cheffe héréditaire d’une tribu de racistes vicieux et autoritaires.

Les mouvements politiques vont et viennent, mais les autorités institutionnelles demeurent. Les militants des partis ont offert une couverture politique à leurs leaders pendant qu’ils créaient tranquillement les conditions du fascisme clé en mains. Maintenant nous sommes à un clic du totalitarisme.

Il n’est pas trop tard.

Démanteler la surveillance d’État ne sera pas facile mais les choses importantes le sont rarement. Des organisations comme l’EFF (USA), Openmedia (Canada), la Quadrature du Net (France) et l’Open Rights Group ont mené cette bataille depuis des années, longtemps avant que la plupart d’entre nous ne prenne conscience du danger. Leur temps est maintenant : le moment où le danger est visible mais que le mal n’est pas irréversible. C’est le moment où jamais.

Les quatre ans à venir apporteront des batailles bien plus urgentes que l’avenir d’Internet : des batailles sur le droit des femmes à disposer de leur corps ; sur les meurtres racistes de la police et l’incarcération de masse, sur les déportations de masse et les camps de concentration ; sur la discrimination selon le genre et l’homophobie ; sur l’accès aux premières nécessités, depuis l’alimentation jusqu’au logement, en passant par la couverture maladie.

Chacune de ces batailles sera gagnée ou perdue en utilisant Internet.

Nous manquons de munitions, de forces vives, nous sommes trop peu nombreux et n’avons pas de plan, mais nous pouvons tout de même gagner. Internet donne l’avantage à la guerre asymétrique, là où le pouvoir brut et l’argent peuvent être contrés par des tactiques novatrices et une opposition agile.

capture-du-2016-11-10-22-27-31

Tor, Signal,l’identification à 2 facteurs, un VPN… des armes pour s’opposer à Trump ?

 

S’il nous faut remporter la victoire dans la lutte pour les droits humains et la dignité humaine, nous devons avoir pour arme un Internet libre, ouvert et équitable. Ça commence maintenant. Ça commence avec la prise de conscience suivante : nous ne pouvons pas nous permettre de créer des armes et des pouvoirs juste pour « notre camp » en croyant que l’autre camp, celui des « méchants », ne voudra pas s’en emparer. Nous avons chargé un fusil et l’avons mis entre les mains d’un cinglé. Engageons-nous à ne plus jamais le faire.

Nous continuons le combat.

 

À lire aussi sur le même sujet :

 

Note

(1) Dans la Bible, « De leurs glaives ils forgeront des houes, Et de leurs lances des serpes … » (Ésaïe 2:4). L’idée est bien sûr de convertir les armes de la guerre en outils pour la paix.

Des routes et des ponts (8) – ce qui motive les contributeurs

lundi 7 novembre 2016 à 18:34

Participer à l’open source est souvent une activité bénévole donc non rémunérée mais qui peut parfois devenir chronophage et difficilement compatible avec une autre activité ou un emploi. Nadia Eghbal, dans ce nouveau chapitre nous donne à voir aujourd’hui les trois motivations principales des contributeurs de l’open source.

motivation_phboukobza

Image de Cécile Delannoy, Photo Philippe Boubovska CC-BY 2.0

Pourquoi les gens continuent-ils de contribuer à ces projets, alors qu’ils ne sont pas payés pour cela ?

Traduction Framalang : Adélie, goofy, xi, woof, Diane, Asta, Rozmador, Lumibd, Piup, teromene, mika, lyn. et deux anonymes
De nombreuses infrastructures numériques sont entretenues par des contributeurs individuels ou par une communauté de contributeurs. Dans la plupart des cas, ces contributeurs ne sont pas directement rémunérés pour ce travail. En réalité, ils contribuent pour des raisons propres aux communautés open source, pour se construire une réputation, par exemple, ou dans un esprit de service public. Ce chapitre explorera certaines de ces motivations plus en détail.

Contribuer à l’open source pour se construire une réputation.

Se construire une réputation est peut-être la motivation la plus concrète pour contribuer à un projet open source. Pour les développeurs, rédacteurs techniques et autres, ces projets sont une occasion de faire leurs preuves en public, et leur offrent une chance de participer à quelque chose de grand et d’utile.
Dans le cadre d’un programme appelé Google Summer of Code (l’été du code de Google), Google propose des bourses d’été à des étudiants développeurs pour qu’ils contribuent à des projets open source populaires. Le programme fonctionne bien, parce que les développeurs sont des étudiants, novices dans le domaine de l’informatique et avides de démontrer leurs talents.
Les développeurs, en particulier, tirent profit de leurs expériences de contribution à l’open source pour se constituer un portfolio. De plus, en contribuant à des projets populaires dotés de communautés actives, un développeur a des chances de se construire une réputation en devenant « connu ».

GitHub, site web déjà cité, est une plateforme populaire pour l’élaboration collaborative de code. Quand un développeur contribue à un projet public de logiciel, ses contributions apparaissent sur son profil. Le profil GitHub d’un développeur peut faire office de portfolio pour des sociétés de logiciels, mais seules les contributions effectuées pour des projets publics (c’est-à-dire open source) sont visibles par tous.

Cependant, les motivations basées sur la réputation ne sont pas dénuées de risques, surtout parmi les jeunes développeurs. Un développeur dont la carrière est encore naissante peut contribuer à un projet open source dans le seul but de trouver un employeur, puis arrêter de contribuer une fois cet objectif atteint. De plus, un développeur cherchant uniquement à se construire un portfolio risque de proposer des contributions de moindre qualité, qui ne seront pas acceptées et qui pourront même ralentir le processus de développement du projet. Enfin, si le but d’une contribution publique de la part d’un développeur est de se construire une réputation, alors ce développeur sera tenté de contribuer uniquement aux projets les plus populaires et attractifs (une extension du « syndrome de la pie » déjà évoqué), et de ce fait, les projets plus anciens auront du mal à trouver de nouveaux contributeurs.

Le projet est devenu très populaire de manière inattendue, et son développeur se sent obligé d’en assurer le suivi.

Des entreprises, des particuliers ou des organisations peuvent devenir dépendants d’un projet open source populaire. En d’autres termes, le code est utilisé dans des logiciels opérationnels, écrits et déployés par d’autres, ces logiciels peuvent servir pour un tas de choses : achats en ligne ou soins médicaux. En raison de la complexité du réseau de dépendances (dont beaucoup ne sont même pas connues de l’auteur du projet, puisqu’il ne peut pas savoir exactement qui utilise son code), la personne qui maintient le projet peut se sentir moralement obligée de continuer à l’entretenir.
Arash Payan, le développeur d’Appirater mentionné au début de ce rapport, a publié son projet en 2009. Au sujet de sa décision de continuer à maintenir le projet, il déclare :

« Ce n’est pas quelque chose de très excitant, mais il y a tellement de gens qui utilisent le projet (qui en dépendent, même ?) pour leurs applications, que je me sens obligé d’en prendre soin correctement. Personnellement, j’ai quitté iOS, donc maintenir une bibliothèque iOS n’est pas exactement la première chose que je veux faire de mon temps libre. »

Payan estime que maintenir le projet à jour lui prend 1 à 2 heures par mois maximum, donc cela ne le dérange pas.
Mais certains projets devenus populaires de façon inattendue prennent plus de temps à maintenir. Andrey Petrov est un développeur indépendant qui a écrit une bibliothèque Python appelée urllib3. Sa publication en 2008 fut une avancée majeure pour la bibliothèque standard déjà existante, et elle est devenue populaire parmi les développeurs Python. Aujourd’hui, tous les utilisateurs de Python en dépendent.
Andrey a rendu le projet open source dans l’espoir que d’autres gens soutiendraient son développement et sa maintenance. Il est développeur indépendant ; bien qu’il apprécie de maintenir urllib3, il ne peut s’en occuper que pendant son temps libre puisqu’il n’est pas payé pour ce travail. Cory Benfield, qui est employé par la Hewlett Packard Enterprise pour aider à maintenir des bibliothèques Python d’importance critique (que HPE utilise et dont HPE dépend), est désormais affecté à la maintenance de urllib3 dans le cadre de son travail ; cela a allégé la charge de travail d’Andrey.

Le projet est une passion plus qu’un travail

Eric Holsher est l’un des créateurs de Read the Docs, une plateforme qui héberge de la documentation sur des logiciels. La documentation est l’équivalent d’un mode d’emploi. De même qu’on a besoin d’un mode d’emploi pour monter un meuble, un développeur a besoin de documentation pour savoir comment implémenter un projet. Sans la documentation adéquate, il serait difficile pour un développeur de savoir par où commencer.
Read the Docs fournit de la documentation pour 18 000 logiciels, y compris pour des entreprises clientes, et compte plus de 15 millions de pages consultées chaque mois.
Bien qu’il génère des revenus grâce à de grosses sociétés clientes, le projet Read the Docs est toujours majoritairement financé par les dons de ses utilisateurs. Le coût des serveurs est quant à lui couvert grâce au mécénat de l’entreprise Rackspace.
Eric et son cofondateur, Anthony Johnson, s’occupent de la maintenance du projet et n’en tirent pas de revenus réguliers bien qu’ils s’y consacrent à temps plein. Une subvention ponctuelle de 48 000 $ de la Fondation Mozilla, reçue en décembre 2015, les aidera à court terme à couvrir leurs salaires. Ils expérimentent actuellement un modèle publicitaire (qui ne piste pas ses utilisateurs) qui rendrait le modèle viable.
Eric remarque que la difficulté ne réside pas uniquement dans le travail de développement, mais aussi dans les fonctions extérieures au code, comme le support client, qui nécessite qu’un mainteneur soit d’astreinte chaque week-end en cas de problème. Pour expliquer pourquoi il continuait de maintenir le projet, Eric l’a qualifié de « travail-passion ».

« Soit les humains sont irrationnels, soit ils ne sont pas intéressés seulement par l’argent. Il y a clairement une autre motivation pour moi dans ce cas. C’est un travail-passion. Si je le voulais, je pourrais clore ce projet demain et ne plus jamais y revenir, mais je travaille dessus depuis 5 ans et je n’ai aucune envie que ça se termine. »

Eric est motivé pour travailler sur Read the Docs parce qu’il perçoit la valeur que cela crée pour les autres. Pour beaucoup de mainteneurs de projets, cet impact sur autrui est la première motivation, parce qu’ils peuvent directement constater l’effet positif que leur travail a sur la vie d’autres personnes. En ce sens, l’open source a beaucoup de points communs avec le secteur à but non-lucratif. Cependant, tout comme dans le secteur à but non-lucratif, cette mentalité de « travail-passion » peut augmenter la difficulté qu’ont les communautés open source à aborder le sujet qui fâche : comment pérenniser des projets qui nécessitent davantage de ressources et d’attention que ce que les contributeurs actuels peuvent fournir ?

Un peu d’hygiène numérique

mardi 1 novembre 2016 à 09:10

Les quelques conseils qui suivent sont élémentaires et relèvent du bon sens plus que de la technique. Ils doivent cependant être répétés sans cesse tant il nous est facile de passer outre et de négliger ce qui peut pourtant nous rendre un fier service…

Saviez-vous que Mozilla dispose d’une équipe et d’un site Internet Citizen qui publie de semaine en semaine des conseils pour que chacun puisse agir et « Protéger la plus vaste ressource globale partagée » ? C’est sur ce portail que j’ai choisi l’article de M.J. Kelly, à la suite duquel vous trouverez quelques pistes pour aller plus loin. Mais avant d’installer un VPN, de chiffrer notre disque dur ou de créer un nœud Tor, si nous commencions par sécuriser nos mots de passe ?

 

Devez-vous vraiment masquer votre webcam ?

Source : Should you cover your webcam ?

par M.J. Kelly

mjkelly2Lorsque les médias nous ont révélé que des personnalités comme le PDG de Facebook Mark Zuckerberg et le directeur du FBI James Comey masquaient leurs webcams, nous avons été amenés à nous demander si nous ne devrions pas tous en faire autant. Mettre un post-it ou un bout de sparadrap sur la caméra peut vous donner l’impression que vous gardez le contrôle en vous protégeant contre l’espionnage d’un pirate. C’est vrai, tant que votre webcam est masquée, on ne peut pas vous voir, mais est-ce une protection efficace pour votre sécurité ?

Marshall Erwin, responsable du département Vie privée et confidentialité chez Mozilla, répond : « — pas tant que ça… »

Masquer votre webcam pourrait en réalité aggraver la situation, précise Erwin. Les pirates pourraient encore vous écouter en utilisant le microphone, par exemple. Si vous avez masqué la caméra et ne voyez pas le voyant lumineux à côté de la lentille, vous ne saurez pas que le pirate a activé la caméra et vous écoute.

Erwin souligne également que votre webcam peut être compromise par d’autres moyens, comme le piratage des appels vidéo, appelé piggybacking(1). Masquer votre webcam n’est pas une défense parfaite.

newsletter_03_bandaid_1-0_blog

Un bout de sparadrap, pourquoi pas, mais…

Avant de la débrancher carrément, il existe de meilleures solutions que de lui coller un pansement ou de la jeter à la poubelle. Vous pouvez faire preuve d’astuce et vous protéger des intrusions de sécurité avant qu’elles ne surviennent

Voici quoi faire :

En définitive, vous n’avez pas vraiment de raisons d’avoir peur d’utiliser des webcams. Elles ne représentent qu’un petit élément parmi une foule de technologies web qui rendent Internet dynamique et plaisant. Restez conscient-e de la possibilité d’avoir une webcam piratée, mais faites preuve de bon sens. Mettez un cache sur votre webcam (une gommette, un postit™, un autocollant avec un chat…) si ça vous fait plaisir, mais ne vous figurez pas que vous tenez là une solution radicale.

Efforcez-vous surtout d’agir en citoyen.ne du numérique avisé.e et conscient.e de sa sécurité en ligne, que la caméra soit ou non activée.

Vous voudrez sûrement aller plus loin :

 

(1) Voyez l’entrée Piggybacking du glossaire en français du site panoptinet.com

Si Google vous ignore, votre projet est en péril

lundi 31 octobre 2016 à 17:47

L’affaire a eu un certain retentissement : une entreprise qui propose du courrier électronique chiffré à ses clients et dont la croissance commence à faire de l’ombre à Gmail disparaît subitement des écrans de radar, ou plutôt des premières pages de la recherche Google, ce qui met en danger son modèle économique.

Aujourd’hui tout est réparé, mais cet épisode illustre une fois de plus le pouvoir de nuisance de Google dans la recherche sur Internet, qui est désormais un tentacule parmi d’autres de la pieuvre Alphabet.

google-search-risk-monopoly

Remerciements particuliers au graphiste James Belkevitz de Glasgow pour cette image

Traduction Framalang : Penguin, goofy, Asta, Rozmador, Lumibd, KoS, xi
Article original sur le site de ProtonMail : Search Risk – How Google Almost Killed ProtonMail

Le risque de la recherche — Comment Google a bien failli faire disparaître ProtonMail

par Andy Yen

andyyenprotonmailcofounder

Andy est un cofondateur de ProtonMail

Ces deux derniers mois, nombre d’entre vous nous ont contactés pour en savoir plus sur le mystérieux tweet que nous avons envoyé à Google en août. Chez ProtonMail, la transparence est une valeur fondamentale, et nous essayons d’être aussi transparents envers notre communauté que possible. Comme beaucoup de gens continuent à nous poser des questions, nous devons être plus transparents à ce sujet pour éviter toute confusion et spéculation. C’est pourquoi nous racontons toute l’affaire aujourd’hui pour clarifier ce qui est arrivé.

Que s’est-il passé ?

Pour faire court, depuis un an Google ne faisait pas apparaître ProtonMail dans les résultats de recherche (NdT : en langue anglaise) sur les requêtes telles que secure email (e-mail sécurisé) et encrypted email (e-mail chiffré). C’était très suspect car ProtonMail a longtemps été le plus important fournisseur de messagerie chiffrée au monde.

Lorsque la version bêta de ProtonMail a été lancée en mai 2014, notre communauté a rapidement grandi tandis que des gens du monde entier se sont réunis et nous ont soutenu dans notre mission de protection de la vie privée à l’ère numérique. Notre campagne de financement collaboratif a battu tous les records en récoltant plus d’un demi-million de dollars des donateurs et nous a fourni les ressources nécessaires afin d’être compétitifs, même contre les plus gros mastodontes du secteur de l’e-mail.

À l’été 2015, ProtonMail avait passé la barre du demi-million d’utilisateurs et était le service sécurisé de courriels le plus connu au monde. ProtonMail était aussi bien classé à l’époque dans les résultats de recherche de Google, sur la première ou la deuxième page pour la plupart des requêtes comme secure email et encrypted email. Pourtant, à la fin du mois d’octobre 2015, la situation avait complètement changé, et ProtonMail n’apparaissait mystérieusement plus dans les résultats de recherche pour nos deux mots-clefs principaux.

Entre le début de l’été et l’automne 2015, ProtonMail a, il faut le souligner, connu beaucoup de changements. Nous avons lancé ProtonMail 2.0, sommes passés complètement en open source, nous avons lancé des applications mobiles en bêta, et nous avons mis à jour notre site, remplaçant notre ancien domaine de premier niveau .ch par .com, plus connu. Nous avons aussi doublé en taille, atteignant près d’un million d’utilisateurs à l’automne. Tous ces changements auraient dû amélioré le classement de ProtonMail dans les résultats de recherche puisque nous offrions une solution de plus en plus pertinente pour davantage d’utilisateurs.

En novembre 2015, nous nous sommes aperçu du problème et avons consulté un certain nombre d’experts en référencement reconnus. Aucun d’entre eux ne pouvait comprendre le problème, en particulier parce que ProtonMail n’a jamais utilisé de tactiques déloyales de référencement, et que nous n’avons jamais observé l’utilisation de ces mêmes techniques contre nous. Mystérieusement, le problème était entièrement restreint à Google, puisque cette anomalie n’était constatée pour aucun autre moteur de recherche. Ci-dessous, le classement dans les résultats de recherche de ProtonMail pour les mots-clefs secure email et encrypted email au début du mois d’août 2016 pour les principaux moteurs de recherche. Nous apparaissons sur la première ou la deuxième page partout sauf pour Google où nous n’apparaissons pas du tout.

protonmail_seo_rank_augustTout au long du printemps 2016, nous avons tenté activement d’établir le contact avec Google. Nous avons créé deux tickets sur leur formulaire de signalement de spam où nous expliquions la situation. Nous avons même contacté le président des Relations Stratégiques EMOA chez Google, mais n’avons ni reçu de réponse ni constaté d’amélioration. Vers cette époque, nous avons aussi entendu parler de l’action liée au droit de la concurrence engagée par la Commission Européenne contre Google, accusant Google d’abuser de son monopole sur les recherches pour abaisser le classement de ses concurrents. Il s’agissait d’une nouvelle inquiétante, car en tant que service de courriels qui valorise d’abord la vie privée des utilisateurs, nous sommes la première alternative à Gmail pour les personnes qui souhaitent que leurs données personnelles restent confidentielles.

En août, à défaut d’autre solution, nous nous sommes tournés vers Twitter pour exposer notre problème. Cette fois, nous avons enfin eu une réponse, en grande partie grâce aux centaines d’utilisateurs de ProtonMail qui ont attiré l’attention sur notre situation et l’ont rendue impossible à ignorer. Quelques jours plus tard, Google nous a informés qu’ils avaient « réparé quelque chose » sans fournir plus de détails. Les résultats ont été visibles immédiatement.

google_protonmail_search_risk

Classement dans les résultats de recherche Google de ProtonMail pour Encrypted Email

Dans le graphique ci-dessus, l’axe des abscisses représente le temps et l’axe des ordonnées le classement dans les résultats (les nombres les plus bas sont les meilleurs). Les dates pour lesquelles il n’y a pas de point correspondent à des moments où nous n’apparaissions pas du tout dans les résultats de Google. Après les quelques changements de Google, le classement de ProtonMail s’est immédiatement rétabli et ProtonMail est maintenant n°1 et n°3 respectivement pour secure email et encrypted email. Sans plus d’explications de la part de Google, nous ne saurons sans doute jamais pourquoi ProtonMail a été déclassé. En tout cas, nous apprécions le fait que Google ait enfin fait quelque chose pour résoudre le problème, nous aurions seulement souhaité qu’ils le fassent plus tôt.

Le risque de la recherche

Cet incident souligne cependant un danger auparavant méconnu que nous appelons maintenant le « Risque de la Recherche ». Le danger est que n’importe quel service comme ProtonMail peut facilement être supprimé par les entreprises qui gèrent les moteurs de recherche, ou le gouvernement qui contrôle ces entreprises. Cela peut même arriver à travers les frontières nationales. Par exemple, même si Google est une société américaine, elle contrôle plus de 90 % du trafic de recherche européen. Dans ce cas précis, Google a directement causé une réduction de la croissance mondiale de ProtonMail de plus de 25 % pendant plus de dix mois.

Cela signifiait que les revenus que Protonmail tirait de ses utilisateurs ont été aussi été réduits de 25 %, mettant de la pression financière sur nos activités. Nous sommes passés  de la capacité à  couvrir toutes nos dépenses mensuelles à la nécessité de puiser de l’argent de notre fonds de réserve d’urgence. La perte de revenus et les dommages financiers consécutifs ont été de plusieurs milliers de francs suisses (1 CHF = 1,01 USD), qui ne seront jamais remboursés.

La seule raison pour laquelle nous avons survécu pour raconter cette histoire est que la majeure partie de la croissance de ProtonMail provient du bouche à oreille, et que notre communauté est trop active pour l’ignorer. Bien d’autres entreprises ne seront pas aussi chanceuses. Cet épisode montre que bien que les risques en matière de recherche internet sont sérieux, et nous soutenons donc maintenant la commission européenne : compte tenu de la position hégémonique de Google sur la recherche web, plus de transparence et de surveillance sont indispensables.

Se défendre contre le risque de la recherche

Cet épisode démontre que pour que ProtonMail réussisse, il est important que nous puissions nous développer indépendamment des moteurs de recherche, de sorte qu’il devienne impossible pour n’importe quelle entreprise qui gère la recherche de nous paralyser sans le vouloir. Plus facile à dire qu’à faire, mais voici une liste d’actions que nous pouvons tous mener pour préserver l’avenir de ProtonMail :

Plus nous diffuserons l’idée que la vie privée en ligne est très importante, plus nous rendrons impossible de supprimer ou interdire les services de messagerie chiffrés tels que ProtonMail, ou d’exercer sur eux une pression quelconque. Nous croyons que la vie privée en ligne est essentielle pour un avenir ouvert, démocratique et libre, et quels que soient les obstacles devant nous, nous allons continuer à élaborer les outils nécessaires pour protéger cet avenir. Nous vous remercions de nous soutenir et de rendre cela possible.

Cordialement,
L’équipe ProtonMail

Des routes et des ponts (7) – pour une infrastructure durable

lundi 31 octobre 2016 à 10:31

Une question épineuse pour les projets libres et open source est leur maintenance à long terme, et bien évidemment les ressources, tant financières qu’humaines, que l’on peut y consacrer. Tel est le sujet qu’aborde ce nouveau chapitre de l’ouvrage de Nadia Eghbal Des routes et des ponts que le groupe Framalang vous traduit semaine après semaine (si vous avez raté les épisodes précédents)

Elle examine ici une série de cas de figures en fonction de l’origine de l’origine projet.

Comment les projets d’infrastructure numérique sont-ils gérés et maintenus ?

TraductionFramalang : Diane, Penguin, Asta, Rozmador, Lumibd, jum-s, goofy, salade, AFS, Théo

Nous avons établi que les infrastructures numériques sont aussi nécessaires à la société moderne que le sont les infrastructures physiques. Bien qu’elles ne soient pas sujettes aux coûts élevés et aux obstacles politiques auxquels sont confrontées ces dernières, leur nature décentralisée les rend cependant plus difficiles à cerner. Sans une autorité centrale, comment les projets open source trouvent-ils les ressources dont ils ont besoin ?

En un mot, la réponse est différente pour chaque projet. Cependant, on peut identifier plusieurs lieux d’où ces projets peuvent  émaner : au sein d’une entreprise, via une startup, de développeurs individuels ou collaborant en communauté.

Au sein d’une entreprise

Parfois, le projet commence au sein d’une entreprise. Voici quelques exemples qui illustrent par quels moyens variés un projet open source peut être soutenu par les ressources d’une entreprise :

Go, le nouveau langage de programmation évoqué précédemment, a été développé au sein de Google en 2007 par les ingénieurs Robert Griesemer, Rob Pike, et Ken Thompson, pour qui la création de Go était une expérimentation. Go est open source et accepte les contributions de la communauté dans son ensemble. Cependant, ses principaux mainteneurs sont employés à plein temps par Google pour travailler sur le langage.

React est une nouvelle bibliothèque JavaScript dont la popularité grandit de jour en jour.
React a été créée par Jordan Walke, ingénieur logiciel chez Facebook, pour un usage interne sur le fil d’actualités Facebook. Un employé d’Instagram (qui est une filiale de Facebook) a également souhaité utiliser React, et finalement, React a été placée en open source, deux ans après son développement initial.
Facebook a dédié une équipe d’ingénieurs à la maintenance du projet, mais React accepte aussi les contributions de la communauté publique des développeurs.

Swift, le langage de programmation utilisé pour iOS, OS X et les autres projets d’Apple, est un exemple de projet qui n’a été placé en open source que récemment. Swift a été développé par Apple en interne pendant quatre ans et publié en tant que langage propriétaire en 2014. Les développeurs pouvaient utiliser Swift pour écrire des programmes pour les appareils d’Apple, mais ne pouvaient pas contribuer au développement du cœur du langage. En 2015, Swift a été rendu open source sous la licence Apache 2.0.

Pour une entreprise, les incitations à maintenir un projet open source sont nombreuses. Ouvrir un projet au public peut signifier moins de travail pour l’entreprise, grâce essentiellement aux améliorations de la collaboration de masse.
Cela stimule la bonne volonté et l’intérêt des développeurs, qui peuvent alors être incités à utiliser d’autres ressources de l’entreprise pour construire leurs projets.

Disposer d’une communauté active de programmeurs crée un vivier de talents à recruter. Et parfois, l’ouverture du code d’un projet aide une entreprise à renforcer sa base d’utilisateurs et sa marque, ou même à l’emporter sur la concurrence. Plus une entreprise peut capter de parts de marché, même à travers des outils qu’elle distribue gratuitement, plus elle devient influente. Ce n’est pas très différent du concept commercial de « produit d’appel ».

Même quand un projet est créé en interne, s’il est open source, alors il peut être librement utilisé ou modifié selon les termes d’une licence libre, et n’est pas considéré comme relevant de la propriété intellectuelle de l’entreprise au sens traditionnel du terme. De nombreux projets d’entreprise utilisent des licences libres standard qui sont considérées comme acceptables par la communauté des développeurs telles que les licences Apache 2.0 ou BSD. Cependant, dans certains cas, les entreprises ajoutent leurs propres clauses. La licence de React, par exemple, comporte une clause additionnelle qui pourrait potentiellement créer des conflits de revendications de brevet avec les utilisateurs de React.

En conséquence, certaines entreprises et individus sont réticents à utiliser React, et cette décision est fréquemment décrite comme un exemple de conflit avec les principes de l’open source.

Via une startup

Certains projets d’infrastructures empruntent la voie traditionnelle de la startup, ce qui inclut des financements en capital-risque. Voici quelques exemples :
Docker, qui est peut-être l’exemple contemporain le plus connu, aide les applications logicielles à fonctionner à l’intérieur d’un conteneur. (Les conteneurs procurent un environnement propre et ordonné pour les applications logicielles, ce qui permet de les faire fonctionner plus facilement partout). Docker est né en tant que projet interne chez dotCloud, une société de Plate-forme en tant que service (ou PaaS, pour  platform as a service en anglais), mais le projet est devenu si populaire que ses fondateurs ont décidé d’en faire la principale activité de l’entreprise. Le projet Docker a été placé en open source en 2013. Docker a collecté 180 millions de dollars, avec une valeur estimée à plus d’1 milliard de dollars.

Leur modèle économique repose sur du support technique, des projets privés et des services. Les revenus de Docker pour l’année 2014 ne dépassaient pas 10 millions de dollars.

Npm est un gestionnaire de paquets sorti en 2010 pour aider les développeurs de Node.js à partager et à gérer leurs projets. Npm a collecté près de 11 millions de dollars de financements depuis 2014 de la part de True Ventures et de Bessemer Ventures, entre autres. Leur modèle économique se concentre sur des fonctionnalités payantes en faveur de la vie privée et de la sécurité.

Meteor est un framework JavaScript publié pour la première fois en 2012. Il a bénéficié d’un programme d’incubation au sein de Y Combinator, un prestigieux accélérateur de startups qui a également été l’incubateur d’entreprises comme AirBnB et Dropbox. À ce jour, Meteor a reçu plus de 30 millions de dollars de financements de la part de firmes comme Andreessen Horowitz ou Matrix Partners. Le modèle économique de Meteor se base sur une plateforme d’entreprise nommée Galaxy, sortie en Octobre 2015, qui permet de faire fonctionner et de gérer les applications Meteor.

L’approche basée sur le capital-risque est relativement nouvelle, et se développe rapidement.
Lightspeed Venture Partners a constaté qu’entre 2010 et 2015, les sociétés de capital-risque ont investi plus de 4 milliards de dollars dans des entreprises open source, soit dix fois plus que sur les cinq années précédentes.

Le recours aux fonds de capital-risque pour soutenir les projets open source a été accueilli avec scepticisme par les développeurs (et même par certains acteurs du capital-risque eux-mêmes), du fait de l’absence de modèles économiques ou de revenus prévisibles pour justifier les estimations. Steve Klabnik, un mainteneur du langage Rust, explique le soudain intérêt des capital-risqueurs pour le financement de l’open source :

« Je suis un investisseur en capital-risque. J’ai besoin qu’un grand nombre d’entreprises existent pour gagner de l’argent… J’ai besoin que les coûts soient bas et les profits élevés. Pour cela, il me faut un écosystème de logiciels open source en bonne santé. Donc je fais quoi ? … Les investisseurs en capital-risque sont en train de prendre conscience de tout ça, et ils commencent à investir dans les infrastructures. […]
Par bien des aspects, le matériel open source est un produit d’appel, pour que tu deviennes accro…puis tu l’utilises pour tout, même pour ton code propriétaire. C’est une très bonne stratégie commerciale, mais cela place GitHub au centre de ce nouvel univers. Donc pour des raisons similaires, a16z a besoin que GitHub soit génial, pour servir de tremplin à chacun des écosystèmes open source qui existeront à l’avenir… Et a16z a suffisamment d’argent pour en « gaspiller » en finançant un projet sur lequel ils ne récupéreront pas de bénéfices directs, parce qu’ils sont suffisamment intelligents pour investir une partie de leurs fonds dans le développement de l’écosystème. »

GitHub, créé en 2008, est une plateforme de partage/stockage de code, disponible en mode public ou privé, doté d’un environnement ergonomique. Il héberge de nombreux projets open source populaires et, surtout, il est devenu l’épicentre culturel de la croissance explosive de l’open source (dont nous parlerons plus loin dans ce rapport).
GitHub n’a reçu aucun capital-risque avant 2012, quatre ans après sa création. Avant cette date, GitHub était une entreprise rentable. Depuis 2012, GitHub a reçu au total 350 millions de dollars de financements en capital-risque.

nickquaranto_cc-by-2-0

Image par Nick Quaranto (CC BY-SA 2.0)

Andreessen Horowitz (alias a16z), la firme d’investissement aux 4 millards de dollars qui a fourni l’essentiel du capital de leur première levée de fonds de 100 millions de dollars, a déclaré qu’il s’agissait là de l’investissement le plus important qu’elle ait jamais fait jusqu’alors.
En d’autres termes, la théorie de Steve Klabnik est que les sociétés de capital-risque qui investissent dans les infrastructures open source promeuvent ces plateformes en tant que « produit d’appel », même quand il n’y a pas de modèle économique viable ou de rentabilité à en tirer, parce que cela permet de faire croître l’ensemble de l’écosystème. Plus GitHub a de ressources, plus l’open source est florissant. Plus l’open source est florissant, et mieux se portent les startups. À lui seul, l’intérêt que portent les sociétés d’investissement à l’open source, particulièrement quand on considère l’absence de véritable retour financier, est une preuve du rôle-clé que joue l’open source dans l’écosystème plus large des startups.
Par ailleurs, il est important de noter que la plateforme GitHub en elle-même n’est pas un projet open source, et n’est donc pas un exemple de capital-risque finançant directement l’open source. GitHub est une plateforme à code propriétaire qui héberge des projets open source. C’est un sujet controversé pour certains contributeurs open source.

 

Par des personnes ou un groupe de personnes

Enfin, de nombreux projets d’infrastructures numériques sont intégralement développés et maintenus par des développeurs indépendants ou des communautés de développeurs. Voici quelques exemples :

Python, un langage de programmation, a été développé et publié par un informaticien, Guido van Rossum, en 1991.
Van Rossum déclarait qu’il « était à la recherche d’un projet de programmation « passe-temps », qui [le] tiendrait occupé pendant la semaine de Noël. »
Le projet a décollé, et Python est désormais considéré comme l’un des langages de programmation les plus populaires de nos jours.

Van Rossum reste le principal auteur de Python (aussi connu parmi les développeurs sous le nom de « dictateur bienveillant à vie » et il est actuellement employé par Dropbox, dont les logiciels reposent fortement sur Python.

Python est en partie géré par la Python Software Foundation (NdT : Fondation du logiciel Python), créée en 2001, qui bénéficie de nombreux sponsors commerciaux, parmi lesquel Intel, HP et Google.

RubyGems est un gestionnaire de paquets qui facilite la distribution de programmes et de bibliothèques associés au langage de programmation Ruby.
C’est une pièce essentielle de l’infrastructure pour tout développeur Ruby. Parmi les sites web utilisant Ruby, on peut citer par exemple Hulu, AirBnB et Bloomberg. RubyGems a été créé en 2003 et est géré par une communauté de développeurs. Certains travaux de développement sont financés par Ruby Together, une fondation qui accepte les dons d’entreprises et de particuliers.

Twisted, une bibliothèque Python, fut créée en 2002 par un programmeur nommé Glyph Lefkowitz. Depuis lors,  son usage s’est largement répandu auprès d’individus et d’organisations, parmi lesquelles Lucasfilm et la NASA.
Twisted continue d’être géré par un groupe de volontaires. Le projet est soutenu par des dons corporatifs/commerciaux et individuels ; Lefkowitz en reste l’architecte principal et gagne sa vie en proposant ses services de consultant.

Comme le montrent tous ces exemples, les projets open source peuvent provenir de pratiquement n’importe où. Ce qui est en général considéré comme une bonne chose. Cela signifie que les projets utiles ont le plus de chances de réussir, car ils évitent d’une part les effets de mode futiles inhérents aux startups, et d’autre part la bureaucratie propre aux gouvernements. La nature décentralisée de l’infrastructure numérique renforce également les valeurs de démocratie et d’ouverture d’Internet, qui permet en principe à chacun de créer le prochain super projet, qu’il soit une entreprise ou un individu.
D’un autre côté, un grand nombre de projets utiles proviendront de développeurs indépendants qui se trouveront tout à coup à la tête d’un projet à succès, et qui devront prendre des décisions cruciales pour son avenir. Une étude de 2015 menée par l’Université fédérale de Minas Gerai au Brésil a examiné 133 des projets les plus activement utilisés sur Github, parmi les langages de programmation, et a découvert que 64 % d’entre eux, presque les deux tiers, dépendaient pour leur survie d’un ou deux développeurs seulement.

Bien qu’il puisse y avoir une longue traîne de contributeurs occasionnels ou ponctuels pour de nombreux projets, les responsabilités principales de la gestion du projet ne reposent que sur un très petit nombre d’individus.

Coordonner des communautés internationales de contributeurs aux avis arrêtés, tout en gérant les attentes d’entreprises classées au Fortune 500 qui utilisent votre projet, voilà des tâches qui seraient des défis pour n’importe qui. Il est impressionnant de constater combien de projets ont déjà été accomplis de cette manière. Ces tâches sont particulièrement difficiles dans un contexte où les développeurs manquent de modèles clairement établis, mais aussi de soutien institutionnel pour mener ce travail à bien. Au cours d’interviews menées pour ce rapport, beaucoup de développeurs se sont plaints en privé qu’ils n’avaient aucune idée de qui ils pouvaient solliciter pour avoir de l’aide, et qu’ils préféreraient « juste coder ».

Pourquoi continuent-ils à le faire ? La suite de ce rapport se concentrera sur pourquoi et comment les contributeurs de l’open source maintiennent des projets à grande échelle, et sur les raisons pour lesquelles c’est important pour nous tous.