Je ne veux pas les latences au déploiement que peut avoir la NASA. Je ne veux pas les coûts d’assurance qualité de la NASA. Je suis prêt à casser des choses ponctuellement si c’est pour avancer vite.
« Move fast and break things » ce n’est pas qu’un Moto. C’est un vrai choix stratégique.
Et si on assume le risque casser des choses, en fonction du contexte et des besoins, ce n’est pas forcément déconnant de choisir quand gérer ce risque.
La règle de la mise en production du vendredi, pour les équipes qui en ont une, n’est parfois que cela : un arbitrage entre le risque de casse, le bénéfice à livrer maintenant, la disponibilité des équipes dans les heures ou jours a venir, la facilité ou l’envie de rappeler les personnes concernées hors heures ouvrées si nécessaire, la disponibilité d’équipes d’astreinte, la possibilité de laisser un site dysfonctionnel tout un week-end ou pas, etc.
En général les équipes arbitrent ça très bien elles-mêmes. À chacun de voir si livrer un vendredi soir avant de partir est pertinent pour son propre contexte. Les deux seules options fautives sont de ne pas y réfléchir et d’ignorer le risque.
« Si ta CI est bien faite, tu n’es sensé rien casser »
La plateforme d’intégration continue ne va tester que ce que l’équipe a pensé à lui faire tester. L’équipe ne pensera jamais à tout. D’ailleurs même la NASA fait des erreurs, et l’article cité en haut de billet relate justement une anomalie découverte au cours de la vie de la sonde.
Avoir une bonne plateforme d’intégration continue dans laquelle on a confiance n’empêche pas de prendre en compte le risque dans ses choix.
Même si je pouvais avoir une CI parfaite, pour ma part, je ne le voudrais d’ailleurs pas. Le jour où je n’aurai plus aucun incident ni anomalie, je considérerai qu’on a mal fait notre travail en surinvestissant dans la qualité par rapport à nos besoins réels.
Je ne sais pas ce que deviendront ces rendez-vous physiques dans le nouveau monde où tant de personnes semblent préférer le télétravail. SudWeb a fermé ses portes un moment. ParisWeb aurait très bien pu le faire et l’équation semble difficile.
Je suis heureux de retrouver de nouveau, au moins cette fois, la bande d’amis et de connaissances qui partagent quelques unes de mes valeurs. Ça reste des moments de repos même si, forcément, le nombre de personnes fait que ça me demande une énergie monstre.
Voilà qu’on reparle de modération de Mastodon. L’histoire de départ c’est une instance (« Infosec ») qui a choisi d’en mettre une autre (« Journa ») sous silence pour ne pas subit les propos que cette dernière a choisi de laisser en ligne.
Hein ? Une instance ?
Mastodon fonctionne à travers un réseau fédéré. Son petit nom est le fédiverse. Les utilisateurs sont regroupés en ilots plus ou moins gros qu’on appelle les instances. Certains utilisateurs ont leur propre instance personnel. D’autres instances regroupent plusieurs dizaines de milliers de personnes.
Si un Tom d’Infosec est abonné à Alice de Journa, alors les deux instances communiquent entre elles pour que Journa envoie les messages d’Alice à Infosec. Infosec fera ensuite en sorte de les présenter à Tom.
Différentes instances
Vous connaissez déjà ça avec les emails, qui fonctionnent sur le même principe. On a un îlot Gmail, un Outlook, un Yahoo, un Orange, un Free… et chaque entreprise créé le sien avec son propre nom.
Ok, mais c’est quoi le blocage d’une instance ?
Si Infosec choisit de bloquer entièrement Journa, alors elle ne traitera plus les nouveaux messages de cette dernière et n’y enverra plus les siens. On parle de défédérer une instance.
Cette procédure n’influera que sur l’instance qui réalise qui le blocage (Infosec) et les utilisateurs de cette dernière. L’instance ciblée (Journa) continuera à converser avec toutes les milliers d’autres instances du réseau.
Blocage d’une instance par une autre.
En réalité il y a un niveau intermédiaire qu’on appelle la mise sous silence.
Mastodon a trois flux : le flux personnel qui présente uniquement les abonnements, le flux local qui présente uniquement les messages locaux à l’instance, et le flux fédéré qui présente tous les messages reçus par l’instance.
La mise sous silence masque les contenus concernés dans le flux fédéré mais permet de recevoir des messages dans le flux personnel à condition de s’y être explicitement abonné.
C’est ce niveau de blocage intermédiaire (la mise sous silence) qui a été mis en œuvre par Infosec.
Mais pourquoi faire ça ?
La vraie réponse : Peu importe. Si tu choisis de ne pas écouter CNews chez toi, tu n’as pas à donner d’explication. C’est ton choix.
C’est la même chose pour l’instance Infosec et ses utilisateurs : Ils font ce qu’ils veulent chez eux.
Le plus souvent on bloque une instance quand elle est la source de spam, de harcèlements, ou de propos racistes, transphobes, handiphobes, pédopornographiques ou injurieux.
Chaque instance a ses propres sensibilités. Certaines tiennent à une liberté d’expression très large, d’autres préfèrent exclure la pornographie ou certains sujets pour créer un espace qui leur convient.
Certains préfèrent une modération légère quitte à subir parfois quelques contenus problématiques là où d’autres préfèrent une modération forte quitte à limiter certaines interactions externes légitimes.
C’est un choix local, qui ne concerne qu’eux.
Ici Infosec a jugé que certains propos venant de Journa étaient transphobes et les utilisateurs d’Infosec souhaitaient s’en protéger (c’est à dire ne plus les voir ni en assurer la transmission chez eux).
On bloque toute une instance et tous les utilisateurs pour un unique message problématique ?
Mastodon prévoit un moyen de signaler les propos gênants à l’instance d’origine. Le plus souvent les blocages d’instance interviennent quand l’instance d’origine (ici Journa) refuse d’agir, ou que le problème survient trop régulièrement.
Pour faire un parallèle, si je sais que CNews invite régulièrement des invités que je ne supporte pas, je peux préférer ne plus du tout regarder CNews pour m’en protéger, quitte à ne plus entendre certains autres invités qui seraient eux acceptables à mes yeux. Je n’interdis pas CNews, je choisis juste de ne pas diffuser cette chaîne dans mon salon.
J’avoue que sur ce sujet, si j’avais eu à modérer, avec une seule occurrence qui n’est qu’un partage d’un contenu d’un journal de référence, j’aurais mis sous silence uniquement l’utilisateur concerné et pas l’instance, mais ce n’est que mon choix lié à mes équilibres personnels.
Infosec a fait un autre choix, et il ne regarde qu’eux.
Pourquoi est-ce que Journa a refusé d’agir sur des propos transphobes ?
Les équilibres de liberté d’expression sont très subjectifs. Tous les pays n’ont déjà pas le même socle de base en interne. Les communautés peuvent en plus choisir d’aller au-delà de ce socle de base. Certaines le font, d’autres pas, et pas toujours sur les mêmes sujets.
Enfin, parfois il y a simplement désaccord sur ce qui est ou pas injurieux, ce qui est ou pas transphobe, ce qui est ou pas raciste, ce qui est ou pas un constitutif d’un harcèlement, etc.
Les communautés se regroupent autour de politiques, valeurs et cultures communes, mais n’ont pas forcément les mêmes que le voisin.
C’est ce qu’il se passe ici. Soit Journa a considéré que l’article du New York Times relayé était suffisamment étayé avec des avis de docteurs et chercheurs à propos des effets indésirables de certains traitements, soit Journa n’a pas agit en pensant que ce n’est pas son rôle de trancher une telle question et remettre en cause le New York Times.
D’autres personnes sur Infosec ont, elles, considéré que le contenu était transphobe et qu’il valait mieux bloquer l’instance si elle n’agissait pas pour empêcher la diffusion de contenus transphobes à l’avenir. Infosec a agit en fonction de ses propres utilisateurs, et ça ne regarde qu’eux (oui, je me répète mais c’est important).
Ça pose quand même un sacré problème de liberté d’expression, non ?
En fait, pas vraiment, pas beaucoup plus que tous les gens qui comme moi font le choix de ne jamais allumer la TV sur CNews.
Personne n’empêche les membres de Journa de s’exprimer, ou d’être entendu, ou même d’être relayé sur la très grande majorité des instances Mastodon.
Dans le schéma de tout à l’heure, le blocage est à la périphérie de l’instance Infosec et pas à la périphérie de l’instance Journa. Tant qu’Infosec n’est qu’un des très nombreux acteurs du réseau, ça ne pose pas de problème majeur.
Blocage d’une instance par une autre.
Les seuls pour qui il y aurait potentiellement un enjeu de liberté d’expression, ce sont les membres de l’instance d’Infosec.
Ahah ! Tu vois, tu le dis toi-même, il y a bien un problème pour eux !
Ça dépend. Si je participe à une association, qu’il y a une TV dans la salle de pause et qu’il a été décide que cette TV diffuserait Arte plutôt que CNews, est-ce une atteinte à la liberté d’expression parce que je ne peux pas y écouter les chroniqueurs de CNews ?
Probablement pas : Je peux encore écouter CNews chez moi, ou dans une autre association, ou même monter ma propre association qui aura des règles différentes. Cela ne commencera à être un problème que si ma capacité à aller voir ailleurs est limitée ou complexe, ou si on donne à l’association d’origine une autorité quelconque.
C’est exactement la même chose avec Infosec. Ses membres peuvent toujours aller lire Journa ailleurs avec un second compte, ou déménager leur compte principal sur une autre instance, ou même monter leur propre instance. Ajouter un second compte ou migrer ailleurs est facile, sans limite.
Non seulement personne ne bride l’expression des membres de Journa mais en plus personne ne limite la capacité à aller les lire facilement.
Pourtant tu disais toi-même que…
La question surgirait différemment si Infosec avait une situation de quasi-monopole, ou que toutes les instances bloquant Journa avaient en se regroupant une situation de quasi-monopole limitant de fait la capacité à accéder au contenu dont on parle.
Ce n’est pas le cas aujourd’hui.
Ce serait aussi un sujet pour un blocage litigieux réalisé de façon cachée. Ici l’administrateur d’Infosec a publié un billet sur le sujet et le fait même que j’en parle ici montre qu’on est loin de ce cas.
Ça pose au moins une question de démocratie interne d’Infosec
Pas à mon avis. Tout fonctionnement interne n’a pas forcément à être démocratique. C’est important pour un pays ou une collectivité territoriale parce qu’on ne choisit pas son pays d’origine et qu’on ne change pas facilement de pays ou de territoire.
La démocratie c’est « le pouvoir au peuple ». Sur Mastodon l’utilisateur a le pouvoir vu qu’il peut choisir à tout moment une instance avec des règles qui lui conviennent, sans avoir de conséquences négatives significatives.
C’est d’autant moins un sujet que le message de l’administrateur d’Infosec laisse entendre que ce sont des utilisateurs de l’instance qui l’ont fait agir et pas lui qui a pris la décision unilatéralement.
Mais alors il n’y a aucun problème ?
Il y a plein de problèmes, mais pas forcément des questions de liberté d’expression ou de démocratie, et pas forcément sur le cas Infosec – Journa.
Un premier problème est la transparence. Infosec a agi en transparence mais ce n’a pas toujours été lé cas de toutes les instances par le passé. Quand c’est transparent on fait nos choix, éventuellement on va voir ailleurs. Quand c’est caché ça veut dire manipuler l’information reçue et influencer des personnes sans qu’ils ne le sachent, et ça c’est déjà beaucoup plus litigieux.
La contrainte est un second problème. Ce ne semble pas le cas ici mais par le passé la menace de défédérer a été utilisée comme une pression pour forcer une autre communauté à changer ses propres règles et valeurs (« si tu ne bloques pas l’instance xxx alors on bloque ton instance aussi »). On est là dans une démarche où l’outil a été détourné pour devenir une arme plutôt qu’un bouclier.
Enfin, il y a un sujet si une instance ou un groupe d’instances peut avoir suffisamment de poids pour que ça devienne effectivement un sujet de liberté d’expression. C’est particulièrement le cas si on cumule avec le problème précédent. Là ça peut être aussi moche qu’un réseau centralisé, ou créer plusieurs sous-réseaux indépendants et qui ne communiquent pas entre eux.
Du coup le système de Mastodon est problématique ?
Oui, non, ça dépend de tes propres choix.
C’est juste qu’il n’y a pas de système parfait ni de façon universelle de positionner les équilibres entre les différents enjeux.
Le choix de Mastodon est un choix qui répond à des problèmes vus sur Twitter ou d’autres réseaux centralisés, qui ouvre d’autres possibilités et d’autres façons de penser les équilibres. C’est déjà pas mal.
Que peut-on améliorer ?
Inciter à plus de transparence à l’intérieur d’une instance, sur ce qui est bloqué globalement et pourquoi.
Refuser globalement les guerres de modération entre instances et les instances qui veulent contraindre les règles des autres (le « si tu ne bloques pas l’instance xxx alors on bloque ton instance aussi »)
S’assurer qu’aucune instance ne représente plus de 20% des utilisateurs actifs, et qu’un groupe d’instances ne devienne majoritaire au point de pouvoir devenir un problème.
Faire en sorte que jamais la procédure de déménagement de compte ne soit limitée, même en cas de blocage d’instance.
J’ai régulièrement le sentiment d’une avancée extraordinaire des pratiques et des outils en 15 ans.
Aujourd’hui on peut faire du travail à deux avec flux audio, vidéo, et code à quatre mains sur les mêmes fichiers.
Je peux suivre chacune des actions de mon collègue et suivre son déroulé en l’écoutant. Quand il parle d’une dépendance à changer je peux aller le faire en parallèle sans l’interrompre dans son avancée. Il voit ses tests passer au vert au fur et à mesure de mon travail annexe. Je peux à tout moment revenir vers ce qu’il fait si ce qu’il dit m’intéresse ou m’interroge, et il en est de même dans l’autre sens.
On alterne suivi et travail parallèle, sur le même code, avec la possibilité de se compléter pour éviter la charge mentale de « j’ai ça qu’il faudra que je fasse » et les micro-interruptions pour gérer toutes ces micro-tâches annexes.
Dites, est-ce moi qui suis dans la phase de sur-valorisation ou est-ce qu’on ne devrait plus travailler que comme ça ? (à distance en visio ou côte à côte à l’oral, peu importe).
J’ai l’impression de cumuler à la fois les avantages du pair programing et du travail en parallèle.
We found that people are not more hostile online than offline; that hostile individuals do not preferentially select into online (vs. offline) political discussions
New research suggests that the internet is not responsible for making people become more aggressive when engaging in political discussions online, but rather makes the behaviour of more aggressive people more visible.
Qui sont des vulgarisations de l’étude suivante :
we test the mismatch hypothesis but only find evidence for limited selection effects. Instead, hostile political discussions are the result of status-driven individuals who are drawn to politics and are equally hostile both online and offline. Finally, we offer initial evidence that online discussions feel more hostile, in part, because the behavior of such individuals is more visible online than offline.
Une donnée accessible dans l’espace public n’est pas une donnée libre d’utilisation
Il y a le droit d’auteur, le droit des bases de données, les règles d’utilisation des données personnelles, le cas spécifique des informations appartenant à l’État, et probablement bien d’autres choses.
La licéité de l’information ou de certains usages de l’information n’entraine pas celle d’un autre usage de cette même information
C’est particulièrement vrai pour tout ce qui est données personnelles, où chaque traitement et chaque finalité est indépendante des autres.
C’est vrai aussi de manière générale : Que la donnée soit utilisable dans certains cas n’implique pas que tout ce que vous en ferez sera forcément légitime, ni moralement ni légalement.
J’aime beaucoup Simon Willison depuis des années. Il tient un carnet de notes en guise de blog, comme j’aurais longtemps voulu avoir le courage de faire.
When caching the result of an expensive computation or a network call, don’t actually cache the result, but cache the promise that awaits the result.
This way, if a new, uncached key gets requested twice in rapid succession, ie faster than the computation takes, you avoid computing/fetching the same value twice. […] In other words, the promise acts as a mutex around the computation, and the resulting code is understandable even by people unfamiliar with mutexes, locks and so on.
Hier j’ai corrigé un test technique d’un candidat ayant 55 ans. Un des plus beaux tests que j’ai pu voir.
– BORING code, clair, concis, efficace, très compréhensible
– pas d’over archi, pas de démonstration technique, straight to the point
– tous les use case testés, le bon algo sélectionné et implémenté
Et … rien de plus à dire ! Et c’est LE point ! Le plus compliqué en dev, c’est de faire des choses simples.
Là, c’est un gros ✅
Sur un groupe de CTO, 17 juin 2022
Je ne saurais confirmer trop fort ce message. Comprendre les motifs habituels d’architecture c’est important mais c’est un outil dans la trousse, pas l’objectif.
Ben oui, c’est bien joli de dire que les données sont sécurisées parce que chiffrées, mais ça veut tout et rien dire.
Petite analogie avec des bijoux et un coffre-fort qu’on va considérer inviolable pour l’exercice.
Chiffrement au repos
La banque vous offre un coffre-fort personnel pour vos bijoux à la banque. Ils sont super sécurisés, personne ne peut forcer le coffre.
Bon, par contre c’est le personnel de la banque qui a la clef de tous les coffres, le votre aussi. Ce sont eux qui vont chercher vos bijoux, accéder à la salle des coffres, ouvrir le coffre, et vous les ramener au guichet à chaque vous que vous voulez y accéder.
La banque sait exactement ce que vous stockez et comment vous y accéder. En fait c’est même elle qui stocke et qui accède. Elle peut voler ou copier le contenu. Un salarié de la banque peut accéder à ce même contenu ou le voler s’il arrive à mettre la main en interne sur la clef du coffre. Un voleur tiers pourrait réussir à profiter d’une faille dans les procédures de la banque et faire un braquage qui lui permet d’accéder à la fois aux clefs et aux coffres, et voler ou copier vos bijoux. Enfin, peut-être que la banque ou un de ses prestataire seront négligents, et laisseront traîner n’importe où la clef, ou un double de celle-ci, ou même vos bijoux avant de vous les remettre.
Bref, c’est mieux que rien (il y a un coffre), mais tout repose dans la confiance en la banque, en sa sécurité, en ses employés.
Chiffrement en transit
Quand la banque vous donne accès aux bijoux, elle vous les livre chez vous. Pour ça elle utilise un petit coffre-fort dont vous avez échangé les clefs à l’avance. La banque en a une copie, la seconde est entre vos mains. Personne d’autre ne peut ouvrir le coffre en l’état actuel des technologies pour peu que ni vous ni la banque ne laisse traîner les clefs.
Vos bijoux restent accessibles à la banque. La banque sait ce qu’elle vous envoie. Elle peut les examiner à loisir, voire les voler ou les copier à ce moment là. Plusieurs employés de la banque peuvent faire de même, pour plein de raisons légitimes différentes. Certains pourraient profiter de failles dans les processus internes pour y accéder de façon illégitime. Un braqueur pourrait toujours avoir accès à vos bijoux s’il braque la banque.
Enfin, peut-être que la banque ou un de ses prestataire seront négligents, et laisseront traîner n’importe où la clef, ou un double de celle-ci, ou même vos bijoux avant de vous les remettre. Peut-être que vous-même aurez laissé votre exemplaire de votre clef dans votre appartement privé non sécurisé et que quelqu’un pourra y accéder.
Bref, c’est indispensable (on ne va pas vous envoyer vos bijoux dans un carton standard par La Poste) mais ça ne « sécurise » pas totalement vos bijoux pour autant.
Chiffrement au repos et en transit
Bien évidemment votre banque est sérieuse, elle s’occupe donc du stockage et du transit.
Sauf qu’au final c’est quand même la banque qui va accéder et ouvrir votre coffre à la banque, prendre les bijoux, puis les stocker dans le coffre qui sert à l’envoi. Au passage elle les manipule directement sans protection, par exemple pour les nettoyer.
La banque a toujours total accès à vos bijoux, pour savoir lesquels est-ce, les copier, les dégrader ou les voler si elle n’est pas de bonne foi. Plusieurs employés de la banque ont accès directement ou indirectement à ces bijoux, pour des raisons légitimes. Certains pourraient être de mauvaise foi. D’autres employés pourraient abuser certaines faiblesses dans les procédures de sécurité pour y accéder malicieusement aussi. Un braqueur pourrait accéder à la banque et récupérer les bijoux ou les clefs, ou les deux à la fois. Des prestataires pourraient avoir une copie des clefs, ou les laisser trainer. Des employés pourraient être négligents.
Bref, on protège avec des coffres mais le principal reste : Il faut faire confiance à la banque, à ses employés, à ses prestataires, à la robustesse des procédures de sécurité.
Chiffrement de bout en bout
Vous avez un coffre, que vous avez acheté dans une boutique de confiance ou construit de vos propres mains. La boutique de confiance peut être votre banque mais pourrait aussi être un tiers, ou une banque concurrente.
Seul vous en avez les clefs. Vous stockez vos bijoux dedans, donnez le coffre fermé au transporteur. La banque stocke votre coffre tel quel, sans pouvoir l’ouvrir, en inspecter le contenu, le copier ou le voler. Quand vous voulez accéder à vos bijoux, on vous rend votre coffre et c’est à vous de l’ouvrir. Personne n’a pu voir vos bijoux, ou même savoir si ce sont vraiment des bijoux.
La banque n’a plus accès à rien. Vous n’avez pas besoin de lui faire confiance. Tout au plus elle peut perdre votre coffre mais personne ne pourra accéder au contenu tant que vous n’en perdez pas les clefs (*). C’est par contre à vous de vous assurer de garder les clefs dans un endroit sûr, et d’acheter le coffre à un tiers de confiance qui n’en garde pas les doubles.
Pour accéder à vos bijoux il faudra cependant vous braquer vous (ou que le vendeur du coffre ait été fautif au point de garder un double des clefs et qu’il se fasse braquer lui) et ensuite aller braquer la banque pour accéder au coffre. C’est possible mais ça commence à être bien plus limité.
Bien évidemment, vous êtes toujours sujet à un braquage chez vous, une fois le coffre ouvert, mais ça la banque n’y pourra jamais rien.
(*) Point sensible : Si le coffre est inviolable et que vous perdez vos clefs, plus personne ne pourra vous aider à récupérer vos bijoux. Ils seront perdus à jamais pour tout le monde. La sécurité complète c’est à double tranchant. Il y a des solution à ce problème, des bonnes et des mauvaises, mais c’est un sujet à part entière.
Conseil CSS : utilisez `font-variant-numeric: tabular-nums;` pour aligner soigneusement les nombres dans un tableau, des compteurs de progression, etc.
