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.
Le projet Lima s’éteint. C’est dommage. Je suis convaincu que les équipes de Lima ont fait tout ce qu’elles pouvaient pour que ça n’arrive pas. Des fois « on n’y arrive pas ». C’est dommage mais c’est ainsi et on doit plutôt remercier les gens d’avoir essayé.
Les appareils concernés vont à terme devenir inutilisables. C’est un bon exemple de « n’utilisez pas d’appareils connectés qui dépendent d’un service centralisé » mais à mon sens la leçon n’est pas celle là.
Je n’aime pas tirer sur l’ambulance mais mon problème est un problème éthique.
What happens if CGC dies ?
What’s good with Lima is that it’s entirely private and decentralized. So Lima can work independently from any servers, and continue managing your data even if our startup dies (disclosure: we don’t plan anything like that)
The only thing we manage on our side of the equations are updates of our app and the web interface of Lima. In case of company crash, we’ll do our best to open source at least the most critical parts of our code, so the community continues improving the solution every night.
La disparition de l’entreprise a été envisagée dès le début de l’aventure (c’est bien) et des éléments de réassurance ont été posés (c’est bien aussi, même si ce n’est que du best effort).
J’ai un problème éthique parce que toutes les équipes de Lima, des fondateurs jusqu’aux développeurs ont accepté de poser ces éléments de réassurance alors qu’ils semblent faux.
En pratique le serveur de l’infrastructure Lima est un composant essentiel et les boitiers vont progressivement arrêter de fonctionner. Ce n’est pas moi qui le dit, c’est Lima eux-mêmes. Là on est dans la tromperie pure et simple par rapport à la promesse affichée.
While your Lima product synchronises with your devices without servers, our servers are still needed to make your devices find each other and establish a connection.
Unfortunately, as our services shut down, your Lima will progressively stop to work.
La promesse de l’open source est similaire. En pratique il est impossible de passer le code open source une fois la société en liquidation. C’est confirmé par les réponses sur Twitter.
C’est simplement légal. Les actionnaires perdent le contrôle de la société et le liquidateur a l’obligation légale de tirer le maximum des possessions de la société. Ça inclut le code source et la propriété intellectuelle. Libérer le code source gratuitement n’est légalement plus possible.
If there’s any way, we will. But unfortunately the complexity of IP law makes it difficult: it is no longer up to us.
Il aurait fallu s’y prendre avant le début des difficultés. Il aurait fallu déposer le code source régulièrement chez un tiers de confiance et s’engager contractuellement avec lui sur une cession de droits qui ne deviendra effective qu’à certaines conditions pré-établies.
Même si la FAQ parle de « do our best », on est dans la tromperie. Il n’est pas imaginable que la question ait été abordée dans la FAQ et que les collaborateurs de l’entreprise aient pu ignorer les enjeux ci-dessus. Ils semblent pourtant ne rien avoir prévu, consciemment, et avoir participé là aussi à un décalage significatif entre le discours et les actions.
J’en veux aux développeurs qui ont participé à ça, et qui vont mettre le doute sur tous les autres.
Développeurs, vous ne devriez pas mettre l’éthique de côté. Vous ne devriez pas apporter votre concours à des sociétés qui trichent, qui trompent, peu importe le degré de coolitude du produit ou du service.
Github est un concentré de technologies. On ne refera pas Github de zéro avec juste une poignée de développeurs dans un garage.
Mais… 7 milliards et demi de dollars. Vous comptez comme vous voulez mais la technologie seule en vaut difficilement un centième. Multipliez par 10 parce que c’est prêt et qu’on évite du risque et du délai, il y aura encore au moins un zéro de trop. Les dividendes à venir ne valent pas cette différence.
Ce que Microsoft achète ce n’est pas Github, le logiciel et les équipes, c’est vous, clients. Vous et vos projets. On vient de vous vendre comme une marchandise. Vous n’en avez même pas touché des miettes.
Proposer de l’auto-hébergement c’est comme recommander aux gens de faire leur propre potager quand ils te parlent des problèmes de la chaîne de distribution alimentaire (*).
Oui l’auto-suffisance alimentaire est un énorme pas dans le bon sens. Non tout le monde n’a pas les connaissances ou les compétences pour maintenir son potager, les moyens financiers d’avoir un terrain et le matériel pertinent, ou simplement le temps à y consacrer.
Même quand on a tout ça, on peut vite se retrouver avec une récolte à vide, ou obligé de déverser plus de pesticide et plus d’eau que ne le ferait une culture intensive.
Bref, c’est super, mais ce n’est pas la solution magique à tout et pour tout le monde. Pas ainsi.
Certains feront leur potager, mais plus par plaisir ou conviction que comme source d’approvisionnement. D’autres iront dans des AMAP, dans des circuits courts, au supermaché bio ou solidaire, à la supérette du coin, ou même au supermarché en faisant attention à ce qu’ils achètent, en fonction de leurs moyens, de leurs contraintes et de leurs besoins.
L’auto-hébergement c’est pareil. Il vous faut un matériel adapté, une connexion Internet stable et suffisante, des compétences non négligeables, et surtout pas mal de temps et d’attention.
Maintenir un service en fonctionnement n’est qu’une petite partie du problème. Combien de ceux à qui on aura conseillé l’auto-hébergement vont se retrouver sans sauvegarde fonctionnelle au premier incident ? Combien vont faire une erreur et perdre leurs données ? Combien auront une qualité de service acceptable ? Et surtout, combien vont gérer correctement la sécurité ?
Genma parle d’élitisme. C’est un peu vrai mais il n’y a pas que ça. Même pour quelqu’un du métier, qui a les moyens financiers et du temps à y consacrer, une sécurité correcte demande désormais un investissement démesuré pour la plupart des besoins personnels.
Je ne dis pas que c’est forcément une mauvaise idée. La centralisation et la dépendance sont de vrais enjeux, la vie privée aussi, mais ne résumons pas ça à l’auto-hébergement.
Faites-le pour vous amuser, pour apprendre, pour tester, pour bidouiller. Faites-le si vous en avez envie, tout simplement. Aidez ceux qui veulent le faire.
Arrêtez par contre d’asséner ça comme une solution facile et universelle. Arrêtez de faire culpabiliser ceux qui délèguent et font confiance à un prestataire. Vous ne rendez service à personne, pas même à vos amis et votre famille à qui vous êtes en train de dire « mais si, sois dépendant de moi et mets-moi administrateur sur toutes tes données, tu verras ce sera génial ».
(*) L’analogie n’est pas de moi, je l’ai croisée récemment chez Clochix, merci à lui.
Mise à jour : Depuis, l’excellent Aeris a parlé de ça en détail et avec bien plus de brio que moi. Allez lire.
Certains ont très bien expliqué ce que c’est. Bref, c’est décentralisé. Youpi !
Sauf que bon, je réserve mon jugement définitif pour plus tard mais à vue de nez c’est encore une réponse purement technique qui passe à côté des enjeux.
* * *
Si je veux jouer avec Mastodon il y a toutes les chances que je me retrouve sur mastodon.social et que je créé un compte là bas. Je me retrouve avec un outil similaire à Twitter, quelques bonnes idées en plus, la stabilité et les 150 clients et robots compatibles en moins mais surtout… sans tous les gens qui me suivent ni ceux que je suis.
Comment est-ce que je transitionne si je ne peux pas forcer mes camarades de jeu ? Jabber a échoué face à MSN pour ça. Status.net a échoué face à Twitter pour ça. Je pourrais parler aussi de Google+ et 50 autres.
Status.net avait tenté la synchronisation avec Twitter. Les clients pouvaient se connecter aux deux réseaux, y publier la même chose et interagir avec les résidents des deux côtés. Jabber avait le soutien de poids lourds comme Google, Facebook et des acteurs locaux comme Orange. Google+ a tenté de se rendre essentiel dans l’incontournable Google.
Rien de tout cela ici et je ne vois aucune stratégie qui me permette d’y croire : pas de marketing agressif (on parlerait en dizaines de millions d’euros pour envisager battre twitter), aucun acteur de poids, pas de partenariat important avec des sources incontournables, pas de fonctionnalité importante au point de me faire abandonner le réseau existant… rien.
* * *
Mais « c’est décentralisé ! » vous allez me dire. Outre que c’est un argument qui ne convaincra que les geeks, ma réponse sera surtout « ah bon ? ».
90% des utilisateurs ont créé un compte sur l’instance principale mastodon.social. Autant dire que côté décentralisation… Le pire c’est que leur identifiant est lié à la plateforme donc ils devront abandonner tous leurs contacts et leur historique si d’aventure ils devaient changer d’instance.
Vous pouvez aller voir ailleurs, mais déjà que le réseau est petit, il est bien difficile de se dire qu’une petite instance sera là dans la durée. Si pour migrer je dois tout perdre, même moi je risque d’aller sur l’instance principale et jeter l’idée de décentralisation.
Pour jouer à ce jeu, il faut non seulement un système de délégation ou d’indirection au niveau des identifiants mais aussi aider les 90% des utilisateurs à effectivement l’utiliser (non, implémenter webfinger ne suffit pas).
À défaut il faut prévoir dans le protocole un moyen d’annoncer aux clients qu’un utilisateur a changé d’instance, que les clients se mettent à jour à partir de là et que les serveurs sachent réimporter l’historique d’un utilisateur en migration. C’est toujours possible de l’ajouter après coup mais qu’ils n’y aient pas pensé ne me rend pas optimiste sur la compréhension des enjeux.
* * *
Bref, pour que j’y crois il aurait fallu une stratégie pour faire migrer une masse critique d’utilisateurs, plus une mise en œuvre autrement que théorique de la décentralisation.
Je n’ai aucun des deux aujourd’hui et ce n’est pas faute de l’espérer mais je ne crois pas une seconde que les quelques petites fonctionnalités techniques fassent la différence vis à vis d’un réseau qui est quasiment passé dans le langage courant, soutenu par une entreprise qui peut mettre des dizaines millions sur la table du jour au lendemain.
Il est temps d’arrêter de croire que tous les problèmes sont techniques et peuvent se résoudre avec des lignes de code. Faire un système de publication décentralisé c’est (relativement) simple. D’autres l’ont déjà fait et ce n’est pas ça qui bloque. L’enjeu pour sortir de la centralisation de Twitter se situe ailleurs.
J’ai acheté ma TV il y a bien longtemps. À l’époque nous avons accepté d’y mettre plus pour avoir un système de replay intégré à la TV. À la sortie du carton le replay ne fonctionnait pas, « prochainement » qu’ils disaient. Ça a duré des mois puis on a eu M6, mais sans les séries et fictions phares. Quand elles ont été là nous avons eu des publicités avant lecture… alors que le site officiel n’en avait pas (ou pas autant, je ne sais plus). Au bout d’un moment le service a été fermé. Voilà pour ma TV. Sony je pense à toi, je n’ai plus rien racheté chez toi depuis.
En avril c’est le hub Nest qui est arrêté, à peine deux ans après sa commercialisation. On ne parle pas d’une fonction annexe de perdue mais d’un appareil de 300 $ qui ne sert plus que de presse-papier.
Il y a quelques jours j’ai vu passer l’annonce d’arrêt d’une carte SD wifi. Oui, une simple carte SD qui fait wifi. Le constructeur peut décider de ne simplement plus les faire fonctionner, à peine un an après sa fin de commercialisation.
Et si demain Adobe, Amazon ou Kobo décident d’arrêter le support de leur DRM de livre numérique ? Vos livres risquent de ne devenir que des suites de 0 et de 1 totalement illisibles.
Nous avons de plus en plus d’objets connectés, de contenus numériques contrôlés par des tiers, sans que jamais nous n’ayons un quelconque engagement de pérennité.
Pour du logiciel sur abonnement c’est une chose, pour du matériel qu’on achète et qui n’a aucune raison de s’arrêter de fonctionner, c’est encore plus difficile à concevoir.
Internet of things qu’ils disaient. Nous ne contrôlons plus rien, nous ne détenons plus rien. Une société privée peut à tout moment décider que notre matériel, chez nous, arrêtera de fonctionner, simplement parce que ce n’est plus rentable pour elle. Peut-être même simplement pour promouvoir ou se concentrer sur une nouvelle version en vente.
À l’heure où on parle d’obsolescence programmée, de garantie de disponibilité de pièces détachées, il serait temps d’imposer par la loi une pérennité minimum, ou au moins que le vendeur affiche très explicitement le temps de fonctionnement garanti.
Pendant un temps, en particulier grâce à Google Reader, l’habitude commençait à prendre. Aujourd’hui la syndication RSS/Atom semble de moins en moins utilisée. Hors les blogs et les geeks, les flux disponibles disparaissent.
Certaines plateformes en profitent d’ailleurs bien pour forcer le public à rester dans l’écosystème. Parfois même avoir un lien direct vers un contenu demande des contorsions agaçantes.
Je ne sais pas comment font les gens normaux pour suivre des contenus. Je n’imagine même pas suivre plus de 10 sources sans un agrégateur bien foutu – et non, Facebook ou Twitter ne répondent pas au besoin, pas même de loin.
Sébastien Sauvage nous propose un petit pont pour produire du RSS à partir de quelques sites ou quelques contenus qui n’en ont pas. Je suis un peu déçu que ça ne soit pas natif sur les agrégateurs, mais c’est assez intéressant pour les geeks comme moi. Allez donc voir.
rss-bridge is a PHP project capable of generating ATOM feeds for websites which don’t have one.
[…] Le partage d’un simple lien à peine accompagné d’un titre est remplacé par des dispositifs décentralisés, souvent en parallèle de carnets en ligne. Des partages augmentés d’une recontextualisation, d’un commentaire et de rebonds. Des veilles distribuées.
[…] Les gens que je lis le plus souvent sont ceux qui se sont déjà éloignés des réseaux. Karl a quitté Flickr bien avant les scandales sur le droit d’auteur par exemple ; Éric et David partagent leur lecture sur des billets courts.
Ce qu’il manque c’est de reprendre les notifications et tissages de discussion. Je ne sais que tu reprends une de mes lecture que parce que je te suis. Vous êtes au moins 5 à faire la suite sur vos propres blogs (Toi, David, Karl, Clément, le Hollandais Vollant). Il y en a certainement d’autres – je ne peux que l’espérer.
Je manque certainement des suites intéressantes faute de notification même la plus élémentaires. Ça fait longtemps que j’aimerais développer un petit robot à partir des entêtes de `Referer` mais non seulement c’est amené à ne plus fonctionner avec HTTPS, mais en plus j’ai toujours mieux à faire.
Entre temps je lance des notifications sur Twitter – mais c’est quand même le contraire de l’objectif annoncé – et je manque certainement beaucoup de choses.
En attendant mieux, j’ai pingback d’activé, mais je suis visiblement le seul des cinq et vous ne les recevez ni envoyez. Ça serait bien d’avancer.
The Kindle Fire comes with a SDXC card slot that outclasses every other tablet in its price range, accommodating storage cards that can hold as much as 128GB of media — but it won’t read ebooks from the slot.
Chris adds, « This seems like a strange oversight, given that every other media app on the tablet uses that card for downloading and storage, and its 5 GB usable internal memory isn’t a lot for people who have a large library of picture-heavy e-books — especially if they want to install other apps, too. »
[…]
Every walled garden wants to keep out the competition. Amazon also announced yesterday that it would stop carrying the Chromecast and Appletv, devices from Google and Apple that compete with its own Fire TV.
Et pourtant j’ai encore des gens, à chaque fois que j’aborde des comparatifs de liseuses en expliquant avoir mis de côté les Kindle, qui m’argumentent que je réagis par intérêt ou par idéologie.
Pour l’instant le jardin est grand, doré, mais il est fermé. Demain le jardin sera peut être trop petit, ou les dorures auront disparues parce qu’il sera temps de rentabiliser. Vous, vous serez encore à l’intérieur.
Vous, nous peut-être. Je ne sais pas. Parce que l’analyse vaut pour plus que le livre numérique et Kindle.
