J'ai cru comprendre en lisant en diagonal que c'est pas 3 ans après le commit, mais 3 années après une release qui est dans le fichier de licence (ou 4 ans après une version spécifique).
Ensuite, la licence est vraiment mal fagoté je trouve.
La licence BSL balance "production use" et "non production use" sans vraiment définir le terme.
Car bon, pour un système de CI/CD, l'instance de jenkins et ses tests qui aboutissent au déploiement, c'est un usage en production. Si ton pipeline de déploiement est cassé et que quelqu'un est chargé de réparer ça, pour moi, c'est de la prod (ça produit quelque chose, c'est dans le nom).
Et donc, qui va vouloir faire une bibli qui utilise akka ou se connecte sur akka dans ces conditions alors qu'il y a une incertitude juridique parce que la licence est mal écrite ?
Et surtout, surtout : bordel, pourquoi est-ce-que ça doit prendre tant de place ?
Parce que c'est fait par le presta qui a proposé la presta la moins cher en prenant soit des gens qui sont en cours d'apprentissage (enfin, comme nous tous), ou a qui on a donné juste le temps qu'il faut avant les remettre sur un autre projet.
En même temps, je pense que le pneu ne va pas trop s'user dans l'espace (ou du moins, pas comme sur terre), donc c'est sans doute faisable (sauf si le plan est de construire une autoroute).
Ensuite, on pourrait aussi simplement demander aux devs de baisser leur salaire si on veut réduire l'inflation à ce niveau, mais on me dit que ça serait sans doute pas une mesure populaire.
ok, du coup tu dirais quoi? (puisque bon, BIOS corrompu ==
plein de complications pénibles à gérer ensuite)
Un BIOS corrompu (l'exemple du virus CIH de 1998 me vient en tête), ça serait comme du matos qui tombe en panne, sauf qu'on peut le réparer en reflashant.
Mais on peut imaginer pareil en terme de dégat sur le firmware du disque dur. En fait, c'est pire parce qu'un disque dur corrompu, ça va me coûter plus qu'un BIOS corrompu, vu que je peux changer la carte mère et voila. Sortir les données d'un disque foutu, ça coûte un chouia plus cher.
C'est pas le BIOS. L'iLO tourne sur un processeur à part sur une carte à part avec un OS à part (voir quasiment un Linux embarqué).
Je veux bien qu'on compte ça dans le BIOS sous le prétexte que ça vient avec le matériel dans ton serveur, mais ça serait un abus de langage.
Ensuite, si tu parles de la fonctionnalité équivalente pour les proc intel (eg, AMT), ça vient avec le processeur, pas avec le BIOS. Encore une fois, je veux bien qu'on compte tout qui est avant grub comme "le BIOS" mais ça serait toujours un abus de langage.
Est ce que le BIOS est plus sensible que le processeur ?
Je pense que non (et c'est pour ça aussi que je dit que le BIOS n'est pas le plus sensible en terme de sécurité), mais si on dit "le BIOS est le plus sensible en terme de sécurité", alors le processeur l'est moins. Et c'est pas ce que je voit vu le foin autour des procs intels.
Ensuite, si l'affirmation est "le plus sensible en terme de sécurité, c'est le matériel", l'omniprésence de matériel et/ou de firmware non libre me laisse croire que c'est pas si sensible que ça par rapport au logiciel.
Le matos est la, il est en vente, mais pourtant, j'ai pas le sentiment que ça se bouscule pour acheter (vu qu'il n'y a que Leah sur le coup depuis des années).
Le paranoïaque est il le seul à penser l'être suffisamment?
Je sais pas, je suis pas psychologue, faut aller voir le DSM.
"pas le plus sensible", ça veut pas dire "on s'en balek".
Ça veut juste dire que dans un classement, c'est pas en haut.
La preuve, pendant des années, on a pas eu de mécanismes simples de mises à jour du BIOS ou de l'UEFI (eg, fwupdate sous Linux), et que je sache, on a pas eu d'apocalypse, et que je voudrais bien dire "le nombre de souci de sécurité lié à un souci dans le BIOS se compte sur les doigts d'une main", mais j'ai rien qui me vient à l'esprit.
À coté de ça, on a eu plus de gens qui ont eu des soucis à cause des certificats et du manque de TLS, on eu plus de souci suite à des soucis de crypto (la faille openssh de debian en 2008), etc.
Ensuite, si tu veux éviter le homebrew sur ton matériel, oui. si tu es Google, Amazon ou Nintendo ou n'importe qui qui veut controler le matériel face à ses users, oui, il te faut un BIOS blindé.
Dans une console de jeux, le BIOS va importer à mort. Mais que je sache, on parle pas de ça ici. Et non seulement on parle pas de ça, mais en plus, si on en parle, on va en parler pour la perte de liberté que ça entraîne (eg, secureboot par défaut sur les trucs ARM, etc).
Primo, c'est un rootkit UEFI. Techniquement, c'est pas du BIOS, mais je vais pas jouer sur les mots. Mais surtout, la présence d'un rootkit possible est assez séparé de la question de la sécurité.
Pour utiliser ce genre de rootkit, tu as 2 choix.
Le premier, c'est un accès physique avec assez de temps pour installer le rootkit. C'est assez spécifique, mais si tu peux reflasher la puce mémoire, alors on peut supposer que tu peux installer le rootkit en question, et c'est indépendant du code du BIOS/UEFI et de sa sensibilité vu qu'il va se faire écraser et/ou augmenter.
eg., ce qui est sensible, c'est pas le BIOS/UEFI mais la carte mère (et le fait d'accepter des BIOS/UEFI non signé, ou signé par des clés qu'on peut trouver facilement, etc)
L'autre choix, c'est de flasher depuis l'OS. La, on peut avoir une discussion sur savoir si c'est plus sur de ne pas pouvoir remplacer un logiciel (car en read-only dans une ROM) sachant que ça implique aussi de ne pas pouvoir le patcher en cas de pépin. Mais pareil, le fait de flasher ou pas n'est pas aussi important que le fait que ça implique d'avoir une faille avant pour exécuter du code ce qui rends à mon sens l'userspace plus sensible.
Si j'ai uniquement une faille userspace, je peux te voler des infos, avec ou sans faille dans le BIOS/UEFI. Si j'ai qu'une faille UEFI/BIOS, bah, je suis quand même bien coincé en tant qu'attaquant.
La, l'exemple parle d'une attaque sur le firmware, mais à part la persistance qui se fait au niveau de l'UEFI, il n'y a rien de spécial qui va montrer que l'UEFI est le plus sensible. Si je fais un implant qui persiste via cron, est ce que crond devient "le plus sensible en terme de sécurité" ?
Même si le code de l'UEFI était blindé à mort avec 5 signatures incassables et 0 failles de sécurité, ç'est un implant qui est transmis par le fabricant. Tu peux pas faire grand chose contre ça, et ça marcherais aussi bien avec un pilote d'imprimante ou n'importe quoi d'autre.
Du coup, je suis pas sur de piger exactement le point que tu cherches à démontrer par ton lacunaire Ahem.
La, par exemple, je pense que le fabricant est plus sensible en terme de sécurité que le BIOS d'une machine, surtout parce que le fabriquant s'est fait poutré et que ce genre d'attaques arrivent, alors que des attaques sur le BIOS (ou l'UEFI), y en a 0.
Et un implant, c'est pas une attaque. Pas plus que mettre un rootkit serait une attaque sur le kernel, sur une distro ou sur le projet GNU.
Mais je suis d'accord sur la 2eme partie de ton commentaire.
En effet, tout le monde peut se tromper, mais je pense tu n'avais pas besoin d'en fait la démonstration par l'exemple avec ton début de commentaire.
En fait, je pense pas qu'il y a un arrangement explicite.
Comme dit ailleurs, c'est de l'apprentissage avec du machine learning. Et si en effet, en moyenne, le fournisseur voit que les mails venant de ton range chez Belgacom, c'est surtout des virus et du spam, et qu'il y a 1 personne avec son serveur qui envoie un mail de temps en temps, les maths sont contre elle.
J'ai le même souci avec mon VPN pour l'IP v6. Je me fait régulièrement bloqué (ou je me prends des captchas) parce que je passe par digital ocean pour ça. Si j'avais mis le VPN sur la connexion de chez moi, je suis sur que j'aurais 0 soucis.
Par contre je ne pense pas que ce soit le spam qui favorise
l’émergence d'acteurs dominants ; tant qu'on est sur du libre,
les informations transitent, et les petits sont aussi armés que
les gros pour lutter contre le spam
Alors je ne pense pas que c'est le spam qui fait qu'on va chez un gros acteur.
Mais avoir 1 acteur avec 100 000 boites mails , ou 1000 acteurs avec 100 boites mails, ça change la donne.
Déjà, les 1000 acteurs, ça implique (pour simplifier) d'avoir 1 admin par acteur. L'acteur avec 100 000 boites mails, à ressources égales, il va se retrouver avec 1000 admins. Si on suppose que ça ne croit pas de manière linéaire et qu'on peut fire 100 000 boites mails avec 100 admins, alors l'acteur dominant va avoir plus de ressources pour lutter contre le spam (les 900 personnes), et il peut faire des choses que les plus petits ne peuvent pas.
Par exemple, il a une vue sur plus d'opérations, il va recevoir plus de spam et/ou plus vite, ce qui permet de réagir plus vite et donc d’arrêter plus vite, ce qui diminue le nombre de spam par utilisateurs.
En dehors de ses capacités, un acteur dominant a un avantage pour la lutte contre le spam.
Et tu parles d'avoir les informations qui transitent, mais il n'y a rien qui transite à part des DNSBL qui n'ont rien de libre ou d'ouvert.
Les systèmes modernes des GAFAMs se basent sur l'apprentissage statistique de la réputation des serveurs, mais ça ne marche que si tu as beaucoup de mail. Moi, avec mon serveur perso, je vais pas faire grand chose à ce niveau si j'ai 1 mail par jour.
Ce qui pourrait être fait pour les mails aussi, de façon assez trivial en fait.
C'est une des idées proposé par hey.com, et une qui peut se faire chez soi avec un peu de code.
Par exemple, tu envoies tout les mails ailleurs que dans ta inbox, sauf si le mail est dans une liste spécifique. Tu peux ensuite déplacer un email dans un dossier spécial pour déclencher le changement du filtre et le déplacement des emails qui correspondent vers la inbox.
Si c'était la solution, alors quelqu'un d'autre que Hey le proposerait. Mais visiblement, ça ne suffit pas.
Un point qui me semble revenir rarement est la question des autres fédérations. Par exemple, XMPP, Matrix, et tout ce qui tourne à ActivityPub.
Le protocole SMTP de base a plein de souci. Mais une fois qu'on rajoute DKIM, SPF, etc, le probléme du spam persiste.
Pour le moment, les autres protocoles fédérés sont épargnés en partie parce que relativement personne (à l'échelle de la planète) ne les utilisent pour le moment.
Est ce qu'il ne faut pas se poser la question de se dire ce qui devrait être fait avant qu'on refasse la même chose que l'email ?
Ou est ce qu'il faut juste accepter que c'est inéluctable et que ça vient avec le fait d'avoir du succès, donc du monde, donc des problèmes d'échelle qui entraîne l'ossification du protocole et l’émergence d'acteurs dominants.
C'est possible, mais ça ne posait pas de souci avec un autre opérateur (celui d'avant, et celui d’après aussi). Et mes collègues se plaignaient aussi du réseau chez eux (et moi aussi, c'est comme ça que j'ai su pour les femtocells).
C'est con, mais ça aide d'avoir du réseau pour recevoir les alertes nagios.
Certes mais ce n'était qu'un exemple. Le reste du logiciel est pareil. Prenons par exemple et justement l'action de modifier la barre d'outils.
C'est dans préférence, barre d'outils et de menu. C'est facile à trouver, mais quand on clique sur ça, on arrive sur une fenetre quasiment vide avec une liste déroulante.
Primo, le premier item "cliquer pour choisir la barre d'outils…" est un des choix possibles, alors qu'à mon sens, ça devrait être un label avec un choix par défaut (un clic de moins pour éditer).
Ensuite, choisir les éléments via leur nom, c'est pas exactement l'UX la plus intuitive, surtout quand tu as 2 réglages suivant la présence ou pas d'une liseuse branché, et ça me parait une magouille dans le code pour faire apparaître le bouton d'opération sur la liseuse la ou je pense qu'une bonne pratique, c'est d'avoir un bouton grisé quand rien n'est branché. Pour moi, ça serait comme avoir libreoffice avec 2 choix "document à sauver / document sans modification", pour cacher l’icône de sauvegarde
Ça mentionne une "seconde barre d'outil optionnel", d’où est ce qu'elle vient, quelle sont ses réseaux ? Il y aussi le "menu contextuelle pour la liste de livres divisées", je suppose que c'est le menu qui s'affiche pour clic droit, mais à quel moment (sachant qu'il y a toujours une liste de livre, donc qu'est ce qui est divisé) ?
C'est pas que le logiciel n'est pas utilisable, et j'ai vu largement pire.
Mais tout a un coté baroque.
Mon dernier exemple, quand tu va dans les préférences, tu peux fermer une fenêtre via la croix en haut. Sauf que la croix agit comme "retour arrière", vu que tu reviens à la fenêtre d'avant.
Il y a spécifiquement une surcharge d'un comportement par défaut d'un élément d'interface compris depuis les premiers macs.
Ça me fume un peu. Ensuite, c'est sans doute les séquelles de mes années à faire de l'ergonomie.
Ensuite, le souci de Calibre, c'est que son UX a tendance à faire des miracles. Pas des miracles comme faire marcher les cul de jattes, plus des miracles comme faire saigner des statues par les yeux (en tout cas, c'est l'effet que ça me fait, et je suis loin d'être un saint).
Par exemple, l'ordre des icônes dans le menu est assez (on m'excuseras le jeu de mot) orthodoxe.
"Convertir le livre" n'est pas à coté de "Éditer le livre", alors que fondamentalement, ça reste proche. Le bouton d'aide, traditionnellement à la fin des menus, est au milieu.
De même, "éditer le livre" est à l'opposé d'"éditer le livre".
Les widgets utilisés sont assez curieux, car c'est des boutons / menus, et je ne sais pas pourquoi "éditer le livre" et "connecter / partager" sont des menus sans la flèche qui réagissent comme les autres boutons.
Je ne pige pas pourquoi il y a une icône "visualiser" alors que tu as déjà un moyen de faire ça en double cliquant sur un livre, ou en cliquant et en regardant le résumé à droite.
Je suis content que Calibre existe, mais j'ai un peu le sentiment de me trimballer avec une cilice comme dans Da Vinci Code chaque fois que je l'utilise, sans doute pour expier mes crimes de téléchargements illégaux.
Après concernant les frais de port, y'a moyen pour que tu sois
condamné à payer cher, si c'est un envoi à l'unité d'un livre
volumineux et lourd.
Les frais de port sur Amazon n'avaient pas l'air aussi faramineux. Je viens d'aller voir, ça serait $11.30 aujourd'hui pour ~ 16 ounces, soit 450 grammes. Par comparaison, le premier O Reilly que j'ai trouvé sur ma bibli fait 1.25 pounds soit 560 grammes. C'est sur que c'est plus gros qu'un livre de poche, mais ça me parait raisonnable.
Ensuite, comme dit plus haut, je ne veux pas commander sur Amazon, ni me faire livrer chez moi (car j'ai pas envie que mon adresse physique traîne partout, suite à des soucis de stalking (aussi bien moi que mon coloc)), donc j'essaye de prendre en magasin (et payer en cash aussi, j'ai vu Seven, je veux pas prendre de risque).
Ceci dit, je réalise que j'aurais pu me faire livrer au boulot comme pour le matos informatique.
Même si on a un téléphone, quand on est à l'étranger dans un
pays où on n'a pas de mobile (je sais que c'est de plus en plus
rare avec les abonnements actuels, mais quand-même), on peut se
trouver coincé à ne pas pouvoir effectuer de paiement.
Ou alors, quand ça ne capte pas. La maison des parents de mon coloc, ou on a passé une partie des vacances, est dans un endroit fort peu desservi par les ondes (en partie à cause des murs, en partie à cause de la géographie, en partie parce qu'il y a personne).
Donc pour faire des opérations bancaires, j'ai du aller dehors vers la route la plus proche pour recevoir mon SMS de vérification. Et pourtant, c'était pas perdu au milieu de la Creuse ou du Vercors, il y a un train vers Paris.
Dans le mesure ou les 2 sont présentés comme des absolus qui se contredisent, sans doute que si.
La distinction pirate vs grand public est assez artificielle. Ma soeur est capable de choper un livre pirate sur le web ou de choper matlab avec 250 000€ d'extensions pour son master de finance sans mon aide. Mon coloc (bibliothécaire) arrive sans doute mieux que moi à choper des films pirates (sans doute parce qu'il ne s'impose pas de lancer un client torrent en CLI sur un serveur distant).
Et pourtant, ayant du faire du support pour leurs machines respectives, je sais qu'ils sont loin d'être différent des commerciaux pour qui j'ai du faire le support au travail (genre par exemple, les commerciaux à qui je doit expliquer que non, faut pas laisser tourner deluge quand tu es au bureau, et que oui, non seulement l'équipe sécu l'a vu, mais en plus, elle te juge d'avoir pris "Camping 3 HD")
Une autre option, c'est aussi d'acheter le livre avec DRM et de faire sauter le DRM en question (ou de trouver une version sans DRM en dehors d'une boutique officielle)
Je n'ai pas testé, mais on trouve des tas de tutos plus ou moins bons pour faire ça avec Calibre.
Les 2 sont des logiciels libres, et il y a une communauté assez active sur MobileRead. Ensuite, ça dépend du degré d'ouverture de la liseuse, certaines (Kindle) sont plus fermés que d'autres, et certaines sont très largement bidouillable (par exemple, Kobo, mais sans doute d'autres).
Les sites (en l’occurrence libgen et son clone Z-library, mais aussi sci-hub) sont en général référencé sous d'autres noms de domaines non bloqués et qui sont disponible sur des forums Reddit, sur les pages Wikipedia des projets, et parfois accessibles via des sites qui servent uniquement à faire des redirections (donc moins facilement bloqué).
Z-lib est aussi dispo via un service en .onion qui est théoriquement difficilement censurable.
La base de Z-library fait 220 T d'après Wikipedia (et il y a des tas de doublons), et les plus gros disques dur du moment font dans les 20T, sauf erreur de ma part.
Je pense qu'on se rapproche assez rapidement du moment ou il sera possible de faire tenir tout les epub/pdf piratés du monde dans un disque dur à un prix accessible au grand public, et je pense que ça risque d'être un moment intéressant pour la connaissance.
D'ailleurs, il y a des discussions sur le sujet, comme le fait de filtrer libgen par taille de fichiers, ou l'annonce récente d'un projet visant à faire une copie de z-library afin de mettre ça dans libgen.
[^] # Re: noyage de poisson
Posté par Misc (site web personnel) . En réponse au lien Akka devient privateur. Évalué à 5.
J'ai cru comprendre en lisant en diagonal que c'est pas 3 ans après le commit, mais 3 années après une release qui est dans le fichier de licence (ou 4 ans après une version spécifique).
Ensuite, la licence est vraiment mal fagoté je trouve.
# "Production use"
Posté par Misc (site web personnel) . En réponse au lien Akka devient privateur. Évalué à 7.
La licence BSL balance "production use" et "non production use" sans vraiment définir le terme.
Car bon, pour un système de CI/CD, l'instance de jenkins et ses tests qui aboutissent au déploiement, c'est un usage en production. Si ton pipeline de déploiement est cassé et que quelqu'un est chargé de réparer ça, pour moi, c'est de la prod (ça produit quelque chose, c'est dans le nom).
Et donc, qui va vouloir faire une bibli qui utilise akka ou se connecte sur akka dans ces conditions alors qu'il y a une incertitude juridique parce que la licence est mal écrite ?
[^] # Re: noyage de poisson
Posté par Misc (site web personnel) . En réponse au lien Akka devient privateur. Évalué à 7.
Attendre 3 ans avant d'avoir le correctif d'un CVE, c'est sur que la version libre va être utile.
# Facile
Posté par Misc (site web personnel) . En réponse au journal Sobriété, j'écris ton nom. Évalué à 10.
Parce que c'est fait par le presta qui a proposé la presta la moins cher en prenant soit des gens qui sont en cours d'apprentissage (enfin, comme nous tous), ou a qui on a donné juste le temps qu'il faut avant les remettre sur un autre projet.
[^] # Re: Et en même temps…
Posté par Misc (site web personnel) . En réponse au lien EU regulators want 5 years of smartphone parts, much better batteries - OSnews. Évalué à 5.
En même temps, je pense que le pneu ne va pas trop s'user dans l'espace (ou du moins, pas comme sur terre), donc c'est sans doute faisable (sauf si le plan est de construire une autoroute).
[^] # Re: Trackers ?
Posté par Misc (site web personnel) . En réponse au lien Comment rendre les applications moins énergivores ?. Évalué à 2.
En fait, de gagner de l'argent, oui.
Ensuite, on pourrait aussi simplement demander aux devs de baisser leur salaire si on veut réduire l'inflation à ce niveau, mais on me dit que ça serait sans doute pas une mesure populaire.
[^] # Re: Fauxpensource et libriste en carton ?
Posté par Misc (site web personnel) . En réponse au lien Windows prohibé chez Gitlab !!!. Évalué à 2.
Un BIOS corrompu (l'exemple du virus CIH de 1998 me vient en tête), ça serait comme du matos qui tombe en panne, sauf qu'on peut le réparer en reflashant.
Mais on peut imaginer pareil en terme de dégat sur le firmware du disque dur. En fait, c'est pire parce qu'un disque dur corrompu, ça va me coûter plus qu'un BIOS corrompu, vu que je peux changer la carte mère et voila. Sortir les données d'un disque foutu, ça coûte un chouia plus cher.
Et le firmware d'un disque, ça peut s'attaquer
C'est pas le BIOS. L'iLO tourne sur un processeur à part sur une carte à part avec un OS à part (voir quasiment un Linux embarqué).
Je veux bien qu'on compte ça dans le BIOS sous le prétexte que ça vient avec le matériel dans ton serveur, mais ça serait un abus de langage.
Ensuite, si tu parles de la fonctionnalité équivalente pour les proc intel (eg, AMT), ça vient avec le processeur, pas avec le BIOS. Encore une fois, je veux bien qu'on compte tout qui est avant grub comme "le BIOS" mais ça serait toujours un abus de langage.
Est ce que le BIOS est plus sensible que le processeur ?
Je pense que non (et c'est pour ça aussi que je dit que le BIOS n'est pas le plus sensible en terme de sécurité), mais si on dit "le BIOS est le plus sensible en terme de sécurité", alors le processeur l'est moins. Et c'est pas ce que je voit vu le foin autour des procs intels.
Ensuite, si l'affirmation est "le plus sensible en terme de sécurité, c'est le matériel", l'omniprésence de matériel et/ou de firmware non libre me laisse croire que c'est pas si sensible que ça par rapport au logiciel.
Le matos est la, il est en vente, mais pourtant, j'ai pas le sentiment que ça se bouscule pour acheter (vu qu'il n'y a que Leah sur le coup depuis des années).
Je sais pas, je suis pas psychologue, faut aller voir le DSM.
[^] # Re: Fauxpensource et libriste en carton ?
Posté par Misc (site web personnel) . En réponse au lien Windows prohibé chez Gitlab !!!. Évalué à 3.
"pas le plus sensible", ça veut pas dire "on s'en balek".
Ça veut juste dire que dans un classement, c'est pas en haut.
La preuve, pendant des années, on a pas eu de mécanismes simples de mises à jour du BIOS ou de l'UEFI (eg, fwupdate sous Linux), et que je sache, on a pas eu d'apocalypse, et que je voudrais bien dire "le nombre de souci de sécurité lié à un souci dans le BIOS se compte sur les doigts d'une main", mais j'ai rien qui me vient à l'esprit.
À coté de ça, on a eu plus de gens qui ont eu des soucis à cause des certificats et du manque de TLS, on eu plus de souci suite à des soucis de crypto (la faille openssh de debian en 2008), etc.
Ensuite, si tu veux éviter le homebrew sur ton matériel, oui. si tu es Google, Amazon ou Nintendo ou n'importe qui qui veut controler le matériel face à ses users, oui, il te faut un BIOS blindé.
Dans une console de jeux, le BIOS va importer à mort. Mais que je sache, on parle pas de ça ici. Et non seulement on parle pas de ça, mais en plus, si on en parle, on va en parler pour la perte de liberté que ça entraîne (eg, secureboot par défaut sur les trucs ARM, etc).
[^] # Re: Fauxpensource et libriste en carton ?
Posté par Misc (site web personnel) . En réponse au lien Windows prohibé chez Gitlab !!!. Évalué à 2.
Primo, c'est un rootkit UEFI. Techniquement, c'est pas du BIOS, mais je vais pas jouer sur les mots. Mais surtout, la présence d'un rootkit possible est assez séparé de la question de la sécurité.
Pour utiliser ce genre de rootkit, tu as 2 choix.
Le premier, c'est un accès physique avec assez de temps pour installer le rootkit. C'est assez spécifique, mais si tu peux reflasher la puce mémoire, alors on peut supposer que tu peux installer le rootkit en question, et c'est indépendant du code du BIOS/UEFI et de sa sensibilité vu qu'il va se faire écraser et/ou augmenter.
eg., ce qui est sensible, c'est pas le BIOS/UEFI mais la carte mère (et le fait d'accepter des BIOS/UEFI non signé, ou signé par des clés qu'on peut trouver facilement, etc)
L'autre choix, c'est de flasher depuis l'OS. La, on peut avoir une discussion sur savoir si c'est plus sur de ne pas pouvoir remplacer un logiciel (car en read-only dans une ROM) sachant que ça implique aussi de ne pas pouvoir le patcher en cas de pépin. Mais pareil, le fait de flasher ou pas n'est pas aussi important que le fait que ça implique d'avoir une faille avant pour exécuter du code ce qui rends à mon sens l'userspace plus sensible.
Si j'ai uniquement une faille userspace, je peux te voler des infos, avec ou sans faille dans le BIOS/UEFI. Si j'ai qu'une faille UEFI/BIOS, bah, je suis quand même bien coincé en tant qu'attaquant.
La, l'exemple parle d'une attaque sur le firmware, mais à part la persistance qui se fait au niveau de l'UEFI, il n'y a rien de spécial qui va montrer que l'UEFI est le plus sensible. Si je fais un implant qui persiste via cron, est ce que crond devient "le plus sensible en terme de sécurité" ?
Même si le code de l'UEFI était blindé à mort avec 5 signatures incassables et 0 failles de sécurité, ç'est un implant qui est transmis par le fabricant. Tu peux pas faire grand chose contre ça, et ça marcherais aussi bien avec un pilote d'imprimante ou n'importe quoi d'autre.
Du coup, je suis pas sur de piger exactement le point que tu cherches à démontrer par ton lacunaire Ahem.
La, par exemple, je pense que le fabricant est plus sensible en terme de sécurité que le BIOS d'une machine, surtout parce que le fabriquant s'est fait poutré et que ce genre d'attaques arrivent, alors que des attaques sur le BIOS (ou l'UEFI), y en a 0.
Et un implant, c'est pas une attaque. Pas plus que mettre un rootkit serait une attaque sur le kernel, sur une distro ou sur le projet GNU.
Mais je suis d'accord sur la 2eme partie de ton commentaire.
En effet, tout le monde peut se tromper, mais je pense tu n'avais pas besoin d'en fait la démonstration par l'exemple avec ton début de commentaire.
[^] # Re: Des oublis
Posté par Misc (site web personnel) . En réponse au lien Self-Hosted email is the hardest it's ever been, but also the easiest.. Évalué à 3.
En fait, je pense pas qu'il y a un arrangement explicite.
Comme dit ailleurs, c'est de l'apprentissage avec du machine learning. Et si en effet, en moyenne, le fournisseur voit que les mails venant de ton range chez Belgacom, c'est surtout des virus et du spam, et qu'il y a 1 personne avec son serveur qui envoie un mail de temps en temps, les maths sont contre elle.
J'ai le même souci avec mon VPN pour l'IP v6. Je me fait régulièrement bloqué (ou je me prends des captchas) parce que je passe par digital ocean pour ça. Si j'avais mis le VPN sur la connexion de chez moi, je suis sur que j'aurais 0 soucis.
[^] # Re: Quid des autres federations ?
Posté par Misc (site web personnel) . En réponse au lien After self-hosting my email for twenty-three years I have thrown in the towel. The oligopoly has won. Évalué à 5.
Alors je ne pense pas que c'est le spam qui fait qu'on va chez un gros acteur.
Mais avoir 1 acteur avec 100 000 boites mails , ou 1000 acteurs avec 100 boites mails, ça change la donne.
Déjà, les 1000 acteurs, ça implique (pour simplifier) d'avoir 1 admin par acteur. L'acteur avec 100 000 boites mails, à ressources égales, il va se retrouver avec 1000 admins. Si on suppose que ça ne croit pas de manière linéaire et qu'on peut fire 100 000 boites mails avec 100 admins, alors l'acteur dominant va avoir plus de ressources pour lutter contre le spam (les 900 personnes), et il peut faire des choses que les plus petits ne peuvent pas.
Par exemple, il a une vue sur plus d'opérations, il va recevoir plus de spam et/ou plus vite, ce qui permet de réagir plus vite et donc d’arrêter plus vite, ce qui diminue le nombre de spam par utilisateurs.
En dehors de ses capacités, un acteur dominant a un avantage pour la lutte contre le spam.
Et tu parles d'avoir les informations qui transitent, mais il n'y a rien qui transite à part des DNSBL qui n'ont rien de libre ou d'ouvert.
Les systèmes modernes des GAFAMs se basent sur l'apprentissage statistique de la réputation des serveurs, mais ça ne marche que si tu as beaucoup de mail. Moi, avec mon serveur perso, je vais pas faire grand chose à ce niveau si j'ai 1 mail par jour.
[^] # Re: Quid des autres federations ?
Posté par Misc (site web personnel) . En réponse au lien After self-hosting my email for twenty-three years I have thrown in the towel. The oligopoly has won. Évalué à 4. Dernière modification le 05 septembre 2022 à 12:25.
Ce qui pourrait être fait pour les mails aussi, de façon assez trivial en fait.
C'est une des idées proposé par hey.com, et une qui peut se faire chez soi avec un peu de code.
Par exemple, tu envoies tout les mails ailleurs que dans ta inbox, sauf si le mail est dans une liste spécifique. Tu peux ensuite déplacer un email dans un dossier spécial pour déclencher le changement du filtre et le déplacement des emails qui correspondent vers la inbox.
Si c'était la solution, alors quelqu'un d'autre que Hey le proposerait. Mais visiblement, ça ne suffit pas.
# Quid des autres federations ?
Posté par Misc (site web personnel) . En réponse au lien After self-hosting my email for twenty-three years I have thrown in the towel. The oligopoly has won. Évalué à 9.
Un point qui me semble revenir rarement est la question des autres fédérations. Par exemple, XMPP, Matrix, et tout ce qui tourne à ActivityPub.
Le protocole SMTP de base a plein de souci. Mais une fois qu'on rajoute DKIM, SPF, etc, le probléme du spam persiste.
Pour le moment, les autres protocoles fédérés sont épargnés en partie parce que relativement personne (à l'échelle de la planète) ne les utilisent pour le moment.
Est ce qu'il ne faut pas se poser la question de se dire ce qui devrait être fait avant qu'on refasse la même chose que l'email ?
Ou est ce qu'il faut juste accepter que c'est inéluctable et que ça vient avec le fait d'avoir du succès, donc du monde, donc des problèmes d'échelle qui entraîne l'ossification du protocole et l’émergence d'acteurs dominants.
[^] # Re: Service de réception de SMS en ligne
Posté par Misc (site web personnel) . En réponse au journal Paypal et l'authentification à deux facteurs. Évalué à 8.
Ce que tu cherches, c'est pas simplement ça: https://docs.gammu.org/smsd/smsd.html
Avec une carte sim et un modem 4G sur un serveur en USB ?
[^] # Re: Et les zones blanches
Posté par Misc (site web personnel) . En réponse au journal Paypal et l'authentification à deux facteurs. Évalué à 4.
C'est possible, mais ça ne posait pas de souci avec un autre opérateur (celui d'avant, et celui d’après aussi). Et mes collègues se plaignaient aussi du réseau chez eux (et moi aussi, c'est comme ça que j'ai su pour les femtocells).
C'est con, mais ça aide d'avoir du réseau pour recevoir les alertes nagios.
[^] # Re: Expérience liseuses++
Posté par Misc (site web personnel) . En réponse au journal Les DRM, ma liseuse et moi. Évalué à 5.
Certes mais ce n'était qu'un exemple. Le reste du logiciel est pareil. Prenons par exemple et justement l'action de modifier la barre d'outils.
C'est dans préférence, barre d'outils et de menu. C'est facile à trouver, mais quand on clique sur ça, on arrive sur une fenetre quasiment vide avec une liste déroulante.
Primo, le premier item "cliquer pour choisir la barre d'outils…" est un des choix possibles, alors qu'à mon sens, ça devrait être un label avec un choix par défaut (un clic de moins pour éditer).
Ensuite, choisir les éléments via leur nom, c'est pas exactement l'UX la plus intuitive, surtout quand tu as 2 réglages suivant la présence ou pas d'une liseuse branché, et ça me parait une magouille dans le code pour faire apparaître le bouton d'opération sur la liseuse la ou je pense qu'une bonne pratique, c'est d'avoir un bouton grisé quand rien n'est branché. Pour moi, ça serait comme avoir libreoffice avec 2 choix "document à sauver / document sans modification", pour cacher l’icône de sauvegarde
Ça mentionne une "seconde barre d'outil optionnel", d’où est ce qu'elle vient, quelle sont ses réseaux ? Il y aussi le "menu contextuelle pour la liste de livres divisées", je suppose que c'est le menu qui s'affiche pour clic droit, mais à quel moment (sachant qu'il y a toujours une liste de livre, donc qu'est ce qui est divisé) ?
C'est pas que le logiciel n'est pas utilisable, et j'ai vu largement pire.
Mais tout a un coté baroque.
Mon dernier exemple, quand tu va dans les préférences, tu peux fermer une fenêtre via la croix en haut. Sauf que la croix agit comme "retour arrière", vu que tu reviens à la fenêtre d'avant.
Il y a spécifiquement une surcharge d'un comportement par défaut d'un élément d'interface compris depuis les premiers macs.
Ça me fume un peu. Ensuite, c'est sans doute les séquelles de mes années à faire de l'ergonomie.
[^] # Re: Et les zones blanches
Posté par Misc (site web personnel) . En réponse au journal Paypal et l'authentification à deux facteurs. Évalué à 4.
On a eu le même souci au travail avec SFR. Leur solution, c'était de proposer gratuitement d'avoir des relais 3G femtocell.
Ils sont gentils, mais si tu proposes pas le service comme promis, c'est pas à moi de sponsoriser le courant et la bande passante pour ça.
[^] # Re: Expérience liseuses++
Posté par Misc (site web personnel) . En réponse au journal Les DRM, ma liseuse et moi. Évalué à 5.
Ensuite, le souci de Calibre, c'est que son UX a tendance à faire des miracles. Pas des miracles comme faire marcher les cul de jattes, plus des miracles comme faire saigner des statues par les yeux (en tout cas, c'est l'effet que ça me fait, et je suis loin d'être un saint).
Par exemple, l'ordre des icônes dans le menu est assez (on m'excuseras le jeu de mot) orthodoxe.
"Convertir le livre" n'est pas à coté de "Éditer le livre", alors que fondamentalement, ça reste proche. Le bouton d'aide, traditionnellement à la fin des menus, est au milieu.
De même, "éditer le livre" est à l'opposé d'"éditer le livre".
Les widgets utilisés sont assez curieux, car c'est des boutons / menus, et je ne sais pas pourquoi "éditer le livre" et "connecter / partager" sont des menus sans la flèche qui réagissent comme les autres boutons.
Je ne pige pas pourquoi il y a une icône "visualiser" alors que tu as déjà un moyen de faire ça en double cliquant sur un livre, ou en cliquant et en regardant le résumé à droite.
Je suis content que Calibre existe, mais j'ai un peu le sentiment de me trimballer avec une cilice comme dans Da Vinci Code chaque fois que je l'utilise, sans doute pour expier mes crimes de téléchargements illégaux.
[^] # Re: Pas de problème de DRM
Posté par Misc (site web personnel) . En réponse au journal Les DRM, ma liseuse et moi. Évalué à 5.
Une de plus que je ne connaissait pas.
Les frais de port sur Amazon n'avaient pas l'air aussi faramineux. Je viens d'aller voir, ça serait $11.30 aujourd'hui pour ~ 16 ounces, soit 450 grammes. Par comparaison, le premier O Reilly que j'ai trouvé sur ma bibli fait 1.25 pounds soit 560 grammes. C'est sur que c'est plus gros qu'un livre de poche, mais ça me parait raisonnable.
Ensuite, comme dit plus haut, je ne veux pas commander sur Amazon, ni me faire livrer chez moi (car j'ai pas envie que mon adresse physique traîne partout, suite à des soucis de stalking (aussi bien moi que mon coloc)), donc j'essaye de prendre en magasin (et payer en cash aussi, j'ai vu Seven, je veux pas prendre de risque).
Ceci dit, je réalise que j'aurais pu me faire livrer au boulot comme pour le matos informatique.
# Et les zones blanches
Posté par Misc (site web personnel) . En réponse au journal Paypal et l'authentification à deux facteurs. Évalué à 7.
Ou alors, quand ça ne capte pas. La maison des parents de mon coloc, ou on a passé une partie des vacances, est dans un endroit fort peu desservi par les ondes (en partie à cause des murs, en partie à cause de la géographie, en partie parce qu'il y a personne).
Donc pour faire des opérations bancaires, j'ai du aller dehors vers la route la plus proche pour recevoir mon SMS de vérification. Et pourtant, c'était pas perdu au milieu de la Creuse ou du Vercors, il y a un train vers Paris.
[^] # Re: Pas de problème de DRM
Posté par Misc (site web personnel) . En réponse au journal Les DRM, ma liseuse et moi. Évalué à 5.
Dans le mesure ou les 2 sont présentés comme des absolus qui se contredisent, sans doute que si.
La distinction pirate vs grand public est assez artificielle. Ma soeur est capable de choper un livre pirate sur le web ou de choper matlab avec 250 000€ d'extensions pour son master de finance sans mon aide. Mon coloc (bibliothécaire) arrive sans doute mieux que moi à choper des films pirates (sans doute parce qu'il ne s'impose pas de lancer un client torrent en CLI sur un serveur distant).
Et pourtant, ayant du faire du support pour leurs machines respectives, je sais qu'ils sont loin d'être différent des commerciaux pour qui j'ai du faire le support au travail (genre par exemple, les commerciaux à qui je doit expliquer que non, faut pas laisser tourner deluge quand tu es au bureau, et que oui, non seulement l'équipe sécu l'a vu, mais en plus, elle te juge d'avoir pris "Camping 3 HD")
[^] # Re: Pas de problème de DRM
Posté par Misc (site web personnel) . En réponse au journal Les DRM, ma liseuse et moi. Évalué à 3.
Je trouve ça assez intéressant car il y a quand même un double discours dans la communauté sur le sujet des DRMs.
D'un coté, on dit que ça ne fait pas chier les pirates, que les DRMs seront toujours cassés et donc inutiles (exemple ici).
De l'autre, on agite la peur de la perte et qu'il faut résister (cf ton exemple de Korben).
Le petit arrière goût de "l'ennemi est à la foi faible et fort" me parait quand même au mieux curieux, au pire, pas terrible.
[^] # Re: Pas de problème de DRM
Posté par Misc (site web personnel) . En réponse au journal Les DRM, ma liseuse et moi. Évalué à 3. Dernière modification le 31 août 2022 à 13:50.
Une autre option, c'est aussi d'acheter le livre avec DRM et de faire sauter le DRM en question (ou de trouver une version sans DRM en dehors d'une boutique officielle)
Je n'ai pas testé, mais on trouve des tas de tutos plus ou moins bons pour faire ça avec Calibre.
[^] # Re: Pas de problème de DRM
Posté par Misc (site web personnel) . En réponse au journal Les DRM, ma liseuse et moi. Évalué à 4.
Je n'ai pas testé, mais plato propose des hooks pour télécharger du contenu.
Koreader a une option aussi pour du RSS/Atom.
Les 2 sont des logiciels libres, et il y a une communauté assez active sur MobileRead. Ensuite, ça dépend du degré d'ouverture de la liseuse, certaines (Kindle) sont plus fermés que d'autres, et certaines sont très largement bidouillable (par exemple, Kobo, mais sans doute d'autres).
[^] # Re: Pour les pirates…
Posté par Misc (site web personnel) . En réponse au journal Les DRM, ma liseuse et moi. Évalué à 4.
Les sites (en l’occurrence libgen et son clone Z-library, mais aussi sci-hub) sont en général référencé sous d'autres noms de domaines non bloqués et qui sont disponible sur des forums Reddit, sur les pages Wikipedia des projets, et parfois accessibles via des sites qui servent uniquement à faire des redirections (donc moins facilement bloqué).
Z-lib est aussi dispo via un service en .onion qui est théoriquement difficilement censurable.
La base de Z-library fait 220 T d'après Wikipedia (et il y a des tas de doublons), et les plus gros disques dur du moment font dans les 20T, sauf erreur de ma part.
Je pense qu'on se rapproche assez rapidement du moment ou il sera possible de faire tenir tout les epub/pdf piratés du monde dans un disque dur à un prix accessible au grand public, et je pense que ça risque d'être un moment intéressant pour la connaissance.
D'ailleurs, il y a des discussions sur le sujet, comme le fait de filtrer libgen par taille de fichiers, ou l'annonce récente d'un projet visant à faire une copie de z-library afin de mettre ça dans libgen.