Exactement. Et tu peux toujours configuré ton client mail pour avoir deux compte, un qui tape sur le nouveau imap et un qui tape sur l'ancien, donc tu peux même copier coller un mail d'un imap à un autre.
Oui, j'ai juste un peu peur d'une possible confusion. J'ai pas mal de mails pro qui peuvent arriver d'un seul coup. M'enfin bon, tant qu'ils arrivent, je vais pas me plaindre. Il va juste falloir que je joue correctement avec les DNS durant la transition. Merci d'avoir confirmé mon intuition.
Et soit dit en passant une bonne pratique est de toute manière d'avoir un backup imap sur un autre serveur ou en local avec un outil de synchro comme imapsync, offlineimap ou isync (les deux derniers gèrent la synchro dans les deux sens), donc tu peux utiliser aussi cela pour ta migration.
Oui, j'utilise au quotidien offlineimap avec sauvegarde externe régulière en plus. Je pensais l'utiliser de toute façon pour faire une copie des mails vers le nouvel hébergeur (même si celui que j'envisage, Infomaniak, parce qu'ils proposent SIEVE, semble avoir un outils d'importation des mails via imap, mais à voir comment ça marche et si c'est efficace).
Je suis en train de regarder imapsync aussi au cas où. J'ai un peu plus de 2Go de mails avec quelques dossiers à plus de 50K mails, et j'ai besoin d'y avoir accès "depuis l'ordinateur d'un autre". Rien ne sera perdu, mais je vais avoir quelques suées durant la transition, c'est certain.
Ok merci pour la précision. Donc si je comprends bien, j'effectue la migration et, durant le temps du transfert, j'aurai le temps d'utiliser un truc comme imapsync entre imap.gandi et imap.XXX, c'est ça ?
Du coup j'imagine que tant que la propagation DNS ne sera pas faite vers le nouveau registrar, les nouveaux mails continueront à arriver chez gandi, n'est-ce pas ?
Je sens que ça va être stressant cette migration. Et encore, je gère qu'un truc personnel, j'ose à peine imaginer ce que ça va être pour les professionnels qui gèrent je ne sais combien de nom de domain + mail pour des clients…
Salut ! Je pense que la question était de passer d'un registrar qui gère le mail à un autre registrar qui gère le mail sans (trop d') interruption. Si on quitte Gandi+Mail et qu'on passe chez, mettons, OVH+mail, Infomaniak+mail ou autre, est-ce qu'il y a une façon simple de faire ça ?
Autrement dit, si je transfère mon nomdedomaine.com de Gandi à XXX, comment peut-on faire pour avoir une continuité de service du mail moi@nomdedomaine.com ?
Est-ce même possible ? Si j'ai bien compris le transfert peut prendre quelques jours…
Sauf que tu y as accès et possiblement de manière non traçable (dans le sens le faire sans que l'enfant ne le sache). C'est bien de ne pas lire le contenu, mais c'est difficile d'être sûr que cela n'arrivera jamais. Typiquement je ne suis pas sûr moi même de pouvoir résister à cette tentation si j'en avais l'opportunité.
Toute la question est là justement. C'est je crois au parent de poser et de maintenir un cadre de confiance sain et mutuel, sans doutes aucuns pour l'enfant. De poser ce cadre et de s'y tenir !
Je pense que finalement la question n'est peut-êre pas que technique.
Heureusement, j’accède à ses mails (ils sont au courant) et parfois je rectifie le tir.
Personnellement j'ai du mal avec ce genre de choses…
Moi aussi, c’est pour ça, que le compte mail des enfants est sur mon thunderbird, je ne regarde que très rarement, et uniquement le sujet du mail ainsi que l’expéditeur.
Lorsque j'étais jeune ado, j'entretenais une correspondance épistolaire avec une fille qui habitait dans une autre ville. J'ai reçu plusieurs lettres et, un jour, une des lettres avait été ouverte. Je découvrais que ma mère avait cru bon d'ouvrir et de lire ce courrier. C'était pour moi la limite implicite à ne pas dépasser. Qu'elle puisse surveiller de façon général ce qu'il se passe, je pouvais le comprendre et m'en accommoder, mais la lecture de chose que je considérais comme intime, c'était beaucoup trop.
À l'époque, nous habitions dans la partie administrative d'un hôpital. Aussi, mes parents récupéraient le courrier de toute la famille à l'accueil (donc le mien aussi) et nous le distribuait ensuite. Donc ma mère me donnait les lettres qui étaient pour moi ; elle savait ainsi qui m'écrivait et quand. Le jour où elle a ouvert une de mes lettres, la relation de confiance qu'on avait sur ce sujet était pour moi brisée. Je me suis donc arrangé avec le gars de l'accueil pour qu'il détourne tous les courriers qui m'étaient adressés afin que je puisse moi-même le récupérer en main-propre. Et le jour où cela a été mis en place, j'ai compris que je pouvais me faire livrer sans que jamais mes parents ne le sachent (Maman, si tu me lis, je n'en ai pas abusé, promis :P).
Cette petite anecdote montre bien je crois la question n'est finalement pas tant "numérique" que cela (même s'il est évident que les dangers qui y sont liés sont bien plus grands que d'arriver à se faire livrer des revues cochonnes (Non, Maman, calme-toi, je l'ai pas fait, c'est juste un exemple pour démontrer mon propos aux lecteurs de LinuxFr !!).
Plus haut dans le fil, certains ont parlé de confiance et de dialogue (total ou limité, selon les enfants à qui on s'adresse). Je crois que c'est vraiment le noeud du problème. La question est de savoir, en accord avec ses enfants (parce que là, même si on réfute leur possibilité à une "vie privée", il va bien falloir admettre qu'ils en ont une et qu'ils sont probablement prêt à la défendre et à la préserver par tous les moyens), la question, disais-je, est de savoir jusqu'où le contrôle peut aller.
Mes enfants me font confiance pour ça, je ne suis pas sûr que ce soit si mal, sinon, il m’aurait déjà fait remarquer qu’ils étaient contre.
Personnellement je pense que c'est ça. Avec, autant que possible, une éducation autour de l'hygiène numérique.
Et bien j'ai cherché avant de poster et il semble que que le terme « obfuscation » est un néologisme tiré de l'anglais (source wikipedia). Du coup, bon, c'est vrai que cela fait bizarre, mais je me suis dit que j'allais parler français et utiliser le terme offuscation. Ceci dit, d'après le wiktionnaire, bien que notés comme synonymes, les deux termes (obfuscation et offuscation) en informatique ont une définition sensiblement différente.
Malgré tout, offuscation, étant « le fait d'offusquer », c'est-à-dire « empêcher d’être vu », je me suis convaincu que c'était le bon terme en français à utiliser puisque cela collait à ce qui arrive aux liens proposés par le Courrier du hacker. Bon, c'est vrai que si on prend le sens figuré, ça fait des « liens qui sont choqués » :D
Il fallait donc évidemment prendre le terme dans son sens premier, littéral.
Je fais parti de ceux qui critiquaient l'utilisation de Mailchimp par le Courrier du hacker, notamment de mon point de vue de l'abonné, puisque tous les liens vers les articles partagés étaient systématiquement transformés pour pointer vers les serveurs de Mailchimp afin de nous tracer. Aussi, je rejoins les autres pour sincèrement te remercier et te féliciter du travail de migration effectué.
Par contre c'est avec regret que je constate que, malgré l'utilisation de Mailtrain, les liens sont toujours offusqués (cette fois-ci pour transiter par le serveur du courrierduhacker.com) quand on est abonné à la liste de diffusion ! Heureusement quand on passe par les archives du site les liens n'ont pas subis ce traitement.
Comme promis, AlienBob a sorti un long tutoriel expliquant la mise en place et l'utilisation de KeePassXC et xBrowserSync suite à l'utilisation d'un Chromium exempt des services de Google. Pour ceux que cela intéresse, on peut retrouver ces informations dans son article Sync and share your (Chromium and more) browser data among all your computers.
Mais dans un contexte libre/gratuit, et si l'utilisateur tient tant que ça à jouer sur plusieurs devices, un transfert du profil ou ta solution XBrowserSync sont vraiment si hardcore à suggérer ?
En un mot j'aurai tendance à dire oui. Pour la simple et bonne raison que les solutions proposées par Google représente une forme de sécurité, de stabilité et de simplicité pour de nombreux utilisateurs finaux qui peuvent déjà utiliser par ailleurs l'écosystème de Google (soit par choix personnel soit parce que c'est l'environnement mis en avant dans le cadre d'une institution/entreprise). Je pense que, à moins d'avoir une démarche pro-active en ce sens, c'est une des raisons (et peut-être la principale) qui fait que des solutions comme xBrowserSync sont moins courues. Sans parler du fait que, pour être vraiment certain que les données ne soient pas hébergés chez quelqu'un que l'on ne connait finalement pas (parce que oui, même l'api proposée par xbrowsersync.org n'a peut-être pas ce niveau de confiance), il faut installer sa propre instance (avec les connaissances et les problèmes de sécurité que cela génère).
Et question bonus, y-a-t-il des APIs ouachement utiles hors Google Sync ?
Au niveau de l'utilisateur final, les APIs de synchronisation sont quand même celles qui sont pas mal mises en avant.
Mais dans un contexte libre/gratuit, et si l'utilisateur tient tant que ça à jouer sur plusieurs devices, un transfert du profil ou ta solution XBrowserSync sont vraiment si hardcore à suggérer ?
En un mot j'aurai tendance à dire oui. Pour la simple et bonne raison que les solutions proposées par Google représente une forme de sécurité, de stabilité et de simplicité pour de nombreux utilisateurs finaux qui peuvent déjà utiliser par ailleurs l'écosystème de Google (soit par choix personnel soit parce que c'est l'environnement mis en avant dans le cadre d'une institution/entreprise). Je pense que, à moins d'avoir une démarche pro-active en ce sens, c'est une des raisons (et peut-être la principale) qui fait que des solutions comme xBrowserSync sont moins courues. Sans parler du fait que, pour être vraiment certain que les données ne soient pas hébergés chez quelqu'un que l'on ne connait finalement pas (parce que oui, même l'api proposée par xbrowsersync.org n'a peut-être pas ce niveau de confiance), il faut installer sa propre instance (avec les connaissances et les problèmes de sécurité que cela génère).
Et question bonus, y-a-t-il des APIs ouachement utiles hors Google Sync ?
Au niveau de l'utilisateur final, les APIs de synchronisation sont quand même celles qui sont pas mal mises en avant.
Car en effet, et comme dit, certains services restant accessibles, l'une des clefs reste valide pour ces cas là. Mais le développeur qui proposera un tel accès sera facturé dès la première connexion.
Ce n’est pas ce que dit l’article d’AlienBob.
En effet, c'est une erreur de ma part, merci de la correction. Au moment du premier jet de l'article, j'ai effectué quelques recherches sur cette question et j'ai sauté (trop) rapidement à la conclusion que le quota de gratuité serait lui aussi supprimé puisque le remaniement de tout cet écosystème semble pointer dans cette direction. Ainsi que tu le dis, il est clair qu'un nouveau modèle risque de voir le jour d'ici à l'année prochaine (pronostic personnel). Aussi je crois, personnellement, que cela va finir comme ça mais, pour le moment, et comme tu fais bien de l'expliquer, rien n'est certain sur ce point. Puis AlienBob est clairement revenu sur cet élément dans son commentaire du 5 mars sous son article (où il dit en substance wait and see) et j'ai manqué d'éditer mon article en conséquence.
En passant, rien à voir, mais question à tout le monde : n'est-il pas possible d'éditer mon journal afin d'apporter la correction et les précisions pointées par MrLapinot ?
Maintenant tu mets en avant un élément très intéressant à savoir les questions de sécurité, raison évoquée par Google à différents moments depuis plusieurs mois, que je n'aborde pas du tout pour des questions d'exhaustivité (au sens où je ne voulais pas m'étendre sur ce sujet ici et que je ne voulais pas non plus juste dire "ils disent que c'est une question de sécurité", argument que l'on ne peut pas juste évoquer seul comme cela tellement il a été galvaudé). Si mes souvenirs sont bons, c'est quelque chose qui est discuté (vis-à-vis des APIs je veux dire) depuis au moins début 2019 n'est-ce pas ? Par ailleurs, et dans ce même cadre, il aurait aussi été intéressant de parler de l'arrêt du support complet des Chrome apps d'ici à juin 2022 et de la volonté de Google de voir les développements de ces applications aller vers des Progressive Web App ; ce qui fait un lien de plus avec ta remarque sur Chromium0S. Mais là, à nouveau, je trouvais que je sortais trop du cadre et ne voulait pas alourdir mon propos. D'ailleurs, j'avais un paragraphe justement en prenant l'exemple de Samsung mais j'ai décidé de le supprimer histoire de ne pas ouvrir encore d'autres portes que je ne pourrais pas refermer. Enfin, j'ai personnellement beaucoup plu eu à lire sur la question des téléviseurs connectés (en lien notamment avec Samsung) mais il est indéniable que la coupure des accès aux APIs ainsi que l'arrêt du support des apps va poser d'énormes problèmes à beaucoup de monde.
[^] # Re: Migration
Posté par f6k (site web personnel) . En réponse au journal Gandi, passe de « no bullshit » à « bait and switch » ?. Évalué à 1.
Oui, j'ai juste un peu peur d'une possible confusion. J'ai pas mal de mails pro qui peuvent arriver d'un seul coup. M'enfin bon, tant qu'ils arrivent, je vais pas me plaindre. Il va juste falloir que je joue correctement avec les DNS durant la transition. Merci d'avoir confirmé mon intuition.
Oui, j'utilise au quotidien offlineimap avec sauvegarde externe régulière en plus. Je pensais l'utiliser de toute façon pour faire une copie des mails vers le nouvel hébergeur (même si celui que j'envisage, Infomaniak, parce qu'ils proposent SIEVE, semble avoir un outils d'importation des mails via imap, mais à voir comment ça marche et si c'est efficace).
Je suis en train de regarder imapsync aussi au cas où. J'ai un peu plus de 2Go de mails avec quelques dossiers à plus de 50K mails, et j'ai besoin d'y avoir accès "depuis l'ordinateur d'un autre". Rien ne sera perdu, mais je vais avoir quelques suées durant la transition, c'est certain.
[^] # Re: Migration
Posté par f6k (site web personnel) . En réponse au journal Gandi, passe de « no bullshit » à « bait and switch » ?. Évalué à 2.
Ok merci pour la précision. Donc si je comprends bien, j'effectue la migration et, durant le temps du transfert, j'aurai le temps d'utiliser un truc comme imapsync entre imap.gandi et imap.XXX, c'est ça ?
Du coup j'imagine que tant que la propagation DNS ne sera pas faite vers le nouveau registrar, les nouveaux mails continueront à arriver chez gandi, n'est-ce pas ?
Je sens que ça va être stressant cette migration. Et encore, je gère qu'un truc personnel, j'ose à peine imaginer ce que ça va être pour les professionnels qui gèrent je ne sais combien de nom de domain + mail pour des clients…
[^] # Re: Migration
Posté par f6k (site web personnel) . En réponse au journal Gandi, passe de « no bullshit » à « bait and switch » ?. Évalué à 5.
Salut ! Je pense que la question était de passer d'un registrar qui gère le mail à un autre registrar qui gère le mail sans (trop d') interruption. Si on quitte Gandi+Mail et qu'on passe chez, mettons, OVH+mail, Infomaniak+mail ou autre, est-ce qu'il y a une façon simple de faire ça ?
Autrement dit, si je transfère mon nomdedomaine.com de Gandi à XXX, comment peut-on faire pour avoir une continuité de service du mail moi@nomdedomaine.com ?
Est-ce même possible ? Si j'ai bien compris le transfert peut prendre quelques jours…
# Jolie balade
Posté par f6k (site web personnel) . En réponse au journal Unknown Pleasures : un pulsar iconique. Évalué à 5.
Super article ; et comme dit plus haut, merci beaucoup pour la balade :)
# sudo systemctl enable cotillons.socket
Posté par f6k (site web personnel) . En réponse au journal Nouvelle : systemd-society.service. Évalué à 10.
! Bravo, franchement ! J'ai pris à lire beaucoup de plaisir
[^] # Re: 14 et 15 ans.
Posté par f6k (site web personnel) . En réponse au journal Ados et réseaux sociaux. Évalué à 1.
Toute la question est là justement. C'est je crois au parent de poser et de maintenir un cadre de confiance sain et mutuel, sans doutes aucuns pour l'enfant. De poser ce cadre et de s'y tenir !
[^] # Re: 14 et 15 ans.
Posté par f6k (site web personnel) . En réponse au journal Ados et réseaux sociaux. Évalué à 8. Dernière modification le 08 avril 2021 à 13:59.
Je pense que finalement la question n'est peut-êre pas que technique.
Lorsque j'étais jeune ado, j'entretenais une correspondance épistolaire avec une fille qui habitait dans une autre ville. J'ai reçu plusieurs lettres et, un jour, une des lettres avait été ouverte. Je découvrais que ma mère avait cru bon d'ouvrir et de lire ce courrier. C'était pour moi la limite implicite à ne pas dépasser. Qu'elle puisse surveiller de façon général ce qu'il se passe, je pouvais le comprendre et m'en accommoder, mais la lecture de chose que je considérais comme intime, c'était beaucoup trop.
À l'époque, nous habitions dans la partie administrative d'un hôpital. Aussi, mes parents récupéraient le courrier de toute la famille à l'accueil (donc le mien aussi) et nous le distribuait ensuite. Donc ma mère me donnait les lettres qui étaient pour moi ; elle savait ainsi qui m'écrivait et quand. Le jour où elle a ouvert une de mes lettres, la relation de confiance qu'on avait sur ce sujet était pour moi brisée. Je me suis donc arrangé avec le gars de l'accueil pour qu'il détourne tous les courriers qui m'étaient adressés afin que je puisse moi-même le récupérer en main-propre. Et le jour où cela a été mis en place, j'ai compris que je pouvais me faire livrer sans que jamais mes parents ne le sachent (Maman, si tu me lis, je n'en ai pas abusé, promis :P).
Cette petite anecdote montre bien je crois la question n'est finalement pas tant "numérique" que cela (même s'il est évident que les dangers qui y sont liés sont bien plus grands que d'arriver à se faire livrer des revues cochonnes (Non, Maman, calme-toi, je l'ai pas fait, c'est juste un exemple pour démontrer mon propos aux lecteurs de LinuxFr !!).
Plus haut dans le fil, certains ont parlé de confiance et de dialogue (total ou limité, selon les enfants à qui on s'adresse). Je crois que c'est vraiment le noeud du problème. La question est de savoir, en accord avec ses enfants (parce que là, même si on réfute leur possibilité à une "vie privée", il va bien falloir admettre qu'ils en ont une et qu'ils sont probablement prêt à la défendre et à la préserver par tous les moyens), la question, disais-je, est de savoir jusqu'où le contrôle peut aller.
Personnellement je pense que c'est ça. Avec, autant que possible, une éducation autour de l'hygiène numérique.
[^] # Re: Liens offusqués
Posté par f6k (site web personnel) . En réponse à la dépêche Le Courrier du hacker, newsletter du Libre, se libère de Mailchimp. Évalué à 6. Dernière modification le 30 mars 2021 à 09:58.
Et bien j'ai cherché avant de poster et il semble que que le terme « obfuscation » est un néologisme tiré de l'anglais (source wikipedia). Du coup, bon, c'est vrai que cela fait bizarre, mais je me suis dit que j'allais parler français et utiliser le terme offuscation. Ceci dit, d'après le wiktionnaire, bien que notés comme synonymes, les deux termes (obfuscation et offuscation) en informatique ont une définition sensiblement différente.
Malgré tout, offuscation, étant « le fait d'offusquer », c'est-à-dire « empêcher d’être vu », je me suis convaincu que c'était le bon terme en français à utiliser puisque cela collait à ce qui arrive aux liens proposés par le Courrier du hacker. Bon, c'est vrai que si on prend le sens figuré, ça fait des « liens qui sont choqués » :D
Il fallait donc évidemment prendre le terme dans son sens premier, littéral.
# Liens offusqués
Posté par f6k (site web personnel) . En réponse à la dépêche Le Courrier du hacker, newsletter du Libre, se libère de Mailchimp. Évalué à 10.
Je fais parti de ceux qui critiquaient l'utilisation de Mailchimp par le Courrier du hacker, notamment de mon point de vue de l'abonné, puisque tous les liens vers les articles partagés étaient systématiquement transformés pour pointer vers les serveurs de Mailchimp afin de nous tracer. Aussi, je rejoins les autres pour sincèrement te remercier et te féliciter du travail de migration effectué.
Par contre c'est avec regret que je constate que, malgré l'utilisation de Mailtrain, les liens sont toujours offusqués (cette fois-ci pour transiter par le serveur du courrierduhacker.com) quand on est abonné à la liste de diffusion ! Heureusement quand on passe par les archives du site les liens n'ont pas subis ce traitement.
# MàJ conclusion : Tutoriel KeePassXC et xBrowserSync par AlienBob
Posté par f6k (site web personnel) . En réponse au journal AlienBob et les dédales de Chromium sous Slackware. Évalué à 2.
Comme promis, AlienBob a sorti un long tutoriel expliquant la mise en place et l'utilisation de KeePassXC et xBrowserSync suite à l'utilisation d'un Chromium exempt des services de Google. Pour ceux que cela intéresse, on peut retrouver ces informations dans son article Sync and share your (Chromium and more) browser data among all your computers.
[^] # Re: Précisions : gratuité et sécurité
Posté par f6k (site web personnel) . En réponse au journal AlienBob et les dédales de Chromium sous Slackware. Évalué à 1.
C'est noté merci ! Je serais beaucoup plus vigilant la prochaine fois :)
[^] # Re: Google Sync, mauvais feeling dès le départ
Posté par f6k (site web personnel) . En réponse au journal AlienBob et les dédales de Chromium sous Slackware. Évalué à 0.
En un mot j'aurai tendance à dire oui. Pour la simple et bonne raison que les solutions proposées par Google représente une forme de sécurité, de stabilité et de simplicité pour de nombreux utilisateurs finaux qui peuvent déjà utiliser par ailleurs l'écosystème de Google (soit par choix personnel soit parce que c'est l'environnement mis en avant dans le cadre d'une institution/entreprise). Je pense que, à moins d'avoir une démarche pro-active en ce sens, c'est une des raisons (et peut-être la principale) qui fait que des solutions comme xBrowserSync sont moins courues. Sans parler du fait que, pour être vraiment certain que les données ne soient pas hébergés chez quelqu'un que l'on ne connait finalement pas (parce que oui, même l'api proposée par xbrowsersync.org n'a peut-être pas ce niveau de confiance), il faut installer sa propre instance (avec les connaissances et les problèmes de sécurité que cela génère).
Au niveau de l'utilisateur final, les APIs de synchronisation sont quand même celles qui sont pas mal mises en avant.
[^] # Re: Google Sync, mauvais feeling dès le départ
Posté par f6k (site web personnel) . En réponse au journal AlienBob et les dédales de Chromium sous Slackware. Évalué à 4.
En un mot j'aurai tendance à dire oui. Pour la simple et bonne raison que les solutions proposées par Google représente une forme de sécurité, de stabilité et de simplicité pour de nombreux utilisateurs finaux qui peuvent déjà utiliser par ailleurs l'écosystème de Google (soit par choix personnel soit parce que c'est l'environnement mis en avant dans le cadre d'une institution/entreprise). Je pense que, à moins d'avoir une démarche pro-active en ce sens, c'est une des raisons (et peut-être la principale) qui fait que des solutions comme xBrowserSync sont moins courues. Sans parler du fait que, pour être vraiment certain que les données ne soient pas hébergés chez quelqu'un que l'on ne connait finalement pas (parce que oui, même l'api proposée par xbrowsersync.org n'a peut-être pas ce niveau de confiance), il faut installer sa propre instance (avec les connaissances et les problèmes de sécurité que cela génère).
Au niveau de l'utilisateur final, les APIs de synchronisation sont quand même celles qui sont pas mal mises en avant.
[^] # Re: Précisions : gratuité et sécurité
Posté par f6k (site web personnel) . En réponse au journal AlienBob et les dédales de Chromium sous Slackware. Évalué à 6.
En effet, c'est une erreur de ma part, merci de la correction. Au moment du premier jet de l'article, j'ai effectué quelques recherches sur cette question et j'ai sauté (trop) rapidement à la conclusion que le quota de gratuité serait lui aussi supprimé puisque le remaniement de tout cet écosystème semble pointer dans cette direction. Ainsi que tu le dis, il est clair qu'un nouveau modèle risque de voir le jour d'ici à l'année prochaine (pronostic personnel). Aussi je crois, personnellement, que cela va finir comme ça mais, pour le moment, et comme tu fais bien de l'expliquer, rien n'est certain sur ce point. Puis AlienBob est clairement revenu sur cet élément dans son commentaire du 5 mars sous son article (où il dit en substance wait and see) et j'ai manqué d'éditer mon article en conséquence.
En passant, rien à voir, mais question à tout le monde : n'est-il pas possible d'éditer mon journal afin d'apporter la correction et les précisions pointées par MrLapinot ?
Maintenant tu mets en avant un élément très intéressant à savoir les questions de sécurité, raison évoquée par Google à différents moments depuis plusieurs mois, que je n'aborde pas du tout pour des questions d'exhaustivité (au sens où je ne voulais pas m'étendre sur ce sujet ici et que je ne voulais pas non plus juste dire "ils disent que c'est une question de sécurité", argument que l'on ne peut pas juste évoquer seul comme cela tellement il a été galvaudé). Si mes souvenirs sont bons, c'est quelque chose qui est discuté (vis-à-vis des APIs je veux dire) depuis au moins début 2019 n'est-ce pas ? Par ailleurs, et dans ce même cadre, il aurait aussi été intéressant de parler de l'arrêt du support complet des Chrome apps d'ici à juin 2022 et de la volonté de Google de voir les développements de ces applications aller vers des Progressive Web App ; ce qui fait un lien de plus avec ta remarque sur Chromium0S. Mais là, à nouveau, je trouvais que je sortais trop du cadre et ne voulait pas alourdir mon propos. D'ailleurs, j'avais un paragraphe justement en prenant l'exemple de Samsung mais j'ai décidé de le supprimer histoire de ne pas ouvrir encore d'autres portes que je ne pourrais pas refermer. Enfin, j'ai personnellement beaucoup plu eu à lire sur la question des téléviseurs connectés (en lien notamment avec Samsung) mais il est indéniable que la coupure des accès aux APIs ainsi que l'arrêt du support des apps va poser d'énormes problèmes à beaucoup de monde.