Le libre c'est la médiocrité, et les seules solutions envisageables pour des besoins d'envergures et modernes, ce sont les Gafam.
Heureusement que certains politiciens du XXe avaient un peu plus de hauteur de vue. Sinon l'Europe aurait été intégrée dans un bloc à l'est ou à l'ouest depuis belle lurette et ce ne serait pas en Ukraine que se déroulerait une guerre. En effet, ça pique. Le système est admirablement expliqué (quoique d'une point de vue US, où ça pique au moins autant) sur ce blog de C. Doctorow. Par exemple dans cet article, au titre évocateur de permanent overlords.
Quelqu'un peut me (lui) rappeler quel est le système d'exploitation de tous les super-calculateurs depuis des années au fait ? Rapport à la médiocrité.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
Ce qui devrait suffire à convaincre quiconque que le modèle du libre n'est nullement cantonné au gratuit, au médiocre, etc. Mais malgré cela, on ne cesse d'entendre répéter ces mêmes antiennes en litanie. Sans doute depuis le camp des marketeux ou des politiques non-comprenant.
Ce n'est pas vraiment un résumé fidèle. Il dit plutôt qu'être sous licence libre n'est pas une silver bullet/une garantie magique et que si tu n'arrives pas à suivre le rythme de ce qui est jugé nécessaire (par le législateur en termes de sécurité, par les utilisateurs en termes de fonctionnalités, etc.) alors tu te fais marginaliser d'abord, puis exclure ensuite.
Quelques personnes veulent du libre pour le libre, prioritairement à tout le reste ou très prioritairement en tout cas. Mais si une large majorité veut autre chose (l'ensemble du catalogue de fonctionnalités des GAFAM, des garanties annoncées de sécurité comme avec les dépôts d'application ou les clouds des hyperscalers, etc.), ben ça ne suffit pas ou plus ou surtout pas à tout le monde d'être libre.
Ca ressemble plus à l'hypothèse de la Reine rouge : pour rester dans la course, il faut continuer à avancer. Il ne faut pas être le meilleur partout, mais il ne faut pas se laisser distancer totalement non plus.
Absolument. C'est plus une expression d'humeur face à un texte qui m’horripile. J'espère que le ton était suffisamment virulent pour ne pas laisser imaginer une quelconque intention de neutralité ? Si certaines personnes veulent du libre pour du libre, d'autres veulent du proprio car personne n'a jamais été viré pour avoir choisi mirosoft. Deux positions politiques parfaitement antagonistes : Travaillons honnêtement à construire le monde opposé à laissons faire les puissants. Présenter l'une ou l'autre comme résultant de la seule logique la plus inéluctable me semble relever d'une forme de malhonnêteté par omission ; d'où ma réaction, histoire de rappeler que l'autre extrême existe.
Maintenant, il faut bien avouer que nos contemporains votent très largement pour la position que j'abhorre ; ce n'est pas une raison pour se taire.
L'hypothèse de la reine rouge n'implique-t-elle pas que tous les survivants en soient, très globalement, au même point ? nul ne progressant. C'est plutôt bon pour les petits joueurs et les acteurs non dominants. Non ?
De mon point de vue, cet article mélange allègrement des réflexions intéressantes avec des arguments franchement naïfs. Je pense notamment à tout le paragraphe sur les bricolages et la garantie apportée par les éditeurs à support payant.
E. Garantie
Pendant un an à compter de la livraison, Oracle garantit que les logiciels fonctionneront comme indiqué dans la documentation, sur tous les points essentiels. Vous devez avertir Oracle de tout manquement à cette garantie dans le délai d’un (1) an à compter de la livraison.
Oracle garantit également que les services seront fournis en conformité avec les règles de l’art. Vous devez avertir Oracle de tout manquement à cette garantie dans les quatre-vingt dix (90) jours à compter de l’exécution des services indiqués au bon de commande.
Les garanties ci-dessus sont limitatives, et Oracle ne garantit pas qu’Oracle corrigera toutes les erreurs, ni que les logiciels fonctionneront de manière ininterrompue ou exempte d’erreurs, ni l'aptitude des logiciels à satisfaire vos objectifs particuliers.
Si Oracle ne respecte pas les termes de la garantie ci-dessus, vous aurez exclusivement la faculté de (A) faire corriger les erreurs ou si Oracle est dans l’impossibilité d’y remédier pour l’essentiel à des conditions économiquement acceptables, de résilier le contrat de licence, et de vous faire rembourser le prix acquitté pour le logiciel ou les services de support technique non utilisés ou (B) faire réexécuter les services défectueux ou si Oracle est dans l’impossibilité d’y remédier à des conditions économiquement acceptables, de mettre fin aux dits services et de vous faire rembourser du prix acquitté pour les services défectueux.
L'état devrait dans ce cas endosser les responsabilités, sans possibilité de recours au défaussement rituel sur prestataire … Il devrait de ce fait assumer une charge salariale associée, quand les fonctionnaires sont vu comme des bouffe-culotte que le dogme se doit d'éradiquer.
Posté par Yth (Mastodon) .
Évalué à 6 (+5/-1).
Dernière modification le 19 février 2024 à 09:30.
Ou même avec des prestataires existants, imposer une obligation de mise en conformité avec des délais clairs, et l'argent qui arrive dès le début du contrat, ça peut aussi suffire à avoir un acteur cocorico qui remplirait, pour le coup, l'intégralité du cahier des charges.
En quoi, un an ? Deux ans ?
Ce ne sont pas les compétences techniques qui manquent, c'est comme partout en France, c'est l'argent qui manque, on est trop occupé à le faire sortir de nos frontières cet argent, pour réussir à l'utiliser utilement.
Très clairement le problème est aussi politique de ce côté. Les GAFAM sont aussi ce qu’ils sont parce que les US font de la commande publique et des subventions à mort.
L’intégralité du budget de Google est déjà rempli pour les 10 prochaines années juste avec les contrats étatiques de l’armée américaine… 9 milliards de dollars à se partager entre les 4 fournisseurs cloud américains rien que pour le budget 2020 du JWCC. Etc.
Forcément que tu peux innover…
Autant je ne suis pas pour le protectionnisme, ou en tout cas pas à outrance, mais j’y suis carrément opposé quand c’est uniquement pour sauver des éco-systèmes qui n’ont juste pas réussi du tout à se tenir à jour.
Je ne saurai dire si ça relève d’un cercle vicieux du protectionnisme (US) qui appelle le protectionnisme (EU) ou si c’est juste qu’on a totalement été à côté de nos pompes, certainement un truc entre les 2 comme toujours. Mais aujourd’hui vouloir continuer à maintenir en vie des trucs qu’on devrait plutôt euthanasier parce qu’ils arrivent très clairement au bout du rouleau, c’est quand même assez con…
On est totalement passé à côté de la réalité concrète du bordel sur plein de sujet et on le paie dorénavant très cher.
On a le même problème avec la plupart des business modèles du moment qui sont juste totalement illégaux, mais on préfère avoir des politiques qui tentent de sauver les meubles quitte à juste reculer pour encore plus mal sauter que de juste dire « déso pas déso, mais pour vous c’est la fin ».
Mais forcément, un politique qui va annoncer des millions de licenciement et la remise à plat de tout le système… c’est pas méga vendeur…
Le problème c'est que nos "Huiles Essentielles" pourtant issues pour la plupart du monde juridique sont incapables de faire un contrat qui ne soit au détriment de l'Etat. (cf les concessions d'autoroutes, délégations de services publiques, les recours aux cabinets d'expertises, les contrats de prestatations etc…)
Ou alors les élites savent mais ne veulent pas, mais je n'ose y penser.
Il faut savoir être honnête aussi : un tel système construit par l’État risque de coûter bien trop cher pour être financé exclusivement par l’impôt. Les partenariats public-privés sont aussi là en mode « nous on peut pas vous financer intégralement, vous financez le complément et vous repartez avec les bénéfices ».
Le problème en France est effectivement surtout qu’on est très mauvais pour réellement avoir des contrats donnant-donnant et qu’on finit souvent complètement plumé par le privé.
C'est une question de volonté politique, c'est tout.
On est capable de dépenser des milliards dans bien des projets dont l'utilité au long terme est discutable et sans aucune garantie de retour sur investissement.
(cf les JO2024 cible facile mais pas seulement, tous les grands événements passés, y compris la Coupe du Monde de foot 98 considérée comme une réussite laissent des ardoises pharaoniques à la puissance publique)
S'agissant de données de santé des citoyens, on aurait pu en faire une priorité stratégique nationale.
Concernant les PPP, c'est, au mieux, un artifice comptable coûteux pour ne pas laisser apparaître une dette supplémentaire.
Il y a un audit européen sur les PPP. C'est assez saignant, même si ça date de 2018, un extrait:
"Ainsi, 1,5 milliard d’euros, dont 0,4 milliard d’euros de fonds de l’UE, ont été dépensés de manière inefficace…ces partenariats risquent fort de ne pas contribuer dans la mesure voulue à la réalisation de l’objectif qui consiste à mettre en oeuvre davantage de fonds de l’UE au moyen de projets bénéficiant de financements mixtes, entre autres des PPP."
D'autres audits de cours des comptes régionales semblent aller assez dans le même sens.
Dans le Canard Enchaîné les articles se sont accumulés sur le "Balardgone" (l'Etat Major des forces armées, en PPP), l'hôpital Sud Ile-de-France, divers chantiers de BTP y compris des routes construits en PPP, où au final la puissance publique aura dépensé 2,3,4 fois le prix qu'aurait coûté au complet un équipement équivalent même avec des taux d'intérêt élevés.
N'y a-t-il pas simplement désaccord sur la définition de ce qu'est une réussite entre les partis ? D'un côté, ceux qui pensent collectif et qui aimeraient voir se développer la société, et de l'autre les individualistes dont l'objectif est de se remplir les poches le plus efficacement possible ? De ce dernier point de vue, une grande commande public est toujours une aubaine ; quelle qu'en soit le l'appréciation des résultats par les premiers, sauf intervention des juges et passage par la case prison.
Posté par MrBidon .
Évalué à 5 (+5/-1).
Dernière modification le 19 février 2024 à 09:51.
Dans ce billet, il y a des sources très intéressantes.
Par contre, le monsieur, c'est tout ce que je n'aime pas, par exemple :
Il semble ok de voir des GAFAMs (le bien) en concurrence libre et non faussée avec des PME Européenne, par contre, c'est ok pour de contrôler les caisses, parce que les indépendants (le mal) ne font que gruger la TVA.
Je sens aussi un élitisme nauséabond dans le paragraphe où il décrit que le méchant libre permet de rendre accessible la technique à tout le monde, et ce n'est pas sécurisé sous prétexte que "les gens" ne comprendraient pas les tenants et aboutissant.
Je ne pense pas qu'il porte particulièrement les GAFAM dans son coeur (vu son historique personnel et son rappel de Schrems II) mais je pense qu'il déplore le fait que les prestataires européens n'ont rien à proposer en face de ce que les géants américains proposent. Mais il a le ton souvent outrancier, ce qui amha déforce son propos.
On peut aussi se demander la pertinence de ce que les appels d'offres demandent, certains appels d'offre sont très maximalistes et demandent des trucs qui ne seront vraisemblablement jamais nécessaires ni utilisés (un peu comme pour les offres d'emplois, tiens).
Par contre si la loi demande une certification (la TVA n'est qu'un exemple), et bien il est logique que tous les acteurs soient certifiés, et le fait d'être indépendant en soi n'est pas une bonne raison pour le pas le faire. Par contre le coût de la certification est parfois (souvent?) prohibitif et peut rendre les choses compliquées pour les petits acteurs, par exemple si l'on doit certifier chaque version de chaque logiciel plutôt que la société en elle-même. Mais en Europe on aime bien les certifications et la législation à outrance. C'est souvent présenté comme une façon de contrôler les géants américains mais en pratique ça rend également très compliqué l'accès au marché par les petits acteurs. C'est aussi ce dont se plaignent les agriculteurs dans leur domaine, par ailleurs, et c'est surprenant quand en façade certaines personnaltiés mettent en avant le logiciel libre comme une solution à l'hégémonie logicielle américaine.
On est d'accord, il y a un soucis. On légifère à outrance et en plus, on met les entreprises locales en concurrence "à égalité" avec les entreprises étrangère. C'est pourquoi il y a des appels d'offre spécifiques pour favoriser les entreprises locales, il n'y a pas d'autre moyen (à ma connaissance) pour que les institutions puissent favoriser ces entreprises locales, mais comme tout, il y a certainement des abus. Idéalement, il faudrait que cela soit possible légalement et que les institutions disposent d'outil pour cela, actuellement cela n'existe pas.
et c'est surprenant quand en façade certaines personnaltiés mettent en avant le logiciel libre comme une solution à l'hégémonie logicielle américaine.
Je ne vois aucune raison de privilégier plus les entreprises locales des entreprises étrangères. On est actuellement dans un monde globalisé où on s’en cogne un peu complètement de ta nationalité. Pourquoi est-ce qu’on irait payer plus cher un produit plus merdique juste parce qu’il est FR alors que le concurrent DE ou US fait mieux pour moins cher ?
Si encore le produit FR n’est pas foncièrement trop éloigné des caractéristiques et des coûts de la concurrence, bon ok pourquoi pas faire un petit effort pour le privilégier et payer 10% de plus pour faire local avec peu ou prou les mêmes fonctionnalités. Mais quand les écarts sont juste abyssaux…
Sans parler que typiquement, s’il y a bien un truc que t’as pas spécialement envie de voir dans les mains de ton État, c’est bien tes données de santé…
Point Godwin, mais il n’y a pas si longtemps, la Stasi aurait été ravie d’avoir juste un select à faire dans une base de données pour choper tous les handicapés, les juifs ou les homosexuels de sa population et que c’est aussi ce genre de problème qui a conduit à la fondation de la CNIL en 1978…
Il y a du coup certainement un compromis à faire à ce niveau entre favoriser du national et se protéger d’un éventuel petit problème de changement de régime politique…
Le 100% FR n’est pas non plus une balle en argent. Surtout à l’approche de 2027…
Pour l’avoir vécu en direct avec la réquisition illicite de mes machines sur décision illicite d’un juge sur impulsion illicite politique après une décente de police illicite dans le datacenter d’un hébergeur français, les avoir héberger en Allemagne ou aux Pays-Bas m’aurait éviter beaucoup d’ennuis et de frais de justice…
Le point Godwin c’est pour les références au nazisme non ? J’ai l’impression que tu t’es mélangé : la stasi c’était l’Allemagne de l’est, sous contrôle de l’URSS.
je ne vois aucune raison de privilégier plus les entreprises locales des entreprises étrangères. On est actuellement dans un monde globalisé où on s’en cogne un peu complètement de ta nationalité.
Ben quand les autres pays (coucou les US) passent leur temps à faire ça, et sont susceptibles de profiter de leur “accès” pour faire de l’espionnage sans vergogne (industriel, commercial ou politique) je crois pas que les raisons de leur rendre la pareille manquent vraiment. Qu’on le fasse mal c’est une chose et je te rejoins là dessus. Mais de là à tendre la deuxième joue, ça ressemble à du masochisme.
C’est un peu différent pour les US. Ou la Chine d’ailleurs. Ils ont fait en sorte d’avoir des entreprises nationales qui répondent à leurs besoins et ne les tiennent pas en vie sous perfusion aux soins palliatifs alors qu’elles sont totalement obsolètes. Au contraire ils injectent de l’argent pour les conserver dans la course au niveau décent attendu par l’état de l’art.
Pour faire le parallèle avec ce qu’on vit en France avec le parc nucléaire, c’est la différence entre maintenir dans la course ton fleuron industriel national en lui commandant chaque année des réacteurs en plus qui lui subventionnent les études de la prochaine génération et le maintenir sous perfusion d’argent public pour qu’il ne meurt pas parce que tu ne lui en as plus commandé depuis 20 ans et qu’il s’avère incapable d’en faire dorénavant…
Ça coûte le même pognon, sauf que dans un cas tu as de la Gen3 et tu attaques la R&D de la Gen4 et dans l’autre de la Gen2.5 où tu patauges à sortir de la Gen3…
C’est aussi tout le problème du truc, c’est que le jour où tu arrêtes la commande publique… le système s’effondre tout seul. A priori Google ou Amazon cessent d’exister tels qu’on les connaît si la commande publique disparaît.
Et oui, une fois que tu es compétitif par rapport à tout le reste, ben tu profites aussi de ta position dominante… Les Chinois et les Américains peuvent se tirer la bourre avec leur techno et envisager de striker le concurrent du marché, ils s’en foutent ils n’ont pas besoin du voisin et ça fait parti des négociations.
Quand t’es l’Europe et dépendant des 2 autres, c’est pas la même chose… Difficile de mettre dans la balance l’arrêt des imports ou des exports, t’as rien à leur proposer et ils savent que sans eux, tu crèves 🤣
C’est pas vraiment fait pour me convaincre. Ce que je comprends de ton point de vue : “c’est trop tard, alors perdu pour perdu maintenant on se fout de tout”.
Il y a quand même moyen de faire mieux que ça. Moi ça me fait chier de me dire qu’on contribue maintenant fortement à aider ces entreprises à maintenir leur avance.
Ben c'est un peu ça.
Et puis là on parle d'informatique, pas de nucléaire, le problème est très différent, et en vrai il n'y a pas lourd, ni en temps, ni en investissement, à rattraper pour être au niveau des clouds Ricains.
Que la France ait gérée, et continue de gérer, comme une ignare, la situation d'EDF, c'est un fait, et c'est déprimant, et ça coûte une blinde.
Mais en informatique, le privé a juste besoin de la confiance des états, et de commandes publiques.
En dehors de CapGemini bien sûr…
Et peut-être aussi de ne pas financer la propriété intellectuelle américaine avec le CIR, ça serait pas mal, comme ça, ça coûterait pas un centime au contribuable, on flèche l'argent public vers les projets publics, une idée con, comme ça…
C’est pas tant de dire que tout est foutu mais que la décision du HDH n’est pas forcément si débile que ça. Oui on peut encore réagir, mais à date, ça va être difficile. Et si tu ne veux pas accumuler du retard côté santé, faut AUSSI avancé sur le HDH.
"Too big to fail" ça n'existe pas.
Les GAFAM finiront aussi par se casser la gueule un jour.
Et ce jour-là, il est préférable d'avoir d'autres acteurs pour assurer la continuité de service au mieux.
Mieux encore, d'avoir des acteurs déjà implantés, qui connaissent le marché et maîtrisent leurs technos.
Bref, l'argument "too big to fail", très peu pour moi. Ça me conforte au contraire dans l'idée que j'ai bien raison de multiplier les acteurs pour mes différents services et de ne pas tout concentrer au même endroit (et encore moins chez les GAFAM).
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
Too big to fail, ça veut pas dire que le système économique de l'organisation est fiable. Ça veut dire que cette organisation constitue le socle du tissu économique à une certaine échelle, et que si cette organisation vient à être démantelée (liquidation, antitrust, etc.), alors il y a une révolution systémique à faire. Et ça, c'est quelque chose dont personne ne veut, en général.
Donc tout le monde va essayer de sauver cette organisation, en injectant des fonds publics ou en changeant la loi. Wikipédia est assez succint (https://fr.wikipedia.org/wiki/Too_big_to_fail) mais pour le coup, c'est à peu près ça.
Sans parler que typiquement, s’il y a bien un truc que t’as pas spécialement envie de voir dans les mains de ton État, c’est bien tes données de santé…
Et donc c'est mieux de les filer à un état tiers dont les intérêts ne coïncident pas avec les nôtres, et qui pourrait utiliser ça contre nous, citoyens, l'état français, etc ?
Avec un Trump au pouvoir, qui sait ce qu'ils vont encore inventer.
Déjà que leur juridiction a vocation supra-nationale, donc qu'ils se sentent le droit de faire chier des entreprises étrangères qui font du business à l'étranger, parce que ce business ne respecte pas leurs règles nationales, on a quand même affaire à un machin un brin envahissant…
Je veux dire, quitte à choisir entre la peste et le scorbut, prends le scorbut et achète des fruits, au final tu t'en sortiras mieux, et pour moins cher !
Je pige toujours pas l'argument moi.
D'un côté on préférerais entretenir des monstres états-uniens qui n'ont pas besoin de ça pour nous plumer, de l'autre on pourrait faire des appels à projet et des subventions, qui pour une fois pourraient ne pas être perdus, et reviendraient moins cher. Parce que bon, ça coûte une blinde de se faire plumer.
C'est pas la technique le problème, ils sont pas plus intelligents dans la Silicon Valley, ils sont pas plus compétents non plus, et derrière on utilise tous les mêmes logiciels, qui sont très majoritairement des logiciels libres, et tout ça tourne sur du Linux, et ya plein de gens qui savent administrer du Linux en France, et encore plus en Europe…
Et s'il faut se protéger de son propre état, peut-être que comme tu dis, on peut faire héberger ça juste à côté, en Allemagne, en Roumanie, en Islande.
Ça serait nettement mieux politiquement : les données personnelles Européennes sont gérées en Europe, ya pas de protectionnisme commercial ici, ça ressemble plutôt à du bon sens.
Déjà que leur juridiction a vocation supra-nationale
Question simple : as-tu déjà vu réellement un débordement de FISA ou du Cloud Act ? La réponse est assez simple a priori : ça n’existe juste pas. Manhack avait débunké ça dans son article cité dans le mien, et les gens se font tout un patakès d’un truc qui en vrai sont juste des accès juridiques rapides comme il en existe des tonnes un peu partout dans le monde et en Europe. Ce n’est pas une porte ouverte à toutes les fenêtres.
Cet argument est juste un argument pour aller taper gratuitement sur les US sans avoir à se justifier plus que ça (et je reconnais moi-même l’utiliser en ce sens), mais sans action AUSSI côté EU, Schrems II est un non argument.
Qu’est-ce qu’un gouvernement étranger peut faire de mes données de santé ? Globalement rien.J’ai bien plus peur d’une action de mon gouvernement qui peut me foutre en zonzon quand il a envie sans avoir à se justifier que d’un gouvernement étranger qui voudrait en faire de même.
Je veux dire, quitte à choisir entre la peste et le scorbut, prends le scorbut
et achète des fruits, au final tu t'en sortiras mieux, et pour moins cher !
Je pige toujours pas l'argument moi.
Tu supposes qu’on a des fruits. On n’en a pas.
de l'autre on pourrait faire des appels à projet et des subventions, qui pour
une fois pourraient ne pas être perdus, et reviendraient moins cher. Parce que
bon, ça coûte une blinde de se faire plumer.
Ça aurait été vrai si on avait agit au départ. On a dorénavant une 15aine d’années sinon plus de retard sur les systèmes US et rattraper le retard coûtera HORRIBLEMENT plus cher que de continuer à engraisser l’Oncle Sam.
Oui, on peut encore agir, mais ça va faire VRAIMENT SA MÈRE mal.
On parle de rattraper au moins 15 à 20 ans de subventions à 2 milliards d’euro sur un seul projet pour quatre hébergeurs. Soit au bas mot une enveloppe de quelques centaines sinon milliers de milliards à foutre sur la table en quelques années. Et en provisionnant déjà les subventions à venir et à maintenir chaque année.
Rien qu'en regardant les caractéristiques visibles de l'extérieur pour la gestion des emails de LaPoste ou de Wanadoo/Orange, et tu te demandes comment ce genre d'entreprises peut arriver à un résultat aussi médiocre.
Même Free.fr s'en sort mieux.
Du coup, les gens qui n'hébergent pas leurs emails chez des "pro" comme OVH ou Hetzner comparent ce qu'ils ont avec LaPoste ou Orange, et décident d'aller tout mettre chez Gmail parce que "ça marche", et on ne peut pas dire qu'ils ont tord, même s'ils ne se rendent pas compte qu'une partie des emails qui arrivent chez Gmail sont filtrés silencieusement et arbitrairement.
C'est dommage parce que ce qu'on a chez les Chatons, OVH ou Hetzner (par exemple) fonctionne bien mieux.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
Surtout qu’on a de vraies bonnes formations et d’excellents ingénieurs en informatique et électronique en France. Si je prends le premier exemple qui me vient à l’esprit, Quarkus est fortement porté par RedHat France. On a même été précurseurs dans certains domaines (rappelez-vous la carte à puce, le Minitel…)
Par contre, on accumule des décennies de décisions politiques et économiques contre nos industries (et ça n’est pas un appel à lorgner du côté du modèle social américain !), y compris l’informatique. D’ailleurs, l’informatique est peu vue comme une industrie en France, et rien que ça c’est un problème, notamment quand il s’agit d’investir dans des outils. L’Europe (via l’UE ou autres) aurait aussi pu permettre l’émergence d’énormes forces industrielles capables de concurrencer les USA, la Chine, etc., mais non, on a préféré faire chacun dans son coin son petit truc et préférer faire la Sainte Concurrence et le Libre Marché avec les résultats que l’on a aujourd’hui.
Posté par Yth (Mastodon) .
Évalué à 7 (+5/-0).
Dernière modification le 19 février 2024 à 20:21.
J'ai failli répondre aussi sur les Chatons et Framasoft.
La preuve qu'une poignée de bénévoles, et quelques salariés associatifs peuvent fournir des services pertinents et efficaces.
Imagine la même avec des entreprises et des subventions, ou des marchés publics, et la confiance de nos entreprises locales aussi.
On parle d'informatique, l'état de l'art il est dans le logiciel libre, et n'importe qui y a accès.
Il y a /e/, Murena, aussi, en cocorico, qui donne certainement une meilleure sécurité qu'un quelconque iPhone.
Franchement un truc comme Commown/FairPhone/Murena, tu as un meilleur service et un meilleur support à long terme que ce que tu peux trouver chez Apple.
J'ai failli répondre aussi sur les Chatons et Framasoft.
La preuve qu'une poignée de bénévoles, et quelques salariés associatifs peuvent fournir
des services pertinents et efficaces.
Mais illégaux. Comme déjà signalé par NOYB et j’en fais aussi le constat, la plupart des systèmes y compris libres violent la majorité du temps la plupart des obligations légales de sécurité.
Typiquement Mastodon viole frontalement le RGPD par pilées de 12, ça leur a déjà été remonté, et ils en ont rien à foutre.
Je suppose qu’on lâcherait une APD fonctionnelle sur les Chatons, soit les opérateurs soit les utilisateurs se prendraient des prunes dans les mêmes volumes.
Aller, pour rigoler, combien de Chatons ont un SIEM, un IAM ou juste simplement des interfaces d’administration dédiées au niveau matériel et non exposées au net ?
On est en train de te dire que des assoces, et des particuliers, rendent des services qui fonctionnent, là où des boulets comme Orange et Laposte n'y arrivent pas.
Et que donc le problème n'est pas technique.
Une entreprise peut parfaitement se positionner sur ce créneau et faire un service qui marche, tout ce qu'ils ont à faire c'est de pousser, professionnellement, au niveau du respect des réglementations.
Mais la partie technique du service se fait à la maison sur un Raspberry Pi (j'exagère à peine pour le mail), avec 2FA, chiffrement des données, SPF, DKIM, annuaire, et tout le tintouin.
Par contre, prends tes mails chez OVH et ça va juste marcher.
Offre-leur un extincteur pour noël aussi, ils en manquent…
Donc quand derrière tu parles de 15 ans de retard et de milliards de dollars, je suis toujours autant largué par ta vision des choses, que je peine à trouver cohérente.
Concernant Mastodon et le RGPD, voilà quelques règles du RGPD :
Transparence des conditions générales d’utilisation des réseaux
Droit à la portabilité des données pour les internautes
Conditions adaptées pour les utilisateurs de moins de 15 ans
Obligation d’autorisation parentale pour l’inscription des mineurs
Que je sache, il n'existe pas le moindre réseau social qui remplisse ces conditions, à part la première, et la seconde pour quelques cas particuliers, dont aucun des grands réseaux américains (tu peux récupérer tes données, au moins en partie, mais ça n'a rien de portable).
Je veux bien qu'on crache sur Mastodon, mais va pas me dire que TwitBook fait mieux ici…
Transparence des conditions générales d’utilisation des réseaux
Les CGU de la plupart des instances sont illicites.
Donc transparence c’est cool, mais si c’est parce que t’as oublié les ¾ des mentions obligatoires…
Droit à la portabilité des données pour les internautes
Qui n’est pas complète et donc illicite.
Actuellement on perd le contenu.
Même Twitter est meilleur. Mon ancien compte est dispo ici : https://twitter.imirhil.fr/.
Mon ancienne instance Mastodon par contre…
Conditions adaptées pour les utilisateurs de moins de 15 ans
Obligation d’autorisation parentale pour l’inscription des mineur
Existe chez la plupart des GAFAM.
Et tu as oublié l’article 15, respecté par les GAFAM et pas par Mastodon, l’article 13 dont Mastodon refuse la mise en œuvre (et pas les GAFAM), etc.
Conditions adaptées pour les utilisateurs de moins de 15 ans
Obligation d’autorisation parentale pour l’inscription des mineur
Existe chez la plupart des GAFAM.
T'as vu ça où toi ?
C'est le même bouton « j'ai plus de 18 ans, promis, sisi » que sur les sites classés X c'est ça ?
Transparence des conditions générales d’utilisation des réseaux
Les CGU de la plupart des instances sont illicites.
Donc transparence c’est cool, mais si c’est parce que t’as oublié > les ¾ des mentions obligatoires…
Constatation qui s'applique à tous les MAGAF que je sache, les conditions illicites dans les CGU c'est un grand classique de… absolument partout.
Je ne vais pas faire de différence ici, il faudrait être légiste et étudier en détail, mais quand les CGU sont longues comme un romans, on peut douter de leur légalité globale étant donné qu'il apparaît comme évident que personne ne les a lues, et certainement pas comprises, en détail, et donc que l'acceptation est de facto obtenue sans réel consentement.
Ce qui est /moins/ vrai sur Mastodon…
Droit à la portabilité des données pour les internautes
Qui n’est pas complète et donc illicite.
Actuellement on perd le contenu.
Même Twitter est meilleur. Mon ancien compte est dispo ici : https://twitter.imirhil.fr/.
Mon ancienne instance Mastodon par contre…
Bah tu peux les exporter tes données, et les importer sur une autre instance Mastodon, il y a même des systèmes pour basculer ton identité sur une autre instance.
Ça ressemble nettement plus à de la portabilité que ton bidule statique bricolé à partir des données exportées depuis Twitter.
Comme tu ne peux importer ça nulle part, y compris sur Twitter, c'est difficile d'appeler ça de la « portabilité ».
Tu peux récupérer tes données, ok, mais c'est vraiment pareil sur Mastodon hein, avec la portabilité en plus…
Et tu as oublié l’article 15, respecté par les GAFAM et pas par Mastodon, l’article 13 dont Mastodon refuse la mise en œuvre (et pas les GAFAM), etc.
J'ai pris les 4 règles mises en avant sur le site du RGPD, pour les réseaux sociaux, ici : https://donnees-rgpd.fr/traitement-donnees/reseaux-sociaux/
Je n'ai jamais prétendu être exhaustif, simplement que rien qu'avec ces 4 règles là, personne sur le marché ne remplis vraiment les conditions.
Si personne ne remplis les conditions, j'ai du mal à saisir l'objectif de mettre spécifiquement les défauts de Mastodon en avant, qui plus est avec de la mauvaise foi.
Franchement, soit tu trolles, soit tu as un biais énorme vis-à-vis des MAGAF et de leur capacité à respecter les règles, lois, etc.
Ils se mangent quand même régulièrement des amendes délirantes pour non-respect du RGPD, entre autre, mais ça ne te dérange pas de colporter la légende de leur perfection, et du fait qu'ils seraient les seuls à pouvoir remplir le cahier des charges, et qu'ils auraient même 15 ans d'une avance irrattrapable ?!
J'en rigole encore…
Un brin jaune cependant.
Je n’ai pas dis qu’ils rempliraient à la perfection les cases de sécurité.
Je dis que de tous les systèmes que j’ai pu auditer, de près ou de loin, en interne comme en externe, ceux qui ont actuellement sur les tables d’autopsie des autorités de protection des données les dossiers les plus petits de ma part sont les GAFAM.
Et que la plupart des problèmes auxquels ils font face sont généré in fine par leurs propres clients et non par leur business direct.
À l’inverse les dossiers les plus importants que j’ai eu à faire sont ceux concernant des entreprises FR ou du logiciel libre. Je galère plus avec des admins ou développeurs d’instances Mastodon pour leur faire comprendre le RGPD qu’à des gus de chez Google ou de l’IAB, ils sont moins de mauvaise foi.
Qui a été capable de répondre correctement et dans les temps à une demande d’accès RGPD ? Les GAFAM.
Qui a été capables de propager des demandes d’opposition correctement et efficacement ? Les GAFAM.
Qui est capable de détecter le mésusage des interfaces d’administration grâce à du SIEM et procèdent au licenciement de plusieurs milliers d’employés indélicats chaque année ? Les GAFAM.
Qui ont des mécanismes capables de gérer les droits d’effacement et d’opposition jusque dans les systèmes de sauvegarde avec la mise en place de clefs de chiffrement individualisées dont il suffit de détruire la clef pour détruire les backups ? Les GAFAM.
Oui leurs pubs est pas cool mais qui a été capables de me filer tous les affichages de mon profil et l’ensemble des annonceurs concernées ? Les GAFAM. En face en France les boîtes se font sanctionner par la CNIL pour avoir refuser de communiquer les annonceurs…
C’est pas parfait, la preuve, ils se prennent des amendes. Mais quand tu vois toutes les amendes qui tombent, surtout dans les pays avec des APD fonctionnelles, ça pique fort sur les non GAFAM. Plus fort.
L’Espagne qui a une des APD les plus efficaces, Google c’est 1 sanction, Facebook 0. À l’inverse Vodafone c’est 75 condamnations, les banques 11, les assos on en est déjà à 25 sanctions, et même les particuliers on en est à 154. Si on les lâchait en France, ça serait des amendes pour tout le monde ou presque.
Et rappelons aussi un truc que les gens oublient vachement beaucoup : les GAFAM ne se rémunèrent pas par la pub. Pas dans le sens que les gens le pense. Les GAFAM se rémunèrent sur le pourcentage qu’ils touchent de leurs clients qui vendent d’un côté des placements produits et de l’autre des emplacements publicitaires.
Demande au marketing de chez toi ce que ça fait si Facebook ne leur envoie plus leur KPI de placement produit que eux ont demandé de cibler, tu vas voir, ils vont pleurer.
Le vrai problème des GAFAM est surtout leur taille, qui induit effectivement des effets de masses à la con.
Crois-moi, le marketing de ma boîte, il en a rien à faire des MAGAF…
Il se fait plutôt à Matignon ou à Bruxelles, et il rapporte plein de brouzoufs.
J'en suis pas spécialement fier, au contraire.
Bon, sinon, Framasoft, zéro amendes pour violation de RGPD, et pourtant leur forge logicielle a même été utilisé pour notre gouvernement pour les codes de Parcours Sup.
Comme quoi, c'est peut-être pas intrinsèque à la techno utilisée hein ? Ni même au pognon disponible ?
J'en ai pas vu passer non plus pour Scaleway, pour revenir au sujet initial de fournir un HDH compliant.
Ou pour OVH non plus, mais bon, je ne vois pas tout non plus.
Il y a des centaines d'instances Mastodon, tu sais trouver des exemples d'instances qui se foutent du RGPD, et tu en conclus que c'est la techno et le modèle qui sont pétés ?
Que hors-MAGAF point de salut là encore ?
Qui a été capable de répondre correctement et dans les temps à une demande d’accès RGPD ? Les GAFAM.
Bah c'est sûr que même si ça représente peu de choses, une amende de 50 millions (par la CNIL en 2019) ça pousse à embaucher quelques gusses pour répondre aux demandes RGPD, ça revient vite moins cher.
Mais pour s'être bouffé l'amende la première fois, c'est peut-être qu'ils étaient pas si raccord, et si preste que ça à répondre sans se foutre de la gueule de la CNIL.
Après, j'interprète peut-être mal hein, et surtout je ne sais pas ce qu'il peut se passer avec les petites instances Mastodon.
Par contre je suis sûr que ça ne signifie pas qu'un service basé sur Mastodon ne peut pas exister et être parfaitement réglo.
Ou qu'un HDH européen ne peut pas exister sans « 15 ans de retard et 1000 miliards d'investissements ».
Évidemment, si on mise sur Orange - ou Vodafone - il en faudra le double et au bout du compte ça ne fonctionnera pas.
Posté par Aeris (site web personnel) .
Évalué à -2 (+2/-5).
Dernière modification le 20 février 2024 à 00:20.
Bon, sinon, Framasoft, zéro amendes pour violation de RGPD, et pourtant leur forge logicielle a même été utilisé pour notre gouvernement pour les codes de Parcours Sup.
Ne pas avoir d’amende ne veut pas dire que tu es conforme avec la loi
Sais-tu que la CNIL (qui est une APD déficiente d’ailleurs, au même titre que la DPC) recommande actuellement un logiciel (libre) pour l’éducation nationale qui représente actuellement un contrôle là-bas pour la violation de la totalité du RGPD de l’article 5 à l’article 50 et un joli dossier de plus d’une centaine de pages de violation RGPD diverses et variés ? Et même a priori qu’elle ne veut pas le sanctionner et abuse de délais de réponse effroyables et de pirouettes juridiques pour éviter d’avoir à le faire ? Certainement pour cause d’ordre politique d’ailleurs… T’aurais été chez Pronote t’aurais eu moins de problème…
Il y a des centaines d'instances Mastodon, tu sais trouver des exemples d'instances qui se foutent du RGPD, et tu en conclus que c'est la techno et le modèle qui sont pétés ?
Toute sauf les self-hosted mono utilisateur (exemption de RGPD article 2(2)c, et encore c’est compliqué). Actuellement des fonctionnalités sont en dur dans le code en violation du RGPD (les notes libres sur un compte utilisateur violent l’article 13 du RGPD et les lignes directrices de la CNIL sur les champs libres). Le manque de certaines fonctions aussi (auditabilité des accès et action administrateur qui violent les principes d’accountability et sont une obligation légale). À ma connaissance aucune instance n’a un DPA digne de ce nom et encore moins légal avec leur sous-traitants, tout ceux dispos en ligne étant illicites puisqu’il manque des clauses obligatoires (et que la CNIL en a déjà condamné 2 ou 3 des comme ça). La quasi totalité des instances n’ont aucune privacy policy ou juste pas licites. Aucune instance ne sait répondre à une demande d’accès article 15, les registres de traitement sont inexistants, le droit à la portabilité est incomplet…
Les instances principales ont basculés sur Cloudflare, en violation de Schrems II. D’autres ont activé reCaptcha, aussi en violation de Schrems II et des sanctions CNIL sur le sujet.
Eugen et sa clique refusent voire réfutent l’applicabilité du DSA (https://www.contexte.com/actualite/tech/plateformes-le-mastodon-dans-la-piece-2_160879.html)
Les propos même de Eugen font extrêmement peur. Le mec est littéralement le développeur principal d’un réseau social mais vient annoncer la bouche en cœur qu’il ne traite aucune DCP… https://github.com/mastodon/mastodon/issues/7280#issuecomment-385376837
Ça devrait juste allumer des warnings de partout que ce mec ne sait juste absolument pas de quoi il parle…
Je pige pas, tu me pointes une discussion sur github qui date de avril à juin 2018 (bientôt 6 ans tout de même, ça ne dit pas grand chose sur la situation aujourd'hui), avec des débats, des échanges, des discussions, on y trouve des informations sur ce qui va, et potentiellement ne va pas.
Une forme de conclusion semble être que ça respecte si derrière le serveur fait pas n'importe quoi, et que de toute façon ce n'est pas le logiciel qui doit respecter le RGPD mais l'instance, ce qui semble logique…
Je ne vois pas Eugen et sa clique refusent voire réfutent l’applicabilité du DSA dans cet échange.
Il va falloir être beaucoup plus précis là…
C’est toi qui est de mauvaise foi ici.
Je te cite une position WTF de Eugen, qui n’a pas changé depuis. Je t’ai cité tout un article de Contexte qui étudie le problème. Je t’ai cité un avocat du numérique parmi le plus réputé en France sur ce sujet qui te dit qu’il y en a un.
Je peux continuer encore hein.
Posté par Aeris (site web personnel) .
Évalué à 1 (+3/-3).
Dernière modification le 20 février 2024 à 10:07.
Et quand à dire « oui mais c’est l’instance qui doit respecter », déjà c’est faux, Mastodon agit en co-responsabilité de traitement (ils définissent et les moyens et des finalités sans demander l’avis préalables de toutes les instances, et en particulier ne permettent pas à une instance de ne pas activer les nouvelles fonctionnalités sans perdre les mises à jour de sécurité) et donc pas en sous-traitant et conserve donc la responsabilité mais en plus même si c’était vrai, ça sert à quoi de développer un soft européen si PERSONNE n’a légalement le droit de s’en servir sans devoir tout recoder ?
Étant donné que la plupart (je n'ai pas tout lu) des tickets sont ouverts et pas fermés "won't fix", je trouve que c'est malhonnête de ta part de dire que les auteurs s'en foutent.
Il y a clairement un manque de prise en compte de la RGPD et une réactivité très molle, se défaussant sur le fait que si c'est pas utilisé par une entreprise la RGPD ne s'y applique pas.
Mastodon n'est pas un réseau social, c'est un serveur activity pub qui peut s'interconnecter avec d'autre. Il serait certe mieux de promouvoir un outil qui permet à chaque admin de respecter la RGPD facilement, mais ça reste une responsabilité individuelle de chaque admin.
Maintenant l'Union Européenne a sa propre instance Mastodon (mais pas avec ouverture de compte ouverte), donc je pense que comme dans chaque changement de législation il y a un délai de mise en conformité accordé à tous les acteurs. J'imagine qu'on peut accepter qu'un logiciel libre développé par une petite équipe financée par des dons avec un budget annuel de 10000€ n'ait pas la même vitesse de mise en comformité.
C'est plutôt des services comme masto.host qui vendent de l'hébergement Mastodon qu'il faut se plaindre je dirais.
Le RGPD, c’est approbation du texte par le Parlement UE en décembre 2015, entrée en vigueur en mai 2016, avec mise en application des sanctions en 2018, le tout alors qu’il existait du coup déjà la directive 95 depuis 1995 qui était plus ou moins équivalente…
Quand t’as un projet qui démarre, qui veut faire la nique aux GAFAM, la 1ère chose à peut-être faire… c’est de ne juste pas inclure DU TOUT de violation dès le départ ?
On ne parle ici pas de se mettre en conformité avec un soft existant de 20 ans d’âge et une législation qui a évolué depuis que tu l’as lancé. Mais d’un nouveau produit qui se lance sur le marché dont le 1er commit date du 20 février 2016 donc APRÈS l’approbation du texte et 4 mois avant l’entrée en vigueur, et avec encore 2 ans pour virer tes non conformités avant les sanctions…
Ah mais je ne dis pas qu'ils n'ont pas été nuls sur ce point hein.
Maintenant à la date du 1er commit en 2016, le sieur Rochko était un étudiant de 23 ans, pas un chef d'entreprise avec un département légal à même de lui expliquer les tenants et aboutissants de la RGPD.
Parce que bon à l'époque, j'en ai vu des services informatiques complètement perdus par les questions de conformités à la RGPD (et des services étatiques) et je connais encore dans ma boite actuelle des services qui se mettent seulement en conformité (mais qui sont peu visibles et peu sujet à plaintes puisqu'ils n'ont comme clients que des entreprises signant contrat avec eux) et je ne doute pas qu'il y a plein de trucs pas vu / pas pensés dans des milliers d'entreprises.
Non seulement nul n’est sensé ignorer la loi, mais j’ai aussi beaucoup de mal avec les gens qui commencent en mode « yolo j’ai 23 piges balek me renseigner sur mes obligations légales, moi je vais faire le bien donc je peux pas faire de la merde ». Google/Facebook a pas commencé mieux à l’origine 🤣.
Ça n’est en aucune manière ne serait-ce qu’un début d’excuse pour Eugen. Surtout quand tu développes ça justement pour casser du GAFAM et après tout le merdier qu’on connaît sur les données persos.
Ça veut juste dire que tu ne peux pas invoquer l'ignorance dans le cadre d'un procès. Dans les fait la majorité des gens ignorent la majorité des lois.
Du reste je n'explique pas, je comprends. Plein d'autres auraient fait pareil. Et ce qui compte c'est ce qu'on en fait maintenant.
Je te cite une position WTF de Eugen, qui n’a pas changé depuis.
Je ne la trouve pas WTF, il faut m'expliquer, en lisant la discussion github que tu pointes, je vois pas mal de « ya des trucs déjà gérés », du « je ne suis pas légiste, donc je ne prends pas la responsabilité de te donner une opinion légale », et aussi du « attendons de voir comment ça va se dérouler ».
Sachant que la discussion date de 2018 au moment de la mise en place du RGPD, on peut admettre l'attitude d'attente au moment de transition.
Ça aurait été écrit en 2023, j'aurais pensé que bon, on en a du recul, ya foutage de gueule.
Là je vois pas, donc je te demande des détails, parce que aussi :
Je t’ai cité tout un article de Contexte qui étudie le problème.
Et non, ton lien est illisible, paywall.
Et là tu fais pareil, tu innondes de lien, tu n'expliques rien.
Donne des arguments, développe ta pensée, balance pas des liens en vrac et démerdez-vous !
T'as une position, tu veux la défendre, alors donne-la plus précisément qu'avec des phrases à l'emporte-pièce du genre « Mastodon viole frontalement le RGPD par pilées de 12 ».
Concernant tes liens :
Décembre 2023, ouvert.
Août 2023, toujours ouvert, sur un problème de « peut-être une violation ».
Août 2023, même problème, et ça se met sur le coin de la gueule.
décembre 2022, il y a une solution simple au problème présenté, et c'est toujours ouvert…
2020, ouvert, et pas clair du tout d'ailleurs comme ticket.
Décembre 2022, des choses ont changées, des discussions ont lieu, et là aussi, va falloir pointer la violation de RGPD : d'un côté on a une obligation légale de conserver des données de connexion et des logs d'accès, pour le cas d'une enquête judiciaire, de l'autre il faudrait quoi, ne conserver les IPs de connexion que 5 minutes ? Et se re-logger toutes les 5 minutes ? Aujourd'hui ça semble paramétrable sur l'instance, donc toute violation est forcément dans l'instance pas dans le logiciel.
février 2024, pas encore répondu.
2020, franchement, j'aimerais plus que l'opinion de la personne qui a ouvert le ticket quant-à la légalité en terme de RGPD de la suppression des données d'un compte banni à jamais.
2019, mais les notes sont disponibles aujourd'hui.
Discussion de 2018, où en est-on aujourd'hui ?
Là-dedans, des problèmes réels, ne dépendant pas de l'administrateur de l'instance, non traités et qui n'ont pas été rapportés la semaine dernière, j'en vois pas tant que ça.
C'est un concours de mauvaise foi ?
Fais gaffe, t'as pas mal d'avance…
Par ailleurs, je ne vois toujours pas en quoi ça condamnerait l'outil définitivement, et sans appel.
Ni en quoi la seule solution viable serait de tout laisser tomber et aller voir les gros silos pas beaux aux states…
Yth, ouais, je suis un peu focalisé sur ton message initial.
C'est clair, Aeris, que si tu faisias aussi le travail de fourmi aussi bien pour la multitude de serveurs Mastodon que pour les sites Wordpress, Spip, Joomla etc. il y aurait des millions de dossiers à la CNIL.
Personnellement, j'aurai un peu plus de tolérance quand il n'y a pas d'usage commercial, publicitaire, ou de revente/partage de données.
Ça me gave que sur beaucoup de sites administratifs (Énergies, emploi, CAF etc.) il y ait quasi systématiquement des données chez les GAFAM (cloudflare, et autres CDN) et la collecte de statistiques ou le profiling avec tagcommander. Lesquels n'en n'ont pas?
Alors oui, peut être que ça respecte le RGPD ou Schrem1,2,3… mais ça signifie aussi que le RGPD n'est pas encore adapté pour protéger les utilisateurs.
L'histoire de la note privée sur une fiche d'un contact concerne:
- Wechat
- Whatapps (c'est indirect, mais je le fais via une note sur la fiche contact du shitphone)
- Mastodon
et probablement aussi d'autres logiciels comme Signal, mais je ne l'ai pas réactivé donc je ne peux pas vérifier.
L'intérêt de Mastodon, c'est que c'est noté dans le code, en dur, et que comme c'est un Logiciel Libre, si tes modifications ne sont pas acceptées, alors tu peux forker et créer ton propre client. Tu peux aussi te baser sur l'un des nombreux clients Mastodon pour ça.
Contrairement à Twitter/X, Wechat, Whatapps, … tu peux avoir des clients différents, avec des implémentations différentes, et, un peu mieux contrôler ce qui est fait derrière ton dos.
L'obligation de s'identifier à travers un numéro de téléphone mobile devrait être interdite, parce que c'est une donnée personnelle, et que ça empêche le pseudo-anonymat sans empêcher les abus/harcèlements.
Pourquoi tu passes autant d'énergie contre Mastodon alors que c'est enfin un service décentralisé qui laisse beaucoup de choix, et qui est celui qui est le plus respectueux des utilisateurs. Tu as même le choix au niveau des instances. Peut être qu'il n'y en a aucune à ton goût ou qui serait assez respectueuses des utilisateurs et du RGPD.
Tu pourrais monter la tienne ou donner un coup de main à une instance existante?
Si encore le Fédiverse avait 0.01% des ressources de l'un des Gafam, tu ne penses pas qu'on arriverait à quelque chose de super? mais voilà, aucun investisseur ne veut investir dans un projet qui ne rapportera rien puisque sans publicité, sans tracking, sans collecte de données etc…
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
Mastodon alors que c'est enfin un service décentralisé qui laisse beaucoup de choix, et qui est celui qui est le plus respectueux des utilisateurs.
Non. C’est juste que c’est celle qui te convient TOI le mieux à ta définition de ce qu’est le respect des utilisateurs mais ce n’est PAS un système qui respecte ses utilisateurs. Certainement pas.
Tu as même le choix au niveau des instances. Peut être qu'il n'y en a aucune à ton goût ou qui serait assez respectueuses des utilisateurs et du RGPD.
Tu pourrais monter la tienne ou donner un coup de main à une instance existante?
J’ai la mienne depuis… bien avant que Mastodon existe ? Il se trouve que Mastodon a démoli l’intégralité du réseau où j’étais bien avant que le Mammouth dégomme tout sur son passage et atomise l’existant avec du Embrace Extend Extinguish.
Quand aux coups de main, j’ai tenté à plusieurs reprises de faire de l’accompagnement juridique et cie pour mettre ça dans le bon chemin du RGPD et du DSA. Je me suis fait rembarrer à chaque fois. Et bien vénère. Parce qu’ils en ont en pratique réellement strictement rien à foutre.
Du coup s’il faut foutre des plaintes aussi sur ces plateformes et témoigner contre elles, je le ferais. Ce n’est pas de la revanche personnelle ou autre, juste le strict respect des mêmes lois qu’on demande aux GAFAM de respecter.
C’est pas parce que t’es une asso ou que tu fais du libre que tu bénéficieras plus de bienveillance là-dessus.
Posté par Psychofox (Mastodon) .
Évalué à 9 (+7/-1).
Dernière modification le 20 février 2024 à 15:12.
J’ai la mienne depuis… bien avant que Mastodon existe ? Il se trouve que Mastodon a démoli l’intégralité du réseau où j’étais bien avant que le Mammouth dégomme tout sur son passage
Aaah en fait c'était personnel! Fallait le dire avant.
Je ne connais aucun réseau qui a été démoli par Mastodon soit-dit en passant.
Juste GNU/Social ? 🤔
Mastodon s’est pointé en 2017 en ne supportant que OStatus, en ne respectant rien de ce qui existait, a implémenté des features non compatibles aux forceps (message « privé » Mastodon qui du coup était public côté GNU/Social…), puis a forcé ActivityPub, avant de virer le support de OStatus et de massacrer GNU/Social qui ne s’en est jamais remis.
Google n’aurait pas fait mieux…
GNU/Social n’en est pas au même point. L’arrivée de Mastodon a complètement stérilisé le développement de ce projet… La communauté a suivi côté Mastodon parce que c’était le plus gros réseau. Ça a explosé le projet et tu n’en trouveras presque plus une miette.
On parle aujourd’hui d’un relicat d’une 20aine d’instances et de moins de 1000 personnes.
GNU Social était il me semble le plus vieux projet de réseau social centralisé libre. Pump.io donc Activity Pub, a été créé bien avant Mastodon et des réseaux comme identi.ca ont fait le switch avant l'arrivée de Mastodon.
GNU Social n'était déjà pas très dynamique. Mastodon ne l'a pas tué. Il était tout simplement déjà mort mais ne le savait pas encore.
Dans ce que tu écris, j'ai l'impression qu'il n'y a pas de messages directs (privé, mais les admins peuvent y accéder) dans Gnu.social comme dans ActivityPub.
J'ai regardé https://fr.wikipedia.org/wiki/GNU_social et ça ne m'a pas plus éclairé.
Mastodon utilise ActivityPub pour les échanges de messages, ce qui ouvre l'accès à tout le Fédiverse.
La première fois que j'avais entendu parler de ActivityPub, c'était sur à propos de Jabber/XMPP
Dans la page sur ActivityPub il est précisé que c'est une évolution de OStatus
Tu dis que cela a été forcé, mais peut être que simplement les besoin était d'avoir un peu plus de fonctionnalités ou de souplesses. D'ailleurs, tout ce qui est connecté au Fédiverse et qui communique via ActivityPub n'en prend en charge qu'une partie.
Je vois bien que OStatus est très bien pour du microbloging, avec aussi la prise en compte de Atom.
Mais, les usages et les besoins évoluent.
En quoi selon toi OStatus serait préférable à ActivityPub? Plus simple?
De mon point de vue, OStatus est très différent de ActivityPub, bien plus limité, et ne convient pas suffisamment avec les besoins de communications des utilisateurs autour du microbloging parce que les gens en veulent toujours un peu plus, y compris s'échanger des messages, partager des contenus, commenter, s'envoyer des fleurs etc.
Si un jour on peut lancer une visioconf via un client Mastodon, pour compléter les messages vidéos ou audio, ce serait super. Reste à créer la connexion avec un Galène, un BBB ou un Jitsy.
Mastodon, c'est une partie du Fédiverse.
Il suffirait à Gnu.social de prendre en charge une partie de Activitypub pour pouvoir rejoindre le Fédiverse. Alors oui, c'est un gros travail. Parfois pas grand chose suffit, et ça permet d'avoir Peertube dans le Fédiverse et c'est génial.
Oui, il y a 30 ans, s'échanger des emails était plus facile.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
Je me suis fait rembarrer à chaque fois. Et bien vénère. Parce qu’ils en ont en pratique réellement strictement rien à foutre.
En même temps, si t'es arrivé avec tes gros sabots en disant, comme ce que tu fais ici, « vous faites de la merde pas légale, bandes de nazes, laissez tomber t'façon vous z'avez pas les épaules pour gérer ce foutoir », c'est peut-être un peu normal que tu te sois fait accueillir fraîchement ?
Ah non j’ai dit « vous faites un truc pas légal et voilà comment vous pourriez faire pour être légal » et on m’a rembarré en me disant « nan mais si on fait ça on pourra jamais concurrencer les GAFAM » (à peu près).
Pour sortir du seul cas de Mastodon, je pourrais prendre plus ou moins n’importe quel projet libre et on serait plus ou moins dans la même situation.
Des devs qui n’ont jamais lu la moindre ligne du RGPD et qui font les trucs naïvement totalement illégalement. Et ça sans compter les projets hostés exclusivement sous Github (violation Schrems II), utilisant des media de support US (discord), déployant sur des infras US (Cloudflare, AWS, gitlab.io…), avec une privacy policy inexistante ou illicite, avec des features illicites (même Mozilla a foutu non seulement du tracking d’audience illice mais en plus passant par Google…), etc.
Et c’est plus ou moins le sens de mon propos d’ailleurs : au motif qu’on a foutu « GPL » dans une licence, tout le monde se croit autorisé à faire n’importe quoi et à ne jamais réfléchir au moins sur les obligations légales…
Et donc que « libre » n’est pas un argument en soi. Ça n’apporte STRICTEMENT RIEN à une décision concernant un choix de soft en 2024.
Et donc que « libre » n’est pas un argument en soi. Ça n’apporte STRICTEMENT RIEN à une décision concernant un choix de soft en 2024.
Bah… Si.
Ça reste libre.
Si on a les mêmes défauts des deux côtés : libre et proprio. Les mêmes difficultés à vraiment suivre le RGPD, les même merdes dans tous les coins.
Alors la solution n'est pas d'abandonner le libre et de se jeter dans les bras des MAGAF, au contraire, c'est de continuer à pousser le libre et de faire en sorte qu'il le soit, conforme.
Ça reste toujours un argument, ça reste même le même argument que depuis 30 ans.
En fait, rien n'a changé dans le rapport de force entre libre et non libre.
Sauf…
Bah sauf que le libre permet une meilleure collaboration européenne en dehors de silos type MAGAF, et une meilleure construction durable du respect du RGPD, quand on en sera enfin là.
Donc tout ça n'est toujours pas un argument valable pour envoyer le HDH aux states.
Zéro pointé.
Toujours aussi foireux comme argument.
Derrière, c'est business as usual et lobbys à gogo.
Posté par Aeris (site web personnel) .
Évalué à -2 (+0/-3).
Dernière modification le 20 février 2024 à 16:40.
Encore une fois non. Parce qu’actuellement je me fritte BEAUCOUP plus avec le libre qui brandit justement son côté libre pour ne RIEN faire niveau conformité (« parce que je ne peux pas être méchant, je suis libre », « oui mais le RGPD c’est pour les GAFAM, moi si je l’applique je meurt et comme je suis libre, ça serait pas bien tu vois » qu’avec des outils proprios.
Sur le papier le libre est supposé un argument EN PLUS mais en pratique il est un argument INDUIT. Les forks ne fonctionnent pas en pratique, les softs libres mais pourris pullulent, même les trucs comme Mozilla sont bardés de tracker.
Comme dit, j’ai pas un soft libre que je ne devrais pas éclater à la bombe atomique devant une APD avec une plainte de 80 pages, et me dire « ben t’as qu’à forker » est un non sens. Non seulement j’ai pas le temps pour ça, mais en plus ton produit est tellement construit sur ces non conformités que le taff à abattre pour le mettre en conformité est plus important que de tout refaire from scratch à supposer même que ce que tu cherches à faire soit en réalité légalement possible…
Encore une fois le terme « libre » n’apporte juste plus aucune plus-value à l’équation.
Si je prend encore une fois l’exemple de Mastodon parce que c’est le plus facile à expliquer, dire « ta modération ne respecte pas le RGPD » impose de forker Mastodon et de :
tracer l’intégralité des actions administrateurs, ce que la plupart juste refusent de mettre en œuvre au motif que les admins ne doivent avoir de compte à rendre à personne, décision limite fondatrice du projet initial
mettre en place une politique d’appel, complexe à mettre en œuvre dans un environnement fédéré et incompatible avec la vision actuelle d’Eugen en particulier et des admins du Fediverse en général sur le sujet, en lien avec le point 1 d’indépendance des modérateurs
virer les notes de profil qui ont été une grande demande de la part des utilisateurs, en tout cas pas sans mise-en-œuvre des article 14 et 21 qui ne sont actuellement pas possible par le protocole ActivityPub
interdire les bannissements express et la destruction du contenu, en permettant aux personnes bloquées la continuité de l’exercice de leur droit, ce qui implique par exemple la continuité de la portabilité (contenu compris, donc)
modifier activitypub pour permettre une réelle mise en œuvre des article 14, 15, 16, 17, 18, 20 et 23, qui actuellement sont (mal) traités exclusivement par l’instance primaire émettant le contenu et aucunement propagés ni propageables aux instances secondaires le recevant
le tout en assurant la stricte compatibilité avec un soft illicite qui va rester probablement l’instance mainstream par excellence et que vu la population et la demande actuelle sur le fédiverse, ton fork va être utilisé par toi-même exclusivement
Non seulement ça ne ressemblerait plus du tout à Mastodon, mais ton propre réseau n’a plus ou moins aucune chance d’avoir le moindre visiteur.
Et c’est aussi pour ça que la justice du droit de la concurrence commence à regarder du côté du RGPD, parce que la non conformité est une atteinte et une distorsion de la concurrence : un soft RGPD-conforme est non-concurrentiel par rapport à un soft violant le RGPD pouvant proposer de facto plus de fonctionnalités mais illicites ou d’attrait pour les utilisateurs.
Déjà au DSA qui impose une procédure d’appel neutre et impartial jusqu’à 6 mois après le blocage. Ça implique donc ne de certainement pas supprimer les données dès le ban, comme l’autorise (et en abuse) actuellement certains admins de Mastodon et parce que Mastodon a implémenté ça comme ça (avec une check-box DELETE juste à côté du bouton BAN, qui ne devrait donc légalement pas exister, ou exclusivement pour des admins/super-modo et pour des usages très spécifiques, certainement pas accessible à un modo standard).
Et il faut que je retrouve la jurisprudence qui avait acté que le bannissement d’un service ne pouvait faire s’éteindre les droits de la personne concernée (donc 15-22 continuent à être 100% applicable jusqu’à la fin même banni)
Posté par Psychofox (Mastodon) .
Évalué à 6 (+3/-0).
Dernière modification le 21 février 2024 à 07:52.
(avec une check-box DELETE juste à côté du bouton BAN, qui ne devrait donc légalement pas exister, ou exclusivement pour des admins/super-modo et pour des usages très spécifiques, certainement pas accessible à un modo standard).
Je dirais que tout modo qui n'authorise pas les accès depuis l'europe peut l'utiliser.
Déjà au DSA qui impose une procédure d’appel neutre et impartial jusqu’à 6 mois après le blocage.
Ça les GAFAM ne les respectent pas.
Ils gardent sans doute les données 6 mois mais si tu es ban ton unique recourt c'est de faire assez de bruit sur les autres réseaux sociaux pour que ça fasse un scandale et qu'un humain passe par une procédure manuelle.
Ils gardent sans doute les données 6 mois mais si tu es ban ton unique recourt c'est de faire assez de bruit sur les autres réseaux sociaux pour que ça fasse un scandale et qu'un humain passe par une procédure manuelle.
Les quelques scandales qui ont eu lieu ces derniers temps montrent que même le support humain est incapable de régler le problème, et que les comptes bloqués sont irréversibles. Il était question de pouvoir récupérer les données après blocage de comptes.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
Je viens de retrouver un lien intéressant. Voilà ce qui a été rédigé par des assos qu’on qualifiera assez difficilement d’être des dangereux extrémistes néo-nazis qui veulent défendre des trucs illégitimes : https://santaclaraprinciples.org/#3-appeal
Donc voilà, même des entités aussi importantes que l’ACLU et l’EFF, ou encore le centre pour la démocratie et la technologie ou la coalition national contre la censure, ont rédigé des principes de modérations en 2018 bien avant le DSA/DMA et pourtant qui en sont 100% compatibles.
Et actent donc que la modération de Mastodon/du Fediverse c’est juste du gros n’importe quoi et que ça ne respecte pas vraiment les principes démocratiques de base.
Oui ok, du coup c’est pas forcément bien appliqué. Mais c’est quoi le mieux du coup ?
Des entités comme Mastodon qui disent « yolo les principes rédigés par les entités les plus respectables en la matière de défense des libertés fondamentales et de la démocratie, on s’en cogne c’est pour les faibles/les méchants et ils ont tord » ou ceux qui ont au moins fait l’effort de signer la charte et donc a priori tentent d’en respecter les principes (même si c’est manifestement perfectible) ?
C’est quoi du coup qui est illégitime ? Le DSA/DMA qui ne fait que reprendre des principes initiés par l’EFF et l’ACLU ? Ou les gus de Mastodon qui chient dessus par pilées de 12 ?
C'est un peu ce qui était dit plus haut.
Alors oui, ils ont signés une charte, et l'appliquent plus ou moins.
Mais, ça n'empêchera pas les utilisateurs de perdre toutes leurs données chez leur prestataire parce que l'utilisateur aurait envoyé par email une photo du kiki de son fils par email à un Docteur parce que les consultations en présentiel étaient difficiles pendant les confinements liés à Covid19. Et malgré les contestations auprès du support, ce fut irreversible.
Il y avait aussi un autre cas avec un journaliste qui avait un abonnement illimité de stockage dans un Cloud, payant, et qui s'est retrouvé aussi dans une salle situation, malgré le contact avec le support.
Combien d'exemples qui n'ont pas été médiatisés?
Alors oui, ce que font la plupart des administrateurs des serveurs Mastodon ce n'est pas bien, mais ils faut aussi qu'ils gèrent leur serveurs avec les faibles ressources à leur disposition.
C'est un peu comme l'obligation de retrait d'un document dans un délai d'une heure, si la notification arrive en pleine nuit, ça ne sera pas traité avant le matin s'il n'y a pas assez de modérateurs. Certains, les très gros, ont l'obligation d'avoir assez de modérateurs.
je n'ai pas mis de liens, parce que je ne les ai pas notés quand ces histoires ont été publiées, mais si vous avez des sources sous le coude, n'hésitez pas à compléter. Mais ne perdez pas votre temps à les chercher.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
Posté par Psychofox (Mastodon) .
Évalué à 6 (+3/-0).
Dernière modification le 20 février 2024 à 17:38.
modifier activitypub pour permettre une réelle mise en œuvre des article 14, 15, 16, 17, 18, 20 et 23, qui actuellement sont (mal) traités exclusivement par l’instance primaire émettant le contenu et aucunement propagés ni propageables aux instances secondaires le recevant
Même si la propagation automatique serait idéale, je ne crois pas que instance 1 pourrait être poursuivie parce que instance 2 a récupéré des trucs et n'a pas conscience que @bidule@instance1 veut, par exemple, que telle ou telle donnée soit corrigée. Une fois que les données sont chez un autre admin, c'est de la responsabilité de l'autre admin.
Et on impose pas par exemple gmail de supprimer les emails de tartampion@hotmail.com qui ont été envoyés à des addresses gmail parce que monsieur tartampion demande à hotmail de supprimer son compte et ses données.
La RGPD n'est tout simplement pas federation ready.
Une fois que les données sont chez un autre admin, c'est de la responsabilité de l'autre admin.
Non justement. Le RGPD dit spécifiquement l’inverse. Ta transmission en tant que responsable de traitement à un autre responsable de traitement n’éteint pas ta responsabilité. LES DEUX en deviennent responsables, et en particulier le 1er est supposé continue à propager les demandes d’accès/rectification/effacement et a l’obligation de prouver qu’il fait le taff et propage bien toutes les demandes.
Et on impose pas par exemple gmail de supprimer les emails de tartampion@hotmail.com qui ont été envoyés à des addresses gmail parce que monsieur tartampion demande à hotmail de supprimer son compte et ses données.
Cas très différent de la fédération. Le mail est décentralisé, mais pas fédéré.
Le destinataire final conserve aussi des intérêts puisqu’il s’agit bien d’une correspondance dont il est destinataire explicite.
La RGPD n'est tout simplement pas federation ready.
Tu te trompes et inverse juste le problème. Et tient exactement les mêmes propos que les GAFAM (juste que eux disent « le RGPD n’est tout simplement pas business ready »).
La fédération n’est effectivement pas RGPD ready.
Et ce n’est pas forcément le RGPD qu’il faut revoir. Le DSA a même été spécifiquement conçu pour justement ne pas permettre l’évitement des réglementations via des prétextes de fédération.
Et les propos que tu tiens ne font que confirmer ce que je dis dans mon article.
« Le libre » devient un argument en soit, sans réflexion des avantages ou inconvénients apportés, et le fait qu’on est gêné par la loi et que parce qu’on est « libre » ou « fédéré » on devrait ne pas avoir à la respecter. Sans jamais d’abord poser la question de savoir si ce que « le libre » ou « la fédération » cherche à faire est réellement légitime/morale/légal/whatever.
« Je fais du libre donc je ne peux pas être du mauvais côté ». Et derrière j’entend déjà « oui bon le RGPD est une merde du coup et faut le changer » ou autre « l’article 8 de la CEDH c’est pas pour nous ». Comme les GAFAM quoi… L’aspect financier en moins…
Je pourrais aussi citer Shinigami Eyes qui s’est juste pris un taquet monstrueux de la part de la plus grande autorité de protection des données d’Europe, saisie par l’APD qui fait le mieux son taff en Europe (la Norvège), mais que au motif que c’était pour taper sur les transphobes, fallait surtout plus être trop trop regardant sur le respect de la vie privée et qu’on était forcément du côté du bien.
Ben non en fait, Bob… T’es juste à foutre dans le même sac que les autres hein ! Et c’est pas parce que tu fais du libre ou que tu penses que tu fais le bien que c’est l’absolution totem d’immunité !
Et que oui, des p**** de gens continuent d’utiliser cette extension libre (licence MIT) qui s’est juste fait démonter par EDPB pour de bonnes raisons légitimes et morales et est littéralement interdite en Norvège (à défaut qu’EDPB ait pu l’interdire dans toute l’Europe) !!!! Et ça ne choque… personne… 😑
Posté par Psychofox (Mastodon) .
Évalué à 8 (+5/-0).
Dernière modification le 21 février 2024 à 08:15.
« Le libre » devient un argument en soit, sans réflexion des avantages ou inconvénients apportés, et le fait qu’on est gêné par la loi et que parce qu’on est « libre » ou « fédéré » on devrait ne pas avoir à la respecter.
Je n'ai pas dis ça. Ne fait pas ton Zénitram
« Je fais du libre donc je ne peux pas être du mauvais côté ».
Je n'ai pas dit ça non plus.
Du restes c'est TOI qui fait un amalgame libre = non conformité à la RGPD.
La licence n'a rien à voir là-dedans, si Mastodon avait une licence proprio les problèmes seraient exactement les mêmes.
Il y a d'ailleurs plusieurs fédérations, la plus connue est celle qu'on utilise tous avec nos comptes mails persos ou pros, mais il en existe d'autres comme MSSanté par exemple.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Non justement. Le RGPD dit spécifiquement l’inverse. Ta transmission en tant que responsable de traitement à un autre responsable de traitement n’éteint pas ta responsabilité. LES DEUX en deviennent responsables, et en particulier le 1er est supposé continue à propager les demandes d’accès/rectification/effacement et a l’obligation de prouver qu’il fait le taff et propage bien toutes les demandes.
Étant donné qu'une instance Mastodon correctement configuré n'a qu'un cache limité dans le temps sur les données qui lui sont propagées, je ne vois pas trop en qu'est-ce qu'il manque? Si un utilisateur édite sont message, l'édition est propagée. C'est juste un cache. S'il ferme son compte et quitte l'instance mastodon d'origine, ses changements de statut vont disparaitre non? Qu'est-ce qu'il manque selon toi?
Cas très différent de la fédération. Le mail est décentralisé, mais pas fédéré.
Bien sûr que si que le mail est fédéré.
Le destinataire final conserve aussi des intérêts puisqu’il s’agit bien d’une correspondance dont il est destinataire explicite.
Dans le cas d'un statut mastodon aussi on pourrait rétorquer que c'est invocable, surtout quand il y a des mentions.
Tu te trompes et inverse juste le problème. Et tient exactement les mêmes propos que les GAFAM (juste que eux disent « le RGPD n’est tout simplement pas business ready »).
La fédération n’est effectivement pas RGPD ready.
Et ce n’est pas forcément le RGPD qu’il faut revoir. Le DSA a même été spécifiquement conçu pour justement ne pas permettre l’évitement des réglementations via des prétextes de fédération.
Je reviens là dessus.
Le principe de fédération, c'est un tout autre concept qu'un système de traitement de données par un sous-traitant ou vente de données internes à un client. Et je réitère que ça n'a pas été pris en compte dans la RGPD.
Une loi peut bel et bien ne pas être, ou partiellement (on n'est pas obligé de jeter toute l'eau du bain hein), adaptée à une société. Ce n'est pas pour rien que les lois sont longuement débatues et amendées. Je crois que tu ne me contrediras pas pour dire que la loi qui interdisait le port du pantalon aux femmes jusqu'en 2013 était complètement inadaptée à la société. On peut t'en sortir par centaines des lois mal branlées.
Je vais faire une réponse simple :
Il y a certainement beaucoup plus de logiciels et services libres dont tu n'entends jamais parler, que de ceux dont tu entends parler.
Le fait qu'il y ait plusieurs milliers d'instances mastodon alors qu'il n'y a qu'une seule instance Twitter explique simplement le fait que tu sois submergés de problèmes liés à des logiciels libres par rapport aux équivalents proprios.
Ce n'est pas intrinsèque au libre, c'est intrinsèque à la décentralisation.
Tu préfères la centralisation parce que ça te simplifie le boulot.
Je peux comprendre, je ne partage pas, mais je peux comprendre.
J'ai plus de mal à comprendre que tu bâches le libre en tant que victime collatérale…
Des arguments du genre « le libre ne fait RIEN niveau conformité » sont d'une telle bêtise crasse, que je ne comprend pas comment tu peux les dire.
D'autant plus que tu as UN unique exemple, et c'est Mastodon.
Le libre est bien un argument EN PLUS.
Mais cet argument c'est le respect des 4 libertés fondamentales, pas celui du respect du RGPD.
Ça c'est lié à chaque projet, à chaque gouvernance.
Tiens, bah trouve-moi les infractions au RGPD dans Delta-Chat, je veux bien les connaître s'il y en a !
Je ne dis pas qu'il n'y en a pas, mais bigre, j'aimerais bien les connaître.
Alors que bon, juste le rapport Exodus sur l'appli outlook de chez Microsoft t'indique que côté RGPD, t'es foutu, t'es hors clous, tes données elles partent n'importe où, chez Google, chez Facebook, chez d'autres gusses que tu connais même pas…
This website is hosted by an external hoster (Hetzner GmbH).
C’est plutôt GreenHost pour le coup. Je ne peux pas vérifié, mais je suppose que le DPA que vous avez signé avec votre hébergeur est comme 99.999% des cas illicites (la plupart des standards dispo sur le net par les providers le sont). Et que vous ne conduisez aucun des audits annuels/bi-annuels nécessaires à la conformité RGPD (sanction de EDF par la CNIL de mémoire).
for other administrative purposes.
Clause illicite, les « other » ou « par exemple » sont illégaux et chaque finalité doit être explicitement détaillé.
The legal basis for the data processing is Art.6 (1) lit.f GDPR.
Faux, au moins 2 sont des obligations légales (sécurité des SI et journalisation des accès) et non des intérêts légitimes.
Idem, difficile à juger de loin, mais avez-vous bien passer les triples tests (nécessité, proportionnalité, balance des droits) de justification de l’intérêt légitime pour éviter une requalification en consentement par une APD ?
Ensuring a convenient use of our website
Généralement clause considérée comme problématique par EDPB, pas assez spécifique ni éclairée
At the end of the fifth calendar year after these posts were written or after the deletion of your user account, anonymization will take place
Délai trop long, la suppression est supposée être opérée avant 2 ans, et à la date anniversaire de suppression, pas à la fin de l’année calendaire (sinon celles du 1er janvier sont conservés 6 ans en pratique)
In addition, to prevent bots and spam
Interdit sous le régime du « nécessaire au contrat » invoqué au 6(1)b, et la jurisprudence EDPB/CJUE indique plutôt une obligation de consentement, l’intérêt légitime étant trop intrusif sur la balance des droits (3ème test de l’IL qui ne passe pas)
Your user behavior is recorded in server log files in order to analyze technical problems and possible abuse. The legal basis for this processing to protect our legitimate interests is Art.6 (1) lit.b and f GDPR.
User behavior = données sensibles article 9 donc intérêt légitime difficile à passer.
« analyze technical problem or possible abuse » déclarés trop vague par EDPB dans ses lignes directrices.
processing to improve the forum, to prevent advertising bots and spammers
IL fragile relativement souvent requalifié en consentement par les APD
Among other things, your (presumed) interests and preferences may be recorded to display personalized advertising.
Violation ePrivacy + violation encadrement de la sous-traitance article 28
Tout le § est globalement faux, laissant sous-entendre que delta.chat n’est responsable de rien, alors qu’il reste 100% responsable de traitement de l’intégralité des transferts de données générés par ses recommandations ou usages.
The legal basis for this processing is Art.6 (1) lit.f and b GDPR
Publicité ciblée interdite en Europe sur le fondement de l’IL explicitement depuis au moins juin 2023 et la décision urgente de EDPB envers Meta.
Twitter/Youtube
Je développe pas hein… (Schrems II, tout ça…)
The legal basis for this is found in Art. 6 (1) lit. c and f GDPR.
Un traitement ne doit être fondé que sur une et une seule base légale. Ici c’est donc une clause illicite.
You can therefore usually contact the supervisory authority of your usual place of residence or workplace or our registered office
Illégal. Le mécanisme du One-Stop-Shop impose que seule l’APD de la personne concernée soit saisi, charge à elle de transmettre à l’APD du responsable de traitement derrière
128-bit v3
Non sens technique
This data protection declaration is valid as of November 2021
A priori pas d’update de la privacy policy depuis 2 ans, dont des changements majeures de réglementation Schrems II & cie sur le sujet entre temps.
Une PP pas mise à jour au moins chaque année, c’est louche déjà
J’ajoute au pif non respect des exigences minimales de sécurité de l’ANSSI, utilisation de suite non PFS dépréciées depuis 10 ans. Pas de supporte de HSTS. Clef RSA de 2048 bits au lieu des 3072 minimums (surtout si pas de PFS).
Tu mélanges tous les sujets. Ce genre d'audit où tu sors un million de micro remarques comme tu le fais, les grandes boites 100% RGPD SecNumCloud ISO Mes Couilles Mille Un en passent 42 fois par an et obtiennent globalement la même chose (sauf qu'en plus comme c'est closed source secret des affaires inside, tu ne pourras rien vérifier).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Et donc parce que je prouve que delta-chat se torche avec le RGPD, faudrait dire « non mais les GAFAM font pareil donc on continue » ?
On me dit que c’est propre, j’ouvre juste le truc et je fais une syncope. On m’explique ?
Même TLS qui est un truc qui a subit un gros bordel en 2014-2016 est pas à jour quoi… 😑😡
Encore une nième fois, ça ne fait que confirmer ce que je dis dans mon blog. « Être libre » est dorénavant une excuse pour ne rien faire, se foutre de la gueule du monde et espérer un totem d’immunité et de sympathie pour ne pas avoir à respecter la loi…
Je ne suis pas en train de te parler d’une loi random fait par des machins yolo remplis de lobbying, j’suis en train de te parler d’un réglement qui est une des rares où la Commission a tenu tête à des lobbyings pendant 6 ans, n’a reculé sur rien, pour défendre des sujets qu’on a nous-même demandé et qui ont été poussé par la majorité sinon la totalité des associations libristes et assimilées depuis 20 ans, et qu’aujourd’hui qu’on l’a enfin en application « non mais j’ai piscine, totem d’immunité GPL-MIT-BSD ».
Et ça a été exactement pareil par exemple sur la fédération/intéropérabilité…
T’as LQDN qui fait des pieds et des mains pendant 10 ans sur ce sujet, qui fait une pétition et un appel national, et quand t’as Meta qui se pointe « bonjour, on peut fédérer du coup ? », y’a la moitié du bordel qui l’insta-strike !
Ça montre de plus en plus que les arguments avancés par tout ce milieu sont juste des PRÉTEXTES pour distordre la concurrence et que quand il faut appliquer tout ça à soi-même, y’a aquaponey.
Il était écrit noir sur blanc que Meta allait tout pomper.
Et, je l'ai déjà écrit, quelles que soit les promesses de Meta, personne ne peut leur faire confiance. Et personne n devrait leur faire confiance.
Pourquoi les gros, avec tout le pognon qu'ils ont, refusent de respecter les lois et réglementations? Concrètement, pas juste des promesses.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
Ils ne se torchent pas avec le RGPD : tu nous as sorti une page qui parle du service de support assuré par Merlinux, ce qui n'est pas tout à fait la même chose que le logiciel Delta Chat.
Delta Chat est un client mail, il n'est pas lié à un service en ligne spécifique : c'est l'hébergeur mail que tu configures qui traite tes données.
Si justement grâce à Delta Chat, tu actives le chiffrement de bout en bout, les dites données seront très limitées.
Tu as le droit de préférer Outlook en ligne avec un abonnement Office 365, toute ta correspondance privée en clair sera sans doute traitée avec le plus grand respect et la plus grande souveraineté par le tiers de très grande confiance européen Microsoft grâce à ses nombreuses certifications :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
J’ai aussi le droit de défoncer devant une APD exactement de la même manière un logiciel de mail qui a une privacy policy aussi pétée et qui n’incite pas DU TOUT à aller plus loin. Si ta landing page est dans cet état, je ne veux même pas aller voir la gueule de ton service. Quand tu me mets « AES128 v3 » dans ta privacy policy avec un site web qui supporte encore du non PFS avec du chiffrement RSA 2048 bits, laisse-moi douter TRÈS FORTEMENT de ta capacité à faire de la crypto proprement et encore pire en end-to-end.
Delta Chat est un client mail, il n'est pas lié à un service en ligne spécifique : c'est l'hébergeur mail que tu configures qui traite tes données.
C’est faux. Delta-chat, en tant que fournisseur d’un logiciel en Europe, ne peut pas se défausser sur « il avait qu’à faire attention, l’utilisateur ».
Le simple fait que le code source ne soit dispo que sur github est une violation de Schrems II. Le fait qu’on télécharge des .deb chez vous est un traitement de données dont vous êtes responsable de traitement et avez au moins en Europe l’obligation de collecte des données de connexion.
Le fait de le déployer sur le play store fait que Google est un co-responsable de traitement dont vous endossez aussi la responsabilité des CGU tacitement (non) acceptées par vos utilisateurs, et comme déjà sanctionné 5-6× par des APD.
Vous fournissez un .deb sans aucune signature crypto. Pour un soft prétendant faire de la sécurité.
Et je peux continuer encore comme ça longtemps hein…
Pourquoi est-que la v1.42.2 de décembre dernier embarque du react 17.0.2 de 3 ans d’âge (22/03/2021) quand les dernières versions sont en 18.x ? Du use-debounce 3.4.3 livré en 2020 quand il y a dorénavant du 10.0.0 (🤯) ? Du ws 7.5.9 de 2 ans quand on est en 8.16.0 dorénavant ? Bordel quoi…
Ça s'installe sur lineageOS via f-droid, c'est signé, ça passe pas par google, et c'est la 1.42.6.
Je ne me sens toujours pas concerné par tes remarques, et je ne vois toujours pas de violation de RGPD.
Bon, on reprend : on a une application qui est un client mail, et qui utilise le protocole mail pour présenter des discussions sous forme de chat à la Conversation, ou Signal, on peut faire des groupes etc.
Le chiffrement est géré de façon ad-hoc, donc en général pas au premier message, le temps de faire un échange de clés, ça a ses limites, par contre le chiffrement utilisé est non-obsolète.
En pratique, l'application échange des données avec ton hébergeur mail, c'est un client mail, et il n'y a rien d'autre.
Pas de statistiques, pas de trackers, aucune remontées de quoi que ce soit.
L'application conserve les mails localement, comme le fait n'importe quel client mail.
Les mails sont stockés chiffrés sur le serveur mail, géré par ton hébergeur de mails.
J'ai du mal à voir comment tu pourrais blâmer Delta Chat pour une fuite de données en provenance de ton hébergeur de mail, mais dans tous les cas, les mails chiffrés via Delta Chat restent chiffrés, et une faille chez l'hébergeur ne peut pas vraiment changer ça.
Donc, les violations RGPD elles sont où là ?
Vas-y, explique.
Et encore une fois tu ne comprends pas les implications du RGPD et que l’application n’est PAS la seule chose à vérifier pour la conformité d’un projet.
Typiquement je ne PEUX pas auditer ton code sans accepter les CGU de github et violer Schrems II et TU es responsable en tant que responsable de traitement, github étant ici co-responsable de traitement.
Le manque de sécurité de l’application elle-même, avec des libs dépréciées depuis 3 ans, est aussi un manque de l’obligation de sécurité du RGPD et de la doctrine de suivi de version donné par la CNIL en décembre dernier. Et c’est de TA faute.
Et ton comportement est l’archétype même de ce que je dénonce dans mon post. Des réflexions purement « techniques » et que comme « je fais du libre j’ai totem d’immunité », je ne me remet absolument pas en question. Jusqu’au jour où « oups je vais me faire défoncer par mon APD » (ça va, en France y’a de la marge… 😑)
Ah oui, toi qui parle crypto, t’es au courant que delta-chat négocies du non PFS avec les serveurs IMAPS et donc que si ton client se fait défoncer par une faille de sécu sur la ligne, c’est AUSSI delta-chat qui est responsable pour ne pas avoir blacklisté ces cipher suite ? Et que ça négocie aussi du DHE pété depuis 2018 avec logjam & cie ? Et que donc idem ?
Posté par Psychofox (Mastodon) .
Évalué à 7 (+4/-0).
Dernière modification le 21 février 2024 à 14:40.
1) Tu sais que ce n'est pas interdit ni compliquer de demander de manière humaine et courtoise aux developpeurs via la mailing list ou le forum si par hasard ils ne pourraient pas t'envoyer un tarball du code source et/ou le mettre à disposition sur leur site.
Seulement si on te met un vent où que l'on te le refuse tu pourras prétendre que les sources ne sont pas dispo ailleurs.
2) tu n'as pas besoin d'accepter les CGU de github pour télécharger le code source. Les CGU d'un site n'engages que ceux qui les lisent et les acceptent en créant un compte.
3) la Schrems II n'est pas violée si tu vas sur github ou toute autre forge/repo.
Posté par Psychofox (Mastodon) .
Évalué à 6 (+3/-0).
Dernière modification le 21 février 2024 à 14:52.
Et j'ai oublié d'ajouter que tu n'as même pas besoin d'accéder au site github avec un navigateur, tu peux télécharger les sources simplement avec git clone.
Le seule endroit qui pourrait éventuellement être problématique avec deltachat selon moi c'est leur forum de support. Mais comme je n'y ai pas de compte, je n'ai pas étudié la question ni lu leurs conditions d'usage et communications sur le sujet des données utilisateurs.
Il s'est amélioré récemment sur ce point avec l'ajout de SecureJoin et il était déjà possible d'importer ses propres clefs (mais peu de gens le faisaient, car c'est compliqué).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Le simple fait que le code source ne soit dispo que sur github est une violation de Schrems II. Le fait qu’on télécharge des .deb chez vous est un traitement de données d
Le fait de télécharger n'implique pas un traitement de données.
Si puisque tu transmets ton adresse IP à Microsoft.
’fin bon, tu prouves que tu as une culture proche du néant en terme de conformité RGPD…
Github est sous-traitant de delta-chat, delta-chat aurait du signer un DPA avec Microsoft.
Le téléchargement du source sur github (avec delta-chat en responsable de traitement donc et Github en co-responsable de traitement) est un traitement de données soumis à l’article 50 des transferts internationaux de DCP, et une violation de l’arrêt Schrems II de la CJUE.
C’est pas comme si c’était JUSTE UN PEU l’intégralité du rationnel de la CJUE sur Schrems II hein… 😑
Ce qui ne change strictement rien au RGPD. Typiquement il est même interdit par le RGPD de demander aux utilisateurs de mettre en œuvre des mécanismes de protection au lieu de faire les efforts côté responsable de traitement.
C’est explicite pour les cookies par exemple, « t’as qu’à configurer correctement ton navigateur pour les bloquer » est illégal.
Nom mais impose le respect de l'état de l'art en terme de sécurité et donc le suivi des recommandations ANSSI en France, comme encore rappelé par la CNIL dans ses sanctions
Accepter une clé RSA réputée "weak" ne signifie pas que tu l'imposes. Ma connection au site delta.chat utilise TLS 1.3 avec des cyphers élevés par exemple.
Et en l'occurence l'utilisateur de delta.chat ne transmet pas de données privées via cette connection. Il se connecte à des serveur SMTP.
Posté par Aeris (site web personnel) .
Évalué à -1 (+1/-3).
Dernière modification le 21 février 2024 à 10:48.
Accepter une clé RSA weak t’expose à du downgrade attack parce qu’un attaquant peut forcer le repli vers une suite faillible. C’est donc une faille de sécurité et actuellement c’est de toute façon une violation des lignes directrices de l’ANSSI (pas de PFS = support de données après 2030 = 3072 bits minimum) donc une violation du RGPD.
Tu peux argumenter tant que tu veux, c’est un fait juridique.
Établir une connexion TCP/IP, même chiffrée, reste une transmission de DCP (l’adresse IP de l’utilisateur) et est donc en soit un traitement de données soumis au RGPD, et que c’est même exactement ce traitement qui est visé avec Schrems II, la sanction de Google Analytics (malgré l’anonymisation prouvée derrière par la CNIL), Google Fonts, Cloudflare ou tout CDN ou contenu tiers servi par un site internet (violation de l’obligation de minimisation de données article 5 et 6)…
La connexion chiffrée va ensuite échanger un mot de passe et un nom d’utilisateur qui sera aussi une DCP, même si le tunnel lui-même est chiffré. Données accessibles en clair au service en face donc n’étant PAS anonymisées.
Delta-chat est le moyen utilisé pour cette transmission, la finalité étant elle-même décidé par l’utilisateur. Sauf qu’un responsable de traitement est celui qui définit la finalité OU le moyen et donc delta-chat reste responsable de traitement, éventuellement est même sous-traitant au sens du RGPD si delta-chat est utilisé dans le cadre d’une asso ou d’une entreprise (qui est elle-aussi responsable de traitement pour avoir définit la finalité).
Mais tu ne fais que confirmer que tu n’as strictement aucune idée de ce qu’est le RGPD…
Le RGPD ne fait pas la différence effectivement. C’est bien delta-chat qui agit en tant que sous-traitant en fournissant un logiciel à des entités qui peuvent être elle-même responsable de traitement (asso, entreprise, particulier hors 2(2)c).
Alors, je ne parlais pas du site web, mais bien du logiciel.
Une fois installé et quand on l'utilise.
Sur le site de delta.chat, dans les mentions légales, je vois des mentions du RGPD, et la seule date trouvée est novembre 2021.
support.delta.chat semble être un forum annexe de support, encore une fois, c'est pas l'application Delta Chat.
Ok, on peut critiquer le site web, mais je n'avais jamais été regarder là-bas avant alors que j'utilise Delta Chat.
Il n'y a pas de lien, les comptes que tu peux trouver là-bas ne concernent pas l'application, il n'y en a pas besoin, ils servent à autre chose, et ce n'est pas de ça que je voulais parler.
J'avoue, je n'ai pas imaginé une seconde que c'était ce que tu allais faire, regarder le site web et les sites annexes.
Mais laisse-les de côté, ils n'ont en pratique aucun lien avec l'utilisation du logiciel, qui ne se connecte absolument pas à un quelconque service hébergé par delta.chat.
Pour le chiffrement dans l'application, c'est plutôt là qu'il faut regarder : https://delta.chat/fr/help#which-standards-are-used-for-end-to-end-encryption
Que le site web soit la cinquième roue du carrosse et ait un chiffrement ancien, alors que tout est public dessus et pourrait aussi bien exister en HTTP non chiffré, ça ne me perturbe pas spécialement.
Que leur forum soit à la ramasse, c'est un peu dommage, mais je ne vois pas le rapport avec le logiciel non plus.
Ton message plus bas représente bien ton attitude générale ici. Tu sembles plutôt au bord du burnout, et tu mélanges tout, en faisant des amalgames brutaux et incohérents.
Posté par Aeris (site web personnel) .
Évalué à -1 (+1/-3).
Dernière modification le 21 février 2024 à 00:27.
Excuse-moi d’être proche du burnout quand je passe 1 journée à expliquer des trucs à des gens qui disent que je dis de la merde mais prouve par A+B que j’ai raison, et que quand on me donne un exemple, je défonce littéralement le truc à la fois au niveau organisationnel (forum, source, build et j’en passe), juridique (des PP qui n’ont aucun sens) et technique (libs obsolètes de 3 ans d’âge, protocole crypto déprécié depuis 8 et chaîne de dépendance complètement WTF (ça fout quoi dans les livrables le libffmpeg.so que je ne sais même pas de quelle version il vient ?)) y compris sur de la crypto dont c’est supposé être le point fort de la solution… 😑
Mais encore une fois, on a fondé un logiciel libre sur un composant des GAFAM, que personne ne serait certainement capable de me dire quel version de ffmpeg, vulkan et eGL ça embarque, et tout le monde me donne tord depuis hier…
En vrai le soft que tu me demandes d’analyser est juste basé sur le pire navigateur de tout les temps conçus, géré et livré par Google lui-même. Vraiment, on aurait commencé par là, on aurait gagné du temps hein…
Et donc ton « client mail » est en réalité un navigateur de 161Mo embarquant en dur une libffmpeg pas maintenue par le système en cas de faille de sécurité, pour faire tourner le navigateur de Google et appeler des libs JS de 3 ans d’âge pour négocier des protocoles de sécurité pétés depuis 8 ans, le tout livré depuis un site web avec une privacy policy complètement lunaire, fournissant des tar.gz, deb ou appimage non signés, le tout avec un code source dispo exclusivement sous github en violation de Schrems II, et dont je suppose très fortement que tout ça se torche avec la compilation reproductible et que j’aurais aucun moyen de vérifier ce qu’il y a réellement dans le binaire fourni par le projet ?
Et tu oses venir me demander de me justifier sur la non conformité des projets libres ?????
J’oubliais quand même aussi : version d’électron embarquée ? 26.6.0
Fin de vie officielle quand ? 20-Fev-2024
Ah… C’est con… Un navigateur qui est en plus complètement déprécié…
C’est prévu quand la prochaine release de delta-chat du coup pour la migration en electron 27 minimum ?
Posté par Aeris (site web personnel) .
Évalué à 0 (+1/-2).
Dernière modification le 21 février 2024 à 09:27.
Le RGPD impose la minimisation des données et de la friction utilisateur, par exemple aucun effet négatif entre un utilisateur A et un B gui accepterait le tracking.
Dans tous les cas c'est bien delta-chat (l'équipe) le responsable de traitement et empêche l'accès à son propre soft pour quelqu'un qui voudrait l'utiliser.
Une boîte ou un particulier sensibilisé qui voudrait utiliser le soft ne PEUT PAS. Pas de signature des livrables, défaut de sécurité de la supply chain. Pas d'accès simple aux sources sans passer par une boîte US. La simple visite du site web conduit DÉJÀ à des violations du RGPD.
Un responsable de traitement (asso, boîte, particulier agissant hors 2(2)c) qui installe ce soft, sans vérification possible de l'intégrité donc, déploie un chromo obsolète rempli d'une 30aine de CVE, et commet donc une 20aine de violation lui-même (défaut de sécurité, défaut de sous-traitance, usahe de logiciel obsolète, défaut de contrôle de la supply chain, transfert US, …).
Et on en revient à ce que je dis dans mon article. Le libre devrait m'éviter de faire toutes ces vérifications et contrôles et devrait impliquer un certain gage de qualité. Sauf qu'en pratique ce n'est plus le cas et le taff de vérif à accomplir est au moins aussi important que pour le proprio.
Le proprio a par contre le bon goût, lui, de ne pas tenter par tous les moyens de ne même pas reconnaître qu'il est réellement responsable de traitement (c'est dans le contrat et il te file un DPA).
Techniquement en plus on a vu que ce soft est une merde sécuritaire de toute façon.
Ce n'est pas parce que Delta Chat héberge ses sources chez Github que Github devient co/sous-traitant du logiciel au sens de cette règlementation.
Un défaut de sécurité, c'est le quotidien de tout producteur de logiciel, le RGPD ne dit pas que tu ne dois jamais avoir de faille, sinon ce serait impossible de distribuer le moindre bout de soft.
Le libre devrait m'éviter de faire toutes ces vérifications et contrôles et devrait impliquer un certain gage de qualité.
Non pas du tout, c'est d'ailleurs pour ça que la plupart des licences (libres ou privatrices d'ailleurs) ont une clause de non garantie :-)
Bref plutôt que surinterpréter les lois, tu devrais remonter les problèmes que tu découvres :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Un défaut de sécurité, c'est le quotidien de tout producteur de logiciel, le RGPD ne dit pas que tu ne dois jamais avoir de faille, sinon ce serait impossible de distribuer le moindre bout de soft.
Je n’ai jamais dis ça. J’ai dis que tu devais mettre en œuvre les préconisations de l’état de l’art du secteur, en l’occurence celle de l’ANSSI, et que delta-chat ne respectait au moins pas les prérequis sur TLS (pas de PFS, DHE actif, moins de 3070 bits alors que PFS pas garanti).
Ce n'est pas parce que Delta Chat héberge ses sources chez Github que Github devient co/sous-traitant du logiciel au sens de cette règlementation.
Delta-chat agit en responsable de traitement au moins vis-à-vis de ses propres développeurs/contributeurs/whatever, et donc Github est sous-traitant de l’entité développant le logiciel delta-chat. Dans tous les cas.
Et l’utilisateur, en particulier association ou entreprise, ayant le RGPD à respecter donc, agit en tant que responsable de traitement, et delta-chat est son propre sous-traitant (au mieux, responsable de traitement conjoint, au pire).
Delta-chat ne respectant pas la réglementation en vigueur, et à la limite qu’il soit responsable ou pas ne change pas le problème, ne remplit pas les objectifs obligatoires pour utiliser ce logiciel (défaut de sécurisation, défaut de supply-chain, violation de Schrems II pour audit du code ou contribution) et delta-chat ne peut donc PAS être utilisé en Europe par qui que ce soit qui est soumis au RGPD.
Un responsable de traitement souhaitant mettre en œuvre l’article 28 du RGPD sur l’encadrement de la sous-traitance ne pourrait pas établir delta-chat comme sous-traitant conforme.
Delta-chat développe donc au mieux (s’il n’est pas responsable de traitement ni sous-traitant) un logiciel inutilisable légalement en Europe, au pire sera requalifié sous-traitant (ou pire du pire responsable de traitement) violant le RGPD et endosserait aussi la responsabilité d’une non conformité.
Aucune entreprise en Europe n’est en capacité légale de pouvoir utiliser delta-chat sauf à violer encore plus le RGPD. Les manquements que j’ai identifié sont suffisant à ne pas pouvoir mettre en place ne serait-ce qu’un acte de sous-traitance avec delta-chat par une entité soumise au RGPD.
Et à la limite on peut prendre le problème dans l’autre sens : je suis une entreprise/association qui souhaite utiliser delta-chat. Peu importe la relation contractuelle entre moi et delta-chat.
Je dois assurer la sécurité informatique de ma chaîne logicielle et n’utiliser que des outils répondant aux exigences « état de l’art » de l’ANSSI et contrôler ma supply chain, comme rappelé par la CNIL dans ses sanctions.
Je tombe sur un soft qui ne fournit pas de signature d’intégrité, embarque un navigateur obsolète contenant 30 CVE, me contraint dans tous les cas à ouvrir un compte sur Github (Microsoft) pour pouvoir ne serait-ce que remonter les issues. Je ne peux même pas aller constater les violations vu que pour ça faut que j’aille sur github. Ou faut que je me prenne le chou à trouver le moyen d’avoir un accès aux sources. Et qu’il me faut des notions en crypto pour m’apercevoir que la procédure de vérification d’intégrité proposée pour les APK est du flanc qui ne fait strictement rien.
Juste je passe mon chemin. Je ne vais pas passer 3h à chercher un truc quand en faisant 3 clics sur Google j’ai un contrat de DPA les rendant co-responsables de traitement légalement avec moi et que si jamais j’ai des emmerdes j’ai quelqu’un qui va être responsable avec moi, plutôt qu’un truc qui va me dire « démerde-toi tout seul t’avais qu’à forker c’est pas ma merde ».
Et c’est ça que le libre n’arrive pas du tout à adresser. Pire, cf la discussion ici, il NE VEUT PAS le faire.
Ce n'étais pas une erreur dans Matrix (utilisé pour Tchap), mais dans l'implémentation des restrictions d'inscriptions.
Et, je ne vois pas pourquoi tu prétends que c'est sans réflexion en amont. Ils ont pensés à des tas de trucs, et c'est plutôt bien que ce problème soit apparu rapidement.
Alors oui cela a été corrigé rapidement. Ce n'est pas une raison pour tout rejeter.
Beaucoup de projets d'envergure ont eu un soucis causé par une bourde au début de leur vie. Propriétaire ou pas. Ça n'a rien à voir avec la licence.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
Le libre devrait m'éviter de faire toutes ces vérifications et contrôles et devrait impliquer un certain gage de qualité.
Ce n'est pas le but d'une licence libre respectant les 4 libertés d'exécuter le code, l'étudier, en distribuer des copies et des versions modifiées non.
Si ça n'a aucun but et qu'au final en plus ici-même on me répond « de toute façon t'as pas besoin du source », faut qu'on m'explique encore une fois l'intérêt…
Je pourrais aussi signaler qu'un code source dispo sur github n'est du coup pas acccessible. Cette plate-forme est illégale en Europe et donc je ne peux ni voir le source ni contribuer.
Utiliser github viole manifestement au moins une des 4 libertés.
Une boîte ou un particulier sensibilisé qui voudrait utiliser le soft ne PEUT PAS.
Pas de signature des livrables,
Du livrable .deb de la version Desktop.
Pas de tous les livrables.
Ceux sur f-droid sont signés par exemple.
Pas d'accès simple aux sources sans passer par une boîte US.
Faux.
Mais s'il est nécessaire de faire un miroir des dépôts github en Europe pour respecter le RGPD, alors dis-toi que c'est déjà fait.
Tu as besoin de l'URL github pour retrouver ton projet.
Ce n'est pas mis en avant sur la page de Delta-Chat, mais une personne qui compilerait le logiciel serait au delà de l'utilisateur basique et donc on peut compter sur sa capacité à faire une recherche sur software héritage, et le quelifier d'accès simple.
L'utilisateur lambda ayant besoin d'un binaire déjà préparé, il n'a pas besoin des sources, il n'a pas besoin de github.
Si c'est pour un audit de code, tu es suffisamment compétent pour pouvoir considérer que l'utilisation d'un VPN (ou de TOR) ou d'un miroir est une solution simple d'accès aux sources.
Simple au sens ou c'est même trivialement automatisable.
Le proprio a par contre le bon goût, lui, de ne pas tenter par tous les moyens de ne même pas reconnaître qu'il est réellement responsable de traitement (c'est dans le contrat et il te file un DPA).
Ouais. Bon. Le proprio te dit « oui, oui, je suis conforme. » en mentant effrontément, mais ce mensonge n'est pas un crime alors osef ?
Techniquement en plus on a vu que ce soft est une merde sécuritaire de toute façon.
Toujours pas…
Le fait d'utiliser un hébergement mail pété ne bousille pas le modèle sécuritaire de Delta-Chat, et le chiffrement de bout en bout.
Puisque le serveur mail pété n'aurait accès qu'à des mails chiffrés à l'état de l'art.
Tu peux le trouer comme tu veux le serveur mail, récurer toutes les données, il va falloir casser PGP avant de lire les contenus.
Et le projet Delta-Chat, les services (forum) et le site web, les développeurs, etc, n'ont aucun contact avec ton utilisation du logiciel une fois installé.
Et on a vu qu'il y a des moyens d'obtenir le logiciel de façon signée.
En fait, je suppose même que sous un Debian-like, l'apt-get install deltachat ne va pas prendre le .deb officiel s'il existe, et te fournir un paquet, signé par Debian.
Ou Ubuntu.
Ou Redhat, ou Fedora, ou Suse, ou etc.
Je pense que les gens qui installent directement depuis le .deb fourni ne sont pas si nombreux, ce n'est pas le moyen d'accès privilégié pour ce genre de logiciel : c'est le gestionnaire de paquet de ta distrib.
Donc majoritairement il doit être bien plus facile d'obtenir un binaire signé que l'inverse.
Après à voir quelle confiance tu accordes à l'entité signante, mais c'est un autre problème.
La procédure donnée par delta-chat ne vérifie rien en pratique. Donc les devs eux-même ne savent même pas comment permettre la vérification. Sauf en se reposant sur f-droid (ils ont signé un DPA avec F-Droid comme sous-traitant/co-responsable de traitement d’ailleurs ?)
Ce n'est pas mis en avant sur la page de Delta-Chat, mais une personne qui compilerait le logiciel serait au delà de l'utilisateur basique et donc on peut compter sur sa capacité à faire une recherche sur software héritage, et le quelifier d'accès simple.
On ne parle pas de compiler le logiciel mais de faire l’audit bi-annuel obligatoire pour tout usage d’un logiciel tiers pour vérifier sa compliance norme ANSSI et supply chain.
L'utilisateur lambda ayant besoin d'un binaire déjà préparé, il n'a pas besoin des sources, il n'a pas besoin de github.
Une asso ou entreprise ou particulier non soumis à 2(2)c (avocat, médecin, usage pro quelconque mélangé à son usage perso dans sa boîte mail…) ne peut pas juste prendre un binaire random sur le net. C’est juste ça que tu ne comprends pas du tout.
Je pense que les gens qui installent directement depuis le .deb fourni ne sont pas si nombreux, ce n'est pas le moyen d'accès privilégié pour ce genre de logiciel : c'est le gestionnaire de paquet de ta distrib.
Ce n’est mentionné nul part dans la doc de delta-chat. Encore une fois c’est une faute de conformité RGPD. delta-chat ne devrait LÉGALEMENT PAS fournit de moyen d’installation non sécurisé et vérifiée.
Je t'invite à lire le RGPD et la définition de traitement de données. Le simple affichage d'une DCP à l'écran est un traitement. Qui a décidé de comment, dont du moyen, afficher les données à l'écran ? Delta-chat.
Définition de responsable de traitement du RGPD ? Entité qui décide les moyens ou finalités d'un traitement.
Delta-chat est responsable de traitement. Delta-chat doit respecter le RGPD.
Curl et telnet ont à respecter le RGPD. Ou dit autrement, s’ils n’implémentent pas le minimum viable pour être utilisé légalement en Europe, ils n’ont juste aucun sens.
curl ou telnet ne se mettraient pas à jour en terme de sécurité/fix de CVE ou autres, ils ne seraient juste tout simplement plus utilisables en Europe légalement parlant. Et si un utilisateur s’en sert et se fait trouer, ils seraient AUSSI responsables (quoi qu’indique leur licence).
J'ai l'impression que tu penses que le RGPD s'applique aux produits.
Est-ce que le fabricant du miroir dans lequel tu te regardes le matin (qui gère ton reflet, donc ton image, donc une donnée personnelle) est concerné par le RGPD ? Si oui, le constructeur du mur sur lequel il est accroché est-il son co traitant ?
Est-ce que tu as demandé la fiche de traitement au vendeur de brosse à dent, au fabricant de dentifrice et au constructeur de robinetterie avant d'acheter ta maison (tout ça va être en contact avec ton ADN lors de ta toilette) ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Posté par Faya .
Évalué à 8 (+6/-0).
Dernière modification le 21 février 2024 à 16:14.
si un utilisateur s’en sert et se fait trouer, ils seraient AUSSI responsables (quoi qu’indique leur licence).
Attends mais tu es sûr de ce que tu dis là ? Parce que j'ai l'impression que ça signifie tout simplement qu'on n'a plus le droit de fournir de logiciel. Aucun, jamais. Puisque tous les logiciels sont troués ou trouables. Imaginons que je sois un étudiant qui veut coder un webmail. Je fais un truc bien crade en PHP rempli de XSS, je mets ça sur ma forge perso et je poste le lien sur LinuxFR en disant "j'ai fait un joli Webmail, un peu crade mais venez le télécharger pour le tester sur vos serveurs." (Et je ne parle pas de licence, c'est vraiment orthogonal là)
Je suis responsable de traitement ? LinuxFr est co-responsable parce qu'il héberge le lien ?
Si tu déploies un tel logiciel tu dois effectivement dire que ce n'est qu'un poc, qu'il n'est pas utilisable en l'état et n'est pas habilité à traiter de la donnée perso.
Effectivement. Tu ne peux à aucun moment dire qu'il est utilisable et toute personne est supposée le savoir (le RGPD s'applique aussi aux particuliers, surtout pour une boîte mail généralement mélangeant pro et perso.
Tout logiciel livré doit de toute façon faire l'objet d'un DPA avec l'entité utilisatrice, ne serait-ce que pour garantir les maj, les alertes de sécu, les 36h légaux de notification en cas de faille, et toutes les autres exigences de l'article 28 qui doivent être contractualisées.
Posté par Faya .
Évalué à 9 (+7/-0).
Dernière modification le 21 février 2024 à 23:04.
On connaissait les copyright/patent troll, je crois qu'on assiste à la naissance des RGPD trolls là. C'est à dire empêcher les gens de produire du code en utilisant des principes juridiquement corrects (si tant est que tout ça soit vrai, je ne saurais en juger) mais inapplicables à moins d'être une grosse boîte avec une team de juristes dédiés. Plus possible de coder le moindre soft sans avoir un D.U.T Carrières Juridiques. La mort du DIY, de l'autodidacte, du release early release often, … (quelque soit la licence, toujours.) On dirait un roman dystopique.
Il y a énormément de métier que tu ne peux pas faire à la maison sur ton temps libre malgré que ça soit techniquement possible, sauf à passer des certifications préalables et des tets de compétences avant de pouvoir être autonomes.
Pourquoi encore une fois le libre ou le logiciel en général devrait magiquement ne pas faire éventuellement comme les autres ?
Oui développer est un métier qui ne nécessite pas que des compétences techniques mais aussi des compétences légales ou autre.
On ne t’autorise pas à faire de la chirurgie cardiaque dans ton salon.
Posté par Faya .
Évalué à 4 (+2/-0).
Dernière modification le 23 février 2024 à 20:41.
On ne t’autorise pas à faire de la chirurgie cardiaque dans ton salon.
Sérieusement, c'est le meilleur exemple que tu as trouvé pour illustrer ton point de vue ? Comparaison n'est pas raison. Je ne peux peut-être pas faire de chirurgie (pratiquer la médecine) mais je peux tout à fait construire un scalpel, une lampe de bloc opératoire, un lit électrique et même l'ordinateur qui piloterait tout ça. J'en ai le droit et même dans mon salon. J'ai aussi le droit de les refiler à mon pote pour qu'il joue avec à opérer ses peluches si il le souhaite et là c'est lui qui devra veiller à ne pas l'essayer sur son voisin. Comme dit plus haut (ou plus bas je sais plus) tu sembles vouloir appliquer le RGPD aux outils et je ne suis pas certain que ça soit juste. Vu que tu veux ramener au libre alors que la licence est sans rapport, Linux n'aurait jamais pu être testé en Europe avec cette vision extrême. "Développer est un métier" mais c'est aussi, souvent, un hobby. Passe-temps de hackers qui aiment jouer avec des machines et du code.
«Hello everybody out there using minix - I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones»
Je peux tout à fait construire un scalpel, une lampe de bloc opératoire, un lit électrique et même l'ordinateur qui piloterait tout ça. J'en ai le droit et même dans mon salon
Mais tu dois alors annoncer partout que ce truc n’est qu’un jouet, pas qualifié pour de vraies opérations, sans aucune certification médicale et que ce n’est pas utilisable en production, avec tous les warning obligatoires sur le sujet (comme par exemple la mention « ce produit n’est pas un dispositif médical »).
D’autant plus quand tu présentes ça comme la future révolution de ton domaine, que tu as fondé une boîte pour concevoir, développer et opérer ça et que tu en maintiens 2 instances en production pour de vrai.
Mastodon est l’équivalent de Sorin qui lancerait un nouveau pacemaker avec 0 certification, où il manque des gros bouts ne serait-ce que pour pouvoir envisager de lancer la certification, en ferait la promotion sur l’ensemble de ses sites internet et en aurait déjà implantés 2-3 en vrai sur des vrais patients et en maintiendrait même la liste officielle d’implantation réussie en dehors de tout process légal. Et sans jamais dire officiellement ni même officieusement ni même rien du tout « Mais surtout faites pas ça les gens ! » à ces hôpitaux qui se mettent à communiquer d’avoir aussi implanter des patients avec cette merde.
Il semble que cela tourne en boucle et que cette discussion fleuve n'aboutit à rien, je réitère cette demande faite plus haut et qui concerne tout le monde, à savoir s'en tenir là pour cette discussion qui peut dériver à tout moment.
Merci d'avance.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
Posté par Faya .
Évalué à 2 (+0/-0).
Dernière modification le 26 février 2024 à 13:52.
Il semble que cela tourne en boucle et que cette discussion fleuve n'aboutit à rien
Certes.
cette discussion qui peut dériver à tout moment.
Là par contre je ne comprends pas. Bon peut-être que tu fais référence à d'autres fils sur la même page mais ici ni Aeris ni moi n'avons été agressifs ou irrespectueux. OK on déblatère sans fin mais est-ce que ça contrevient aux règles du site ? Je repose ma question précédente, sachant que pour moi LinuxFR est un lieu où j'aime lire des discussions fleuves et intervenir inutilement moi-même, est-ce que la modération nous demande d'économiser les modos ? (vraie question parce que j'avais d'autres choses à demander à Aeris suite à son dernier message… Je peux bien sûr le faire ailleurs (sur Mastodon puisqu'il y est lol) mais je trouve ça bizarre et inquiétant qu'on nous demande d'arrêter de parler sans qu'on ait eu un mot plus haut que l'autre)
Curl et telnet ont à respecter le RGPD. Ou dit autrement, s’ils n’implémentent pas le minimum viable pour être utilisé légalement en Europe, ils n’ont juste aucun sens.
curl ou telnet ne se mettraient pas à jour en terme de sécurité/fix de CVE ou autres, ils ne seraient juste tout simplement plus utilisables en Europe légalement parlant. Et si un utilisateur s’en sert et se fait trouer, ils seraient AUSSI responsables (quoi qu’indique leur licence).
_1. Le présent règlement s'applique au traitement de données à caractère personnel, automatisé en tout ou en partie, ainsi qu'au traitement non automatisé de données à caractère personnel contenues ou appelées à figurer dans un fichier.
_
Curl, telnet ou deltachat ne font pas partie d'un système de traitement de données à caractère personel appelées à figurer dans un fichier.
Il a été affirmé plus haut, je cite : Établir une connexion TCP/IP, même chiffrée, reste une transmission de DCP (l’adresse IP de l’utilisateur) et est donc en soit un traitement de données soumis au RGPD
Comme je suis incompétent sur le sujet, j'en déduis que curl, telnet, et bash aussi, sont soumis au RGPD.
Et donc si curl et cie sont prévus pour être dans un environnement sans DCP, c'est hors RGPD, mais si ça traite (et la simple transmission est un traitement), alors curl doit répondre aux exigences du RGPD, sécurité, supply chain, DPA, gestion de l'obsolescence par une entité compétente, audit…
Et donc si curl livre des trucs pas patchés ou incompatible, il s'exclut possiblement de lui même de tout appel d'offre type HdH oui.
Posté par Aeris (site web personnel) .
Évalué à -3 (+0/-4).
Dernière modification le 21 février 2024 à 19:40.
Et à la limite peu importe de la responsabilité juridique ou pas de curl : livrer un soft pas conforme RGPD pour toute entité utilisatrice soumise au RGPD, ça serait… con.
Comme Mastodon qui dev un soft en pratique inutilisable en Europe… 🤔
Et j'ai aucun problème à ce que curl dise « je m'en fous du RGPD «. Tu m'excuseras simplement de ne pas pleurer s'il ne remporte pas d.appel d'offre, et de ne plus l'utiliser moi-même.
Une grande difficulté, dans le Droit, c'est l'interprétation.
Comme je disais souvent à une amie Avocate : Il y a le Français, et le Français juridique.
Parce que évidement, en terme d'interprétation j'étais souvent à côté.
Hé oui, c'est deux langues différente.
Même s'il y a un effort pour rendre le Droit plus accessible, par exemple dans la réécriture de certains articles, en "droit constant", c'est à dire mieux compréhensible par le commun des mortels mais sans changer le sens juridique.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
Mais tu n'expliques rien, tu ne prouves rien, tu prends des exemples, et tu en fais une généralité abusive et intrinsèque à tout les logiciels libres.
En plus tu te fais chier avec la version desktop de DeltaChat dont j'ignorais l'existence (et qui semble bien pourrave), quand je te parle de l'appli, pour smartphone, qui n'a pas de react, pas de node, pas d'electron, pas de ces trucs là !
Tu veux auditer les sources sans passer par github ?
Bah vas les chercher là : https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://github.com/deltachat/deltachat-android
Il te manque un commit, 1 !
Voilà, t'es en Europe, t'es même en France à l'INRIA !
Tu peux le faire ton audit de code sans approcher de Github.
Et tu mélanges tout en plus, tu mélanges l'accès à un service mail qui utiliserait une crypto obsolète avec le chiffrement des messages géré en interne par Delta Chat.
Ici Delta Chat te permet de te connecter avec un service mail potentiellement obsolète et troué, et de malgré tout l'utiliser avec du chiffrement de bout en bout des messages, qui resteront illisibles sur le serveur mail pété que tu peux quand même utiliser. Et vlan, tu les accuses de ne rien y connaître en sécurité…
Tu mélanges tout, tu fais semblant de ne rien comprendre…
Parce que à ce jeu là, il n'existe pas de client mail qui respecte tes règles. Zéro, aucun, nulle part.
Donc soit tes règles sont pétées, soit ton interprétation est pétée.
Et en pratique tu traduits ça par : les MAGAF me mentent oui en souriant et je préfère ça au dev libriste qui me dit honnêtement non.
T'as une vision hyper biaisée, tu es convaincu qu'au delà des MAGAF point de salut, ils sont la moins pire des solutions, et les autres c'est tous des cons qui en plus t'emmerdent au quotidien.
Et quand ce sont les MAGAF qui enfreignent les règles, bah on glisse sous le tapis parce que bon, z'ont pas le choix et cette règle là osef.
Mais quand ce sont des libristes, ce sont des enflures qui font rien qu'à t'embêter.
Ça ne peut pas être vrai.
Stop.
Déconnecte.
Respire.
Impose des limites à ton pessimisme défaitiste, parce qu'il ne sert à rien.
Donc en fait t'es en train de m'expliquer que le libre c'est bien parce qu'une asso a mirroré un github dans un coin pour avoir accès aux sources sans violer la loi ??
Tu sais que tu ne fais que confirmer ce que je dis dans mon blog hein ?
Et dans tous les cas, je rigole quand même quand j'entend dire que je dis que sans GAFAM point de salut (ce que je n'ai jamais dit) quand tu me files en exemple un soft libre qui tourne sous Chrome avec le source chez Microsoft hein… (C'est bizarre comme Github et Electron sont partout…)
En l'occurence electron ce n'est pas un produit gafam. C'est développé par l'openjs fondation et ça utilise effectivement des briques développés par google, mais bon à ce jeu là on peut dire qu'utiliser linux c'est utiliser et promouvoir les Gafam parce qu'on a accepté du code de leurs développeurs.
Github n'est pas non plus un prérequis pour faire du logiciel libre et j'encourage tout développeur libre à utiliser autre chose. Mais je comprends en même temps l'attrait pour certains à cause de l'effet de réseau.
Et je dis ça alors que j'abhorre electron et les applications basées dessus.
Maintenant j'ai l'impression que t'es parti dans une spirale de whataboutism qui n'est ni saine pour ton esprit, ni pour la discussion.
Github et le libre, ce sont deux choses différentes qui n'ont rien à voir. Tous les logiciels libres ne sont pas distribués via github et github ne distribue pas que des logiciels libres.
Sauf que quand on vient m’expliquer qu’on peut faire sans Github mais que 90% (chiffre au pif mais certainement proche de la réalité) des projets libres sont sous Github et exclusivement sous Github, je rigole.
Non.
TU dis qu'il n'est pas possible d'accéder aux sources, et donc de les auditer sans violer Schrems II.
C'est factuellement faux dès aujourd'hui.
Et si pour respecter Schrems II, le RGPD etc, il faudrait un miroir institutionnel des sources libres en provenance de github, en Europe et sans avoir à passer par Github.
Ce qui est légalement possible au vu des licences des logiciels considérés, d'où ici on parle de libre, parce qu'en dehors du libre, il faut analyser au cas par cas et en général c'est impossible.
Et bien il faut le faire plutôt que de dire que c'est impossible !
Et…
Et bien en fait ça existe déjà.
L'INRIA n'est pas une association.
Encore une fois, tu es convaincu de ce que tu racontes, et quand on t'expliques factuellement que tu te trompes, tu t'en fous.
Je ne sais pas quelle est ton excuse, mais tu as un problème avec les faits, règle-le.
Je pense qu'on peut s'en tenir là, si ça ne vous dérange pas étant donné que ça commence à tourner en boucle. On ne va pas tarder à en venir aux noms d'oiseaux et personne ne veut ça.
Merci d'avance.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
Ce n’est encore une fois pas de la responsabilité des utilisateurs que de faire le taff de mise en conformité qui aurait du être fait par le (au mieux) sous-traitant au sens du RGPD.
Sachant que pour mettre en place un mirroir, il faudrait toujours que celui qui le mette en place soit responsable de traitement avec github en sous-traitant, et que ben t’as toujours pas réglé le problème.
Et pourquoi est-ce que ça serait à moi d’installer Tor, de trouver Software Archive, ou de faire un mirroir de Github, quand ça pourrait être juste delta-chat qui n’utiliserait tout simplement pas Github tout court ?
Surtout quand on prétend ici-même qu’on sait faire sans les GAFAM hein !
Posté par Aeris (site web personnel) .
Évalué à 1 (+2/-2).
Dernière modification le 20 février 2024 à 18:09.
Non, mais que les avantages supposés du libre n’en sont plus vraiment en 2024 voire sont même des problèmes EN PLUS à gérer…
Je ne dis pas que le libre ne peut pas faire correctement les choses, je dis juste qu’aujourd’hui l’argument du libre est beaucoup trop utilisé pour se justifier de ne pas respecter la loi…
Et que par exemple si techniquement la fédération est plus intéressante, couplée à la législation en vigueur (et pour de bonnes raisons), elle n’est pas forcément la plus souhaitable une fois qu’on fait le compromis avec le côté juridique, sauf à aller dans des modèles ultra-décentralisés et de la fédération d’instances de 1-2 personnes maximum, ce qui apporte alors tout un tas d’autres problèmes humains (capacité à s’auto-héberger & cie) aussi à prendre en compte.
Des généralités et des amalgames, basés sur un exemple central à son discours, celui de Mastodon.
Qui n'a aucun rapport avec le fait qu'on pourrait avoir le HDH hébergé en France ou en Europe, basé sur des logiciels libres - existants - et qui respecterait parfaitement les normes ; ce que ne font pas les services cloud américains.
Et j’espère bien pouvoir en parler ici un jour, pour le moment légalement parlant c’est compliqué, mais j’ai quelques autres exemples de projets libres qui ont assez mal tournés justement en se justifiant qu’ils l’étaient, de libre…
Oui, mais justement, au sujet du HDH, tu passes allègrement sur les règles bafouées par les MAGAF pour dire que les services européens ne sont pas viables parce qu'ils en bafouent d'autres…
C'est trop demander d'avoir un minimum de cohérence ?
Soit ça viole, soit ça viole pas.
Si tout le monde viole, comment prétendre que c'est mieux côté MAGAF puisque personne ne répond au cahier des charges, et qu'en plus il y a au moins une règle qui ne peut pas être validée par eux ?
Posté par Aeris (site web personnel) .
Évalué à 0 (+0/-1).
Dernière modification le 21 février 2024 à 09:41.
Et c'est exactement ce que je dis dans mon blog.
Quitte à comparrer 2 trucs illégaux, je compare ce qui est plus ou moins conforme et je prend le moins pire. Et c'est pas forcément le libre.
Merci de la démo.
Et dans le cas de delta-chat, je ne peux même pas télécharger le soft, j'ai pas les signatures ! Donc je ne vais pas plus loin en fait. Ça n'ira jamais sur mon PC. Encore moins si je suis une boîte/asso (violation RGPD instantanée, défait de suply chain).
Comment tu fais pour installer deltachat sans signature, tu m'expliques ?
Je ne sais pas ce que tu essaies d'installer, et quel moyen tu mets en œuvre pour ne pas avoir un paquet signé à installer sur ta machine !
Ben j’ai juste pas de paquet signé hein…
Celui présenté sur le site de delta-chat ne possède aucune signature GPG ou même de checksum. Que ça soit pour le .deb, le app image, les sources ou n’importe quoi sur le site. Le seul truc éventuellement signé est l’APK android.
Tout le reste est livré sans aucune signature.
Et encore, la commande filée pour vérifier l’archive est invalide
Pour imprimer les empreintes SHA256 du certificat de signature de l’APK vous pouvez utiliser, par ex. keytool -list -printcert -jarfile <APK-file>
aeris> keytool -list -printcert -jarfile com.b44t.messenger_6774.apk
erreur keytool : java.lang.Exception: Une seule commande est autorisée : -list et -printcert ont été spécifiées.
Donc en gros on a des gus suffisamment crétin pour rédiger une procédure de vérification d’un APK sans même s’être posé la question de si c’était bien une vérification de signature et pas juste lister un des certificats dispo dans l’APK.
Là comme ça il est assez facile de refaire un APK verrolé qui vérifie exactement la procédure que delta-chat indique, il suffit d’inclure le certificat de fdroid sur un APK signé par un autre certificat.
La procédure de vérification donnée ne vérifiant que la présence du certificat et non la validité de la signature, ça passerait crème pour tous les utilisateurs qui suivraient la procédure officielle de delta-chat…
Et ces gens envisagent de développer un soft basé sur la crypto… 🙄
$ apksigner verify com.b44t.messenger_6774.apk &>/dev/null && echo OK || echo KO
OK
$ echo "\n" >> com.b44t.messenger_6774.apk
$ apksigner verify com.b44t.messenger_6774.apk &>/dev/null && echo OK || echo KO
KO
Mais du coup je suppose que c’est encore à moi d’aller faire l’effort de leur expliquer la crypto ? 🙄
monter/trouver un miroir de github pour virer Microsoft pour auditer le code (violation Schrems II)
passer un doctorat en crypto pour comprendre que la vérification de signature préconisé ne fait rien du tout (défaut de sécurité et de contrôle de la supply chain)
devoir corriger des CVE en migrant sur une version décente de Electron (défaut de sécurité et défaut de suivi obsolescence logicielle)
devoir en fait tout recoder pour virer Electron carrément et donc Google
J’ai pas encore testé, mais je suppose que va aussi :
me falloir monter un miroir de npm.js pour virer Cloudflare (violation Schrems II)
me falloir monter un miroir de crate.io pour virer AWS (violation Schrems II)
Ben comme dit, du coup tu te retrouves avec 2 trucs qui violent la loi.
Si le libre ne l’avait pas violer, j’aurais pu éventuellement dire que je m’en foutais des fonctionnalités différentes entre A (conforme) et B (pas conforme), j’ai que A comme choix viable et donc on s’arrête-là, c’est A qui gagne. Pas parce que c’est libre, mais parce que c’est conforme. Et je m’en cogne que ça soit libre du coup, ça ne m’apporte rien de plus : si c’est A qui est conforme et proprio et que B est non conforme mais libre, je ne PEUX PAS choisir B quelque soit ses avantages autres.
Et quand j’ai A (libre et pas conforme) et B (proprio et pas conforme), avant d’aller me battre pour les éventuelles fonctionnalités, je vais devoir d’abord sélectionner celui qui viole le moins la loi… Et c’est pas forcément A…
Si je dois violer 1 seule fois Schrems II en allant que chez Microsoft, ça sera toujours mieux que de le violer 4× via Google, Microsoft, AWS et Cloudflare.
Si je viole Schrems II en allant chez Microsoft, j’évite aussi de violer encore plus la loi avec une absence de SIEM/IAM/firewall/cloisonnement/interface privée d’admin en plus. 1 violation côté MS, 5 côté pas MS.
Etc.
Et que quitte à devoir dépendre de Microsoft pour Github, de Google pour Electron, de AWS pour npm.js et de Cloudflare pour crate.io, j’irais dépendre uniquement de Microsoft tout court, avec un vrai contrat formalisé et pas des « non mais t’as qu’à faire toi-même et de toute façon NO WARRANTY qu’on a dit ».
Et actuellement, on n’a PAS de solutions libres qui passent le 1er pré-filtre de la conformité. Donc on ne peut même pas commencer à parler de ce qui vient derrière, on en est juste au stade juridique et on fait le choix du moins pire au niveau légal. Pas technique. Pas éthique. Pas morale. Légal.
Et c’est là que vous déformez mes propos. Je n’ai jamais dis qu’on ne pouvait pas faire sans les GAFAM. On peut le faire. Je développe mes softs sur MA forge git, je release sur MES serveurs, je fournis des signatures sur TOUS mes livrables, même un pov’ article de blog (https://blog.imirhil.fr/2014/04/28/gpgit-chiffrez-courriel-entrant.html#installation, oui c’était en 2014 et y’avait pas encore ni Microsoft ni Schrems II pour Github), je fais gaffe à tenir à jour mes dépendances. Je fais des projets en minimisant mes dépendances.
Je dis juste qu’aujourd’hui la plupart des projets, y compris libres, livre de la merde en barre, du docker only electronisé google à mort pour faire l’équivalent d’un dd (je blague même pas, balena est l’équivalent de DD en interface graphique et pèse 133Mo parce qu’il embarque un navigateur complet, discourse n’est plus livré/supporté hors docker, etc), s’en cogne complètement de la conformité (même quand on veut y participer), tout le monde a foncé sur go qui n’est même plus fonctionnel le jour où github tombe et alors même qu’au début du monde le truc faisait des git-clone-main pour sa gestion de dépendances, etc…
C’est du coup pas qu’on ne peut pas faire sans les GAFAM, c’est que les projets libres font tout pour pousser les utilisateurs à y courir !
Le libre est supposé être le modèle d’exemple mais il n’est même pas capable de faire un truc aussi simple que « héberger sa propre forge logicielle sans dépendre de Microsoft et impose à tout contributeur un compte github chez Microsoft »…
Il y a des gens qui s'embrouillent sur Mastodon, ok.
Et c'est sur Twitter qu'on en parle ?
Le temple de l'ambiance toxique ?
Le supermarché de l'insulte et de l'agression en ligne ?
La boîte de pétri des complotismes ?
Le rendez-vous de la désinformation ?
Le trampoline de la haine en ligne ?
Tu es sérieusement sérieux là ?
J'espère que ce n'était pas pour faire une comparaison hein, par pitié, personne ne peut battre Twitter sur ce terrain là, ce sont les meilleurs, et oui, ils ont une avance irrattrapable de 15 bonnes années de puanteur toxique.
Ça se voit bien mieux depuis le rachat, c'est nettement plus décomplexé, mais l'ambiance agressive, violente, et pourrie, elle était déjà là.
On peut peut-être laisser un peu de temps aux petites instances Mastodon pour se construire ou disparaître, sans jeter l'ensemble du réseau ? Peut-être ?
Ou alors, non, on prend juste Twitter parce qu'ils sont plus « compliant » avec les requêtes RGPD ?
Mon sujet est justement qu’on ne devrait prendre ni l’un ni l’autre.
Et construire un truc autre. Certainement pas se ruer sur Mastodon au motif que c’est libre, décentralisé ou souverain.
Et on ne parle pas d’un choix à faire entre 2 réseaux légaux avec leurs avantages et leurs défauts, mais bien d’un non choix entre 2 réseaux illicites qui finiront je l’espère, DANS LES DEUX CAS par avoir des comptes à rendre à la justice.
Vas voir sur le Chapril, l'instance de l'APRIL, tu vas trouver tout un tas d'infos rapport aux réglementations, au RGPD etc.
Pas dis que tu trouves vraiment des infractions, et certain qu'on te répondra, et sans t'insulter.
C'est comme pour l'email, tu vas avoir des service mal foutus, peu réglementaires, peu soucieux des règles, de la sécurité, des utilisateurs, etc.
Et tu en trouveras d'autres qui sont irréprochables.
Y compris des associatifs.
Et tous peuvent communiquer entre eux.
Est-ce que les mauvais joueurs sont signe qu'il faut jeter la technologie, ou même les logiciels qu'ils utilisent, à la poubelle ?
Si ça se trouve, le logiciel derrière Twitter est très bien et pourrait être utilisé pour faire un super réseau social hyper respectueux, mais il n'y a qu'une seul instance, et elle est complètement pourrie.
Pour Mastodon il y a un univers d'instances, et évidemment tu vas trouver de tout.
Est-ce signe que tout est à jeter dans Mastodon ?
Comment tu arrives à cette conclusion ?
Et tu ne penses pas que les gens qui vont sur Mastodon peuvent aussi le faire parce que ça marche pas si mal ?
Non, c'est forcément un effet de mode, et ils sont tous idiots à ne pas voir plus loin que le bout de leur nez, avec leurs lunettes de libristes ?
Alors que le principe même de la fédération avec Mastodon entre autre, c'est qu'on peut facilement couper les branches pourries.
Regarde sur ton instance, tu devrais voir la liste des instances bloquées car irrespectueuses des règles.
Et tu ne vas pas les subir.
Bien sûr, la méthode a ses limites, mais aucun logiciel n'est parfait, et celui-ci cherche à s'améliorer dans le bon sens.
Et toi, tu suggères de laisser tomber, ne pas chercher à améliorer et repartir à zéro ?
À quoi ça sert à part à laisser le champs libre à Twitter ?
Encore une fois, c’est toi qui dit qu’il faudrait tout jeter.
Moi j’ai juste dit que sur des gros projets d’envergure, on n’avait plus que le choix entre des trucs pas conformes US et des trucs encore plus pas conformes EU, avec en plus en Europe souvent un gros retard au niveau fonctionnalités.
Et donc que rationnellement il faut faire dorénavant un choix, et que juste dire « ah ben oui mais c’est libre/souverain » est juste un mauvais argument pour faire ce choix. Être libre ou souverain ne veut plus RIEN dire (surtout en 2024 hein…) et n’est PAS un argument sinon un totem d’immunité sans aucun intérêt ni technique, ni moral, ni éthique, ni conformité, ni rien.
Posté par Aeris (site web personnel) .
Évalué à 1 (+1/-1).
Dernière modification le 20 février 2024 à 10:52.
Je répète : sinon les instances auto-hébergées (et encore, en théorie arrêt de la CJUE sur les réseaux sociaux, l’exemption du RGPD au titre du 2(2)c pour usage strictement personnel et domestique n’est pas possible ici), tout le reste est ILLÉGAL en Europe.
Chapril compris !
Side note : c'est possible d'intégrer le contenu du tweet en citation ?
Je n'y ai plus accès, Nitter ne marche plus à cause de l'expiration des comptes clients temporaires, et Twitter demande un compte pour accéder à n'importe quel tweet.
Tweet de Alexandre Archambault, avocat numérique français :
Des nouvelles de la modération par les geeks (Usenet hier, Discord aujourd'hui). Les mecs partent en vrille à la moindre contrariété froissant leur petit égo.
Et le jour où la justice s'intéressera aux pratiques des shérifs numériques sur Mastodon, ça va être un festival.
Et une des réponses :
L'existence même de ces shérifs sur Mastodon (à l'insu des utilisateurs un serveur plus loin) est une raison suffisante à ne pas y aller.
Et qui veut aller dans la brousse de Mastodon, Bluesky ou Threads lorsque tout se passe sur X?
Pour moi la modération sur Mastodon est un réel problème, en particulier parce qu’elle est conceptuellement cassée (j’en ai déjà parlé sur ce site), mais c’est d’abord et avant tout un problème de relations humaines, pas un problème légal.
D’autre part, après quelques mois de stabilisation, mon compte Twitter/X est maintenant quasiment vide. Des comptes que je suivais sur cette plate-forme, j’en retrouve à la louche 30 % sur Instagram, 10 % sur Mastodon (dont les problèmes intrinsèques ont fait fuir pas mal de non-geeks sur le moyen terme), 50 % sur Bluesky, et les 10 % restants continuent à être exclusifs à Twitter/X. Bon, j’imagine que tout ça dépend beaucoup du type de comptes que tu suis, et personnellement j’avais déjà exclus les personnes actives hors réseaux sociaux (site web, RSS, etc).
Mais dire que « tout se passe sur X » en 2024 c’est quand même se mettre de sacrées œillères, ou avoir des catégories suivies très particulières (j’imagine que c’est le cas quand tu es fan de cryptomonnaies, par exemple).
Alors elle est aussi un problème légal pour le coup.
Mastodon avait déjà un problème de légalité avec à cause du comportement d’Eugen (qui fait que de facto le DSA s’appliquerait à lui en tant que gate-keeper, cf article de Contexte), mais que ça va être encore pire à partir du 1er mars où il entre aussi en vigueur pour tout le monde et plus exclusivement pour les GK.
Le simple fait qu’il n’existe aucune procédure propre, correcte et neutre d’appel en cas de blocage fait que Mastodon va devenir encore plus illicite à partir du 1er mars.
Le simple fait qu’il n’existe aucune procédure propre, correcte et neutre d’appel en cas de blocage fait que Mastodon […]
Est ce qu'il est question du blocage d'une instance par les administrateurs d'une instance, ou bien le blocage fait par un utilisateur vis à vis d'une instance ou d'un autre utilisateur?
Personnellement, je ne vois pas en quoi je quoi je devrais permettre une procédure d'appel dans ces deux cas. <- S'il te plait, je voudrai ton avis.
C'est comme pour les emails, je décide unilatéralement de bloquer des serveurs, des IP, des ranges, des domaines. C'est mon choix. Et si mes utilisateurs appliquent des filtres, pourquoi pas (parce que je n'ai pas implémenté la possibilité que mes utilisateurs puissent bloquer en amont).
Sur des serveurs Mastodon, certains ont décidé de bloquer Thread. Et, il faudrait que Meta (Thread) puisse faire appel? La bonne blague.
Microsoft bloque parfois (c'est variable dans le temps), les emails provenant d'IP domiciliaires, et il n'y a rien pour faire appel (j'ai cherché longtemps, je n'ai pas trouvé).
Je ne comprends pas cette obligation d'avoir une procédure d'appel, d'autant plus qu'il n'y en a pas chez les Gafam non plus, et que quand bien même un utilisateur/client arriverait à joindre le support, celui-ci ne peut rien faire. Alors que les admins de Mastodon, des Chatons et de plein d'autres services sont quand même joignables et que tout est négociable, mais libre aux admins de répondre.
(je fais allusion aux cas de pertes de données par blocage des comptes chez Google sur une simple erreur judiciaire ou après un blocage par un mécanisme automatique)
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
Voilà pourquoi gmail efface silencieusement certains emails reçus… les emails ne sont pas bloqués ni renvoyés, ils sont acceptés (code OK 250) puis éventuellement effacés sans notifications.
Du coup, Microsoft qui bloque les emails provenant de serveurs sur des IP domiciliaires c'est illégal? (Oui, je peux aussi créer un petit tunnel vers un VPS dans un DC juste pour les cas un peu récalcitrants, quand le besoin se fera sentir)
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
Il faut que je retrouve d’ailleurs vu qu’on a parlé de moralité un peu plus bas ici aussi la convention de modération rédigée par l’ACLU et l’EFF et qui est supposé représenter une bonne vision de la moralité. Spoiler : l’obligation d’appel fait parti des exigences pour un respect de la démocratie.
Ne pas permettre une procédure d’appel (neutre, impartiale, etc) est donc non seulement illégal mais aussi immoral.
Ce qui est dommage concernant le DSA, c’est qu’il est très facile de trouver que :
Les règles sont proportionnées à la taille des entreprises et à leur incidence sur la société. Les très petites plateformes sont exemptées de la plupart des obligations.
Source : Règlement sur les services numériques
Par contre, personne n’a l’air motivé pour mettre en accès simple lesdites règles pour les petites plateformes, en tous cas pas depuis les pages officielles qui parlent du DSA.
« Très petite plateforme » ne s’applique de toute façon pas à Mastodon, que ça soit à titre individuelle pour les instances de plusieurs milliers de personnes, ou de toute façon à titre collectif, la décentralisation n’étant pas décomptée comme des entités séparées mais comme des entités communes (cf article Contexte).
Les destinataires du service devraient pouvoir contester facilement et efficacement certaines décisions des fournisseurs de plateformes en ligne, relatives à l’illicéité d’un contenu ou à son incompatibilité avec les conditions générales, qui ont une incidence négative pour eux. Il convient donc que les fournisseurs de plateformes en ligne soient tenus de prévoir des systèmes internes de traitement des réclamations, qui remplissent certaines conditions visant à garantir la facilité d’accès à ces systèmes ainsi que leur capacité d’aboutir à des résultats rapides, non discriminatoires, non arbitraires et équitables, et à garantir que ces systèmes fassent l’objet d’un réexamen par un être humain lorsque des moyens automatisés sont utilisés Ces systèmes devraient permettre à tous les destinataires du service d’introduire une réclamation et ne devraient pas fixer d’exigences formelles, telles que le renvoi à des dispositions juridiques spécifiques pertinentes ou à des explications juridiques compliquées. Les destinataires du service qui ont soumis une notification, au moyen du mécanisme de notification et d’action prévu par le présent règlement ou par l’intermédiaire du mécanisme de notification des contenus qui enfreignent les conditions générales du fournisseur de plateformes en ligne, devraient être autorisés à utiliser le mécanisme de réclamation pour contester la décision du fournisseur de plateformes en ligne concernant leurs notifications, y compris lorsqu’ils estiment que les mesures prises par ce fournisseur n’étaient pas adéquates. La possibilité d’introduire une réclamation visant à obtenir l’annulation de la décision contestée devrait être disponible pendant au moins six mois, à compter du moment auquel le fournisseur de plateformes en ligne a informé le destinataire du service de la décision.
Et article 14
Les fournisseurs de services intermédiaires incluent dans leurs conditions générales des renseignements relatifs aux éventuelles restrictions qu’ils imposent en ce qui concerne l’utilisation de leur service vis-à-vis des informations fournies par les destinataires du service. Ces renseignements comprennent des informations sur les politiques, procédures, mesures et outils utilisés à des fins de modération des contenus, y compris la prise de décision fondée sur des algorithmes et le réexamen par un être humain, ainsi que sur le règlement intérieur de leur système interne de traitement des réclamations. Ils sont énoncés dans un langage clair, simple, intelligible, aisément abordable et dépourvu d’ambiguïté, et sont mis à la disposition du public dans un format facilement accessible et lisible par une machine.
Posté par Aeris (site web personnel) .
Évalué à 2 (+1/-0).
Dernière modification le 20 février 2024 à 13:46.
Et pour les exemptions, c’est seulement les « très petites entreprises » donc moins de 10 personnes « occupées » (avec la vraie problématique ici de la contribution aux sources en particulier en faveur de l’entreprise majoritaire dans le réseau et l’usage de bénévoles pour la modération) et moins de 2 millions de CA. Le tout sans devoir être gate-keeper donc pour une plateforme sous les 45 millions d’utilisateur actifs par mois ou en situation de distorsion de marché (ce que peut être doublement Mastodon).
D’ailleurs soit dit en passant, c’est là qu’on voit que la Commission EU a pensé à prendre en compte la décentralisation/fédération/libre et cie. C’est a priori volontaire d’avoir parlé de « personnes occupées » et non de « personnes employées ». Tes modos bénévoles ou tes contributeurs au code comptent dedans…
Nul n’est censé ignorer la loi… mon c*l ouais, c’est un enfer à lire ces textes.
Bref, pour le DSA, il :
ne devraient pas s’appliquer aux fournisseurs qui peuvent être qualifiés de microentreprises ou de petites entreprises telles qu’elles sont définies dans la recommandation 2003/361/CE.
une petite entreprise est définie comme une entreprise qui occupe moins de 50 personnes et dont le chiffre d'affaires annuel ou le total du bilan annuel n'excède pas 10 millions d'euros.
Et surtout il y a la notion de portée que je trouve intéressante, (mais qui ne semble concerner que les très grands entreprises) fixée à :
45 millions, c’est-à-dire un nombre équivalent à 10 % de la population de l’Union
Mais 45 millions de quoi ? Bah manifestement de « destinataires actifs », c’est à dire de personnes ayant volontairement utilisé le service (on ne compte pas les inscrits inactifs donc) dans les 6 derniers mois. Là c’est assez flou…
DSA, paragraphe 76 & 77
Donc :
– Est-ce que je suis un utilisateur actif de l’instance ou je suis inscrit ? (qui ne doit clairement pas compter + de 45 millions de « destinataires actifs » et est probablement gérée par 1 à 5 personnes)
– Est-ce que je suis un utilisateur de Mastodon ? (ce qui n’a pas vraiment de sens étant fédéré à d’autres services comme PeerTube, Firefish, etc… de toutes façons, Mastodon n’a a priori même pas 7 millions d’utilisateurs)
– Est-ce que je suis un utilisateur d’ActivityPub ? (Je doute quand même qu’on approche des 45 millions)
Du coup, juste pour le DSA, les instances Mastodon doivent pouvoir échapper à la majorité des dispositions, non ?
Et c’est là que « ça dépend ». Si le réseau est considéré comme une entité commune (ce que semble dire la Commission Européenne, à cause en particulier du comportement d’Eugen, et aussi pour éviter d’offrir un boulevard juridique aux GAFAM via de la fédération) ou pas (assez improbable vu la position des personnes interrogées côté Commission).
Et tu remarqueras aussi que c’est justement marqué « occupe » et non « emploi », et que c’est « 50 personnes ET moins de 10 millions » et non pas « 50 personnes OU moins de 10 millions ».
Il y a bien plus de 50 personnes occupées sur Mastodon, en comptant les développeurs (1889 dans le github), les modérateurs, les administrateurs d’instance, et j’en passe.
La 1ère clause du nombre de personne tombant, le DSA s’applique. Et donc certaines instances (mastodon.social via la boîte d’Eugen qui est aussi celui qui détient les droits de copyright sur le soft et fou une sacrée merde juridique) à elles-seules pourraient déjà avoir le DSA sur la tronche, mais en plus le Fediverse tout entier d’après la Commission Européenne dans tous les cas.
Ah oui et sur la portée, la limite de 45 millions n’est que pour la définition de gatekeeper. Qui ont des exigences renforcées.
Pour les autres, et en tout cas depuis le 17 février dernier, il y a quand même des obligations aussi, en particulier de célérité, de processus (appel neutre, etc) et de transparence de la modération à mettre en œuvre pour tout le monde.
Merci pour tes réponses. Dommages qu’elles se soient faites moinsser quand il s’agit de réponses plus techniques que d’un jugement moral personnel.
Du coup, c’est la seule chose que j’aurais à répondre : un sentiment personnel, d’un non-juriste, avec toutes les limites que ça comporte.
Et c’est là que « ça dépend ». Si le réseau est considéré comme une entité commune (ce que semble dire la Commission Européenne, à cause en particulier du comportement d’Eugen, et aussi pour éviter d’offrir un boulevard juridique aux GAFAM via de la fédération) ou pas (assez improbable vu la position des personnes interrogées côté Commission).
Si le réseau se retrouve considéré comme une entité commune alors, c’est ça devient le procès d’ActivityPub, et de tous les services fédérés entre eux. Effectivement, en comptant les développeurs de Mastodon, Firefish, Peertube et les autres (dont Thread de Meta je crois), ActivityPub « occupe » bien plus de 50 personnes… Si c’est vers ça que tend la commission, je souhaite bien du courage aux organismes qui vont être chargés de faire respecter le DSA et les autres textes qui ne manqueront pas de venir réguler les réseaux.
L’argument de considérer le réseau comme entité commune dans le but d’éviter un boulevard juridique aux GAFAMs me semble assez spécieux. Il aurait/serait (je ne sais pas ou on en est de ces discussions) peut-être été préférable de se pencher sur les relations de subordinations directes (l’instance A est la propriété de Meta via la filiale B) ou indirectes (le logiciel a des CGU contraignantes, pas d’export/import de données standardisées vers des logiciels équivalent, une implémentation personnelle du protocole avec des fonctionnalités maisons non-reproductibles, etc. En gros tout ce qui fait du lock-in).
Après, peut-être que justement ce genre de « définition » laisse trop de trous dans la raquette, c’est possible, je ne saurais dire.
Et donc certaines instances (mastodon.social via la boîte d’Eugen qui est aussi celui qui détient les droits de copyright sur le soft et fou une sacrée merde juridique) à elles-seules pourraient déjà avoir le DSA sur la tronche, mais en plus le Fediverse tout entier d’après la Commission Européenne dans tous les cas.
Que la boite d’Eugen, en tant que développeur principal de Mastodon, soit considérée comme « occupant » plus de 50 personnes, pourquoi pas. Que mastodon.social soit comprise dans le lot, parce qu’elle est administrée par des gens de Mastodon gGmbH, oui ok, à la limite. Mon sentiment est qu’on n’en n’est pas vraiment au même niveau/pouvoir de nuisance qu’un Meta ou qu’un X, mais passons. Donc le DSA s’applique à Mastodon gGmbH.
C’est plutôt l’impact pour les « petites » instances, associatives ou non, de quelques milliers d’utilisateurs et composées d’une poignée d’admins que je me pose des questions. En gros, si je comprends bien ce que tu me dis, elles seront assujetties au DSA (et futurs règlements des plateformes et rézosoçios avec les responsabilités qu’ils impliqueront) même pas parce qu’elles utilisent un logiciel développé par plus de 50 personnes, mais bien parce qu’elles se connectent à un réseau dont certaines instances tournent avec un logiciel développé par une grosse boite et/ou plus de 50 personnes…
J’espère vraiment que ça ne sera pas interprété comme ça. Ce serait plus ou moins l’avis d’exécution du Fediverse qui serait signé.
T'as entendu parler d'Alstom ?
Une petite boîte française, partie aux USA sur fond de procès américain, avec détention abusive de ressortissants français sans jugement, pour des histoires de corruption qui n'ont jamais concerné les états-unis, et qui implique précisément l'extra-territorialité de leur juridiction…
Tu supposes qu’on a des fruits. On n’en a pas.
En informatique ?
On en a des pleins jardins, d'ingénieur/es, d'entrepreneur/es, de propriété intellectuelle, de projets, d'idées, de recherche, de gens motivés, etc.
Pas des jardins, non, des champs à perte de vue…
On a dorénavant une 15aine d’années sinon plus de retard sur les systèmes US et rattraper le retard coûtera HORRIBLEMENT plus cher que de continuer à engraisser l’Oncle Sam.
Quelles âneries, faut vraiment rien y connaître alors.
Tu t'y connais en technique informatique pour raconter des bêtises pareilles ?
Tu t'appuies sur quoi ?
C'est quoi tes 15 ans ?
C'est quoi la soi-disant différence impossible à rattraper ?
Avec des raisonnements à la con comme le tiens, jamais on n'aurait construit Ariane ou Airbus, ou même la bombe nucléaire, dans notre mini pays tout en retard.
Ces trucs là, ça va, ça vient, il suffit de peu de choses en vrai pour rattraper et revenir au niveau.
Surtout en informatique, parce qu'il y a 15 ans, le cloud Ricain, c'était du vent, et que tout existe déjà en France.
« Un retard de 15 ans », je vais rigoler encore longtemps en répétant ça tiens.
1000 milliards pour faire un cloud assez balaise pour y mettre nos données de santé ?
Mais dans quel monde tu vis ?
On demande pas de faire des mastodonte délirant comme les gros MAGAF hein, ça sert à rien, on saurait pas les protéger de toute façon, on se les ferait bouffer comme des ânes, comme d'habitude, ou ils deviendrait des veaux à la Orange, poussif, massif et inefficaces.
Mais un tissus d'entreprises de plus petites taille, dans toute l'Europe, capable de répondre aux problématiques de l'Europe, et en plus de faire du commercial vers les Européens, c'est bien moins cher que ça.
Et bien plus rapide aussi.
Et bien plus résilient.
Et bien plus facile à auditer.
Et à entretenir.
Et à protéger.
Bref, il ne faut pas suivre le modèle américain, à leur jeu on va perdre, mais ça ne veut en rien dire qu'on ne peut pas faire autrement, et avoir un bouzin qui fonctionne quand même.
Probablement mieux pour nos besoins d'ailleurs.
Mais peut-être que, comme on peut le lire dans d'autres commentaires, l'idée pourrait être que les certifications dont on a besoin soient non pas extrêmement chères, mais un service public pour entreprises européennes. Un service qui, par contre, ferait son travail efficacement et vérifierai vraiment que le cahier des charge est rempli.
Et peut-être que les gros ricains ils seraient peut-être pas si parfaits que ça, et que la concurrence elle serait un peu moins faussée.
Encore une belle idée reçue ça, que les services des MAGAF seraient à la pointe de la perfection, et rempliraient toutes les cases de la sécurité et de l'efficacité.
Tiens certains contributeurs ne connaissent pas Aéris apparemment, étonnant !
Privilégier des entreprises nationales a notamment l'énorme avantage de créer des emplois locaux, ce qui est bon électoralement(et réduit donc la montée du RN), pour le retour sous forme d'impôts, de consommation, etc. Pourquoi les USA le font-ils à ton avis ? Tiens c'est marrant, ça rappelle beaucoup le contexte qui provoque actuellement une méga-grogne agricole…
Quant au fait que les bases soient propriété de l'état ou pas, ça ne changera rien pour un pouvoir motivé : il obligera tout simplement le prestataire à lui fournir les données.
Selon lui, "on" n'a pas le choix que d'aller chez Microsoft pour le Health Data Hub parce que seul Microsoft a les bonnes certifications ? C'est juste faux.
Qui est actuellement capable de répondre aux exigences ?
Je ne vais pas faire de pub, mais des boites certifiés Hébergeur de Données de Santé, il y a plusieurs en France et pas des TPE…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Par contre, ces hébergeurs sont des hébergeurs de données et pas de projets, dans le sens où un hébergeur peut apparaitre dans cette liste sans être capable d’héberger un projet d’une entreprise tierce. Une entreprise peut être certifiée uniquement dans l’optique d’héberger les données de son propre outil.
Et tu peux aussi demander à InterHop, ils utilisent un hébergeur HDS mais ont aussi eu à mettre en place des procédures très lourdes de leur côté, que ce soit en terme de code, d’automatisation, d’isolement réseau, etc. La certification HDS de l’hébergeur n’a été que l’étape initiale obligatoire, et pas du tout la balle en argent…
Ah oui, comme dit aussi dans mon article, c’est le cumul des exigences qui posent aussi problème. Par exemple sur les 117 hébergeurs, combien sont aussi compatibles avec l’orientation obligatoire des projets étatiques du moment (« cloud au centre ») qui impose une certification SecNumCloud en complément ?
Ça n'est un problème que parce qu'il n'y a aucune volonté politique d'aider les entreprises hors Gafam à acquérir ces certifications. Avec une vraie volonté politique cela aurait été réglé depuis un certain temps déjà !
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
Être certifié n’est pas une garantie de ne pas se faire trouver.
Ne pas être certifié est l’assurance d’avoir des problèmes.
Les certifications, surtout en terme de sécurité quand on parle de PCI-DSS ou HDS sont quand même autrement moins bullshit que certaines autres et imposent surtout un minimum vital de respect de l’état de l’art.
Ce n’est par contre effectivement pas une garantie d’aucune sorte sur la qualité du truc derrière.
Pour le vivre de l’intérieur, je peux te garantir que certaines des certifications vues comme « de haute qualité » et « très contraignantes pour les avoir » sont loin d’être aussi carrées et imposent moins de qualité et de sécurité réelles qu’on pourrait le croire en s’appuyant sur la théorie. Ceci est à comprendre comme « Certaines entreprises certifiées n’ont pas le niveau de rigueur et de qualité réels qu’on pourrait croire en lisant la théorie ». Par contre, pour des raisons évidentes, je ne peux pas donner de détails plus précis.
J'peux témoigner sans trembler que les certifs ça vaut pas grand chose.
On a une certif' ISO-27001 qu'on doit jamais avoir. Mais bon, on invente une vie à 3 disques durs randoms avec un étiquetage sorti le matin même, on demande à quelques employés qui ont des accès admin de ne pas se connecter au réseau de l'entreprise pendant 3 jours et de bien garder leur poste hors ligne, on créé des procédures qui ne seront jamais mises en place mais qu'on est en mesure de détailler à l'auditeur…
Et on est une entreprise française, leader en Europe sur son marché.
Donc à l'échelle des GAFAM je n'ose imaginer les magouilles qu'il y a pour valider les certifs.
Se fier uniquement aux certifications acquises, c'est un bien mauvais choix et ça démontre surtout qu'on est bien loin de la réalité concernant l'acquisition des certif'.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
Alors il n’y a pas beaucoup plus de volonté de certification de la part des éditeurs eux-mêmes hein.
C’est long, chiant, pénible, ça limite tes possibilités de développement et les entreprises préfèrent violer la loi que de la respecter, parce que sinon viser les 10% de croissance n’est plus possible…
Va demander à une boîte d’interdire à ses devs d’avoir le moindre accès à la prod. Pour quelques raisons que ce soit. Même pour debug, même pour avoir des logs. Même pour faire des déploiements. Ça va couiner. Beaucoup.
Et je sais de quoi je parle, c’est extrêmement galère au quotidien à gérer et faut encaisser la direction qui comprend pas pourquoi le moindre déploiement prend 7 jours juste pour ajouter un filtre dans un formulaire web.
Parce que tu dois avoir l’approbation de la Q/A, de la qualif PCI-DSS et les 3 paraphes de la DSI. Que les ¾ des libs disponibles sur Terre te sont interdites parce que ne passent pas les prérequis techniques minimaux.
Ajouter un lien sur le site web, ça a été 6 mois de taff, avec implication de la DSI, du responsable juridique, etc.
Après on a un énorme avantage : on a l’ACPR qui est un régulateur qui est « un poil » plus chiant que la CNIL. 2 contrôles annuels de fond en comble avec insta strike de tout ton business pendant X mois à la moindre case qui passe en rouge, ça motive assez sévère à envoyer chier la direction 🤣
Et on a 2 personnes à plein temps juste pour gérer les audits permanents.
Un développeur n'a pas à avoir accès à la prod non.
Je travaille chez un important éditeur logiciel et aucun développeur n'accède à la prod et non il ne faut pas 7 jours pour changer quoi que ce soit. Avec un process rôdé, c'est quelques heures tout au plus. Si vous êtes incapables de descendre en-dessous d'une semaine pour le moindre changement, alors c'est que vous avez un problème de process et d'organisation.
Et visiblement aussi de communication puisque vous n'êtes pas en mesure de trouver des solutions entre vos différentes équipes pour y pallier.
Le problème ne semble pas provenir des certifications à te lire.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
Que les ¾ des libs disponibles sur Terre te sont interdites parce que ne passent pas les prérequis techniques minimaux.
Ah, tiens, je me suis mis à faire du développement Web il y a 3 ans. Après 15 ans à maintenir dans la même boîte un Jenkins qui compile en autonome sur des VM, façons Debian (pas de connexion à l'extérieur), c'était une tâche horrible que de découvrir l'écosystème JS. Bonjour connexion aléatoire à pour télécharger qui exécute . Ça fait littéralement très peur, pour moi qui venais du Java/C++.
Et les outils pour maîtriser ce genre de choses sont compliqués à installer : serveurs mandataires internes avec cache pour NPM, c'est relou. Il y a le même problème avec Docker : bonjour FROM vendor/machine dont tu arrives même pas à retrouver l'origine, ou alors qui est une cible mouvante.
HDS qui n’est qu’un des certifications nécessaires pour faire tourner un tel projet.
Manipuler des données de santé implique être HDS. Ne nous trompons pas dans la contraposée, être juste HDS n’implique pas de pouvoir automatiquement manipuler des données de santé, ne pas être HDS t’interdit de traiter un tel projet.
Mais être HDS ne suffit pas. Tu dois aussi possiblement être ISO-27001, PCI-DSS, RGPD, DSA, SecNumCloud et j’en passe possiblement d’autres.
Ici HDS n’est pas le seul critère, il y a au moins le RGPD (vu que données perso) et SecNumCloud (vu que politique cloud au centre de l’État) aussi.
Je me permets de réagir sur un argument du billet :
On préfère du LineageOS rooté récupéré sur des liens de direct download russes via un obscur forum random. Ou du FairPhone qui a arrêté les mises-à-jour de sécurité de son téléphone après 7 ans. Apple, ça a été 9 ans pour le 6S de la même année.
La comparaison ne tient pas. Fairphone a vendu 95 000 téléphones en 2020. À 500€ l'appareil, ça fait 50 000 000 € (j'arrondis, je suis gentil). Le résultat net de Apple est de 97 milliards de $ en 2023. Il faut 5 heures de bénéfices Apple pour acheter toute la production Fairphone en un an. Apple maîtrise son produit verticalement, il peut donc obtenir un support matériel plus facilement. Je trouve que justement, le maintien des mises-à-jour par Fairphone relève de l'exploit.
Mais finalement, celui qu'il faut blâmer, c'est plutôt Google : Android supporté pendant 2 à 3 ans (au moment du Fairphone 2), et même si Android tourne sur du matériel largement plus hétérogène, Google possède une arme assez simple, la certification Android. Celle-ci peut très bien imposer le support du matériel et des mise-à-jour de sécurité sur une période plus longue, et soyons conservateur, disons 5 ans.
L'argument initial était de souligner que les libristes préfèrent fermer les yeux sur la sécurité de la chaîne d'approvisionnement logicielle, mais effectivement, ce n'est pas la priorité quand on a aucune garantie d'avoir un retour sur investissement. Et par ailleurs, fédérer la sécurité du libre/open source est un sujet qui pourrait très bien être conduit (j'ai pas dit résolu) par l'UE elle-même. Après tout, le libre est utilisé par… presque tout le monde, et des infrastructures vitales en font partie. Il y a donc la partie normative, mais accompagner les fournisseurs ne serait pas non plus du luxe. Une subvention européenne à la fiabilité de la chaîne d'approvisionnement quoi. Il reste à trouver un acronyme qui ressemble à une déesse grecque, et ça va bien se vendre.
Google a bien amélioré la situation du support long terme avec leur projet Generic kernel image, en offrant des api interne stable à grand coup de padding reserved dans les structure du kernel. Bien qu'il ai peu de chance que leur solution soit un jour mainline, leur travail est loin d'être bête et ils ont fait beaucoup pour améliorer la situation.
Et puis si le support Android te concerne vraiment, tu achète un pixel et tu retrouve la même "intégration vertical" que tu peux trouver chez Apple. Et avant y avait Motorola.
Et puis si le support Android te concerne vraiment, tu achète un pixel et tu retrouve la même "intégration vertical" que tu peux trouver chez Apple.
Sauf que les pixel c'est pas vraiment mieux (du moins les "anciens"). Mon exemple, Pixel 4a, sorti le 3 août 2020, fin du support officiel de Google fin août 2023. Donc mon téléphone ça fait ~6 mois qu'il n'est plus supporté (en vrai Google a fait une dernière mise à jour de sécurité en septembre je crois donc un peu moins), et moins de 3 ans depuis mon achat (puis j'imagine bien les gens qui vont acheter le téléphone début 2023 qui se retrouvent avec seulement quelques mois de support…)
Maintenant j'ai donc les choix suivants:
- je rachète un nouveau téléphone (merci l'environnement).
- je passe sur LineageOs qui est de ce que j'ai trouvé pas mal le seul moyen d'avoir un support qui a de la gueule sur la durée.
Je ne sais pas d'où il sort cette histoire de forum et de liens russes, mais comme pour l'hébergement de données de santé, il n'a pas cherché bien loin.
A moins que ce soit sa mauvaise foi qui soit certifiée trollo-27001 ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Posté par Yth (Mastodon) .
Évalué à 7 (+5/-0).
Dernière modification le 19 février 2024 à 20:35.
D'autant que bon, les ISO lineageOS se trouvent… sur le site de lineageOS.
Après, si t'as un téléphone incompatible et que tu trouves sur un obscur forum russe quelqu'un qui prétend avoir bidouillé une image pour ton téléphone, tu sais pas à quoi tu peux t'attendre non plus.
Mais bon, si t'as pas un iPhone, cherche pas à installer iOS hein ?
Si t'as pas un téléphone compatible lineageOS, ou Murena, mieux vaut peut-être pas trop chercher plus loin…
Je ne sais pas d'où il sort cette histoire de forum et de liens russes, mais comme pour l'hébergement de données de santé, il n'a pas cherché bien loin.
Je pense que ça date du début des rom alternatives, où il fallait souvent aller chercher l'outil pour débloquer le chargeur de démarrage ou autre sur XDA ou autres sites louches. C'était assez vraiment il y a une dizaine d'années, ça l'est beaucoup moins maintenant par contre.
Mais j'ai toujours eu du mal à comprendre pourquoi il n'était pas possible d'avoir « relativement » facilement un mode root sur son téléphone. Chais pas moi, une option au boot, ou alors un mode root qui ne peut se donner qu'à une liste blanche d'applications.
Je comprends le problème initial, et ça évite bien des catastrophes, mais ça ruine également pas mal la confiance dans le système : finalement l'utilisateur ne possède pas son téléphone.
Posté par Psychofox (Mastodon) .
Évalué à 5 (+2/-0).
Dernière modification le 22 février 2024 à 14:05.
Dès que t'as un modèle un peu confidentiel, il y a quand même une culture de l'image recovery twrp pas officielle téléchargée sur un site je ne sais où dans le monde android.
Alors c'est relativement facile de t'acheter un smartphone d'occasion supporté par /e/, graphene ou lineageos installée depuis une image recovery pas sortie d'un site louche mais beaucoup moins de savoir quel modèle sera supporté si tu pars sur du neuf, d'autant plus si tu n'as pas les moyens de t'acheter un haut de gamme.
Question naïve: l’argument de vente du FairPhone c’est que la durabilité ? Ou le côté “fair” c’était aussi “on exploite pas des ouvriers dans des usines-prisons” ?
Les deux.
Ils font un travail sur pas mal de points :
Réparabilité, plus que durabilité d'ailleurs, avec facilité de remplacer juste certains modules.
Recyclage, en essayant d'utiliser un maximum de matériaux recyclés (70% sur le fairphone 5 apparemment !).
Origine, pas de métaux rares en provenance de zones pourries, comme le Cobalt Congolais.
Et du commerce équitable quand ça existe, apparemment pour l'or ils ont le label.
Tu le payes quand même, c'est pas donné un FairPhone, et tu peux trouver techniquement équivalent pour bien moins cher.
Mais ça le vaut probablement sur la durée, avec la réparabilité, et le support LineageOS, qui dure vraiment longtemps, ou Murena maintenant.
Alors ces 2 concepts, s’il y a bien un domaine où tu ne veux pas les mettre en œuvre, c’est bien celui-ci. Vraimente.
Les principes fondamentaux du RGPD et de ePrivacy découlent directement de l’article 8 de la Convention Européenne des Droits de l’Homme et sont justement le retour à la morale dans le droit. Beaucoup de domaines qui se pensaient justement moraux se sont pris ce truc dans les dents derrière et que ben non, pas de bol, t’avais oublié tout un pan de la morale… Le libre est un de ces domaines-là.
Idem côté lettre et esprit de la loi. Pas du tout le bon plan d’aller jouer avec ça du côté du RGPD, la CJUE est encore plus aggressive que ça sur sa lecture de l’esprit de la loi et rend des décisions parfois même très très surprenante. Cf sa jurisprudence sur 2(2)c ou encore la dépublication des registres de transparence.
… je me demande si Aeris n’est pas la première personne à passer la barre des 100 commentaires sous le même contenu (103 à l’instant où j’écris ces lignes) !
On remarquera l’effort de Psychofox (33 messages) et Yth (27 messages) pour l’aider en ce sens.
En même temps il abuse des auto-réponses : 35 commentaires dans ce cas (ouais, c'était le plaisir de trouver un moyen de compter les auto-réponses, et merci ChatGPT). Ça n'en fait plus que 68 ce qui est tout de même remarquable…
# En résumé
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 5 (+6/-3).
Le libre c'est la médiocrité, et les seules solutions envisageables pour des besoins d'envergures et modernes, ce sont les Gafam.
Heureusement que certains politiciens du XXe avaient un peu plus de hauteur de vue. Sinon l'Europe aurait été intégrée dans un bloc à l'est ou à l'ouest depuis belle lurette et ce ne serait pas en Ukraine que se déroulerait une guerre. En effet, ça pique. Le système est admirablement expliqué (quoique d'une point de vue US, où ça pique au moins autant) sur ce blog de C. Doctorow. Par exemple dans cet article, au titre évocateur de permanent overlords.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: En résumé
Posté par moulator42 . Évalué à 1 (+0/-0).
Tiens, il a changé le titre : "Big Tech disrupted disruption".
Permanent Overlords ça pétait bien pourtant…
[^] # Re: En résumé
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 18 février 2024 à 18:07.
Permanent overlords c'est juste le titre dans l'URL. Ma terminologie est équivoque, mais comment l'appeler sinon ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: En résumé
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 5 (+3/-1). Dernière modification le 18 février 2024 à 16:39.
Quelqu'un peut me (lui) rappeler quel est le système d'exploitation de tous les super-calculateurs depuis des années au fait ? Rapport à la médiocrité.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: En résumé
Posté par Krunch (site web personnel) . Évalué à 6 (+4/-0).
Celui qui est développé à >50% par une poignée de grosses sociétés américaines ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: En résumé
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 5 (+3/-0).
Ce qui devrait suffire à convaincre quiconque que le modèle du libre n'est nullement cantonné au gratuit, au médiocre, etc. Mais malgré cela, on ne cesse d'entendre répéter ces mêmes antiennes en litanie. Sans doute depuis le camp des
marketeux ou des politiquesnon-comprenant.« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: En résumé
Posté par Benoît Sibaud (site web personnel) . Évalué à 10 (+16/-0).
Ce n'est pas vraiment un résumé fidèle. Il dit plutôt qu'être sous licence libre n'est pas une silver bullet/une garantie magique et que si tu n'arrives pas à suivre le rythme de ce qui est jugé nécessaire (par le législateur en termes de sécurité, par les utilisateurs en termes de fonctionnalités, etc.) alors tu te fais marginaliser d'abord, puis exclure ensuite.
Quelques personnes veulent du libre pour le libre, prioritairement à tout le reste ou très prioritairement en tout cas. Mais si une large majorité veut autre chose (l'ensemble du catalogue de fonctionnalités des GAFAM, des garanties annoncées de sécurité comme avec les dépôts d'application ou les clouds des hyperscalers, etc.), ben ça ne suffit pas ou plus ou surtout pas à tout le monde d'être libre.
Ca ressemble plus à l'hypothèse de la Reine rouge : pour rester dans la course, il faut continuer à avancer. Il ne faut pas être le meilleur partout, mais il ne faut pas se laisser distancer totalement non plus.
[^] # Re: En résumé
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 6 (+4/-0).
Absolument. C'est plus une expression d'humeur face à un texte qui m’horripile. J'espère que le ton était suffisamment virulent pour ne pas laisser imaginer une quelconque intention de neutralité ? Si certaines personnes veulent du libre pour du libre, d'autres veulent du proprio car personne n'a jamais été viré pour avoir choisi mirosoft. Deux positions politiques parfaitement antagonistes : Travaillons honnêtement à construire le monde opposé à laissons faire les puissants. Présenter l'une ou l'autre comme résultant de la seule logique la plus inéluctable me semble relever d'une forme de malhonnêteté par omission ; d'où ma réaction, histoire de rappeler que l'autre extrême existe.
Maintenant, il faut bien avouer que nos contemporains votent très largement pour la position que j'abhorre ; ce n'est pas une raison pour se taire.
L'hypothèse de la reine rouge n'implique-t-elle pas que tous les survivants en soient, très globalement, au même point ? nul ne progressant. C'est plutôt bon pour les petits joueurs et les acteurs non dominants. Non ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# Des idées intéressantes mais certains arguments confondants de naïveté
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 10 (+10/-0).
De mon point de vue, cet article mélange allègrement des réflexions intéressantes avec des arguments franchement naïfs. Je pense notamment à tout le paragraphe sur les bricolages et la garantie apportée par les éditeurs à support payant.
Sur ce deuxième point, je vous conseille de lire l’édifiant retour d’expérience de Manutan et de son rapport à Microsoft lors d’une cyberattaque, ou tout simplement le contrat de licence et service Oracle qui dit ceci :
La connaissance libre : https://zestedesavoir.com
[^] # Re: Des idées intéressantes mais certains arguments confondants de naïveté
Posté par Graveen . Évalué à 4 (+3/-1).
J'aime bien lire ses réflèxions, je partage donc ton avis (et je tenais à ce que ca se sache…) :D
# L'auteur oublie l'essentiel...
Posté par Psychofox (Mastodon) . Évalué à 10 (+13/-1).
…l'état n'est pas obligé de passer par un prestataire externe et pourrait s'autohéberger, avoir ses propres datacenter et IT.
C'est un choix d'aller chercher ailleurs.
[^] # Re: L'auteur oublie l'essentiel...
Posté par legranblon (site web personnel) . Évalué à 9 (+7/-0).
L'état devrait dans ce cas endosser les responsabilités, sans possibilité de recours au défaussement rituel sur prestataire … Il devrait de ce fait assumer une charge salariale associée, quand les fonctionnaires sont vu comme des bouffe-culotte que le dogme se doit d'éradiquer.
[^] # Re: L'auteur oublie l'essentiel...
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 10 (+8/-1).
Mais ça risque de coûter moins cher pour une meilleure qualité. À condition que les besoins et autres soient correctement définis préalablement.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: L'auteur oublie l'essentiel...
Posté par Yth (Mastodon) . Évalué à 6 (+5/-1). Dernière modification le 19 février 2024 à 09:30.
Ou même avec des prestataires existants, imposer une obligation de mise en conformité avec des délais clairs, et l'argent qui arrive dès le début du contrat, ça peut aussi suffire à avoir un acteur cocorico qui remplirait, pour le coup, l'intégralité du cahier des charges.
En quoi, un an ? Deux ans ?
Ce ne sont pas les compétences techniques qui manquent, c'est comme partout en France, c'est l'argent qui manque, on est trop occupé à le faire sortir de nos frontières cet argent, pour réussir à l'utiliser utilement.
[^] # Re: L'auteur oublie l'essentiel...
Posté par Aeris (site web personnel) . Évalué à 3 (+3/-1).
Très clairement le problème est aussi politique de ce côté. Les GAFAM sont aussi ce qu’ils sont parce que les US font de la commande publique et des subventions à mort.
L’intégralité du budget de Google est déjà rempli pour les 10 prochaines années juste avec les contrats étatiques de l’armée américaine… 9 milliards de dollars à se partager entre les 4 fournisseurs cloud américains rien que pour le budget 2020 du JWCC. Etc.
Forcément que tu peux innover…
[^] # Re: L'auteur oublie l'essentiel...
Posté par moulator42 . Évalué à 5 (+4/-0).
En gros, une forme de protectionnisme. La France aurait plutôt tendance à faire l'inverse (et à se tirer dans le pied)…
[^] # Re: L'auteur oublie l'essentiel...
Posté par Aeris (site web personnel) . Évalué à -2 (+1/-4).
Autant je ne suis pas pour le protectionnisme, ou en tout cas pas à outrance, mais j’y suis carrément opposé quand c’est uniquement pour sauver des éco-systèmes qui n’ont juste pas réussi du tout à se tenir à jour.
Je ne saurai dire si ça relève d’un cercle vicieux du protectionnisme (US) qui appelle le protectionnisme (EU) ou si c’est juste qu’on a totalement été à côté de nos pompes, certainement un truc entre les 2 comme toujours. Mais aujourd’hui vouloir continuer à maintenir en vie des trucs qu’on devrait plutôt euthanasier parce qu’ils arrivent très clairement au bout du rouleau, c’est quand même assez con…
On est totalement passé à côté de la réalité concrète du bordel sur plein de sujet et on le paie dorénavant très cher.
On a le même problème avec la plupart des business modèles du moment qui sont juste totalement illégaux, mais on préfère avoir des politiques qui tentent de sauver les meubles quitte à juste reculer pour encore plus mal sauter que de juste dire « déso pas déso, mais pour vous c’est la fin ».
Mais forcément, un politique qui va annoncer des millions de licenciement et la remise à plat de tout le système… c’est pas méga vendeur…
[^] # Re: L'auteur oublie l'essentiel...
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 5 (+2/-0).
Il oublie un autre facteur "la fonction crée l'organe". Il suffit de passer un contrait clair avec l'entreprise prestataire.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: L'auteur oublie l'essentiel...
Posté par bistouille . Évalué à 6 (+6/-1).
Le problème c'est que nos "Huiles Essentielles" pourtant issues pour la plupart du monde juridique sont incapables de faire un contrat qui ne soit au détriment de l'Etat. (cf les concessions d'autoroutes, délégations de services publiques, les recours aux cabinets d'expertises, les contrats de prestatations etc…)
Ou alors les élites savent mais ne veulent pas, mais je n'ose y penser.
[^] # Re: L'auteur oublie l'essentiel...
Posté par Aeris (site web personnel) . Évalué à 1 (+2/-2).
Il faut savoir être honnête aussi : un tel système construit par l’État risque de coûter bien trop cher pour être financé exclusivement par l’impôt. Les partenariats public-privés sont aussi là en mode « nous on peut pas vous financer intégralement, vous financez le complément et vous repartez avec les bénéfices ».
Le problème en France est effectivement surtout qu’on est très mauvais pour réellement avoir des contrats donnant-donnant et qu’on finit souvent complètement plumé par le privé.
[^] # Re: L'auteur oublie l'essentiel...
Posté par bistouille . Évalué à 10 (+9/-0).
C'est une question de volonté politique, c'est tout.
On est capable de dépenser des milliards dans bien des projets dont l'utilité au long terme est discutable et sans aucune garantie de retour sur investissement.
(cf les JO2024 cible facile mais pas seulement, tous les grands événements passés, y compris la Coupe du Monde de foot 98 considérée comme une réussite laissent des ardoises pharaoniques à la puissance publique)
S'agissant de données de santé des citoyens, on aurait pu en faire une priorité stratégique nationale.
Concernant les PPP, c'est, au mieux, un artifice comptable coûteux pour ne pas laisser apparaître une dette supplémentaire.
Il y a un audit européen sur les PPP. C'est assez saignant, même si ça date de 2018, un extrait:
"Ainsi, 1,5 milliard d’euros, dont 0,4 milliard d’euros de fonds de l’UE, ont été dépensés de manière inefficace…ces partenariats risquent fort de ne pas contribuer dans la mesure voulue à la réalisation de l’objectif qui consiste à mettre en oeuvre davantage de fonds de l’UE au moyen de projets bénéficiant de financements mixtes, entre autres des PPP."
D'autres audits de cours des comptes régionales semblent aller assez dans le même sens.
Dans le Canard Enchaîné les articles se sont accumulés sur le "Balardgone" (l'Etat Major des forces armées, en PPP), l'hôpital Sud Ile-de-France, divers chantiers de BTP y compris des routes construits en PPP, où au final la puissance publique aura dépensé 2,3,4 fois le prix qu'aurait coûté au complet un équipement équivalent même avec des taux d'intérêt élevés.
[^] # Re: L'auteur oublie l'essentiel...
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3 (+1/-0).
N'y a-t-il pas simplement désaccord sur la définition de ce qu'est une réussite entre les partis ? D'un côté, ceux qui pensent collectif et qui aimeraient voir se développer la société, et de l'autre les individualistes dont l'objectif est de se remplir les poches le plus efficacement possible ? De ce dernier point de vue, une grande commande public est toujours une aubaine ; quelle qu'en soit le l'appréciation des résultats par les premiers, sauf intervention des juges et passage par la case prison.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# Des sources intéressantes mais trop de mauvaise foi
Posté par MrBidon . Évalué à 5 (+5/-1). Dernière modification le 19 février 2024 à 09:51.
Dans ce billet, il y a des sources très intéressantes.
Par contre, le monsieur, c'est tout ce que je n'aime pas, par exemple :
Il semble ok de voir des GAFAMs (le bien) en concurrence libre et non faussée avec des PME Européenne, par contre, c'est ok pour de contrôler les caisses, parce que les indépendants (le mal) ne font que gruger la TVA.
Je sens aussi un élitisme nauséabond dans le paragraphe où il décrit que le méchant libre permet de rendre accessible la technique à tout le monde, et ce n'est pas sécurisé sous prétexte que "les gens" ne comprendraient pas les tenants et aboutissant.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par nud . Évalué à 5 (+3/-0).
Je ne pense pas qu'il porte particulièrement les GAFAM dans son coeur (vu son historique personnel et son rappel de Schrems II) mais je pense qu'il déplore le fait que les prestataires européens n'ont rien à proposer en face de ce que les géants américains proposent. Mais il a le ton souvent outrancier, ce qui amha déforce son propos.
On peut aussi se demander la pertinence de ce que les appels d'offres demandent, certains appels d'offre sont très maximalistes et demandent des trucs qui ne seront vraisemblablement jamais nécessaires ni utilisés (un peu comme pour les offres d'emplois, tiens).
Par contre si la loi demande une certification (la TVA n'est qu'un exemple), et bien il est logique que tous les acteurs soient certifiés, et le fait d'être indépendant en soi n'est pas une bonne raison pour le pas le faire. Par contre le coût de la certification est parfois (souvent?) prohibitif et peut rendre les choses compliquées pour les petits acteurs, par exemple si l'on doit certifier chaque version de chaque logiciel plutôt que la société en elle-même. Mais en Europe on aime bien les certifications et la législation à outrance. C'est souvent présenté comme une façon de contrôler les géants américains mais en pratique ça rend également très compliqué l'accès au marché par les petits acteurs. C'est aussi ce dont se plaignent les agriculteurs dans leur domaine, par ailleurs, et c'est surprenant quand en façade certaines personnaltiés mettent en avant le logiciel libre comme une solution à l'hégémonie logicielle américaine.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 2 (+3/-2).
Je valide que je ne porte vraiment pas les GAFAM dans mon cœur 🤣
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par MrBidon . Évalué à 2 (+1/-0).
On est d'accord, il y a un soucis. On légifère à outrance et en plus, on met les entreprises locales en concurrence "à égalité" avec les entreprises étrangère. C'est pourquoi il y a des appels d'offre spécifiques pour favoriser les entreprises locales, il n'y a pas d'autre moyen (à ma connaissance) pour que les institutions puissent favoriser ces entreprises locales, mais comme tout, il y a certainement des abus. Idéalement, il faudrait que cela soit possible légalement et que les institutions disposent d'outil pour cela, actuellement cela n'existe pas.
Je suis prenneur d'exemple
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -2 (+4/-7).
Je ne vois aucune raison de privilégier plus les entreprises locales des entreprises étrangères. On est actuellement dans un monde globalisé où on s’en cogne un peu complètement de ta nationalité. Pourquoi est-ce qu’on irait payer plus cher un produit plus merdique juste parce qu’il est FR alors que le concurrent DE ou US fait mieux pour moins cher ?
Si encore le produit FR n’est pas foncièrement trop éloigné des caractéristiques et des coûts de la concurrence, bon ok pourquoi pas faire un petit effort pour le privilégier et payer 10% de plus pour faire local avec peu ou prou les mêmes fonctionnalités. Mais quand les écarts sont juste abyssaux…
Sans parler que typiquement, s’il y a bien un truc que t’as pas spécialement envie de voir dans les mains de ton État, c’est bien tes données de santé…
Point Godwin, mais il n’y a pas si longtemps, la Stasi aurait été ravie d’avoir juste un select à faire dans une base de données pour choper tous les handicapés, les juifs ou les homosexuels de sa population et que c’est aussi ce genre de problème qui a conduit à la fondation de la CNIL en 1978…
Il y a du coup certainement un compromis à faire à ce niveau entre favoriser du national et se protéger d’un éventuel petit problème de changement de régime politique…
Le 100% FR n’est pas non plus une balle en argent. Surtout à l’approche de 2027…
Pour l’avoir vécu en direct avec la réquisition illicite de mes machines sur décision illicite d’un juge sur impulsion illicite politique après une décente de police illicite dans le datacenter d’un hébergeur français, les avoir héberger en Allemagne ou aux Pays-Bas m’aurait éviter beaucoup d’ennuis et de frais de justice…
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Dring . Évalué à 9 (+7/-0).
Le point Godwin c’est pour les références au nazisme non ? J’ai l’impression que tu t’es mélangé : la stasi c’était l’Allemagne de l’est, sous contrôle de l’URSS.
Ben quand les autres pays (coucou les US) passent leur temps à faire ça, et sont susceptibles de profiter de leur “accès” pour faire de l’espionnage sans vergogne (industriel, commercial ou politique) je crois pas que les raisons de leur rendre la pareille manquent vraiment. Qu’on le fasse mal c’est une chose et je te rejoins là dessus. Mais de là à tendre la deuxième joue, ça ressemble à du masochisme.
Si ça peut t’aider, remplace AWS par AliBaba.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 1 (+2/-2).
C’est un peu différent pour les US. Ou la Chine d’ailleurs. Ils ont fait en sorte d’avoir des entreprises nationales qui répondent à leurs besoins et ne les tiennent pas en vie sous perfusion aux soins palliatifs alors qu’elles sont totalement obsolètes. Au contraire ils injectent de l’argent pour les conserver dans la course au niveau décent attendu par l’état de l’art.
Pour faire le parallèle avec ce qu’on vit en France avec le parc nucléaire, c’est la différence entre maintenir dans la course ton fleuron industriel national en lui commandant chaque année des réacteurs en plus qui lui subventionnent les études de la prochaine génération et le maintenir sous perfusion d’argent public pour qu’il ne meurt pas parce que tu ne lui en as plus commandé depuis 20 ans et qu’il s’avère incapable d’en faire dorénavant…
Ça coûte le même pognon, sauf que dans un cas tu as de la Gen3 et tu attaques la R&D de la Gen4 et dans l’autre de la Gen2.5 où tu patauges à sortir de la Gen3…
C’est aussi tout le problème du truc, c’est que le jour où tu arrêtes la commande publique… le système s’effondre tout seul. A priori Google ou Amazon cessent d’exister tels qu’on les connaît si la commande publique disparaît.
Et oui, une fois que tu es compétitif par rapport à tout le reste, ben tu profites aussi de ta position dominante… Les Chinois et les Américains peuvent se tirer la bourre avec leur techno et envisager de striker le concurrent du marché, ils s’en foutent ils n’ont pas besoin du voisin et ça fait parti des négociations.
Quand t’es l’Europe et dépendant des 2 autres, c’est pas la même chose… Difficile de mettre dans la balance l’arrêt des imports ou des exports, t’as rien à leur proposer et ils savent que sans eux, tu crèves 🤣
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Dring . Évalué à 10 (+8/-0).
C’est pas vraiment fait pour me convaincre. Ce que je comprends de ton point de vue : “c’est trop tard, alors perdu pour perdu maintenant on se fout de tout”.
Il y a quand même moyen de faire mieux que ça. Moi ça me fait chier de me dire qu’on contribue maintenant fortement à aider ces entreprises à maintenir leur avance.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 10 (+8/-0).
Ben c'est un peu ça.
Et puis là on parle d'informatique, pas de nucléaire, le problème est très différent, et en vrai il n'y a pas lourd, ni en temps, ni en investissement, à rattraper pour être au niveau des clouds Ricains.
Que la France ait gérée, et continue de gérer, comme une ignare, la situation d'EDF, c'est un fait, et c'est déprimant, et ça coûte une blinde.
Mais en informatique, le privé a juste besoin de la confiance des états, et de commandes publiques.
En dehors de CapGemini bien sûr…
Et peut-être aussi de ne pas financer la propriété intellectuelle américaine avec le CIR, ça serait pas mal, comme ça, ça coûterait pas un centime au contribuable, on flèche l'argent public vers les projets publics, une idée con, comme ça…
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 1 (+2/-2).
C’est pas tant de dire que tout est foutu mais que la décision du HDH n’est pas forcément si débile que ça. Oui on peut encore réagir, mais à date, ça va être difficile. Et si tu ne veux pas accumuler du retard côté santé, faut AUSSI avancé sur le HDH.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Nibel . Évalué à 7 (+5/-0).
"Too big to fail" ça n'existe pas.
Les GAFAM finiront aussi par se casser la gueule un jour.
Et ce jour-là, il est préférable d'avoir d'autres acteurs pour assurer la continuité de service au mieux.
Mieux encore, d'avoir des acteurs déjà implantés, qui connaissent le marché et maîtrisent leurs technos.
Bref, l'argument "too big to fail", très peu pour moi. Ça me conforte au contraire dans l'idée que j'ai bien raison de multiplier les acteurs pour mes différents services et de ne pas tout concentrer au même endroit (et encore moins chez les GAFAM).
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Glandos . Évalué à 4 (+2/-0).
Too big to fail, ça veut pas dire que le système économique de l'organisation est fiable. Ça veut dire que cette organisation constitue le socle du tissu économique à une certaine échelle, et que si cette organisation vient à être démantelée (liquidation, antitrust, etc.), alors il y a une révolution systémique à faire. Et ça, c'est quelque chose dont personne ne veut, en général.
Donc tout le monde va essayer de sauver cette organisation, en injectant des fonds publics ou en changeant la loi. Wikipédia est assez succint (https://fr.wikipedia.org/wiki/Too_big_to_fail) mais pour le coup, c'est à peu près ça.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 10 (+8/-0).
Et donc c'est mieux de les filer à un état tiers dont les intérêts ne coïncident pas avec les nôtres, et qui pourrait utiliser ça contre nous, citoyens, l'état français, etc ?
Avec un Trump au pouvoir, qui sait ce qu'ils vont encore inventer.
Déjà que leur juridiction a vocation supra-nationale, donc qu'ils se sentent le droit de faire chier des entreprises étrangères qui font du business à l'étranger, parce que ce business ne respecte pas leurs règles nationales, on a quand même affaire à un machin un brin envahissant…
Je veux dire, quitte à choisir entre la peste et le scorbut, prends le scorbut et achète des fruits, au final tu t'en sortiras mieux, et pour moins cher !
Je pige toujours pas l'argument moi.
D'un côté on préférerais entretenir des monstres états-uniens qui n'ont pas besoin de ça pour nous plumer, de l'autre on pourrait faire des appels à projet et des subventions, qui pour une fois pourraient ne pas être perdus, et reviendraient moins cher. Parce que bon, ça coûte une blinde de se faire plumer.
C'est pas la technique le problème, ils sont pas plus intelligents dans la Silicon Valley, ils sont pas plus compétents non plus, et derrière on utilise tous les mêmes logiciels, qui sont très majoritairement des logiciels libres, et tout ça tourne sur du Linux, et ya plein de gens qui savent administrer du Linux en France, et encore plus en Europe…
Et s'il faut se protéger de son propre état, peut-être que comme tu dis, on peut faire héberger ça juste à côté, en Allemagne, en Roumanie, en Islande.
Ça serait nettement mieux politiquement : les données personnelles Européennes sont gérées en Europe, ya pas de protectionnisme commercial ici, ça ressemble plutôt à du bon sens.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -4 (+1/-6).
Question simple : as-tu déjà vu réellement un débordement de FISA ou du Cloud Act ? La réponse est assez simple a priori : ça n’existe juste pas. Manhack avait débunké ça dans son article cité dans le mien, et les gens se font tout un patakès d’un truc qui en vrai sont juste des accès juridiques rapides comme il en existe des tonnes un peu partout dans le monde et en Europe. Ce n’est pas une porte ouverte à toutes les fenêtres.
Cet argument est juste un argument pour aller taper gratuitement sur les US sans avoir à se justifier plus que ça (et je reconnais moi-même l’utiliser en ce sens), mais sans action AUSSI côté EU, Schrems II est un non argument.
Qu’est-ce qu’un gouvernement étranger peut faire de mes données de santé ? Globalement rien.J’ai bien plus peur d’une action de mon gouvernement qui peut me foutre en zonzon quand il a envie sans avoir à se justifier que d’un gouvernement étranger qui voudrait en faire de même.
Tu supposes qu’on a des fruits. On n’en a pas.
Ça aurait été vrai si on avait agit au départ. On a dorénavant une 15aine d’années sinon plus de retard sur les systèmes US et rattraper le retard coûtera HORRIBLEMENT plus cher que de continuer à engraisser l’Oncle Sam.
Oui, on peut encore agir, mais ça va faire VRAIMENT SA MÈRE mal.
On parle de rattraper au moins 15 à 20 ans de subventions à 2 milliards d’euro sur un seul projet pour quatre hébergeurs. Soit au bas mot une enveloppe de quelques centaines sinon milliers de milliards à foutre sur la table en quelques années. Et en provisionnant déjà les subventions à venir et à maintenir chaque année.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par GG (site web personnel) . Évalué à 6 (+4/-0).
Rien qu'en regardant les caractéristiques visibles de l'extérieur pour la gestion des emails de LaPoste ou de Wanadoo/Orange, et tu te demandes comment ce genre d'entreprises peut arriver à un résultat aussi médiocre.
Même Free.fr s'en sort mieux.
Du coup, les gens qui n'hébergent pas leurs emails chez des "pro" comme OVH ou Hetzner comparent ce qu'ils ont avec LaPoste ou Orange, et décident d'aller tout mettre chez Gmail parce que "ça marche", et on ne peut pas dire qu'ils ont tord, même s'ils ne se rendent pas compte qu'une partie des emails qui arrivent chez Gmail sont filtrés silencieusement et arbitrairement.
C'est dommage parce que ce qu'on a chez les Chatons, OVH ou Hetzner (par exemple) fonctionne bien mieux.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 9 (+7/-0).
Surtout qu’on a de vraies bonnes formations et d’excellents ingénieurs en informatique et électronique en France. Si je prends le premier exemple qui me vient à l’esprit, Quarkus est fortement porté par RedHat France. On a même été précurseurs dans certains domaines (rappelez-vous la carte à puce, le Minitel…)
Par contre, on accumule des décennies de décisions politiques et économiques contre nos industries (et ça n’est pas un appel à lorgner du côté du modèle social américain !), y compris l’informatique. D’ailleurs, l’informatique est peu vue comme une industrie en France, et rien que ça c’est un problème, notamment quand il s’agit d’investir dans des outils. L’Europe (via l’UE ou autres) aurait aussi pu permettre l’émergence d’énormes forces industrielles capables de concurrencer les USA, la Chine, etc., mais non, on a préféré faire chacun dans son coin son petit truc et préférer faire la Sainte Concurrence et le Libre Marché avec les résultats que l’on a aujourd’hui.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 7 (+5/-0). Dernière modification le 19 février 2024 à 20:21.
J'ai failli répondre aussi sur les Chatons et Framasoft.
La preuve qu'une poignée de bénévoles, et quelques salariés associatifs peuvent fournir des services pertinents et efficaces.
Imagine la même avec des entreprises et des subventions, ou des marchés publics, et la confiance de nos entreprises locales aussi.
On parle d'informatique, l'état de l'art il est dans le logiciel libre, et n'importe qui y a accès.
Il y a /e/, Murena, aussi, en cocorico, qui donne certainement une meilleure sécurité qu'un quelconque iPhone.
Franchement un truc comme Commown/FairPhone/Murena, tu as un meilleur service et un meilleur support à long terme que ce que tu peux trouver chez Apple.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -4 (+0/-5).
Mais illégaux. Comme déjà signalé par NOYB et j’en fais aussi le constat, la plupart des systèmes y compris libres violent la majorité du temps la plupart des obligations légales de sécurité.
Typiquement Mastodon viole frontalement le RGPD par pilées de 12, ça leur a déjà été remonté, et ils en ont rien à foutre.
Je suppose qu’on lâcherait une APD fonctionnelle sur les Chatons, soit les opérateurs soit les utilisateurs se prendraient des prunes dans les mêmes volumes.
Aller, pour rigoler, combien de Chatons ont un SIEM, un IAM ou juste simplement des interfaces d’administration dédiées au niveau matériel et non exposées au net ?
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 9 (+7/-0).
On est en train de te dire que des assoces, et des particuliers, rendent des services qui fonctionnent, là où des boulets comme Orange et Laposte n'y arrivent pas.
Et que donc le problème n'est pas technique.
Une entreprise peut parfaitement se positionner sur ce créneau et faire un service qui marche, tout ce qu'ils ont à faire c'est de pousser, professionnellement, au niveau du respect des réglementations.
Mais la partie technique du service se fait à la maison sur un Raspberry Pi (j'exagère à peine pour le mail), avec 2FA, chiffrement des données, SPF, DKIM, annuaire, et tout le tintouin.
Par contre, prends tes mails chez OVH et ça va juste marcher.
Offre-leur un extincteur pour noël aussi, ils en manquent…
Donc quand derrière tu parles de 15 ans de retard et de milliards de dollars, je suis toujours autant largué par ta vision des choses, que je peine à trouver cohérente.
Concernant Mastodon et le RGPD, voilà quelques règles du RGPD :
Que je sache, il n'existe pas le moindre réseau social qui remplisse ces conditions, à part la première, et la seconde pour quelques cas particuliers, dont aucun des grands réseaux américains (tu peux récupérer tes données, au moins en partie, mais ça n'a rien de portable).
Je veux bien qu'on crache sur Mastodon, mais va pas me dire que TwitBook fait mieux ici…
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -5 (+0/-6).
Les CGU de la plupart des instances sont illicites.
Donc transparence c’est cool, mais si c’est parce que t’as oublié les ¾ des mentions obligatoires…
Qui n’est pas complète et donc illicite.
Actuellement on perd le contenu.
Même Twitter est meilleur. Mon ancien compte est dispo ici : https://twitter.imirhil.fr/.
Mon ancienne instance Mastodon par contre…
Existe chez la plupart des GAFAM.
Et tu as oublié l’article 15, respecté par les GAFAM et pas par Mastodon, l’article 13 dont Mastodon refuse la mise en œuvre (et pas les GAFAM), etc.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 10 (+9/-0).
T'as vu ça où toi ?
C'est le même bouton « j'ai plus de 18 ans, promis, sisi » que sur les sites classés X c'est ça ?
Constatation qui s'applique à tous les MAGAF que je sache, les conditions illicites dans les CGU c'est un grand classique de… absolument partout.
Je ne vais pas faire de différence ici, il faudrait être légiste et étudier en détail, mais quand les CGU sont longues comme un romans, on peut douter de leur légalité globale étant donné qu'il apparaît comme évident que personne ne les a lues, et certainement pas comprises, en détail, et donc que l'acceptation est de facto obtenue sans réel consentement.
Ce qui est /moins/ vrai sur Mastodon…
Bah tu peux les exporter tes données, et les importer sur une autre instance Mastodon, il y a même des systèmes pour basculer ton identité sur une autre instance.
Ça ressemble nettement plus à de la portabilité que ton bidule statique bricolé à partir des données exportées depuis Twitter.
Comme tu ne peux importer ça nulle part, y compris sur Twitter, c'est difficile d'appeler ça de la « portabilité ».
Tu peux récupérer tes données, ok, mais c'est vraiment pareil sur Mastodon hein, avec la portabilité en plus…
J'ai pris les 4 règles mises en avant sur le site du RGPD, pour les réseaux sociaux, ici :
https://donnees-rgpd.fr/traitement-donnees/reseaux-sociaux/
Je n'ai jamais prétendu être exhaustif, simplement que rien qu'avec ces 4 règles là, personne sur le marché ne remplis vraiment les conditions.
Si personne ne remplis les conditions, j'ai du mal à saisir l'objectif de mettre spécifiquement les défauts de Mastodon en avant, qui plus est avec de la mauvaise foi.
Franchement, soit tu trolles, soit tu as un biais énorme vis-à-vis des MAGAF et de leur capacité à respecter les règles, lois, etc.
Ils se mangent quand même régulièrement des amendes délirantes pour non-respect du RGPD, entre autre, mais ça ne te dérange pas de colporter la légende de leur perfection, et du fait qu'ils seraient les seuls à pouvoir remplir le cahier des charges, et qu'ils auraient même 15 ans d'une avance irrattrapable ?!
J'en rigole encore…
Un brin jaune cependant.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 0 (+3/-4).
Je n’ai pas dis qu’ils rempliraient à la perfection les cases de sécurité.
Je dis que de tous les systèmes que j’ai pu auditer, de près ou de loin, en interne comme en externe, ceux qui ont actuellement sur les tables d’autopsie des autorités de protection des données les dossiers les plus petits de ma part sont les GAFAM.
Et que la plupart des problèmes auxquels ils font face sont généré in fine par leurs propres clients et non par leur business direct.
À l’inverse les dossiers les plus importants que j’ai eu à faire sont ceux concernant des entreprises FR ou du logiciel libre. Je galère plus avec des admins ou développeurs d’instances Mastodon pour leur faire comprendre le RGPD qu’à des gus de chez Google ou de l’IAB, ils sont moins de mauvaise foi.
Qui a été capable de répondre correctement et dans les temps à une demande d’accès RGPD ? Les GAFAM.
Qui a été capables de propager des demandes d’opposition correctement et efficacement ? Les GAFAM.
Qui est capable de détecter le mésusage des interfaces d’administration grâce à du SIEM et procèdent au licenciement de plusieurs milliers d’employés indélicats chaque année ? Les GAFAM.
Qui ont des mécanismes capables de gérer les droits d’effacement et d’opposition jusque dans les systèmes de sauvegarde avec la mise en place de clefs de chiffrement individualisées dont il suffit de détruire la clef pour détruire les backups ? Les GAFAM.
Oui leurs pubs est pas cool mais qui a été capables de me filer tous les affichages de mon profil et l’ensemble des annonceurs concernées ? Les GAFAM. En face en France les boîtes se font sanctionner par la CNIL pour avoir refuser de communiquer les annonceurs…
C’est pas parfait, la preuve, ils se prennent des amendes. Mais quand tu vois toutes les amendes qui tombent, surtout dans les pays avec des APD fonctionnelles, ça pique fort sur les non GAFAM. Plus fort.
L’Espagne qui a une des APD les plus efficaces, Google c’est 1 sanction, Facebook 0. À l’inverse Vodafone c’est 75 condamnations, les banques 11, les assos on en est déjà à 25 sanctions, et même les particuliers on en est à 154. Si on les lâchait en France, ça serait des amendes pour tout le monde ou presque.
Et rappelons aussi un truc que les gens oublient vachement beaucoup : les GAFAM ne se rémunèrent pas par la pub. Pas dans le sens que les gens le pense. Les GAFAM se rémunèrent sur le pourcentage qu’ils touchent de leurs clients qui vendent d’un côté des placements produits et de l’autre des emplacements publicitaires.
Demande au marketing de chez toi ce que ça fait si Facebook ne leur envoie plus leur KPI de placement produit que eux ont demandé de cibler, tu vas voir, ils vont pleurer.
Le vrai problème des GAFAM est surtout leur taille, qui induit effectivement des effets de masses à la con.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 8 (+6/-0).
Crois-moi, le marketing de ma boîte, il en a rien à faire des MAGAF…
Il se fait plutôt à Matignon ou à Bruxelles, et il rapporte plein de brouzoufs.
J'en suis pas spécialement fier, au contraire.
Bon, sinon, Framasoft, zéro amendes pour violation de RGPD, et pourtant leur forge logicielle a même été utilisé pour notre gouvernement pour les codes de Parcours Sup.
Comme quoi, c'est peut-être pas intrinsèque à la techno utilisée hein ? Ni même au pognon disponible ?
J'en ai pas vu passer non plus pour Scaleway, pour revenir au sujet initial de fournir un HDH compliant.
Ou pour OVH non plus, mais bon, je ne vois pas tout non plus.
Il y a des centaines d'instances Mastodon, tu sais trouver des exemples d'instances qui se foutent du RGPD, et tu en conclus que c'est la techno et le modèle qui sont pétés ?
Que hors-MAGAF point de salut là encore ?
Bah c'est sûr que même si ça représente peu de choses, une amende de 50 millions (par la CNIL en 2019) ça pousse à embaucher quelques gusses pour répondre aux demandes RGPD, ça revient vite moins cher.
Mais pour s'être bouffé l'amende la première fois, c'est peut-être qu'ils étaient pas si raccord, et si preste que ça à répondre sans se foutre de la gueule de la CNIL.
Après, j'interprète peut-être mal hein, et surtout je ne sais pas ce qu'il peut se passer avec les petites instances Mastodon.
Par contre je suis sûr que ça ne signifie pas qu'un service basé sur Mastodon ne peut pas exister et être parfaitement réglo.
Ou qu'un HDH européen ne peut pas exister sans « 15 ans de retard et 1000 miliards d'investissements ».
Évidemment, si on mise sur Orange - ou Vodafone - il en faudra le double et au bout du compte ça ne fonctionnera pas.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -2 (+2/-5). Dernière modification le 20 février 2024 à 00:20.
Ne pas avoir d’amende ne veut pas dire que tu es conforme avec la loi
Sais-tu que la CNIL (qui est une APD déficiente d’ailleurs, au même titre que la DPC) recommande actuellement un logiciel (libre) pour l’éducation nationale qui représente actuellement un contrôle là-bas pour la violation de la totalité du RGPD de l’article 5 à l’article 50 et un joli dossier de plus d’une centaine de pages de violation RGPD diverses et variés ? Et même a priori qu’elle ne veut pas le sanctionner et abuse de délais de réponse effroyables et de pirouettes juridiques pour éviter d’avoir à le faire ? Certainement pour cause d’ordre politique d’ailleurs… T’aurais été chez Pronote t’aurais eu moins de problème…
Toute sauf les self-hosted mono utilisateur (exemption de RGPD article 2(2)c, et encore c’est compliqué). Actuellement des fonctionnalités sont en dur dans le code en violation du RGPD (les notes libres sur un compte utilisateur violent l’article 13 du RGPD et les lignes directrices de la CNIL sur les champs libres). Le manque de certaines fonctions aussi (auditabilité des accès et action administrateur qui violent les principes d’accountability et sont une obligation légale). À ma connaissance aucune instance n’a un DPA digne de ce nom et encore moins légal avec leur sous-traitants, tout ceux dispos en ligne étant illicites puisqu’il manque des clauses obligatoires (et que la CNIL en a déjà condamné 2 ou 3 des comme ça). La quasi totalité des instances n’ont aucune privacy policy ou juste pas licites. Aucune instance ne sait répondre à une demande d’accès article 15, les registres de traitement sont inexistants, le droit à la portabilité est incomplet…
Les instances principales ont basculés sur Cloudflare, en violation de Schrems II. D’autres ont activé reCaptcha, aussi en violation de Schrems II et des sanctions CNIL sur le sujet.
Eugen et sa clique refusent voire réfutent l’applicabilité du DSA (https://www.contexte.com/actualite/tech/plateformes-le-mastodon-dans-la-piece-2_160879.html)
Les propos même de Eugen font extrêmement peur. Le mec est littéralement le développeur principal d’un réseau social mais vient annoncer la bouche en cœur qu’il ne traite aucune DCP… https://github.com/mastodon/mastodon/issues/7280#issuecomment-385376837
Ça devrait juste allumer des warnings de partout que ce mec ne sait juste absolument pas de quoi il parle…
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 5 (+3/-0).
Je pige pas, tu me pointes une discussion sur github qui date de avril à juin 2018 (bientôt 6 ans tout de même, ça ne dit pas grand chose sur la situation aujourd'hui), avec des débats, des échanges, des discussions, on y trouve des informations sur ce qui va, et potentiellement ne va pas.
Une forme de conclusion semble être que ça respecte si derrière le serveur fait pas n'importe quoi, et que de toute façon ce n'est pas le logiciel qui doit respecter le RGPD mais l'instance, ce qui semble logique…
Je ne vois pas
Eugen et sa clique refusent voire réfutent l’applicabilité du DSAdans cet échange.Il va falloir être beaucoup plus précis là…
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 3 (+4/-2).
C’est toi qui est de mauvaise foi ici.
Je te cite une position WTF de Eugen, qui n’a pas changé depuis. Je t’ai cité tout un article de Contexte qui étudie le problème. Je t’ai cité un avocat du numérique parmi le plus réputé en France sur ce sujet qui te dit qu’il y en a un.
Je peux continuer encore hein.
Mastodon ne réfléchit pas et utilise du local storage en violation de ePrivacy : https://github.com/mastodon/mastodon/issues/28477
Mastodon ne réfléchit pas et inclut hCaptcha malgré la décision de la CNIL et d’autres APD sur le sujet : https://github.com/mastodon/mastodon/issues/25025
Mastodon refuse toujours de virer hCaptcha au motif de « on n’a pas le temps, on doit shiper » : https://github.com/mastodon/mastodon/issues/25023
Mastodon implémente n’importe comment le droit à la portabilité et bloque le droit à l’effacement : https://github.com/mastodon/mastodon/issues/22042
Mastodon n’est pas complet sur l’article 22 et l’article 15 : https://github.com/mastodon/mastodon/issues/14719
Mastodon viole les 22 arrêts de la CJUE sur la durée de rétention des durées de connexion : https://github.com/mastodon/mastodon/pull/22393
Mastodon viole le RGPD via l’intégration des embeded youtube : https://github.com/mastodon/mastodon/issues/29164
Mastodon viole le RGPD avec des outils pouvant être abusifs et sans protection, comme pourtant imposés par le RGPD : https://github.com/mastodon/mastodon/issues/14718
Mastodon implémente les notes sur un profil en violation du RGPD et malgré les alertes : https://github.com/mastodon/mastodon/issues/11797
Mastodon implémente le blocage des comptes d’une manière incompatible avec le RGPD : https://github.com/mastodon/mastodon/issues/8760
Je peux continuer comme ça longtemps, il y en a littéralement des tonnes…
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 1 (+3/-3). Dernière modification le 20 février 2024 à 10:07.
Et quand à dire « oui mais c’est l’instance qui doit respecter », déjà c’est faux, Mastodon agit en co-responsabilité de traitement (ils définissent et les moyens et des finalités sans demander l’avis préalables de toutes les instances, et en particulier ne permettent pas à une instance de ne pas activer les nouvelles fonctionnalités sans perdre les mises à jour de sécurité) et donc pas en sous-traitant et conserve donc la responsabilité mais en plus même si c’était vrai, ça sert à quoi de développer un soft européen si PERSONNE n’a légalement le droit de s’en servir sans devoir tout recoder ?
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 8 (+5/-0).
Étant donné que la plupart (je n'ai pas tout lu) des tickets sont ouverts et pas fermés "won't fix", je trouve que c'est malhonnête de ta part de dire que les auteurs s'en foutent.
Il y a clairement un manque de prise en compte de la RGPD et une réactivité très molle, se défaussant sur le fait que si c'est pas utilisé par une entreprise la RGPD ne s'y applique pas.
Mastodon n'est pas un réseau social, c'est un serveur activity pub qui peut s'interconnecter avec d'autre. Il serait certe mieux de promouvoir un outil qui permet à chaque admin de respecter la RGPD facilement, mais ça reste une responsabilité individuelle de chaque admin.
Maintenant l'Union Européenne a sa propre instance Mastodon (mais pas avec ouverture de compte ouverte), donc je pense que comme dans chaque changement de législation il y a un délai de mise en conformité accordé à tous les acteurs. J'imagine qu'on peut accepter qu'un logiciel libre développé par une petite équipe financée par des dons avec un budget annuel de 10000€ n'ait pas la même vitesse de mise en comformité.
C'est plutôt des services comme masto.host qui vendent de l'hébergement Mastodon qu'il faut se plaindre je dirais.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+1/-3).
Le RGPD, c’est approbation du texte par le Parlement UE en décembre 2015, entrée en vigueur en mai 2016, avec mise en application des sanctions en 2018, le tout alors qu’il existait du coup déjà la directive 95 depuis 1995 qui était plus ou moins équivalente…
Quand t’as un projet qui démarre, qui veut faire la nique aux GAFAM, la 1ère chose à peut-être faire… c’est de ne juste pas inclure DU TOUT de violation dès le départ ?
On ne parle ici pas de se mettre en conformité avec un soft existant de 20 ans d’âge et une législation qui a évolué depuis que tu l’as lancé. Mais d’un nouveau produit qui se lance sur le marché dont le 1er commit date du 20 février 2016 donc APRÈS l’approbation du texte et 4 mois avant l’entrée en vigueur, et avec encore 2 ans pour virer tes non conformités avant les sanctions…
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 9 (+6/-0).
Ah mais je ne dis pas qu'ils n'ont pas été nuls sur ce point hein.
Maintenant à la date du 1er commit en 2016, le sieur Rochko était un étudiant de 23 ans, pas un chef d'entreprise avec un département légal à même de lui expliquer les tenants et aboutissants de la RGPD.
Parce que bon à l'époque, j'en ai vu des services informatiques complètement perdus par les questions de conformités à la RGPD (et des services étatiques) et je connais encore dans ma boite actuelle des services qui se mettent seulement en conformité (mais qui sont peu visibles et peu sujet à plaintes puisqu'ils n'ont comme clients que des entreprises signant contrat avec eux) et je ne doute pas qu'il y a plein de trucs pas vu / pas pensés dans des milliers d'entreprises.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -5 (+0/-6).
Non seulement nul n’est sensé ignorer la loi, mais j’ai aussi beaucoup de mal avec les gens qui commencent en mode « yolo j’ai 23 piges balek me renseigner sur mes obligations légales, moi je vais faire le bien donc je peux pas faire de la merde ». Google/Facebook a pas commencé mieux à l’origine 🤣.
Ça n’est en aucune manière ne serait-ce qu’un début d’excuse pour Eugen. Surtout quand tu développes ça justement pour casser du GAFAM et après tout le merdier qu’on connaît sur les données persos.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 7 (+4/-0).
Ça veut juste dire que tu ne peux pas invoquer l'ignorance dans le cadre d'un procès. Dans les fait la majorité des gens ignorent la majorité des lois.
Du reste je n'explique pas, je comprends. Plein d'autres auraient fait pareil. Et ce qui compte c'est ce qu'on en fait maintenant.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 6 (+4/-0).
Je ne la trouve pas WTF, il faut m'expliquer, en lisant la discussion github que tu pointes, je vois pas mal de « ya des trucs déjà gérés », du « je ne suis pas légiste, donc je ne prends pas la responsabilité de te donner une opinion légale », et aussi du « attendons de voir comment ça va se dérouler ».
Sachant que la discussion date de 2018 au moment de la mise en place du RGPD, on peut admettre l'attitude d'attente au moment de transition.
Ça aurait été écrit en 2023, j'aurais pensé que bon, on en a du recul, ya foutage de gueule.
Là je vois pas, donc je te demande des détails, parce que aussi :
Et non, ton lien est illisible, paywall.
Et là tu fais pareil, tu innondes de lien, tu n'expliques rien.
Donne des arguments, développe ta pensée, balance pas des liens en vrac et démerdez-vous !
T'as une position, tu veux la défendre, alors donne-la plus précisément qu'avec des phrases à l'emporte-pièce du genre « Mastodon viole frontalement le RGPD par pilées de 12 ».
Concernant tes liens :
Là-dedans, des problèmes réels, ne dépendant pas de l'administrateur de l'instance, non traités et qui n'ont pas été rapportés la semaine dernière, j'en vois pas tant que ça.
C'est un concours de mauvaise foi ?
Fais gaffe, t'as pas mal d'avance…
Par ailleurs, je ne vois toujours pas en quoi ça condamnerait l'outil définitivement, et sans appel.
Ni en quoi la seule solution viable serait de tout laisser tomber et aller voir les gros silos pas beaux aux states…
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par GG (site web personnel) . Évalué à 10 (+10/-0).
C'est clair, Aeris, que si tu faisias aussi le travail de fourmi aussi bien pour la multitude de serveurs Mastodon que pour les sites Wordpress, Spip, Joomla etc. il y aurait des millions de dossiers à la CNIL.
Personnellement, j'aurai un peu plus de tolérance quand il n'y a pas d'usage commercial, publicitaire, ou de revente/partage de données.
Ça me gave que sur beaucoup de sites administratifs (Énergies, emploi, CAF etc.) il y ait quasi systématiquement des données chez les GAFAM (cloudflare, et autres CDN) et la collecte de statistiques ou le profiling avec tagcommander. Lesquels n'en n'ont pas?
Alors oui, peut être que ça respecte le RGPD ou Schrem1,2,3… mais ça signifie aussi que le RGPD n'est pas encore adapté pour protéger les utilisateurs.
L'histoire de la note privée sur une fiche d'un contact concerne:
- Wechat
- Whatapps (c'est indirect, mais je le fais via une note sur la fiche contact du shitphone)
- Mastodon
et probablement aussi d'autres logiciels comme Signal, mais je ne l'ai pas réactivé donc je ne peux pas vérifier.
L'intérêt de Mastodon, c'est que c'est noté dans le code, en dur, et que comme c'est un Logiciel Libre, si tes modifications ne sont pas acceptées, alors tu peux forker et créer ton propre client. Tu peux aussi te baser sur l'un des nombreux clients Mastodon pour ça.
Contrairement à Twitter/X, Wechat, Whatapps, … tu peux avoir des clients différents, avec des implémentations différentes, et, un peu mieux contrôler ce qui est fait derrière ton dos.
L'obligation de s'identifier à travers un numéro de téléphone mobile devrait être interdite, parce que c'est une donnée personnelle, et que ça empêche le pseudo-anonymat sans empêcher les abus/harcèlements.
Pourquoi tu passes autant d'énergie contre Mastodon alors que c'est enfin un service décentralisé qui laisse beaucoup de choix, et qui est celui qui est le plus respectueux des utilisateurs. Tu as même le choix au niveau des instances. Peut être qu'il n'y en a aucune à ton goût ou qui serait assez respectueuses des utilisateurs et du RGPD.
Tu pourrais monter la tienne ou donner un coup de main à une instance existante?
Si encore le Fédiverse avait 0.01% des ressources de l'un des Gafam, tu ne penses pas qu'on arriverait à quelque chose de super? mais voilà, aucun investisseur ne veut investir dans un projet qui ne rapportera rien puisque sans publicité, sans tracking, sans collecte de données etc…
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -4 (+1/-6).
Non. C’est juste que c’est celle qui te convient TOI le mieux à ta définition de ce qu’est le respect des utilisateurs mais ce n’est PAS un système qui respecte ses utilisateurs. Certainement pas.
J’ai la mienne depuis… bien avant que Mastodon existe ? Il se trouve que Mastodon a démoli l’intégralité du réseau où j’étais bien avant que le Mammouth dégomme tout sur son passage et atomise l’existant avec du Embrace Extend Extinguish.
Quand aux coups de main, j’ai tenté à plusieurs reprises de faire de l’accompagnement juridique et cie pour mettre ça dans le bon chemin du RGPD et du DSA. Je me suis fait rembarrer à chaque fois. Et bien vénère. Parce qu’ils en ont en pratique réellement strictement rien à foutre.
Du coup s’il faut foutre des plaintes aussi sur ces plateformes et témoigner contre elles, je le ferais. Ce n’est pas de la revanche personnelle ou autre, juste le strict respect des mêmes lois qu’on demande aux GAFAM de respecter.
C’est pas parce que t’es une asso ou que tu fais du libre que tu bénéficieras plus de bienveillance là-dessus.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 9 (+7/-1). Dernière modification le 20 février 2024 à 15:12.
Aaah en fait c'était personnel! Fallait le dire avant.
Je ne connais aucun réseau qui a été démoli par Mastodon soit-dit en passant.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+1/-3).
Juste GNU/Social ? 🤔
Mastodon s’est pointé en 2017 en ne supportant que OStatus, en ne respectant rien de ce qui existait, a implémenté des features non compatibles aux forceps (message « privé » Mastodon qui du coup était public côté GNU/Social…), puis a forcé ActivityPub, avant de virer le support de OStatus et de massacrer GNU/Social qui ne s’en est jamais remis.
Google n’aurait pas fait mieux…
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 6 (+3/-0).
GNU Social en est au même point qu'il ne l'était à l'époque. Mastodon ne l'a pas démoli, et n'en a jamais eu le pouvoir.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 1 (+2/-2).
GNU/Social n’en est pas au même point. L’arrivée de Mastodon a complètement stérilisé le développement de ce projet… La communauté a suivi côté Mastodon parce que c’était le plus gros réseau. Ça a explosé le projet et tu n’en trouveras presque plus une miette.
On parle aujourd’hui d’un relicat d’une 20aine d’instances et de moins de 1000 personnes.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 10 (+7/-0).
GNU Social était il me semble le plus vieux projet de réseau social centralisé libre. Pump.io donc Activity Pub, a été créé bien avant Mastodon et des réseaux comme identi.ca ont fait le switch avant l'arrivée de Mastodon.
GNU Social n'était déjà pas très dynamique. Mastodon ne l'a pas tué. Il était tout simplement déjà mort mais ne le savait pas encore.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par GG (site web personnel) . Évalué à 4 (+2/-0).
Dans ce que tu écris, j'ai l'impression qu'il n'y a pas de messages directs (privé, mais les admins peuvent y accéder) dans Gnu.social comme dans ActivityPub.
J'ai regardé https://fr.wikipedia.org/wiki/GNU_social et ça ne m'a pas plus éclairé.
Mastodon utilise ActivityPub pour les échanges de messages, ce qui ouvre l'accès à tout le Fédiverse.
La première fois que j'avais entendu parler de ActivityPub, c'était sur à propos de Jabber/XMPP
Dans la page sur ActivityPub il est précisé que c'est une évolution de OStatus
Tu dis que cela a été forcé, mais peut être que simplement les besoin était d'avoir un peu plus de fonctionnalités ou de souplesses. D'ailleurs, tout ce qui est connecté au Fédiverse et qui communique via ActivityPub n'en prend en charge qu'une partie.
Je vois bien que OStatus est très bien pour du microbloging, avec aussi la prise en compte de Atom.
Mais, les usages et les besoins évoluent.
En quoi selon toi OStatus serait préférable à ActivityPub? Plus simple?
De mon point de vue, OStatus est très différent de ActivityPub, bien plus limité, et ne convient pas suffisamment avec les besoins de communications des utilisateurs autour du microbloging parce que les gens en veulent toujours un peu plus, y compris s'échanger des messages, partager des contenus, commenter, s'envoyer des fleurs etc.
Si un jour on peut lancer une visioconf via un client Mastodon, pour compléter les messages vidéos ou audio, ce serait super. Reste à créer la connexion avec un Galène, un BBB ou un Jitsy.
Mastodon, c'est une partie du Fédiverse.
Il suffirait à Gnu.social de prendre en charge une partie de Activitypub pour pouvoir rejoindre le Fédiverse. Alors oui, c'est un gros travail. Parfois pas grand chose suffit, et ça permet d'avoir Peertube dans le Fédiverse et c'est génial.
Oui, il y a 30 ans, s'échanger des emails était plus facile.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 8 (+6/-0).
En même temps, si t'es arrivé avec tes gros sabots en disant, comme ce que tu fais ici, « vous faites de la merde pas légale, bandes de nazes, laissez tomber t'façon vous z'avez pas les épaules pour gérer ce foutoir », c'est peut-être un peu normal que tu te sois fait accueillir fraîchement ?
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -3 (+0/-4).
Ah non j’ai dit « vous faites un truc pas légal et voilà comment vous pourriez faire pour être légal » et on m’a rembarré en me disant « nan mais si on fait ça on pourra jamais concurrencer les GAFAM » (à peu près).
Pour sortir du seul cas de Mastodon, je pourrais prendre plus ou moins n’importe quel projet libre et on serait plus ou moins dans la même situation.
Des devs qui n’ont jamais lu la moindre ligne du RGPD et qui font les trucs naïvement totalement illégalement. Et ça sans compter les projets hostés exclusivement sous Github (violation Schrems II), utilisant des media de support US (discord), déployant sur des infras US (Cloudflare, AWS, gitlab.io…), avec une privacy policy inexistante ou illicite, avec des features illicites (même Mozilla a foutu non seulement du tracking d’audience illice mais en plus passant par Google…), etc.
Et c’est plus ou moins le sens de mon propos d’ailleurs : au motif qu’on a foutu « GPL » dans une licence, tout le monde se croit autorisé à faire n’importe quoi et à ne jamais réfléchir au moins sur les obligations légales…
Et donc que « libre » n’est pas un argument en soi. Ça n’apporte STRICTEMENT RIEN à une décision concernant un choix de soft en 2024.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 8 (+6/-0).
Bah… Si.
Ça reste libre.
Si on a les mêmes défauts des deux côtés : libre et proprio. Les mêmes difficultés à vraiment suivre le RGPD, les même merdes dans tous les coins.
Alors la solution n'est pas d'abandonner le libre et de se jeter dans les bras des MAGAF, au contraire, c'est de continuer à pousser le libre et de faire en sorte qu'il le soit, conforme.
Ça reste toujours un argument, ça reste même le même argument que depuis 30 ans.
En fait, rien n'a changé dans le rapport de force entre libre et non libre.
Sauf…
Bah sauf que le libre permet une meilleure collaboration européenne en dehors de silos type MAGAF, et une meilleure construction durable du respect du RGPD, quand on en sera enfin là.
Donc tout ça n'est toujours pas un argument valable pour envoyer le HDH aux states.
Zéro pointé.
Toujours aussi foireux comme argument.
Derrière, c'est business as usual et lobbys à gogo.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -2 (+0/-3). Dernière modification le 20 février 2024 à 16:40.
Encore une fois non. Parce qu’actuellement je me fritte BEAUCOUP plus avec le libre qui brandit justement son côté libre pour ne RIEN faire niveau conformité (« parce que je ne peux pas être méchant, je suis libre », « oui mais le RGPD c’est pour les GAFAM, moi si je l’applique je meurt et comme je suis libre, ça serait pas bien tu vois » qu’avec des outils proprios.
Sur le papier le libre est supposé un argument EN PLUS mais en pratique il est un argument INDUIT. Les forks ne fonctionnent pas en pratique, les softs libres mais pourris pullulent, même les trucs comme Mozilla sont bardés de tracker.
Comme dit, j’ai pas un soft libre que je ne devrais pas éclater à la bombe atomique devant une APD avec une plainte de 80 pages, et me dire « ben t’as qu’à forker » est un non sens. Non seulement j’ai pas le temps pour ça, mais en plus ton produit est tellement construit sur ces non conformités que le taff à abattre pour le mettre en conformité est plus important que de tout refaire from scratch à supposer même que ce que tu cherches à faire soit en réalité légalement possible…
Encore une fois le terme « libre » n’apporte juste plus aucune plus-value à l’équation.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+1/-3).
Si je prend encore une fois l’exemple de Mastodon parce que c’est le plus facile à expliquer, dire « ta modération ne respecte pas le RGPD » impose de forker Mastodon et de :
tracer l’intégralité des actions administrateurs, ce que la plupart juste refusent de mettre en œuvre au motif que les admins ne doivent avoir de compte à rendre à personne, décision limite fondatrice du projet initial
mettre en place une politique d’appel, complexe à mettre en œuvre dans un environnement fédéré et incompatible avec la vision actuelle d’Eugen en particulier et des admins du Fediverse en général sur le sujet, en lien avec le point 1 d’indépendance des modérateurs
virer les notes de profil qui ont été une grande demande de la part des utilisateurs, en tout cas pas sans mise-en-œuvre des article 14 et 21 qui ne sont actuellement pas possible par le protocole ActivityPub
interdire les bannissements express et la destruction du contenu, en permettant aux personnes bloquées la continuité de l’exercice de leur droit, ce qui implique par exemple la continuité de la portabilité (contenu compris, donc)
modifier activitypub pour permettre une réelle mise en œuvre des article 14, 15, 16, 17, 18, 20 et 23, qui actuellement sont (mal) traités exclusivement par l’instance primaire émettant le contenu et aucunement propagés ni propageables aux instances secondaires le recevant
le tout en assurant la stricte compatibilité avec un soft illicite qui va rester probablement l’instance mainstream par excellence et que vu la population et la demande actuelle sur le fédiverse, ton fork va être utilisé par toi-même exclusivement
Non seulement ça ne ressemblerait plus du tout à Mastodon, mais ton propre réseau n’a plus ou moins aucune chance d’avoir le moindre visiteur.
Et c’est aussi pour ça que la justice du droit de la concurrence commence à regarder du côté du RGPD, parce que la non conformité est une atteinte et une distorsion de la concurrence : un soft RGPD-conforme est non-concurrentiel par rapport à un soft violant le RGPD pouvant proposer de facto plus de fonctionnalités mais illicites ou d’attrait pour les utilisateurs.
https://consultation.avocat.fr/blog/maxime-hardouin/article-45666-un-manquement-au-rgpd-peut-constituer-un-acte-de-concurrence-deloyale.html
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 9 (+6/-0).
Si tu veux interdire les bannissement express tu peux bannir tout internet hein.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 6 (+3/-0).
J'aimerai bien savoir à quel article tu te réfères là d'ailleurs.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 0 (+1/-2).
Déjà au DSA qui impose une procédure d’appel neutre et impartial jusqu’à 6 mois après le blocage. Ça implique donc ne de certainement pas supprimer les données dès le ban, comme l’autorise (et en abuse) actuellement certains admins de Mastodon et parce que Mastodon a implémenté ça comme ça (avec une check-box DELETE juste à côté du bouton BAN, qui ne devrait donc légalement pas exister, ou exclusivement pour des admins/super-modo et pour des usages très spécifiques, certainement pas accessible à un modo standard).
Et il faut que je retrouve la jurisprudence qui avait acté que le bannissement d’un service ne pouvait faire s’éteindre les droits de la personne concernée (donc 15-22 continuent à être 100% applicable jusqu’à la fin même banni)
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 6 (+3/-0). Dernière modification le 21 février 2024 à 07:52.
Je dirais que tout modo qui n'authorise pas les accès depuis l'europe peut l'utiliser.
Ça les GAFAM ne les respectent pas.
Ils gardent sans doute les données 6 mois mais si tu es ban ton unique recourt c'est de faire assez de bruit sur les autres réseaux sociaux pour que ça fasse un scandale et qu'un humain passe par une procédure manuelle.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par GG (site web personnel) . Évalué à 4 (+2/-0).
Les quelques scandales qui ont eu lieu ces derniers temps montrent que même le support humain est incapable de régler le problème, et que les comptes bloqués sont irréversibles. Il était question de pouvoir récupérer les données après blocage de comptes.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 0 (+1/-2).
Je viens de retrouver un lien intéressant. Voilà ce qui a été rédigé par des assos qu’on qualifiera assez difficilement d’être des dangereux extrémistes néo-nazis qui veulent défendre des trucs illégitimes : https://santaclaraprinciples.org/#3-appeal
Donc voilà, même des entités aussi importantes que l’ACLU et l’EFF, ou encore le centre pour la démocratie et la technologie ou la coalition national contre la censure, ont rédigé des principes de modérations en 2018 bien avant le DSA/DMA et pourtant qui en sont 100% compatibles.
Et actent donc que la modération de Mastodon/du Fediverse c’est juste du gros n’importe quoi et que ça ne respecte pas vraiment les principes démocratiques de base.
Devine qui a signé ces Santa Clara Principles ? Apple, Google, Twitter, Facebook…
https://www.eff.org/wp/who-has-your-back-2019
Oui ok, du coup c’est pas forcément bien appliqué. Mais c’est quoi le mieux du coup ?
Des entités comme Mastodon qui disent « yolo les principes rédigés par les entités les plus respectables en la matière de défense des libertés fondamentales et de la démocratie, on s’en cogne c’est pour les faibles/les méchants et ils ont tord » ou ceux qui ont au moins fait l’effort de signer la charte et donc a priori tentent d’en respecter les principes (même si c’est manifestement perfectible) ?
C’est quoi du coup qui est illégitime ? Le DSA/DMA qui ne fait que reprendre des principes initiés par l’EFF et l’ACLU ? Ou les gus de Mastodon qui chient dessus par pilées de 12 ?
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par GG (site web personnel) . Évalué à 5 (+3/-0).
C'est un peu ce qui était dit plus haut.
Alors oui, ils ont signés une charte, et l'appliquent plus ou moins.
Mais, ça n'empêchera pas les utilisateurs de perdre toutes leurs données chez leur prestataire parce que l'utilisateur aurait envoyé par email une photo du kiki de son fils par email à un Docteur parce que les consultations en présentiel étaient difficiles pendant les confinements liés à Covid19. Et malgré les contestations auprès du support, ce fut irreversible.
Il y avait aussi un autre cas avec un journaliste qui avait un abonnement illimité de stockage dans un Cloud, payant, et qui s'est retrouvé aussi dans une salle situation, malgré le contact avec le support.
Combien d'exemples qui n'ont pas été médiatisés?
Alors oui, ce que font la plupart des administrateurs des serveurs Mastodon ce n'est pas bien, mais ils faut aussi qu'ils gèrent leur serveurs avec les faibles ressources à leur disposition.
C'est un peu comme l'obligation de retrait d'un document dans un délai d'une heure, si la notification arrive en pleine nuit, ça ne sera pas traité avant le matin s'il n'y a pas assez de modérateurs. Certains, les très gros, ont l'obligation d'avoir assez de modérateurs.
je n'ai pas mis de liens, parce que je ne les ai pas notés quand ces histoires ont été publiées, mais si vous avez des sources sous le coude, n'hésitez pas à compléter. Mais ne perdez pas votre temps à les chercher.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+3/-0).
Pourquoi il faudrait obligatoirement signer les principes de Sainte Claire machin chose pour avoir une bonne modération ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 8 (+5/-0).
L'expérience montre que ceux qui l'ont signé ont réutilisé le document comme papier toilette alors ça vaut à peu près…rien.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Lutin . Évalué à 4 (+2/-0).
Pourtant, sortir des toilettes avec le fion pas trop gras, ça n'a pas de prix.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 6 (+3/-0). Dernière modification le 20 février 2024 à 17:38.
Même si la propagation automatique serait idéale, je ne crois pas que instance 1 pourrait être poursuivie parce que instance 2 a récupéré des trucs et n'a pas conscience que @bidule@instance1 veut, par exemple, que telle ou telle donnée soit corrigée. Une fois que les données sont chez un autre admin, c'est de la responsabilité de l'autre admin.
Et on impose pas par exemple gmail de supprimer les emails de tartampion@hotmail.com qui ont été envoyés à des addresses gmail parce que monsieur tartampion demande à hotmail de supprimer son compte et ses données.
La RGPD n'est tout simplement pas federation ready.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+3/-0).
Les mails sont de la correspondance privée, le rgpd n'impose pas de supprimer les mails dans les boites d'autres utilisateurs.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 0 (+2/-3).
Non justement. Le RGPD dit spécifiquement l’inverse. Ta transmission en tant que responsable de traitement à un autre responsable de traitement n’éteint pas ta responsabilité. LES DEUX en deviennent responsables, et en particulier le 1er est supposé continue à propager les demandes d’accès/rectification/effacement et a l’obligation de prouver qu’il fait le taff et propage bien toutes les demandes.
Cas très différent de la fédération. Le mail est décentralisé, mais pas fédéré.
Le destinataire final conserve aussi des intérêts puisqu’il s’agit bien d’une correspondance dont il est destinataire explicite.
Tu te trompes et inverse juste le problème. Et tient exactement les mêmes propos que les GAFAM (juste que eux disent « le RGPD n’est tout simplement pas business ready »).
La fédération n’est effectivement pas RGPD ready.
Et ce n’est pas forcément le RGPD qu’il faut revoir. Le DSA a même été spécifiquement conçu pour justement ne pas permettre l’évitement des réglementations via des prétextes de fédération.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 0 (+2/-3).
Et les propos que tu tiens ne font que confirmer ce que je dis dans mon article.
« Le libre » devient un argument en soit, sans réflexion des avantages ou inconvénients apportés, et le fait qu’on est gêné par la loi et que parce qu’on est « libre » ou « fédéré » on devrait ne pas avoir à la respecter. Sans jamais d’abord poser la question de savoir si ce que « le libre » ou « la fédération » cherche à faire est réellement légitime/morale/légal/whatever.
« Je fais du libre donc je ne peux pas être du mauvais côté ». Et derrière j’entend déjà « oui bon le RGPD est une merde du coup et faut le changer » ou autre « l’article 8 de la CEDH c’est pas pour nous ». Comme les GAFAM quoi… L’aspect financier en moins…
Je pourrais aussi citer Shinigami Eyes qui s’est juste pris un taquet monstrueux de la part de la plus grande autorité de protection des données d’Europe, saisie par l’APD qui fait le mieux son taff en Europe (la Norvège), mais que au motif que c’était pour taper sur les transphobes, fallait surtout plus être trop trop regardant sur le respect de la vie privée et qu’on était forcément du côté du bien.
Ben non en fait, Bob… T’es juste à foutre dans le même sac que les autres hein ! Et c’est pas parce que tu fais du libre ou que tu penses que tu fais le bien que c’est l’absolution totem d’immunité !
Et que oui, des p**** de gens continuent d’utiliser cette extension libre (licence MIT) qui s’est juste fait démonter par EDPB pour de bonnes raisons légitimes et morales et est littéralement interdite en Norvège (à défaut qu’EDPB ait pu l’interdire dans toute l’Europe) !!!! Et ça ne choque… personne… 😑
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 8 (+5/-0). Dernière modification le 21 février 2024 à 08:15.
Je n'ai pas dis ça. Ne fait pas ton Zénitram
Je n'ai pas dit ça non plus.
Du restes c'est TOI qui fait un amalgame libre = non conformité à la RGPD.
La licence n'a rien à voir là-dedans, si Mastodon avait une licence proprio les problèmes seraient exactement les mêmes.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par devnewton 🍺 (site web personnel) . Évalué à 5 (+2/-0).
Le mail est à la fois fédéré et décentralisé :-)
Il y a d'ailleurs plusieurs fédérations, la plus connue est celle qu'on utilise tous avec nos comptes mails persos ou pros, mais il en existe d'autres comme MSSanté par exemple.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 6 (+3/-0).
Étant donné qu'une instance Mastodon correctement configuré n'a qu'un cache limité dans le temps sur les données qui lui sont propagées, je ne vois pas trop en qu'est-ce qu'il manque? Si un utilisateur édite sont message, l'édition est propagée. C'est juste un cache. S'il ferme son compte et quitte l'instance mastodon d'origine, ses changements de statut vont disparaitre non? Qu'est-ce qu'il manque selon toi?
Bien sûr que si que le mail est fédéré.
Dans le cas d'un statut mastodon aussi on pourrait rétorquer que c'est invocable, surtout quand il y a des mentions.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 6 (+3/-0).
Je reviens là dessus.
Le principe de fédération, c'est un tout autre concept qu'un système de traitement de données par un sous-traitant ou vente de données internes à un client. Et je réitère que ça n'a pas été pris en compte dans la RGPD.
Une loi peut bel et bien ne pas être, ou partiellement (on n'est pas obligé de jeter toute l'eau du bain hein), adaptée à une société. Ce n'est pas pour rien que les lois sont longuement débatues et amendées. Je crois que tu ne me contrediras pas pour dire que la loi qui interdisait le port du pantalon aux femmes jusqu'en 2013 était complètement inadaptée à la société. On peut t'en sortir par centaines des lois mal branlées.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par devnewton 🍺 (site web personnel) . Évalué à 8 (+5/-0). Dernière modification le 21 février 2024 à 09:45.
Et on a toléré ces femmes non certifiées alors qu'il existait des gafemmes en robe longue catho-27001… Quelle honte !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 6 (+4/-0).
Je vais faire une réponse simple :
Il y a certainement beaucoup plus de logiciels et services libres dont tu n'entends jamais parler, que de ceux dont tu entends parler.
Le fait qu'il y ait plusieurs milliers d'instances mastodon alors qu'il n'y a qu'une seule instance Twitter explique simplement le fait que tu sois submergés de problèmes liés à des logiciels libres par rapport aux équivalents proprios.
Ce n'est pas intrinsèque au libre, c'est intrinsèque à la décentralisation.
Tu préfères la centralisation parce que ça te simplifie le boulot.
Je peux comprendre, je ne partage pas, mais je peux comprendre.
J'ai plus de mal à comprendre que tu bâches le libre en tant que victime collatérale…
Des arguments du genre « le libre ne fait RIEN niveau conformité » sont d'une telle bêtise crasse, que je ne comprend pas comment tu peux les dire.
D'autant plus que tu as UN unique exemple, et c'est Mastodon.
Le libre est bien un argument EN PLUS.
Mais cet argument c'est le respect des 4 libertés fondamentales, pas celui du respect du RGPD.
Ça c'est lié à chaque projet, à chaque gouvernance.
Tiens, bah trouve-moi les infractions au RGPD dans Delta-Chat, je veux bien les connaître s'il y en a !
Je ne dis pas qu'il n'y en a pas, mais bigre, j'aimerais bien les connaître.
Alors que bon, juste le rapport Exodus sur l'appli outlook de chez Microsoft t'indique que côté RGPD, t'es foutu, t'es hors clous, tes données elles partent n'importe où, chez Google, chez Facebook, chez d'autres gusses que tu connais même pas…
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+2/-4).
C’est plutôt GreenHost pour le coup. Je ne peux pas vérifié, mais je suppose que le DPA que vous avez signé avec votre hébergeur est comme 99.999% des cas illicites (la plupart des standards dispo sur le net par les providers le sont). Et que vous ne conduisez aucun des audits annuels/bi-annuels nécessaires à la conformité RGPD (sanction de EDF par la CNIL de mémoire).
Clause illicite, les « other » ou « par exemple » sont illégaux et chaque finalité doit être explicitement détaillé.
Faux, au moins 2 sont des obligations légales (sécurité des SI et journalisation des accès) et non des intérêts légitimes.
Idem, difficile à juger de loin, mais avez-vous bien passer les triples tests (nécessité, proportionnalité, balance des droits) de justification de l’intérêt légitime pour éviter une requalification en consentement par une APD ?
Généralement clause considérée comme problématique par EDPB, pas assez spécifique ni éclairée
Délai trop long, la suppression est supposée être opérée avant 2 ans, et à la date anniversaire de suppression, pas à la fin de l’année calendaire (sinon celles du 1er janvier sont conservés 6 ans en pratique)
Interdit sous le régime du « nécessaire au contrat » invoqué au 6(1)b, et la jurisprudence EDPB/CJUE indique plutôt une obligation de consentement, l’intérêt légitime étant trop intrusif sur la balance des droits (3ème test de l’IL qui ne passe pas)
User behavior = données sensibles article 9 donc intérêt légitime difficile à passer.
« analyze technical problem or possible abuse » déclarés trop vague par EDPB dans ses lignes directrices.
IL fragile relativement souvent requalifié en consentement par les APD
https://www.google.com/{persistent-cookie:SOCS}
https://google.com/{persistent-cookie:__Secure-3PSIDCC}
https://google.com/{persistent-cookie:__Secure-1PSIDCC}
Transfert internationaux vers Google, violation Schrems II
je n’arrive pas à comprendre d’où ça sort exactement, mais ça sort, µMatrix les chope à chaque refresh (à investiguer, clairement ça m’intrigue…)
Violation ePrivacy + violation encadrement de la sous-traitance article 28
Tout le § est globalement faux, laissant sous-entendre que delta.chat n’est responsable de rien, alors qu’il reste 100% responsable de traitement de l’intégralité des transferts de données générés par ses recommandations ou usages.
Publicité ciblée interdite en Europe sur le fondement de l’IL explicitement depuis au moins juin 2023 et la décision urgente de EDPB envers Meta.
Je développe pas hein… (Schrems II, tout ça…)
Un traitement ne doit être fondé que sur une et une seule base légale. Ici c’est donc une clause illicite.
Illégal. Le mécanisme du One-Stop-Shop impose que seule l’APD de la personne concernée soit saisi, charge à elle de transmettre à l’APD du responsable de traitement derrière
Non sens technique
A priori pas d’update de la privacy policy depuis 2 ans, dont des changements majeures de réglementation Schrems II & cie sur le sujet entre temps.
Une PP pas mise à jour au moins chaque année, c’est louche déjà
Pas mis à jour depuis 2013, donc même pas pour être conforme au RGPD de 2016.
Voilà déjà pour la privacy policy, j’ai même pas encore attaqué le service… 😑
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+2/-4).
https://cryptcheck.fr/https/delta.chat
J’ajoute au pif non respect des exigences minimales de sécurité de l’ANSSI, utilisation de suite non PFS dépréciées depuis 10 ans. Pas de supporte de HSTS. Clef RSA de 2048 bits au lieu des 3072 minimums (surtout si pas de PFS).
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par devnewton 🍺 (site web personnel) . Évalué à 8 (+5/-0).
Tu mélanges tous les sujets. Ce genre d'audit où tu sors un million de micro remarques comme tu le fais, les grandes boites 100% RGPD SecNumCloud ISO Mes Couilles Mille Un en passent 42 fois par an et obtiennent globalement la même chose (sauf qu'en plus comme c'est closed source secret des affaires inside, tu ne pourras rien vérifier).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 2 (+3/-2).
Et donc parce que je prouve que delta-chat se torche avec le RGPD, faudrait dire « non mais les GAFAM font pareil donc on continue » ?
On me dit que c’est propre, j’ouvre juste le truc et je fais une syncope. On m’explique ?
Même TLS qui est un truc qui a subit un gros bordel en 2014-2016 est pas à jour quoi… 😑😡
Encore une nième fois, ça ne fait que confirmer ce que je dis dans mon blog. « Être libre » est dorénavant une excuse pour ne rien faire, se foutre de la gueule du monde et espérer un totem d’immunité et de sympathie pour ne pas avoir à respecter la loi…
Je ne suis pas en train de te parler d’une loi random fait par des machins yolo remplis de lobbying, j’suis en train de te parler d’un réglement qui est une des rares où la Commission a tenu tête à des lobbyings pendant 6 ans, n’a reculé sur rien, pour défendre des sujets qu’on a nous-même demandé et qui ont été poussé par la majorité sinon la totalité des associations libristes et assimilées depuis 20 ans, et qu’aujourd’hui qu’on l’a enfin en application « non mais j’ai piscine, totem d’immunité GPL-MIT-BSD ».
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 0 (+1/-2).
Et ça a été exactement pareil par exemple sur la fédération/intéropérabilité…
T’as LQDN qui fait des pieds et des mains pendant 10 ans sur ce sujet, qui fait une pétition et un appel national, et quand t’as Meta qui se pointe « bonjour, on peut fédérer du coup ? », y’a la moitié du bordel qui l’insta-strike !
Ça montre de plus en plus que les arguments avancés par tout ce milieu sont juste des PRÉTEXTES pour distordre la concurrence et que quand il faut appliquer tout ça à soi-même, y’a aquaponey.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par GG (site web personnel) . Évalué à 4 (+2/-0).
Il était écrit noir sur blanc que Meta allait tout pomper.
Et, je l'ai déjà écrit, quelles que soit les promesses de Meta, personne ne peut leur faire confiance. Et personne n devrait leur faire confiance.
Pourquoi les gros, avec tout le pognon qu'ils ont, refusent de respecter les lois et réglementations? Concrètement, pas juste des promesses.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par devnewton 🍺 (site web personnel) . Évalué à 7 (+4/-0).
Ils ne se torchent pas avec le RGPD : tu nous as sorti une page qui parle du service de support assuré par Merlinux, ce qui n'est pas tout à fait la même chose que le logiciel Delta Chat.
Delta Chat est un client mail, il n'est pas lié à un service en ligne spécifique : c'est l'hébergeur mail que tu configures qui traite tes données.
Si justement grâce à Delta Chat, tu actives le chiffrement de bout en bout, les dites données seront très limitées.
Tu as le droit de préférer Outlook en ligne avec un abonnement Office 365, toute ta correspondance privée en clair sera sans doute traitée avec le plus grand respect et la plus grande souveraineté par le tiers de très grande confiance européen Microsoft grâce à ses nombreuses certifications :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+1/-3).
J’ai aussi le droit de défoncer devant une APD exactement de la même manière un logiciel de mail qui a une privacy policy aussi pétée et qui n’incite pas DU TOUT à aller plus loin. Si ta landing page est dans cet état, je ne veux même pas aller voir la gueule de ton service. Quand tu me mets « AES128 v3 » dans ta privacy policy avec un site web qui supporte encore du non PFS avec du chiffrement RSA 2048 bits, laisse-moi douter TRÈS FORTEMENT de ta capacité à faire de la crypto proprement et encore pire en end-to-end.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+1/-3).
C’est faux. Delta-chat, en tant que fournisseur d’un logiciel en Europe, ne peut pas se défausser sur « il avait qu’à faire attention, l’utilisateur ».
Le simple fait que le code source ne soit dispo que sur github est une violation de Schrems II. Le fait qu’on télécharge des .deb chez vous est un traitement de données dont vous êtes responsable de traitement et avez au moins en Europe l’obligation de collecte des données de connexion.
Le fait de le déployer sur le play store fait que Google est un co-responsable de traitement dont vous endossez aussi la responsabilité des CGU tacitement (non) acceptées par vos utilisateurs, et comme déjà sanctionné 5-6× par des APD.
Vous fournissez un .deb sans aucune signature crypto. Pour un soft prétendant faire de la sécurité.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+1/-3).
Et je peux continuer encore comme ça longtemps hein…
Pourquoi est-que la v1.42.2 de décembre dernier embarque du react 17.0.2 de 3 ans d’âge (22/03/2021) quand les dernières versions sont en 18.x ? Du use-debounce 3.4.3 livré en 2020 quand il y a dorénavant du 10.0.0 (🤯) ? Du ws 7.5.9 de 2 ans quand on est en 8.16.0 dorénavant ? Bordel quoi…
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par devnewton 🍺 (site web personnel) . Évalué à 8 (+5/-0).
Tu devrais leur ouvrir des tickets au lieu de poster ton audit flash en commentaires sur linuxfr :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 7 (+5/-0).
Ça s'installe sur lineageOS via f-droid, c'est signé, ça passe pas par google, et c'est la 1.42.6.
Je ne me sens toujours pas concerné par tes remarques, et je ne vois toujours pas de violation de RGPD.
Bon, on reprend : on a une application qui est un client mail, et qui utilise le protocole mail pour présenter des discussions sous forme de chat à la Conversation, ou Signal, on peut faire des groupes etc.
Le chiffrement est géré de façon ad-hoc, donc en général pas au premier message, le temps de faire un échange de clés, ça a ses limites, par contre le chiffrement utilisé est non-obsolète.
En pratique, l'application échange des données avec ton hébergeur mail, c'est un client mail, et il n'y a rien d'autre.
Pas de statistiques, pas de trackers, aucune remontées de quoi que ce soit.
L'application conserve les mails localement, comme le fait n'importe quel client mail.
Les mails sont stockés chiffrés sur le serveur mail, géré par ton hébergeur de mails.
J'ai du mal à voir comment tu pourrais blâmer Delta Chat pour une fuite de données en provenance de ton hébergeur de mail, mais dans tous les cas, les mails chiffrés via Delta Chat restent chiffrés, et une faille chez l'hébergeur ne peut pas vraiment changer ça.
Donc, les violations RGPD elles sont où là ?
Vas-y, explique.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -3 (+1/-5).
Et encore une fois tu ne comprends pas les implications du RGPD et que l’application n’est PAS la seule chose à vérifier pour la conformité d’un projet.
Typiquement je ne PEUX pas auditer ton code sans accepter les CGU de github et violer Schrems II et TU es responsable en tant que responsable de traitement, github étant ici co-responsable de traitement.
Le manque de sécurité de l’application elle-même, avec des libs dépréciées depuis 3 ans, est aussi un manque de l’obligation de sécurité du RGPD et de la doctrine de suivi de version donné par la CNIL en décembre dernier. Et c’est de TA faute.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -2 (+1/-4).
Et ton comportement est l’archétype même de ce que je dénonce dans mon post. Des réflexions purement « techniques » et que comme « je fais du libre j’ai totem d’immunité », je ne me remet absolument pas en question. Jusqu’au jour où « oups je vais me faire défoncer par mon APD » (ça va, en France y’a de la marge… 😑)
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -2 (+1/-4).
Ah oui, toi qui parle crypto, t’es au courant que delta-chat négocies du non PFS avec les serveurs IMAPS et donc que si ton client se fait défoncer par une faille de sécu sur la ligne, c’est AUSSI delta-chat qui est responsable pour ne pas avoir blacklisté ces cipher suite ? Et que ça négocie aussi du DHE pété depuis 2018 avec logjam & cie ? Et que donc idem ?
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 0 (+2/-3). Dernière modification le 21 février 2024 à 00:08.
Je te met une étoile devant tout ce qui est déprécié et actuellement négocié par delta chat
LA MOITIÉ des cipher suite négociées sont dépréciées par l’ANSSI depuis 8 ans au moins !!!!
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 6 (+3/-0).
Cites-moi dans ce journal qui a écrit ça.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 7 (+4/-0).
Bien sûr que si.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 0 (+1/-2).
Ben non. La source officielle est sur Github.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 7 (+4/-0). Dernière modification le 21 février 2024 à 14:40.
1) Tu sais que ce n'est pas interdit ni compliquer de demander de manière humaine et courtoise aux developpeurs via la mailing list ou le forum si par hasard ils ne pourraient pas t'envoyer un tarball du code source et/ou le mettre à disposition sur leur site.
Seulement si on te met un vent où que l'on te le refuse tu pourras prétendre que les sources ne sont pas dispo ailleurs.
2) tu n'as pas besoin d'accepter les CGU de github pour télécharger le code source. Les CGU d'un site n'engages que ceux qui les lisent et les acceptent en créant un compte.
3) la Schrems II n'est pas violée si tu vas sur github ou toute autre forge/repo.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 6 (+3/-0). Dernière modification le 21 février 2024 à 14:52.
Et j'ai oublié d'ajouter que tu n'as même pas besoin d'accéder au site github avec un navigateur, tu peux télécharger les sources simplement avec git clone.
Le seule endroit qui pourrait éventuellement être problématique avec deltachat selon moi c'est leur forum de support. Mais comme je n'y ai pas de compte, je n'ai pas étudié la question ni lu leurs conditions d'usage et communications sur le sujet des données utilisateurs.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par devnewton 🍺 (site web personnel) . Évalué à 7 (+4/-0).
Il s'est amélioré récemment sur ce point avec l'ajout de SecureJoin et il était déjà possible d'importer ses propres clefs (mais peu de gens le faisaient, car c'est compliqué).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0).
Le fait de télécharger n'implique pas un traitement de données.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -2 (+1/-4).
Si puisque tu transmets ton adresse IP à Microsoft.
’fin bon, tu prouves que tu as une culture proche du néant en terme de conformité RGPD…
Github est sous-traitant de delta-chat, delta-chat aurait du signer un DPA avec Microsoft.
Le téléchargement du source sur github (avec delta-chat en responsable de traitement donc et Github en co-responsable de traitement) est un traitement de données soumis à l’article 50 des transferts internationaux de DCP, et une violation de l’arrêt Schrems II de la CJUE.
C’est pas comme si c’était JUSTE UN PEU l’intégralité du rationnel de la CJUE sur Schrems II hein… 😑
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -2 (+0/-3).
https://gdprhub.eu/index.php?title=LG_M%C3%BCnchen_-_3_O_17493/20
https://gdprhub.eu/index.php?title=IMY_(Sweden)_-_DI-2020-11373
https://gdprhub.eu/index.php?title=CNPD_(Portugal)_-_Delibera%C3%A7%C3%A3o_2021/533
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 9 (+6/-0).
Github n'est pas intégré à la page de delta chat. Et le code source ne fait pas partie d'un service delta-chat ni du site delta-chat.
C'est un lien.
Si je te pointes un lien sur linuxfr vers un tweet, linuxfr n'est pas responsable du traitement de données par twitter.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 4 (+2/-0).
Non, puisque j'utilise Tor.
Et/ou un miroir européen.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -2 (+1/-4).
Ce qui ne change strictement rien au RGPD. Typiquement il est même interdit par le RGPD de demander aux utilisateurs de mettre en œuvre des mécanismes de protection au lieu de faire les efforts côté responsable de traitement.
C’est explicite pour les cookies par exemple, « t’as qu’à configurer correctement ton navigateur pour les bloquer » est illégal.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0).
La RGPD ne définie pas un niveau minimum de taille de clés RSA.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+1/-3).
Nom mais impose le respect de l'état de l'art en terme de sécurité et donc le suivi des recommandations ANSSI en France, comme encore rappelé par la CNIL dans ses sanctions
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 6 (+3/-0).
Accepter une clé RSA réputée "weak" ne signifie pas que tu l'imposes. Ma connection au site delta.chat utilise TLS 1.3 avec des cyphers élevés par exemple.
Et en l'occurence l'utilisateur de delta.chat ne transmet pas de données privées via cette connection. Il se connecte à des serveur SMTP.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+1/-3). Dernière modification le 21 février 2024 à 10:48.
Accepter une clé RSA weak t’expose à du downgrade attack parce qu’un attaquant peut forcer le repli vers une suite faillible. C’est donc une faille de sécurité et actuellement c’est de toute façon une violation des lignes directrices de l’ANSSI (pas de PFS = support de données après 2030 = 3072 bits minimum) donc une violation du RGPD.
Tu peux argumenter tant que tu veux, c’est un fait juridique.
Établir une connexion TCP/IP, même chiffrée, reste une transmission de DCP (l’adresse IP de l’utilisateur) et est donc en soit un traitement de données soumis au RGPD, et que c’est même exactement ce traitement qui est visé avec Schrems II, la sanction de Google Analytics (malgré l’anonymisation prouvée derrière par la CNIL), Google Fonts, Cloudflare ou tout CDN ou contenu tiers servi par un site internet (violation de l’obligation de minimisation de données article 5 et 6)…
La connexion chiffrée va ensuite échanger un mot de passe et un nom d’utilisateur qui sera aussi une DCP, même si le tunnel lui-même est chiffré. Données accessibles en clair au service en face donc n’étant PAS anonymisées.
Delta-chat est le moyen utilisé pour cette transmission, la finalité étant elle-même décidé par l’utilisateur. Sauf qu’un responsable de traitement est celui qui définit la finalité OU le moyen et donc delta-chat reste responsable de traitement, éventuellement est même sous-traitant au sens du RGPD si delta-chat est utilisé dans le cadre d’une asso ou d’une entreprise (qui est elle-aussi responsable de traitement pour avoir définit la finalité).
Mais tu ne fais que confirmer que tu n’as strictement aucune idée de ce qu’est le RGPD…
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 9 (+6/-0).
Tu ne fais que confirmer que tu ne sais pas faire la différence entre un service/plateforme en ligne et un client.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+1/-3).
Le RGPD ne fait pas la différence effectivement. C’est bien delta-chat qui agit en tant que sous-traitant en fournissant un logiciel à des entités qui peuvent être elle-même responsable de traitement (asso, entreprise, particulier hors 2(2)c).
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 9 (+6/-0). Dernière modification le 21 février 2024 à 16:30.
J'espère que ce n'est pas ton boulot sinon tes clients ont bien des problèmes.
Deltachat ne peut pas être sous-traitant puisqu'il ne fait pas partie d'un système de traitement de données personnelles. C'est un client mail.
Firefox n'est pas un sous-traitant de facebook.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 6 (+4/-0).
Alors, je ne parlais pas du site web, mais bien du logiciel.
Une fois installé et quand on l'utilise.
Sur le site de delta.chat, dans les mentions légales, je vois des mentions du RGPD, et la seule date trouvée est novembre 2021.
support.delta.chat semble être un forum annexe de support, encore une fois, c'est pas l'application Delta Chat.
Ok, on peut critiquer le site web, mais je n'avais jamais été regarder là-bas avant alors que j'utilise Delta Chat.
Il n'y a pas de lien, les comptes que tu peux trouver là-bas ne concernent pas l'application, il n'y en a pas besoin, ils servent à autre chose, et ce n'est pas de ça que je voulais parler.
J'avoue, je n'ai pas imaginé une seconde que c'était ce que tu allais faire, regarder le site web et les sites annexes.
Mais laisse-les de côté, ils n'ont en pratique aucun lien avec l'utilisation du logiciel, qui ne se connecte absolument pas à un quelconque service hébergé par delta.chat.
Pour le chiffrement dans l'application, c'est plutôt là qu'il faut regarder :
https://delta.chat/fr/help#which-standards-are-used-for-end-to-end-encryption
Que le site web soit la cinquième roue du carrosse et ait un chiffrement ancien, alors que tout est public dessus et pourrait aussi bien exister en HTTP non chiffré, ça ne me perturbe pas spécialement.
Que leur forum soit à la ramasse, c'est un peu dommage, mais je ne vois pas le rapport avec le logiciel non plus.
Ton message plus bas représente bien ton attitude générale ici. Tu sembles plutôt au bord du burnout, et tu mélanges tout, en faisant des amalgames brutaux et incohérents.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+1/-3). Dernière modification le 21 février 2024 à 00:27.
Excuse-moi d’être proche du burnout quand je passe 1 journée à expliquer des trucs à des gens qui disent que je dis de la merde mais prouve par A+B que j’ai raison, et que quand on me donne un exemple, je défonce littéralement le truc à la fois au niveau organisationnel (forum, source, build et j’en passe), juridique (des PP qui n’ont aucun sens) et technique (libs obsolètes de 3 ans d’âge, protocole crypto déprécié depuis 8 et chaîne de dépendance complètement WTF (ça fout quoi dans les livrables le libffmpeg.so que je ne sais même pas de quelle version il vient ?)) y compris sur de la crypto dont c’est supposé être le point fort de la solution… 😑
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 0 (+1/-2). Dernière modification le 21 février 2024 à 00:41.
Aller on continue… Bon ben c’est basé sur Electron hein. Donc Chrome…
Bon ben hein…
378082 access("/usr/share/kservices5/searchproviders/google_news.desktop", F_OK) = 0
378082 access("/usr/share/kservices5/searchproviders/google_groups.desktop", R_OK) = 0
378082 access("/home/aeris/.local/share/kservices5/searchproviders/google_groups.desktop", F_OK) = -1 ENOENT (Aucun fichier ou dossier de ce nom)
378082 access("/home/aeris/.local/share/kservices5/searchproviders/google_groups.desktop", F_OK) = -1 ENOENT (Aucun fichier ou dossier de ce nom)
378082 access("/usr/share/kservices5/searchproviders/google_groups.desktop", F_OK) = 0
378082 access("/usr/share/mime/application/vnd.google-earth.kmz.xml", R_OK) = 0
378082 access("/usr/share/mime/application/vnd.google-earth.kml+xml.xml", R_OK) = 0
378082 access("/usr/share/mime/text/x-google-video-pointer.xml", R_OK) = 0
378082 access("/usr/share/applications/google-maps-geo-handler.desktop", R_OK) = 0
378082 access("/usr/share/applications/google-maps-geo-handler.desktop", F_OK) = 0
378082 access("/usr/share/applications/google-maps-geo-handler.desktop", F_OK) = 0
378082 access("/usr/share/applications/google-maps-geo-handler.desktop", W_OK) = -1 EACCES (Permission non accordée)
378082 access("/usr/share/applications/org.kde.akonadi_google_resource.desktop", R_OK) = 0
378082 access("/usr/share/applications/org.kde.akonadi_google_resource.desktop", F_OK) = 0
378082 access("/usr/share/applications/org.kde.akonadi_google_resource.desktop", F_OK) = 0
378082 access("/usr/share/applications/org.kde.akonadi_google_resource.desktop", W_OK) = -1 EACCES (Permission non accordée)
Oui, c’est delta-chat ça… J’en ai 1038 lignes des comme ça si tu veux…
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 1 (+2/-2).
Mais encore une fois, on a fondé un logiciel libre sur un composant des GAFAM, que personne ne serait certainement capable de me dire quel version de ffmpeg, vulkan et eGL ça embarque, et tout le monde me donne tord depuis hier…
En vrai le soft que tu me demandes d’analyser est juste basé sur le pire navigateur de tout les temps conçus, géré et livré par Google lui-même. Vraiment, on aurait commencé par là, on aurait gagné du temps hein…
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 2 (+3/-2).
Et donc ton « client mail » est en réalité un navigateur de 161Mo embarquant en dur une libffmpeg pas maintenue par le système en cas de faille de sécurité, pour faire tourner le navigateur de Google et appeler des libs JS de 3 ans d’âge pour négocier des protocoles de sécurité pétés depuis 8 ans, le tout livré depuis un site web avec une privacy policy complètement lunaire, fournissant des tar.gz, deb ou appimage non signés, le tout avec un code source dispo exclusivement sous github en violation de Schrems II, et dont je suppose très fortement que tout ça se torche avec la compilation reproductible et que j’aurais aucun moyen de vérifier ce qu’il y a réellement dans le binaire fourni par le projet ?
Et tu oses venir me demander de me justifier sur la non conformité des projets libres ?????
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 1 (+2/-2).
Je peux même pas forker, j’ai pas accès aux sources (github). Même si je forkais, faut que je réécrive tout pour virer Electron/Chrome/Google.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 1 (+2/-2).
J’oubliais quand même aussi : version d’électron embarquée ? 26.6.0
Fin de vie officielle quand ? 20-Fev-2024
Ah… C’est con… Un navigateur qui est en plus complètement déprécié…
C’est prévu quand la prochaine release de delta-chat du coup pour la migration en electron 27 minimum ?
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0).
Le fait que les sources sont sous github ne signifie pas que tu ne peux pas les obtenir autrement.
Lorsque tu télécharge les sources sur github, aucune donnée utilisateur n'est transmise par delta-chat.
Du coup on n'est pas du tout dans le cas d'un transfert de données entre zone EU et US et tu as une lecture toute particulière de Schrems II.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 0 (+1/-2). Dernière modification le 21 février 2024 à 09:27.
Le RGPD impose la minimisation des données et de la friction utilisateur, par exemple aucun effet négatif entre un utilisateur A et un B gui accepterait le tracking.
Dans tous les cas c'est bien delta-chat (l'équipe) le responsable de traitement et empêche l'accès à son propre soft pour quelqu'un qui voudrait l'utiliser.
Une boîte ou un particulier sensibilisé qui voudrait utiliser le soft ne PEUT PAS. Pas de signature des livrables, défaut de sécurité de la supply chain. Pas d'accès simple aux sources sans passer par une boîte US. La simple visite du site web conduit DÉJÀ à des violations du RGPD.
Un responsable de traitement (asso, boîte, particulier agissant hors 2(2)c) qui installe ce soft, sans vérification possible de l'intégrité donc, déploie un chromo obsolète rempli d'une 30aine de CVE, et commet donc une 20aine de violation lui-même (défaut de sécurité, défaut de sous-traitance, usahe de logiciel obsolète, défaut de contrôle de la supply chain, transfert US, …).
Et on en revient à ce que je dis dans mon article. Le libre devrait m'éviter de faire toutes ces vérifications et contrôles et devrait impliquer un certain gage de qualité. Sauf qu'en pratique ce n'est plus le cas et le taff de vérif à accomplir est au moins aussi important que pour le proprio.
Le proprio a par contre le bon goût, lui, de ne pas tenter par tous les moyens de ne même pas reconnaître qu'il est réellement responsable de traitement (c'est dans le contrat et il te file un DPA).
Techniquement en plus on a vu que ce soft est une merde sécuritaire de toute façon.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 8 (+5/-0).
Delta-chat n'est pas un responsable de traitement, ce n'est pas un service ni une plateforme en ligne.
C'est juste…un client mail.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par devnewton 🍺 (site web personnel) . Évalué à 10 (+8/-0).
Tu as une interprétation extensive du RGPD.
Ce n'est pas parce que Delta Chat héberge ses sources chez Github que Github devient co/sous-traitant du logiciel au sens de cette règlementation.
Un défaut de sécurité, c'est le quotidien de tout producteur de logiciel, le RGPD ne dit pas que tu ne dois jamais avoir de faille, sinon ce serait impossible de distribuer le moindre bout de soft.
Non pas du tout, c'est d'ailleurs pour ça que la plupart des licences (libres ou privatrices d'ailleurs) ont une clause de non garantie :-)
Bref plutôt que surinterpréter les lois, tu devrais remonter les problèmes que tu découvres :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -3 (+0/-4).
Je n’ai jamais dis ça. J’ai dis que tu devais mettre en œuvre les préconisations de l’état de l’art du secteur, en l’occurence celle de l’ANSSI, et que delta-chat ne respectait au moins pas les prérequis sur TLS (pas de PFS, DHE actif, moins de 3070 bits alors que PFS pas garanti).
Delta-chat agit en responsable de traitement au moins vis-à-vis de ses propres développeurs/contributeurs/whatever, et donc Github est sous-traitant de l’entité développant le logiciel delta-chat. Dans tous les cas.
Et l’utilisateur, en particulier association ou entreprise, ayant le RGPD à respecter donc, agit en tant que responsable de traitement, et delta-chat est son propre sous-traitant (au mieux, responsable de traitement conjoint, au pire).
Delta-chat ne respectant pas la réglementation en vigueur, et à la limite qu’il soit responsable ou pas ne change pas le problème, ne remplit pas les objectifs obligatoires pour utiliser ce logiciel (défaut de sécurisation, défaut de supply-chain, violation de Schrems II pour audit du code ou contribution) et delta-chat ne peut donc PAS être utilisé en Europe par qui que ce soit qui est soumis au RGPD.
Un responsable de traitement souhaitant mettre en œuvre l’article 28 du RGPD sur l’encadrement de la sous-traitance ne pourrait pas établir delta-chat comme sous-traitant conforme.
Delta-chat développe donc au mieux (s’il n’est pas responsable de traitement ni sous-traitant) un logiciel inutilisable légalement en Europe, au pire sera requalifié sous-traitant (ou pire du pire responsable de traitement) violant le RGPD et endosserait aussi la responsabilité d’une non conformité.
Aucune entreprise en Europe n’est en capacité légale de pouvoir utiliser delta-chat sauf à violer encore plus le RGPD. Les manquements que j’ai identifié sont suffisant à ne pas pouvoir mettre en place ne serait-ce qu’un acte de sous-traitance avec delta-chat par une entité soumise au RGPD.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -2 (+1/-4).
Et à la limite on peut prendre le problème dans l’autre sens : je suis une entreprise/association qui souhaite utiliser delta-chat. Peu importe la relation contractuelle entre moi et delta-chat.
Je dois assurer la sécurité informatique de ma chaîne logicielle et n’utiliser que des outils répondant aux exigences « état de l’art » de l’ANSSI et contrôler ma supply chain, comme rappelé par la CNIL dans ses sanctions.
Je tombe sur un soft qui ne fournit pas de signature d’intégrité, embarque un navigateur obsolète contenant 30 CVE, me contraint dans tous les cas à ouvrir un compte sur Github (Microsoft) pour pouvoir ne serait-ce que remonter les issues. Je ne peux même pas aller constater les violations vu que pour ça faut que j’aille sur github. Ou faut que je me prenne le chou à trouver le moyen d’avoir un accès aux sources. Et qu’il me faut des notions en crypto pour m’apercevoir que la procédure de vérification d’intégrité proposée pour les APK est du flanc qui ne fait strictement rien.
Juste je passe mon chemin. Je ne vais pas passer 3h à chercher un truc quand en faisant 3 clics sur Google j’ai un contrat de DPA les rendant co-responsables de traitement légalement avec moi et que si jamais j’ai des emmerdes j’ai quelqu’un qui va être responsable avec moi, plutôt qu’un truc qui va me dire « démerde-toi tout seul t’avais qu’à forker c’est pas ma merde ».
Et c’est ça que le libre n’arrive pas du tout à adresser. Pire, cf la discussion ici, il NE VEUT PAS le faire.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par GG (site web personnel) . Évalué à 6 (+4/-0).
Cool, il y a d'autres solutions.
Tchap, par exemple, mais je sens que tu vas dire que non.
Bon alors quoi… Teams?
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 0 (+0/-1).
Il me semble que ça a été corrigé depuis, mais Tchap avait été livré sans aucune réflexion en amont… 1h15 après sa publication, il était déjà pété : https://www.lepoint.fr/high-tech-internet/tchap-il-m-a-suffi-de-1-h-15-pour-trouver-la-faille-de-securite-06-05-2019-2311048_47.php
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par GG (site web personnel) . Évalué à 5 (+3/-0).
Ce n'étais pas une erreur dans Matrix (utilisé pour Tchap), mais dans l'implémentation des restrictions d'inscriptions.
Et, je ne vois pas pourquoi tu prétends que c'est sans réflexion en amont. Ils ont pensés à des tas de trucs, et c'est plutôt bien que ce problème soit apparu rapidement.
Alors oui cela a été corrigé rapidement. Ce n'est pas une raison pour tout rejeter.
Beaucoup de projets d'envergure ont eu un soucis causé par une bourde au début de leur vie. Propriétaire ou pas. Ça n'a rien à voir avec la licence.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 8 (+5/-0).
Ce n'est pas le but d'une licence libre respectant les 4 libertés d'exécuter le code, l'étudier, en distribuer des copies et des versions modifiées non.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+0/-2).
Si ça n'a aucun but et qu'au final en plus ici-même on me répond « de toute façon t'as pas besoin du source », faut qu'on m'explique encore une fois l'intérêt…
Je pourrais aussi signaler qu'un code source dispo sur github n'est du coup pas acccessible. Cette plate-forme est illégale en Europe et donc je ne peux ni voir le source ni contribuer.
Utiliser github viole manifestement au moins une des 4 libertés.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 6 (+4/-0).
Du livrable .deb de la version Desktop.
Pas de tous les livrables.
Ceux sur f-droid sont signés par exemple.
Faux.
Mais s'il est nécessaire de faire un miroir des dépôts github en Europe pour respecter le RGPD, alors dis-toi que c'est déjà fait.
Tu as besoin de l'URL github pour retrouver ton projet.
Ce n'est pas mis en avant sur la page de Delta-Chat, mais une personne qui compilerait le logiciel serait au delà de l'utilisateur basique et donc on peut compter sur sa capacité à faire une recherche sur software héritage, et le quelifier d'accès simple.
L'utilisateur lambda ayant besoin d'un binaire déjà préparé, il n'a pas besoin des sources, il n'a pas besoin de github.
Si c'est pour un audit de code, tu es suffisamment compétent pour pouvoir considérer que l'utilisation d'un VPN (ou de TOR) ou d'un miroir est une solution simple d'accès aux sources.
Simple au sens ou c'est même trivialement automatisable.
Ouais. Bon. Le proprio te dit « oui, oui, je suis conforme. » en mentant effrontément, mais ce mensonge n'est pas un crime alors osef ?
Toujours pas…
Le fait d'utiliser un hébergement mail pété ne bousille pas le modèle sécuritaire de Delta-Chat, et le chiffrement de bout en bout.
Puisque le serveur mail pété n'aurait accès qu'à des mails chiffrés à l'état de l'art.
Tu peux le trouer comme tu veux le serveur mail, récurer toutes les données, il va falloir casser PGP avant de lire les contenus.
Et le projet Delta-Chat, les services (forum) et le site web, les développeurs, etc, n'ont aucun contact avec ton utilisation du logiciel une fois installé.
Et on a vu qu'il y a des moyens d'obtenir le logiciel de façon signée.
En fait, je suppose même que sous un Debian-like, l'apt-get install deltachat ne va pas prendre le .deb officiel s'il existe, et te fournir un paquet, signé par Debian.
Ou Ubuntu.
Ou Redhat, ou Fedora, ou Suse, ou etc.
Je pense que les gens qui installent directement depuis le .deb fourni ne sont pas si nombreux, ce n'est pas le moyen d'accès privilégié pour ce genre de logiciel : c'est le gestionnaire de paquet de ta distrib.
Donc majoritairement il doit être bien plus facile d'obtenir un binaire signé que l'inverse.
Après à voir quelle confiance tu accordes à l'entité signante, mais c'est un autre problème.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 0 (+0/-1).
La procédure donnée par delta-chat ne vérifie rien en pratique. Donc les devs eux-même ne savent même pas comment permettre la vérification. Sauf en se reposant sur f-droid (ils ont signé un DPA avec F-Droid comme sous-traitant/co-responsable de traitement d’ailleurs ?)
On ne parle pas de compiler le logiciel mais de faire l’audit bi-annuel obligatoire pour tout usage d’un logiciel tiers pour vérifier sa compliance norme ANSSI et supply chain.
Une asso ou entreprise ou particulier non soumis à 2(2)c (avocat, médecin, usage pro quelconque mélangé à son usage perso dans sa boîte mail…) ne peut pas juste prendre un binaire random sur le net. C’est juste ça que tu ne comprends pas du tout.
Ce n’est mentionné nul part dans la doc de delta-chat. Encore une fois c’est une faute de conformité RGPD. delta-chat ne devrait LÉGALEMENT PAS fournit de moyen d’installation non sécurisé et vérifiée.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0).
À priori tu ne sais pas ce que fais delta-chat.
Delta Chat n'est pas un service qui stocke les données utilisateurs. C'est une messagerie privé instantanée via l'email.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+0/-2).
Et donc un responsable de traitement ou un sous-traitant au sens du RGPD. Merci.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 0 (+0/-1).
Je t'invite à lire le RGPD et la définition de traitement de données. Le simple affichage d'une DCP à l'écran est un traitement. Qui a décidé de comment, dont du moyen, afficher les données à l'écran ? Delta-chat.
Définition de responsable de traitement du RGPD ? Entité qui décide les moyens ou finalités d'un traitement.
Delta-chat est responsable de traitement. Delta-chat doit respecter le RGPD.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 8 (+5/-0). Dernière modification le 21 février 2024 à 10:01.
Delta-chat ne traite aucune donnée, c'est un client mail, pas une plateforme en ligne.
Curl ou telnet n'ont pas à respecter la RGPD, Delta-chat c'est pareil.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+0/-2).
Curl et telnet ont à respecter le RGPD. Ou dit autrement, s’ils n’implémentent pas le minimum viable pour être utilisé légalement en Europe, ils n’ont juste aucun sens.
curl ou telnet ne se mettraient pas à jour en terme de sécurité/fix de CVE ou autres, ils ne seraient juste tout simplement plus utilisables en Europe légalement parlant. Et si un utilisateur s’en sert et se fait trouer, ils seraient AUSSI responsables (quoi qu’indique leur licence).
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par devnewton 🍺 (site web personnel) . Évalué à 8 (+5/-0).
J'ai l'impression que tu penses que le RGPD s'applique aux produits.
Est-ce que le fabricant du miroir dans lequel tu te regardes le matin (qui gère ton reflet, donc ton image, donc une donnée personnelle) est concerné par le RGPD ? Si oui, le constructeur du mur sur lequel il est accroché est-il son co traitant ?
Est-ce que tu as demandé la fiche de traitement au vendeur de brosse à dent, au fabricant de dentifrice et au constructeur de robinetterie avant d'acheter ta maison (tout ça va être en contact avec ton ADN lors de ta toilette) ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Faya . Évalué à 8 (+6/-0). Dernière modification le 21 février 2024 à 16:14.
Attends mais tu es sûr de ce que tu dis là ? Parce que j'ai l'impression que ça signifie tout simplement qu'on n'a plus le droit de fournir de logiciel. Aucun, jamais. Puisque tous les logiciels sont troués ou trouables. Imaginons que je sois un étudiant qui veut coder un webmail. Je fais un truc bien crade en PHP rempli de XSS, je mets ça sur ma forge perso et je poste le lien sur LinuxFR en disant "j'ai fait un joli Webmail, un peu crade mais venez le télécharger pour le tester sur vos serveurs." (Et je ne parle pas de licence, c'est vraiment orthogonal là)
Je suis responsable de traitement ? LinuxFr est co-responsable parce qu'il héberge le lien ?
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+1/-3).
Si tu déploies un tel logiciel tu dois effectivement dire que ce n'est qu'un poc, qu'il n'est pas utilisable en l'état et n'est pas habilité à traiter de la donnée perso.
Effectivement. Tu ne peux à aucun moment dire qu'il est utilisable et toute personne est supposée le savoir (le RGPD s'applique aussi aux particuliers, surtout pour une boîte mail généralement mélangeant pro et perso.
Tout logiciel livré doit de toute façon faire l'objet d'un DPA avec l'entité utilisatrice, ne serait-ce que pour garantir les maj, les alertes de sécu, les 36h légaux de notification en cas de faille, et toutes les autres exigences de l'article 28 qui doivent être contractualisées.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Faya . Évalué à 9 (+7/-0). Dernière modification le 21 février 2024 à 23:04.
On connaissait les copyright/patent troll, je crois qu'on assiste à la naissance des RGPD trolls là. C'est à dire empêcher les gens de produire du code en utilisant des principes juridiquement corrects (si tant est que tout ça soit vrai, je ne saurais en juger) mais inapplicables à moins d'être une grosse boîte avec une team de juristes dédiés. Plus possible de coder le moindre soft sans avoir un D.U.T Carrières Juridiques. La mort du DIY, de l'autodidacte, du release early release often, … (quelque soit la licence, toujours.) On dirait un roman dystopique.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -3 (+0/-4).
Il y a énormément de métier que tu ne peux pas faire à la maison sur ton temps libre malgré que ça soit techniquement possible, sauf à passer des certifications préalables et des tets de compétences avant de pouvoir être autonomes.
Pourquoi encore une fois le libre ou le logiciel en général devrait magiquement ne pas faire éventuellement comme les autres ?
Oui développer est un métier qui ne nécessite pas que des compétences techniques mais aussi des compétences légales ou autre.
On ne t’autorise pas à faire de la chirurgie cardiaque dans ton salon.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Faya . Évalué à 4 (+2/-0). Dernière modification le 23 février 2024 à 20:41.
Sérieusement, c'est le meilleur exemple que tu as trouvé pour illustrer ton point de vue ? Comparaison n'est pas raison. Je ne peux peut-être pas faire de chirurgie (pratiquer la médecine) mais je peux tout à fait construire un scalpel, une lampe de bloc opératoire, un lit électrique et même l'ordinateur qui piloterait tout ça. J'en ai le droit et même dans mon salon. J'ai aussi le droit de les refiler à mon pote pour qu'il joue avec à opérer ses peluches si il le souhaite et là c'est lui qui devra veiller à ne pas l'essayer sur son voisin. Comme dit plus haut (ou plus bas je sais plus) tu sembles vouloir appliquer le RGPD aux outils et je ne suis pas certain que ça soit juste. Vu que tu veux ramener au libre alors que la licence est sans rapport, Linux n'aurait jamais pu être testé en Europe avec cette vision extrême. "Développer est un métier" mais c'est aussi, souvent, un hobby. Passe-temps de hackers qui aiment jouer avec des machines et du code.
«Hello everybody out there using minix - I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones»
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -2 (+1/-4).
Mais tu dois alors annoncer partout que ce truc n’est qu’un jouet, pas qualifié pour de vraies opérations, sans aucune certification médicale et que ce n’est pas utilisable en production, avec tous les warning obligatoires sur le sujet (comme par exemple la mention « ce produit n’est pas un dispositif médical »).
D’autant plus quand tu présentes ça comme la future révolution de ton domaine, que tu as fondé une boîte pour concevoir, développer et opérer ça et que tu en maintiens 2 instances en production pour de vrai.
Mastodon est l’équivalent de Sorin qui lancerait un nouveau pacemaker avec 0 certification, où il manque des gros bouts ne serait-ce que pour pouvoir envisager de lancer la certification, en ferait la promotion sur l’ensemble de ses sites internet et en aurait déjà implantés 2-3 en vrai sur des vrais patients et en maintiendrait même la liste officielle d’implantation réussie en dehors de tout process légal. Et sans jamais dire officiellement ni même officieusement ni même rien du tout « Mais surtout faites pas ça les gens ! » à ces hôpitaux qui se mettent à communiquer d’avoir aussi implanter des patients avec cette merde.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 6 (+3/-0).
Il semble que cela tourne en boucle et que cette discussion fleuve n'aboutit à rien, je réitère cette demande faite plus haut et qui concerne tout le monde, à savoir s'en tenir là pour cette discussion qui peut dériver à tout moment.
Merci d'avance.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Faya . Évalué à 2 (+0/-0). Dernière modification le 26 février 2024 à 13:52.
Certes.
Là par contre je ne comprends pas. Bon peut-être que tu fais référence à d'autres fils sur la même page mais ici ni Aeris ni moi n'avons été agressifs ou irrespectueux. OK on déblatère sans fin mais est-ce que ça contrevient aux règles du site ? Je repose ma question précédente, sachant que pour moi LinuxFR est un lieu où j'aime lire des discussions fleuves et intervenir inutilement moi-même, est-ce que la modération nous demande d'économiser les modos ? (vraie question parce que j'avais d'autres choses à demander à Aeris suite à son dernier message… Je peux bien sûr le faire ailleurs (sur Mastodon puisqu'il y est lol) mais je trouve ça bizarre et inquiétant qu'on nous demande d'arrêter de parler sans qu'on ait eu un mot plus haut que l'autre)
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 8 (+5/-0).
Tu as perdu toute crédibilité mais bon.
Article 2 de la RGPD:
_1. Le présent règlement s'applique au traitement de données à caractère personnel, automatisé en tout ou en partie, ainsi qu'au traitement non automatisé de données à caractère personnel contenues ou appelées à figurer dans un fichier.
_
Curl, telnet ou deltachat ne font pas partie d'un système de traitement de données à caractère personel appelées à figurer dans un fichier.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par shbrol . Évalué à 1 (+0/-0).
Il a été affirmé plus haut, je cite : Établir une connexion TCP/IP, même chiffrée, reste une transmission de DCP (l’adresse IP de l’utilisateur) et est donc en soit un traitement de données soumis au RGPD
Comme je suis incompétent sur le sujet, j'en déduis que curl, telnet, et bash aussi, sont soumis au RGPD.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -2 (+0/-3). Dernière modification le 21 février 2024 à 19:35.
C'ert surtout que c'est marqué « ainsi que » dans le texte cité…
C'est tout traitement auto de DCP ou tout traitement non auto d'un fichier de DCP. Fichier étant au sens général (un post-it est un fichier).
Curl et cie c'est le 1.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+0/-2).
Et donc si curl et cie sont prévus pour être dans un environnement sans DCP, c'est hors RGPD, mais si ça traite (et la simple transmission est un traitement), alors curl doit répondre aux exigences du RGPD, sécurité, supply chain, DPA, gestion de l'obsolescence par une entité compétente, audit…
Et donc si curl livre des trucs pas patchés ou incompatible, il s'exclut possiblement de lui même de tout appel d'offre type HdH oui.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -3 (+0/-4). Dernière modification le 21 février 2024 à 19:40.
Et à la limite peu importe de la responsabilité juridique ou pas de curl : livrer un soft pas conforme RGPD pour toute entité utilisatrice soumise au RGPD, ça serait… con.
Comme Mastodon qui dev un soft en pratique inutilisable en Europe… 🤔
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+0/-2).
Et j'ai aucun problème à ce que curl dise « je m'en fous du RGPD «. Tu m'excuseras simplement de ne pas pleurer s'il ne remporte pas d.appel d'offre, et de ne plus l'utiliser moi-même.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par GG (site web personnel) . Évalué à 3 (+1/-0).
Une grande difficulté, dans le Droit, c'est l'interprétation.
Comme je disais souvent à une amie Avocate : Il y a le Français, et le Français juridique.
Parce que évidement, en terme d'interprétation j'étais souvent à côté.
Hé oui, c'est deux langues différente.
Même s'il y a un effort pour rendre le Droit plus accessible, par exemple dans la réécriture de certains articles, en "droit constant", c'est à dire mieux compréhensible par le commun des mortels mais sans changer le sens juridique.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 6 (+4/-0).
Mais tu n'expliques rien, tu ne prouves rien, tu prends des exemples, et tu en fais une généralité abusive et intrinsèque à tout les logiciels libres.
En plus tu te fais chier avec la version desktop de DeltaChat dont j'ignorais l'existence (et qui semble bien pourrave), quand je te parle de l'appli, pour smartphone, qui n'a pas de react, pas de node, pas d'electron, pas de ces trucs là !
Tu veux auditer les sources sans passer par github ?
Bah vas les chercher là :
https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://github.com/deltachat/deltachat-android
Il te manque un commit, 1 !
Voilà, t'es en Europe, t'es même en France à l'INRIA !
Tu peux le faire ton audit de code sans approcher de Github.
Et tu mélanges tout en plus, tu mélanges l'accès à un service mail qui utiliserait une crypto obsolète avec le chiffrement des messages géré en interne par Delta Chat.
Ici Delta Chat te permet de te connecter avec un service mail potentiellement obsolète et troué, et de malgré tout l'utiliser avec du chiffrement de bout en bout des messages, qui resteront illisibles sur le serveur mail pété que tu peux quand même utiliser. Et vlan, tu les accuses de ne rien y connaître en sécurité…
Tu mélanges tout, tu fais semblant de ne rien comprendre…
Parce que à ce jeu là, il n'existe pas de client mail qui respecte tes règles. Zéro, aucun, nulle part.
Donc soit tes règles sont pétées, soit ton interprétation est pétée.
Et en pratique tu traduits ça par : les MAGAF me mentent oui en souriant et je préfère ça au dev libriste qui me dit honnêtement non.
T'as une vision hyper biaisée, tu es convaincu qu'au delà des MAGAF point de salut, ils sont la moins pire des solutions, et les autres c'est tous des cons qui en plus t'emmerdent au quotidien.
Et quand ce sont les MAGAF qui enfreignent les règles, bah on glisse sous le tapis parce que bon, z'ont pas le choix et cette règle là osef.
Mais quand ce sont des libristes, ce sont des enflures qui font rien qu'à t'embêter.
Ça ne peut pas être vrai.
Stop.
Déconnecte.
Respire.
Impose des limites à ton pessimisme défaitiste, parce qu'il ne sert à rien.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -3 (+0/-4).
Donc en fait t'es en train de m'expliquer que le libre c'est bien parce qu'une asso a mirroré un github dans un coin pour avoir accès aux sources sans violer la loi ??
Tu sais que tu ne fais que confirmer ce que je dis dans mon blog hein ?
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 0 (+0/-1).
Et dans tous les cas, je rigole quand même quand j'entend dire que je dis que sans GAFAM point de salut (ce que je n'ai jamais dit) quand tu me files en exemple un soft libre qui tourne sous Chrome avec le source chez Microsoft hein… (C'est bizarre comme Github et Electron sont partout…)
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 8 (+5/-0).
En l'occurence electron ce n'est pas un produit gafam. C'est développé par l'openjs fondation et ça utilise effectivement des briques développés par google, mais bon à ce jeu là on peut dire qu'utiliser linux c'est utiliser et promouvoir les Gafam parce qu'on a accepté du code de leurs développeurs.
Github n'est pas non plus un prérequis pour faire du logiciel libre et j'encourage tout développeur libre à utiliser autre chose. Mais je comprends en même temps l'attrait pour certains à cause de l'effet de réseau.
Et je dis ça alors que j'abhorre electron et les applications basées dessus.
Maintenant j'ai l'impression que t'es parti dans une spirale de whataboutism qui n'est ni saine pour ton esprit, ni pour la discussion.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 6 (+3/-0).
Github et le libre, ce sont deux choses différentes qui n'ont rien à voir. Tous les logiciels libres ne sont pas distribués via github et github ne distribue pas que des logiciels libres.
Tu t'emmelles les pinceaux.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+0/-2).
Sauf que quand on vient m’expliquer qu’on peut faire sans Github mais que 90% (chiffre au pif mais certainement proche de la réalité) des projets libres sont sous Github et exclusivement sous Github, je rigole.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 8 (+5/-0).
Ben justement, il y a une dépêche en préparation sur Codeberg tu pourrais y ajouter ton grain de sel.
Merci d'avance.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 5 (+3/-0).
Non.
TU dis qu'il n'est pas possible d'accéder aux sources, et donc de les auditer sans violer Schrems II.
C'est factuellement faux dès aujourd'hui.
Et si pour respecter Schrems II, le RGPD etc, il faudrait un miroir institutionnel des sources libres en provenance de github, en Europe et sans avoir à passer par Github.
Ce qui est légalement possible au vu des licences des logiciels considérés, d'où ici on parle de libre, parce qu'en dehors du libre, il faut analyser au cas par cas et en général c'est impossible.
Et bien il faut le faire plutôt que de dire que c'est impossible !
Et…
Et bien en fait ça existe déjà.
L'INRIA n'est pas une association.
Encore une fois, tu es convaincu de ce que tu racontes, et quand on t'expliques factuellement que tu te trompes, tu t'en fous.
Je ne sais pas quelle est ton excuse, mais tu as un problème avec les faits, règle-le.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 10 (+7/-0).
Je pense qu'on peut s'en tenir là, si ça ne vous dérange pas étant donné que ça commence à tourner en boucle. On ne va pas tarder à en venir aux noms d'oiseaux et personne ne veut ça.
Merci d'avance.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 4 (+2/-0).
Ok, je cesse de poster.
Désolé Ysabeau.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 0 (+1/-2).
Ce n’est encore une fois pas de la responsabilité des utilisateurs que de faire le taff de mise en conformité qui aurait du être fait par le (au mieux) sous-traitant au sens du RGPD.
Sachant que pour mettre en place un mirroir, il faudrait toujours que celui qui le mette en place soit responsable de traitement avec github en sous-traitant, et que ben t’as toujours pas réglé le problème.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+1/-3).
Et pourquoi est-ce que ça serait à moi d’installer Tor, de trouver Software Archive, ou de faire un mirroir de Github, quand ça pourrait être juste delta-chat qui n’utiliserait tout simplement pas Github tout court ?
Surtout quand on prétend ici-même qu’on sait faire sans les GAFAM hein !
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par devnewton 🍺 (site web personnel) . Évalué à 9 (+6/-0).
Bref tu trouves que les gafams sont les meilleurs pour résoudre les problèmes qu'ils ont créé ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 1 (+2/-2). Dernière modification le 20 février 2024 à 18:09.
Non, mais que les avantages supposés du libre n’en sont plus vraiment en 2024 voire sont même des problèmes EN PLUS à gérer…
Je ne dis pas que le libre ne peut pas faire correctement les choses, je dis juste qu’aujourd’hui l’argument du libre est beaucoup trop utilisé pour se justifier de ne pas respecter la loi…
Et que par exemple si techniquement la fédération est plus intéressante, couplée à la législation en vigueur (et pour de bonnes raisons), elle n’est pas forcément la plus souhaitable une fois qu’on fait le compromis avec le côté juridique, sauf à aller dans des modèles ultra-décentralisés et de la fédération d’instances de 1-2 personnes maximum, ce qui apporte alors tout un tas d’autres problèmes humains (capacité à s’auto-héberger & cie) aussi à prendre en compte.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+3/-0).
Je ne vois pas trop le rapport avec le logiciel libre, la fédération et la légalité :-)
On peut avoir toutes les combinaisons libre / privateur, fédéré / fermé, légal / pas légal :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 4 (+3/-1).
Des généralités et des amalgames, basés sur un exemple central à son discours, celui de Mastodon.
Qui n'a aucun rapport avec le fait qu'on pourrait avoir le HDH hébergé en France ou en Europe, basé sur des logiciels libres - existants - et qui respecterait parfaitement les normes ; ce que ne font pas les services cloud américains.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 0 (+1/-2).
Ce n’est pas un seul exemple, vu que j’ai aussi parlé du HDH dans mon article et du play integrity framework.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 1 (+1/-1).
Et j’espère bien pouvoir en parler ici un jour, pour le moment légalement parlant c’est compliqué, mais j’ai quelques autres exemples de projets libres qui ont assez mal tournés justement en se justifiant qu’ils l’étaient, de libre…
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 3 (+2/-1).
Oui, mais justement, au sujet du HDH, tu passes allègrement sur les règles bafouées par les MAGAF pour dire que les services européens ne sont pas viables parce qu'ils en bafouent d'autres…
C'est trop demander d'avoir un minimum de cohérence ?
Soit ça viole, soit ça viole pas.
Si tout le monde viole, comment prétendre que c'est mieux côté MAGAF puisque personne ne répond au cahier des charges, et qu'en plus il y a au moins une règle qui ne peut pas être validée par eux ?
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 0 (+0/-1). Dernière modification le 21 février 2024 à 09:41.
Et c'est exactement ce que je dis dans mon blog.
Quitte à comparrer 2 trucs illégaux, je compare ce qui est plus ou moins conforme et je prend le moins pire. Et c'est pas forcément le libre.
Merci de la démo.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+0/-2).
Et dans le cas de delta-chat, je ne peux même pas télécharger le soft, j'ai pas les signatures ! Donc je ne vais pas plus loin en fait. Ça n'ira jamais sur mon PC. Encore moins si je suis une boîte/asso (violation RGPD instantanée, défait de suply chain).
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 3 (+1/-0).
T'es d'une mauvaise foi délirante.
Comment tu fais pour installer deltachat sans signature, tu m'expliques ?
Je ne sais pas ce que tu essaies d'installer, et quel moyen tu mets en œuvre pour ne pas avoir un paquet signé à installer sur ta machine !
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -2 (+0/-3).
Ben j’ai juste pas de paquet signé hein…
Celui présenté sur le site de delta-chat ne possède aucune signature GPG ou même de checksum. Que ça soit pour le .deb, le app image, les sources ou n’importe quoi sur le site. Le seul truc éventuellement signé est l’APK android.
Tout le reste est livré sans aucune signature.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -2 (+0/-3).
Et encore, la commande filée pour vérifier l’archive est invalide
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+1/-3). Dernière modification le 21 février 2024 à 14:10.
Et la procédure de vérification est inefficace. Ça ne fait qu’afficher le certificat de signature sans procéder réellement à la vérification.
C’est apksigner qu’il faut utiliser et pas keytool. Pour des gus supposés faire de la crypto, ça fait peur…
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 0 (+1/-2).
Donc en gros on a des gus suffisamment crétin pour rédiger une procédure de vérification d’un APK sans même s’être posé la question de si c’était bien une vérification de signature et pas juste lister un des certificats dispo dans l’APK.
Là comme ça il est assez facile de refaire un APK verrolé qui vérifie exactement la procédure que delta-chat indique, il suffit d’inclure le certificat de fdroid sur un APK signé par un autre certificat.
La procédure de vérification donnée ne vérifiant que la présence du certificat et non la validité de la signature, ça passerait crème pour tous les utilisateurs qui suivraient la procédure officielle de delta-chat…
Et ces gens envisagent de développer un soft basé sur la crypto… 🙄
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+0/-2).
D’ailleurs y’a même encore plus simple pour le prouver…
YOLO
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+0/-2).
Alors que bon, avec apksigner
Mais du coup je suppose que c’est encore à moi d’aller faire l’effort de leur expliquer la crypto ? 🙄
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -3 (+1/-5).
Donc pour résumer avant d’utiliser delta-chat :
J’ai pas encore testé, mais je suppose que va aussi :
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+2/-4).
À ceux qui répondrait que je peux récupérer le code sur le site de delta-chat : l’archive n’est pas signée.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 1 (+2/-2).
Ben comme dit, du coup tu te retrouves avec 2 trucs qui violent la loi.
Si le libre ne l’avait pas violer, j’aurais pu éventuellement dire que je m’en foutais des fonctionnalités différentes entre A (conforme) et B (pas conforme), j’ai que A comme choix viable et donc on s’arrête-là, c’est A qui gagne. Pas parce que c’est libre, mais parce que c’est conforme. Et je m’en cogne que ça soit libre du coup, ça ne m’apporte rien de plus : si c’est A qui est conforme et proprio et que B est non conforme mais libre, je ne PEUX PAS choisir B quelque soit ses avantages autres.
Et quand j’ai A (libre et pas conforme) et B (proprio et pas conforme), avant d’aller me battre pour les éventuelles fonctionnalités, je vais devoir d’abord sélectionner celui qui viole le moins la loi… Et c’est pas forcément A…
Si je dois violer 1 seule fois Schrems II en allant que chez Microsoft, ça sera toujours mieux que de le violer 4× via Google, Microsoft, AWS et Cloudflare.
Si je viole Schrems II en allant chez Microsoft, j’évite aussi de violer encore plus la loi avec une absence de SIEM/IAM/firewall/cloisonnement/interface privée d’admin en plus. 1 violation côté MS, 5 côté pas MS.
Etc.
Et que quitte à devoir dépendre de Microsoft pour Github, de Google pour Electron, de AWS pour npm.js et de Cloudflare pour crate.io, j’irais dépendre uniquement de Microsoft tout court, avec un vrai contrat formalisé et pas des « non mais t’as qu’à faire toi-même et de toute façon NO WARRANTY qu’on a dit ».
Et actuellement, on n’a PAS de solutions libres qui passent le 1er pré-filtre de la conformité. Donc on ne peut même pas commencer à parler de ce qui vient derrière, on en est juste au stade juridique et on fait le choix du moins pire au niveau légal. Pas technique. Pas éthique. Pas morale. Légal.
Et c’est là que vous déformez mes propos. Je n’ai jamais dis qu’on ne pouvait pas faire sans les GAFAM. On peut le faire. Je développe mes softs sur MA forge git, je release sur MES serveurs, je fournis des signatures sur TOUS mes livrables, même un pov’ article de blog (https://blog.imirhil.fr/2014/04/28/gpgit-chiffrez-courriel-entrant.html#installation, oui c’était en 2014 et y’avait pas encore ni Microsoft ni Schrems II pour Github), je fais gaffe à tenir à jour mes dépendances. Je fais des projets en minimisant mes dépendances.
Je dis juste qu’aujourd’hui la plupart des projets, y compris libres, livre de la merde en barre, du docker only electronisé google à mort pour faire l’équivalent d’un dd (je blague même pas, balena est l’équivalent de DD en interface graphique et pèse 133Mo parce qu’il embarque un navigateur complet, discourse n’est plus livré/supporté hors docker, etc), s’en cogne complètement de la conformité (même quand on veut y participer), tout le monde a foncé sur go qui n’est même plus fonctionnel le jour où github tombe et alors même qu’au début du monde le truc faisait des git-clone-main pour sa gestion de dépendances, etc…
C’est du coup pas qu’on ne peut pas faire sans les GAFAM, c’est que les projets libres font tout pour pousser les utilisateurs à y courir !
Le libre est supposé être le modèle d’exemple mais il n’est même pas capable de faire un truc aussi simple que « héberger sa propre forge logicielle sans dépendre de Microsoft et impose à tout contributeur un compte github chez Microsoft »…
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+1/-3).
Et quand on parle par exemple de Mastodon : https://twitter.com/AlexArchambault/status/1759533906783535532
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 7 (+5/-0).
C'est l'hôpital qui se fout de la charité.
Il y a des gens qui s'embrouillent sur Mastodon, ok.
Et c'est sur Twitter qu'on en parle ?
Le temple de l'ambiance toxique ?
Le supermarché de l'insulte et de l'agression en ligne ?
La boîte de pétri des complotismes ?
Le rendez-vous de la désinformation ?
Le trampoline de la haine en ligne ?
Tu es sérieusement sérieux là ?
J'espère que ce n'était pas pour faire une comparaison hein, par pitié, personne ne peut battre Twitter sur ce terrain là, ce sont les meilleurs, et oui, ils ont une avance irrattrapable de 15 bonnes années de puanteur toxique.
Ça se voit bien mieux depuis le rachat, c'est nettement plus décomplexé, mais l'ambiance agressive, violente, et pourrie, elle était déjà là.
On peut peut-être laisser un peu de temps aux petites instances Mastodon pour se construire ou disparaître, sans jeter l'ensemble du réseau ? Peut-être ?
Ou alors, non, on prend juste Twitter parce qu'ils sont plus « compliant » avec les requêtes RGPD ?
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 0 (+1/-2).
Mon sujet est justement qu’on ne devrait prendre ni l’un ni l’autre.
Et construire un truc autre. Certainement pas se ruer sur Mastodon au motif que c’est libre, décentralisé ou souverain.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+0/-2).
Et on ne parle pas d’un choix à faire entre 2 réseaux légaux avec leurs avantages et leurs défauts, mais bien d’un non choix entre 2 réseaux illicites qui finiront je l’espère, DANS LES DEUX CAS par avoir des comptes à rendre à la justice.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 7 (+5/-0).
Mais…
Choisi ton instance.
Vas voir sur le Chapril, l'instance de l'APRIL, tu vas trouver tout un tas d'infos rapport aux réglementations, au RGPD etc.
Pas dis que tu trouves vraiment des infractions, et certain qu'on te répondra, et sans t'insulter.
C'est comme pour l'email, tu vas avoir des service mal foutus, peu réglementaires, peu soucieux des règles, de la sécurité, des utilisateurs, etc.
Et tu en trouveras d'autres qui sont irréprochables.
Y compris des associatifs.
Et tous peuvent communiquer entre eux.
Est-ce que les mauvais joueurs sont signe qu'il faut jeter la technologie, ou même les logiciels qu'ils utilisent, à la poubelle ?
Si ça se trouve, le logiciel derrière Twitter est très bien et pourrait être utilisé pour faire un super réseau social hyper respectueux, mais il n'y a qu'une seul instance, et elle est complètement pourrie.
Pour Mastodon il y a un univers d'instances, et évidemment tu vas trouver de tout.
Est-ce signe que tout est à jeter dans Mastodon ?
Comment tu arrives à cette conclusion ?
Et tu ne penses pas que les gens qui vont sur Mastodon peuvent aussi le faire parce que ça marche pas si mal ?
Non, c'est forcément un effet de mode, et ils sont tous idiots à ne pas voir plus loin que le bout de leur nez, avec leurs lunettes de libristes ?
Alors que le principe même de la fédération avec Mastodon entre autre, c'est qu'on peut facilement couper les branches pourries.
Regarde sur ton instance, tu devrais voir la liste des instances bloquées car irrespectueuses des règles.
Et tu ne vas pas les subir.
Bien sûr, la méthode a ses limites, mais aucun logiciel n'est parfait, et celui-ci cherche à s'améliorer dans le bon sens.
Et toi, tu suggères de laisser tomber, ne pas chercher à améliorer et repartir à zéro ?
À quoi ça sert à part à laisser le champs libre à Twitter ?
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 1 (+2/-2).
Encore une fois, c’est toi qui dit qu’il faudrait tout jeter.
Moi j’ai juste dit que sur des gros projets d’envergure, on n’avait plus que le choix entre des trucs pas conformes US et des trucs encore plus pas conformes EU, avec en plus en Europe souvent un gros retard au niveau fonctionnalités.
Et donc que rationnellement il faut faire dorénavant un choix, et que juste dire « ah ben oui mais c’est libre/souverain » est juste un mauvais argument pour faire ce choix. Être libre ou souverain ne veut plus RIEN dire (surtout en 2024 hein…) et n’est PAS un argument sinon un totem d’immunité sans aucun intérêt ni technique, ni moral, ni éthique, ni conformité, ni rien.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 1 (+1/-1). Dernière modification le 20 février 2024 à 10:52.
Je répète : sinon les instances auto-hébergées (et encore, en théorie arrêt de la CJUE sur les réseaux sociaux, l’exemption du RGPD au titre du 2(2)c pour usage strictement personnel et domestique n’est pas possible ici), tout le reste est ILLÉGAL en Europe.
Chapril compris !
Et lire aussi ici ce que j’ai du faire pour une de mes assos pour (tenter de) me mettre en conformité : https://wiki.asso-purr.eu.org/registre#firefish
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Glandos . Évalué à 7 (+5/-0).
Side note : c'est possible d'intégrer le contenu du tweet en citation ?
Je n'y ai plus accès, Nitter ne marche plus à cause de l'expiration des comptes clients temporaires, et Twitter demande un compte pour accéder à n'importe quel tweet.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 3 (+2/-0).
Tweet de Alexandre Archambault, avocat numérique français :
Et une des réponses :
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
Pour moi la modération sur Mastodon est un réel problème, en particulier parce qu’elle est conceptuellement cassée (j’en ai déjà parlé sur ce site), mais c’est d’abord et avant tout un problème de relations humaines, pas un problème légal.
D’autre part, après quelques mois de stabilisation, mon compte Twitter/X est maintenant quasiment vide. Des comptes que je suivais sur cette plate-forme, j’en retrouve à la louche 30 % sur Instagram, 10 % sur Mastodon (dont les problèmes intrinsèques ont fait fuir pas mal de non-geeks sur le moyen terme), 50 % sur Bluesky, et les 10 % restants continuent à être exclusifs à Twitter/X. Bon, j’imagine que tout ça dépend beaucoup du type de comptes que tu suis, et personnellement j’avais déjà exclus les personnes actives hors réseaux sociaux (site web, RSS, etc).
Mais dire que « tout se passe sur X » en 2024 c’est quand même se mettre de sacrées œillères, ou avoir des catégories suivies très particulières (j’imagine que c’est le cas quand tu es fan de cryptomonnaies, par exemple).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 2 (+1/-0).
Alors elle est aussi un problème légal pour le coup.
Mastodon avait déjà un problème de légalité avec à cause du comportement d’Eugen (qui fait que de facto le DSA s’appliquerait à lui en tant que gate-keeper, cf article de Contexte), mais que ça va être encore pire à partir du 1er mars où il entre aussi en vigueur pour tout le monde et plus exclusivement pour les GK.
Le simple fait qu’il n’existe aucune procédure propre, correcte et neutre d’appel en cas de blocage fait que Mastodon va devenir encore plus illicite à partir du 1er mars.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par GG (site web personnel) . Évalué à 5 (+3/-0).
Est ce qu'il est question du blocage d'une instance par les administrateurs d'une instance, ou bien le blocage fait par un utilisateur vis à vis d'une instance ou d'un autre utilisateur?
Personnellement, je ne vois pas en quoi je quoi je devrais permettre une procédure d'appel dans ces deux cas. <- S'il te plait, je voudrai ton avis.
C'est comme pour les emails, je décide unilatéralement de bloquer des serveurs, des IP, des ranges, des domaines. C'est mon choix. Et si mes utilisateurs appliquent des filtres, pourquoi pas (parce que je n'ai pas implémenté la possibilité que mes utilisateurs puissent bloquer en amont).
Sur des serveurs Mastodon, certains ont décidé de bloquer Thread. Et, il faudrait que Meta (Thread) puisse faire appel? La bonne blague.
Microsoft bloque parfois (c'est variable dans le temps), les emails provenant d'IP domiciliaires, et il n'y a rien pour faire appel (j'ai cherché longtemps, je n'ai pas trouvé).
Je ne comprends pas cette obligation d'avoir une procédure d'appel, d'autant plus qu'il n'y en a pas chez les Gafam non plus, et que quand bien même un utilisateur/client arriverait à joindre le support, celui-ci ne peut rien faire. Alors que les admins de Mastodon, des Chatons et de plein d'autres services sont quand même joignables et que tout est négociable, mais libre aux admins de répondre.
(je fais allusion aux cas de pertes de données par blocage des comptes chez Google sur une simple erreur judiciaire ou après un blocage par un mécanisme automatique)
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 2 (+1/-0).
Alors non justement, c’est pas ton choix : https://www.freenews.fr/freenews-edition-nationale-299/services-web-180/anti-spam-justice-confirme-condamnation-de-free-blocage-excessif
Actuellement peu de procédures sont lancés là-dessus, mais non, les antispams, en tout cas ceux rejettant le trafic, sont juste en théorie interdits, chaque utilisateur est supposé avoir le droit de décider de lui-même du contenu qui atteint ou non, sa boîte de réception.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par GG (site web personnel) . Évalué à 4 (+2/-0).
Voilà pourquoi gmail efface silencieusement certains emails reçus… les emails ne sont pas bloqués ni renvoyés, ils sont acceptés (code OK 250) puis éventuellement effacés sans notifications.
Du coup, Microsoft qui bloque les emails provenant de serveurs sur des IP domiciliaires c'est illégal? (Oui, je peux aussi créer un petit tunnel vers un VPS dans un DC juste pour les cas un peu récalcitrants, quand le besoin se fera sentir)
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 3 (+2/-0).
Oui, en théorie tu peux les poursuivre en justice. (C’est long, chiant et pénible et c’est pour ça que c’est rare…)
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 2 (+1/-0).
C’est une obligation du DSA qui s’applique à toutes les plateformes en ligne depuis le 17 février, en particulier pour tout système de réseau social : https://www.vie-publique.fr/eclairage/285115-dsa-le-reglement-sur-les-services-numeriques-ou-digital-services-act
Il faut que je retrouve d’ailleurs vu qu’on a parlé de moralité un peu plus bas ici aussi la convention de modération rédigée par l’ACLU et l’EFF et qui est supposé représenter une bonne vision de la moralité. Spoiler : l’obligation d’appel fait parti des exigences pour un respect de la démocratie.
Ne pas permettre une procédure d’appel (neutre, impartiale, etc) est donc non seulement illégal mais aussi immoral.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Ce qui est dommage concernant le DSA, c’est qu’il est très facile de trouver que :
Par contre, personne n’a l’air motivé pour mettre en accès simple lesdites règles pour les petites plateformes, en tous cas pas depuis les pages officielles qui parlent du DSA.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 2 (+1/-0).
« Très petite plateforme » ne s’applique de toute façon pas à Mastodon, que ça soit à titre individuelle pour les instances de plusieurs milliers de personnes, ou de toute façon à titre collectif, la décentralisation n’étant pas décomptée comme des entités séparées mais comme des entités communes (cf article Contexte).
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Sauf que je ne m’intéresse pas que à Mastodon.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 3 (+2/-0).
Pour le texte exact, c’est ici : https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32022R2065
Les points importants soulevés :
Considérant 58
Et article 14
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 2 (+1/-0). Dernière modification le 20 février 2024 à 13:46.
Et pour les exemptions, c’est seulement les « très petites entreprises » donc moins de 10 personnes « occupées » (avec la vraie problématique ici de la contribution aux sources en particulier en faveur de l’entreprise majoritaire dans le réseau et l’usage de bénévoles pour la modération) et moins de 2 millions de CA. Le tout sans devoir être gate-keeper donc pour une plateforme sous les 45 millions d’utilisateur actifs par mois ou en situation de distorsion de marché (ce que peut être doublement Mastodon).
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à 2 (+1/-0).
D’ailleurs soit dit en passant, c’est là qu’on voit que la Commission EU a pensé à prendre en compte la décentralisation/fédération/libre et cie. C’est a priori volontaire d’avoir parlé de « personnes occupées » et non de « personnes employées ». Tes modos bénévoles ou tes contributeurs au code comptent dedans…
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Erwhann . Évalué à 4 (+3/-0).
Nul n’est censé ignorer la loi… mon c*l ouais, c’est un enfer à lire ces textes.
Bref, pour le DSA, il :
https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=uriserv%3AOJ.L_.2022.277.01.0001.01.FRA&toc=OJ%3AL%3A2022%3A277%3ATOC#d1e40-1-1, paragraphe 57
Ce qui du coup correspond à :
https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32003H0361
Ça ne doit pas s’appliquer à beaucoup d’instances ça.
Et surtout il y a la notion de portée que je trouve intéressante, (mais qui ne semble concerner que les très grands entreprises) fixée à :
Mais 45 millions de quoi ? Bah manifestement de « destinataires actifs », c’est à dire de personnes ayant volontairement utilisé le service (on ne compte pas les inscrits inactifs donc) dans les 6 derniers mois. Là c’est assez flou…
DSA, paragraphe 76 & 77
Donc :
– Est-ce que je suis un utilisateur actif de l’instance ou je suis inscrit ? (qui ne doit clairement pas compter + de 45 millions de « destinataires actifs » et est probablement gérée par 1 à 5 personnes)
– Est-ce que je suis un utilisateur de Mastodon ? (ce qui n’a pas vraiment de sens étant fédéré à d’autres services comme PeerTube, Firefish, etc… de toutes façons, Mastodon n’a a priori même pas 7 millions d’utilisateurs)
– Est-ce que je suis un utilisateur d’ActivityPub ? (Je doute quand même qu’on approche des 45 millions)
Du coup, juste pour le DSA, les instances Mastodon doivent pouvoir échapper à la majorité des dispositions, non ?
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -1 (+1/-3).
Et c’est là que « ça dépend ». Si le réseau est considéré comme une entité commune (ce que semble dire la Commission Européenne, à cause en particulier du comportement d’Eugen, et aussi pour éviter d’offrir un boulevard juridique aux GAFAM via de la fédération) ou pas (assez improbable vu la position des personnes interrogées côté Commission).
Et tu remarqueras aussi que c’est justement marqué « occupe » et non « emploi », et que c’est « 50 personnes ET moins de 10 millions » et non pas « 50 personnes OU moins de 10 millions ».
Il y a bien plus de 50 personnes occupées sur Mastodon, en comptant les développeurs (1889 dans le github), les modérateurs, les administrateurs d’instance, et j’en passe.
La 1ère clause du nombre de personne tombant, le DSA s’applique. Et donc certaines instances (mastodon.social via la boîte d’Eugen qui est aussi celui qui détient les droits de copyright sur le soft et fou une sacrée merde juridique) à elles-seules pourraient déjà avoir le DSA sur la tronche, mais en plus le Fediverse tout entier d’après la Commission Européenne dans tous les cas.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . Évalué à -2 (+1/-4).
Ah oui et sur la portée, la limite de 45 millions n’est que pour la définition de gatekeeper. Qui ont des exigences renforcées.
Pour les autres, et en tout cas depuis le 17 février dernier, il y a quand même des obligations aussi, en particulier de célérité, de processus (appel neutre, etc) et de transparence de la modération à mettre en œuvre pour tout le monde.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Erwhann . Évalué à 0 (+0/-1).
Merci pour tes réponses. Dommages qu’elles se soient faites moinsser quand il s’agit de réponses plus techniques que d’un jugement moral personnel.
Du coup, c’est la seule chose que j’aurais à répondre : un sentiment personnel, d’un non-juriste, avec toutes les limites que ça comporte.
Si le réseau se retrouve considéré comme une entité commune alors, c’est ça devient le procès d’ActivityPub, et de tous les services fédérés entre eux. Effectivement, en comptant les développeurs de Mastodon, Firefish, Peertube et les autres (dont Thread de Meta je crois), ActivityPub « occupe » bien plus de 50 personnes… Si c’est vers ça que tend la commission, je souhaite bien du courage aux organismes qui vont être chargés de faire respecter le DSA et les autres textes qui ne manqueront pas de venir réguler les réseaux.
L’argument de considérer le réseau comme entité commune dans le but d’éviter un boulevard juridique aux GAFAMs me semble assez spécieux. Il aurait/serait (je ne sais pas ou on en est de ces discussions) peut-être été préférable de se pencher sur les relations de subordinations directes (l’instance A est la propriété de Meta via la filiale B) ou indirectes (le logiciel a des CGU contraignantes, pas d’export/import de données standardisées vers des logiciels équivalent, une implémentation personnelle du protocole avec des fonctionnalités maisons non-reproductibles, etc. En gros tout ce qui fait du lock-in).
Après, peut-être que justement ce genre de « définition » laisse trop de trous dans la raquette, c’est possible, je ne saurais dire.
Que la boite d’Eugen, en tant que développeur principal de Mastodon, soit considérée comme « occupant » plus de 50 personnes, pourquoi pas. Que mastodon.social soit comprise dans le lot, parce qu’elle est administrée par des gens de Mastodon gGmbH, oui ok, à la limite. Mon sentiment est qu’on n’en n’est pas vraiment au même niveau/pouvoir de nuisance qu’un Meta ou qu’un X, mais passons. Donc le DSA s’applique à Mastodon gGmbH.
C’est plutôt l’impact pour les « petites » instances, associatives ou non, de quelques milliers d’utilisateurs et composées d’une poignée d’admins que je me pose des questions. En gros, si je comprends bien ce que tu me dis, elles seront assujetties au DSA (et futurs règlements des plateformes et rézosoçios avec les responsabilités qu’ils impliqueront) même pas parce qu’elles utilisent un logiciel développé par plus de 50 personnes, mais bien parce qu’elles se connectent à un réseau dont certaines instances tournent avec un logiciel développé par une grosse boite et/ou plus de 50 personnes…
J’espère vraiment que ça ne sera pas interprété comme ça. Ce serait plus ou moins l’avis d’exécution du Fediverse qui serait signé.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Yth (Mastodon) . Évalué à 10 (+11/-0).
T'as entendu parler d'Alstom ?
Une petite boîte française, partie aux USA sur fond de procès américain, avec détention abusive de ressortissants français sans jugement, pour des histoires de corruption qui n'ont jamais concerné les états-unis, et qui implique précisément l'extra-territorialité de leur juridiction…
En informatique ?
On en a des pleins jardins, d'ingénieur/es, d'entrepreneur/es, de propriété intellectuelle, de projets, d'idées, de recherche, de gens motivés, etc.
Pas des jardins, non, des champs à perte de vue…
Quelles âneries, faut vraiment rien y connaître alors.
Tu t'y connais en technique informatique pour raconter des bêtises pareilles ?
Tu t'appuies sur quoi ?
C'est quoi tes 15 ans ?
C'est quoi la soi-disant différence impossible à rattraper ?
Avec des raisonnements à la con comme le tiens, jamais on n'aurait construit Ariane ou Airbus, ou même la bombe nucléaire, dans notre mini pays tout en retard.
Ces trucs là, ça va, ça vient, il suffit de peu de choses en vrai pour rattraper et revenir au niveau.
Surtout en informatique, parce qu'il y a 15 ans, le cloud Ricain, c'était du vent, et que tout existe déjà en France.
« Un retard de 15 ans », je vais rigoler encore longtemps en répétant ça tiens.
1000 milliards pour faire un cloud assez balaise pour y mettre nos données de santé ?
Mais dans quel monde tu vis ?
On demande pas de faire des mastodonte délirant comme les gros MAGAF hein, ça sert à rien, on saurait pas les protéger de toute façon, on se les ferait bouffer comme des ânes, comme d'habitude, ou ils deviendrait des veaux à la Orange, poussif, massif et inefficaces.
Mais un tissus d'entreprises de plus petites taille, dans toute l'Europe, capable de répondre aux problématiques de l'Europe, et en plus de faire du commercial vers les Européens, c'est bien moins cher que ça.
Et bien plus rapide aussi.
Et bien plus résilient.
Et bien plus facile à auditer.
Et à entretenir.
Et à protéger.
Bref, il ne faut pas suivre le modèle américain, à leur jeu on va perdre, mais ça ne veut en rien dire qu'on ne peut pas faire autrement, et avoir un bouzin qui fonctionne quand même.
Probablement mieux pour nos besoins d'ailleurs.
Mais peut-être que, comme on peut le lire dans d'autres commentaires, l'idée pourrait être que les certifications dont on a besoin soient non pas extrêmement chères, mais un service public pour entreprises européennes. Un service qui, par contre, ferait son travail efficacement et vérifierai vraiment que le cahier des charge est rempli.
Et peut-être que les gros ricains ils seraient peut-être pas si parfaits que ça, et que la concurrence elle serait un peu moins faussée.
Encore une belle idée reçue ça, que les services des MAGAF seraient à la pointe de la perfection, et rempliraient toutes les cases de la sécurité et de l'efficacité.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Stéphane Ascoët (site web personnel) . Évalué à 2 (+1/-0).
Tiens certains contributeurs ne connaissent pas Aéris apparemment, étonnant !
Privilégier des entreprises nationales a notamment l'énorme avantage de créer des emplois locaux, ce qui est bon électoralement(et réduit donc la montée du RN), pour le retour sous forme d'impôts, de consommation, etc. Pourquoi les USA le font-ils à ton avis ? Tiens c'est marrant, ça rappelle beaucoup le contexte qui provoque actuellement une méga-grogne agricole…
Quant au fait que les bases soient propriété de l'état ou pas, ça ne changera rien pour un pouvoir motivé : il obligera tout simplement le prestataire à lui fournir les données.
# Il n'a pas trop cherché
Posté par devnewton 🍺 (site web personnel) . Évalué à 9 (+7/-1). Dernière modification le 19 février 2024 à 10:47.
Selon lui, "on" n'a pas le choix que d'aller chez Microsoft pour le Health Data Hub parce que seul Microsoft a les bonnes certifications ? C'est juste faux.
Je ne vais pas faire de pub, mais des boites certifiés Hébergeur de Données de Santé, il y a plusieurs en France et pas des TPE…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Il n'a pas trop cherché
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
Il y a même une liste officielle ici maintenue par un organisme gouvernemental. Rien qu’en filtrant sur les entreprises qui satisfont les 6 critères, on a 117 possibilités.
Par contre, ces hébergeurs sont des hébergeurs de données et pas de projets, dans le sens où un hébergeur peut apparaitre dans cette liste sans être capable d’héberger un projet d’une entreprise tierce. Une entreprise peut être certifiée uniquement dans l’optique d’héberger les données de son propre outil.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Il n'a pas trop cherché
Posté par Aeris (site web personnel) . Évalué à 4 (+3/-0).
Et tu peux aussi demander à InterHop, ils utilisent un hébergeur HDS mais ont aussi eu à mettre en place des procédures très lourdes de leur côté, que ce soit en terme de code, d’automatisation, d’isolement réseau, etc. La certification HDS de l’hébergeur n’a été que l’étape initiale obligatoire, et pas du tout la balle en argent…
[^] # Re: Il n'a pas trop cherché
Posté par Aeris (site web personnel) . Évalué à 4 (+3/-0).
Ah oui, comme dit aussi dans mon article, c’est le cumul des exigences qui posent aussi problème. Par exemple sur les 117 hébergeurs, combien sont aussi compatibles avec l’orientation obligatoire des projets étatiques du moment (« cloud au centre ») qui impose une certification SecNumCloud en complément ?
[^] # Re: Il n'a pas trop cherché
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 10 (+11/-1).
Ça n'est un problème que parce qu'il n'y a aucune volonté politique d'aider les entreprises hors Gafam à acquérir ces certifications. Avec une vraie volonté politique cela aurait été réglé depuis un certain temps déjà !
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Il n'a pas trop cherché
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 10 (+12/-2).
Ce qui est amusant, c'est que même bardées de toutes ces certifications on se retrouve quand même avec toutes les données qui se promènent dans la nature. À croire que ces certifications servent plus à faire tourner des machines Shadoks qu'à faire avancer le schmilblick. À ne pas avoir de volonté politique de faire du local, on se retrouve avec une double peine : l'argent et les compétences qui se volatilisent d'une part, et les données qui s'évaporent de l'autre.
Y aurait-il une réciproque au « beurre et l'argent du beurre » pour décrire la politique française de manière appropriée ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Il n'a pas trop cherché
Posté par Aeris (site web personnel) . Évalué à 1 (+1/-1).
Être certifié n’est pas une garantie de ne pas se faire trouver.
Ne pas être certifié est l’assurance d’avoir des problèmes.
Les certifications, surtout en terme de sécurité quand on parle de PCI-DSS ou HDS sont quand même autrement moins bullshit que certaines autres et imposent surtout un minimum vital de respect de l’état de l’art.
Ce n’est par contre effectivement pas une garantie d’aucune sorte sur la qualité du truc derrière.
[^] # Re: Il n'a pas trop cherché
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 9 (+7/-0). Dernière modification le 19 février 2024 à 19:29.
Pour le vivre de l’intérieur, je peux te garantir que certaines des certifications vues comme « de haute qualité » et « très contraignantes pour les avoir » sont loin d’être aussi carrées et imposent moins de qualité et de sécurité réelles qu’on pourrait le croire en s’appuyant sur la théorie. Ceci est à comprendre comme « Certaines entreprises certifiées n’ont pas le niveau de rigueur et de qualité réels qu’on pourrait croire en lisant la théorie ». Par contre, pour des raisons évidentes, je ne peux pas donner de détails plus précis.
D’autre part, il ne faut jamais oublier que tous ces processus, toutes ces certifications impliquent des humains, avec tout ce que ça implique. Nous vivons dans un monde dans lequel des gens sont prêts à dévoiler des secrets militaires pour avoir raison dans une discussion sur un jeu vidéo, ce qui relativise beaucoup le niveau de fiabilité que l’on peut attendre d’un grand groupe d’humains (en tant que groupe).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Il n'a pas trop cherché
Posté par Nibel . Évalué à 10 (+8/-0).
J'peux témoigner sans trembler que les certifs ça vaut pas grand chose.
On a une certif' ISO-27001 qu'on doit jamais avoir. Mais bon, on invente une vie à 3 disques durs randoms avec un étiquetage sorti le matin même, on demande à quelques employés qui ont des accès admin de ne pas se connecter au réseau de l'entreprise pendant 3 jours et de bien garder leur poste hors ligne, on créé des procédures qui ne seront jamais mises en place mais qu'on est en mesure de détailler à l'auditeur…
Et on est une entreprise française, leader en Europe sur son marché.
Donc à l'échelle des GAFAM je n'ose imaginer les magouilles qu'il y a pour valider les certifs.
Se fier uniquement aux certifications acquises, c'est un bien mauvais choix et ça démontre surtout qu'on est bien loin de la réalité concernant l'acquisition des certif'.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Il n'a pas trop cherché
Posté par Aeris (site web personnel) . Évalué à 0 (+2/-3).
Alors il n’y a pas beaucoup plus de volonté de certification de la part des éditeurs eux-mêmes hein.
C’est long, chiant, pénible, ça limite tes possibilités de développement et les entreprises préfèrent violer la loi que de la respecter, parce que sinon viser les 10% de croissance n’est plus possible…
Va demander à une boîte d’interdire à ses devs d’avoir le moindre accès à la prod. Pour quelques raisons que ce soit. Même pour debug, même pour avoir des logs. Même pour faire des déploiements. Ça va couiner. Beaucoup.
Et je sais de quoi je parle, c’est extrêmement galère au quotidien à gérer et faut encaisser la direction qui comprend pas pourquoi le moindre déploiement prend 7 jours juste pour ajouter un filtre dans un formulaire web.
Parce que tu dois avoir l’approbation de la Q/A, de la qualif PCI-DSS et les 3 paraphes de la DSI. Que les ¾ des libs disponibles sur Terre te sont interdites parce que ne passent pas les prérequis techniques minimaux.
Ajouter un lien sur le site web, ça a été 6 mois de taff, avec implication de la DSI, du responsable juridique, etc.
Après on a un énorme avantage : on a l’ACPR qui est un régulateur qui est « un poil » plus chiant que la CNIL. 2 contrôles annuels de fond en comble avec insta strike de tout ton business pendant X mois à la moindre case qui passe en rouge, ça motive assez sévère à envoyer chier la direction 🤣
Et on a 2 personnes à plein temps juste pour gérer les audits permanents.
[^] # Re: Il n'a pas trop cherché
Posté par Nibel . Évalué à 6 (+4/-0).
Un développeur n'a pas à avoir accès à la prod non.
Je travaille chez un important éditeur logiciel et aucun développeur n'accède à la prod et non il ne faut pas 7 jours pour changer quoi que ce soit. Avec un process rôdé, c'est quelques heures tout au plus. Si vous êtes incapables de descendre en-dessous d'une semaine pour le moindre changement, alors c'est que vous avez un problème de process et d'organisation.
Et visiblement aussi de communication puisque vous n'êtes pas en mesure de trouver des solutions entre vos différentes équipes pour y pallier.
Le problème ne semble pas provenir des certifications à te lire.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Il n'a pas trop cherché
Posté par Glandos . Évalué à 6 (+4/-0).
Ah, tiens, je me suis mis à faire du développement Web il y a 3 ans. Après 15 ans à maintenir dans la même boîte un Jenkins qui compile en autonome sur des VM, façons Debian (pas de connexion à l'extérieur), c'était une tâche horrible que de découvrir l'écosystème JS. Bonjour connexion aléatoire à pour télécharger qui exécute . Ça fait littéralement très peur, pour moi qui venais du Java/C++.
Et les outils pour maîtriser ce genre de choses sont compliqués à installer : serveurs mandataires internes avec cache pour NPM, c'est relou. Il y a le même problème avec Docker : bonjour
FROM vendor/machinedont tu arrives même pas à retrouver l'origine, ou alors qui est une cible mouvante.Finalement ce module Python (https://pypi.org/project/stackoverflow/) qui était une blague est devenu réalité.
[^] # Re: Il n'a pas trop cherché
Posté par Aeris (site web personnel) . Évalué à -1 (+3/-5).
HDS qui n’est qu’un des certifications nécessaires pour faire tourner un tel projet.
Manipuler des données de santé implique être HDS. Ne nous trompons pas dans la contraposée, être juste HDS n’implique pas de pouvoir automatiquement manipuler des données de santé, ne pas être HDS t’interdit de traiter un tel projet.
Mais être HDS ne suffit pas. Tu dois aussi possiblement être ISO-27001, PCI-DSS, RGPD, DSA, SecNumCloud et j’en passe possiblement d’autres.
Ici HDS n’est pas le seul critère, il y a au moins le RGPD (vu que données perso) et SecNumCloud (vu que politique cloud au centre de l’État) aussi.
[^] # Re: Il n'a pas trop cherché
Posté par devnewton 🍺 (site web personnel) . Évalué à 8 (+5/-0).
RGPD et DSA, ce sont des règlements, c'est pas une option :-)
SecNumCloud+HDS, il y en a en France. Ils sont probablement tous ISO-27001.
Après il est toujours possible d'empiler les exigences dans le seul de choisir Azure, mais bon…
Et la souveraineté c'est pas dans les 666 exigences ? Oh ben zut alors quel oubli malheureux !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Argument dérivé
Posté par Glandos . Évalué à 8 (+6/-0).
Je me permets de réagir sur un argument du billet :
La comparaison ne tient pas. Fairphone a vendu 95 000 téléphones en 2020. À 500€ l'appareil, ça fait 50 000 000 € (j'arrondis, je suis gentil). Le résultat net de Apple est de 97 milliards de $ en 2023. Il faut 5 heures de bénéfices Apple pour acheter toute la production Fairphone en un an. Apple maîtrise son produit verticalement, il peut donc obtenir un support matériel plus facilement. Je trouve que justement, le maintien des mises-à-jour par Fairphone relève de l'exploit.
Mais finalement, celui qu'il faut blâmer, c'est plutôt Google : Android supporté pendant 2 à 3 ans (au moment du Fairphone 2), et même si Android tourne sur du matériel largement plus hétérogène, Google possède une arme assez simple, la certification Android. Celle-ci peut très bien imposer le support du matériel et des mise-à-jour de sécurité sur une période plus longue, et soyons conservateur, disons 5 ans.
L'argument initial était de souligner que les libristes préfèrent fermer les yeux sur la sécurité de la chaîne d'approvisionnement logicielle, mais effectivement, ce n'est pas la priorité quand on a aucune garantie d'avoir un retour sur investissement. Et par ailleurs, fédérer la sécurité du libre/open source est un sujet qui pourrait très bien être conduit (j'ai pas dit résolu) par l'UE elle-même. Après tout, le libre est utilisé par… presque tout le monde, et des infrastructures vitales en font partie. Il y a donc la partie normative, mais accompagner les fournisseurs ne serait pas non plus du luxe. Une subvention européenne à la fiabilité de la chaîne d'approvisionnement quoi. Il reste à trouver un acronyme qui ressemble à une déesse grecque, et ça va bien se vendre.
[^] # Re: Argument dérivé
Posté par Tangi Colin . Évalué à 3 (+2/-0).
Google a bien amélioré la situation du support long terme avec leur projet Generic kernel image, en offrant des api interne stable à grand coup de padding reserved dans les structure du kernel. Bien qu'il ai peu de chance que leur solution soit un jour mainline, leur travail est loin d'être bête et ils ont fait beaucoup pour améliorer la situation.
Et puis si le support Android te concerne vraiment, tu achète un pixel et tu retrouve la même "intégration vertical" que tu peux trouver chez Apple. Et avant y avait Motorola.
[^] # Re: Argument dérivé
Posté par Storm . Évalué à 5 (+4/-0).
Sauf que les pixel c'est pas vraiment mieux (du moins les "anciens"). Mon exemple, Pixel 4a, sorti le 3 août 2020, fin du support officiel de Google fin août 2023. Donc mon téléphone ça fait ~6 mois qu'il n'est plus supporté (en vrai Google a fait une dernière mise à jour de sécurité en septembre je crois donc un peu moins), et moins de 3 ans depuis mon achat (puis j'imagine bien les gens qui vont acheter le téléphone début 2023 qui se retrouvent avec seulement quelques mois de support…)
Maintenant j'ai donc les choix suivants:
- je rachète un nouveau téléphone (merci l'environnement).
- je passe sur LineageOs qui est de ce que j'ai trouvé pas mal le seul moyen d'avoir un support qui a de la gueule sur la durée.
[^] # Re: Argument dérivé
Posté par devnewton 🍺 (site web personnel) . Évalué à 8 (+5/-0).
Je ne sais pas d'où il sort cette histoire de forum et de liens russes, mais comme pour l'hébergement de données de santé, il n'a pas cherché bien loin.
A moins que ce soit sa mauvaise foi qui soit certifiée trollo-27001 ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Argument dérivé
Posté par Yth (Mastodon) . Évalué à 7 (+5/-0). Dernière modification le 19 février 2024 à 20:35.
D'autant que bon, les ISO lineageOS se trouvent… sur le site de lineageOS.
Après, si t'as un téléphone incompatible et que tu trouves sur un obscur forum russe quelqu'un qui prétend avoir bidouillé une image pour ton téléphone, tu sais pas à quoi tu peux t'attendre non plus.
Mais bon, si t'as pas un iPhone, cherche pas à installer iOS hein ?
Si t'as pas un téléphone compatible lineageOS, ou Murena, mieux vaut peut-être pas trop chercher plus loin…
Bref, du FUD.
[^] # Re: Argument dérivé
Posté par Storm . Évalué à 4 (+3/-0).
Je pense que ça date du début des rom alternatives, où il fallait souvent aller chercher l'outil pour débloquer le chargeur de démarrage ou autre sur XDA ou autres sites louches. C'était assez vraiment il y a une dizaine d'années, ça l'est beaucoup moins maintenant par contre.
[^] # Re: Argument dérivé
Posté par Aeris (site web personnel) . Évalué à 3 (+2/-0).
Oh c’est toujours vivant. Exemple encore jeudi dernier : https://xdaforums.com/t/kernel-t2s-exynos-5-4-242-expara-kernel-kernelsu.4656566/
[^] # Re: Argument dérivé
Posté par Glandos . Évalué à 5 (+3/-0).
Ahah, effectivement, c'est assez marrant.
Mais j'ai toujours eu du mal à comprendre pourquoi il n'était pas possible d'avoir « relativement » facilement un mode root sur son téléphone. Chais pas moi, une option au boot, ou alors un mode root qui ne peut se donner qu'à une liste blanche d'applications.
Je comprends le problème initial, et ça évite bien des catastrophes, mais ça ruine également pas mal la confiance dans le système : finalement l'utilisateur ne possède pas son téléphone.
[^] # Re: Argument dérivé
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0). Dernière modification le 22 février 2024 à 14:05.
Dès que t'as un modèle un peu confidentiel, il y a quand même une culture de l'image recovery twrp pas officielle téléchargée sur un site je ne sais où dans le monde android.
Alors c'est relativement facile de t'acheter un smartphone d'occasion supporté par /e/, graphene ou lineageos installée depuis une image recovery pas sortie d'un site louche mais beaucoup moins de savoir quel modèle sera supporté si tu pars sur du neuf, d'autant plus si tu n'as pas les moyens de t'acheter un haut de gamme.
[^] # Re: Argument dérivé
Posté par Dring . Évalué à 5 (+3/-0).
Question naïve: l’argument de vente du FairPhone c’est que la durabilité ? Ou le côté “fair” c’était aussi “on exploite pas des ouvriers dans des usines-prisons” ?
[^] # Re: Argument dérivé
Posté par Glandos . Évalué à 6 (+4/-0).
https://shop.fairphone.com/fr/about-us
Le but premier est de faire des téléphones le plus durable possible : impact environnemental et humain en même temps.
[^] # Re: Argument dérivé
Posté par Yth (Mastodon) . Évalué à 8 (+6/-0).
Les deux.
Ils font un travail sur pas mal de points :
Réparabilité, plus que durabilité d'ailleurs, avec facilité de remplacer juste certains modules.
Recyclage, en essayant d'utiliser un maximum de matériaux recyclés (70% sur le fairphone 5 apparemment !).
Origine, pas de métaux rares en provenance de zones pourries, comme le Cobalt Congolais.
Et du commerce équitable quand ça existe, apparemment pour l'or ils ont le label.
Tu le payes quand même, c'est pas donné un FairPhone, et tu peux trouver techniquement équivalent pour bien moins cher.
Mais ça le vaut probablement sur la durée, avec la réparabilité, et le support LineageOS, qui dure vraiment longtemps, ou Murena maintenant.
# Deux concepts qui me semblent utiles au vu des discussions ici
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 7 (+5/-0).
Au vu de la teneur des discussions qui ont lieu par ici, je vous propose de découvrir ou réviser deux concepts qui me semblent intéressants :
La connaissance libre : https://zestedesavoir.com
[^] # Re: Deux concepts qui me semblent utiles au vu des discussions ici
Posté par Aeris (site web personnel) . Évalué à 2 (+2/-1).
Alors ces 2 concepts, s’il y a bien un domaine où tu ne veux pas les mettre en œuvre, c’est bien celui-ci. Vraimente.
Les principes fondamentaux du RGPD et de ePrivacy découlent directement de l’article 8 de la Convention Européenne des Droits de l’Homme et sont justement le retour à la morale dans le droit. Beaucoup de domaines qui se pensaient justement moraux se sont pris ce truc dans les dents derrière et que ben non, pas de bol, t’avais oublié tout un pan de la morale… Le libre est un de ces domaines-là.
Idem côté lettre et esprit de la loi. Pas du tout le bon plan d’aller jouer avec ça du côté du RGPD, la CJUE est encore plus aggressive que ça sur sa lecture de l’esprit de la loi et rend des décisions parfois même très très surprenante. Cf sa jurisprudence sur 2(2)c ou encore la dépublication des registres de transparence.
# Si quelqu’un a les stats sous la main…
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 7 (+5/-0).
… je me demande si Aeris n’est pas la première personne à passer la barre des 100 commentaires sous le même contenu (103 à l’instant où j’écris ces lignes) !
On remarquera l’effort de Psychofox (33 messages) et Yth (27 messages) pour l’aider en ce sens.
Vous avez trop de temps libre, les gens ;-)
La connaissance libre : https://zestedesavoir.com
[^] # Re: Si quelqu’un a les stats sous la main…
Posté par Psychofox (Mastodon) . Évalué à 6 (+3/-0). Dernière modification le 22 février 2024 à 08:07.
C'est vrai, ou on passe trop de temps aux toilettes. On aurait pu écrire des dépêches pendant ce temps!
[^] # Re: Si quelqu’un a les stats sous la main…
Posté par Benoît Sibaud (site web personnel) . Évalué à 4 (+1/-0).
Sur un journal, non (et de loin). Mais sur un lien, oui.
[^] # Re: Si quelqu’un a les stats sous la main…
Posté par Faya . Évalué à 3 (+1/-0).
En même temps il abuse des auto-réponses : 35 commentaires dans ce cas (ouais, c'était le plaisir de trouver un moyen de compter les auto-réponses, et merci ChatGPT). Ça n'en fait plus que 68 ce qui est tout de même remarquable…
# Merci pour ce moment
Posté par EdLeH (site web personnel) . Évalué à 7 (+6/-0).
J'ai même appris que le RGPD nous interdisait de violer Shrek 2.
Ça prouve bien que c'est un troll.
[^] # Re: Merci pour ce moment
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
Non, un ogre. Shrek, c’est un ogre.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Merci pour ce moment
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+1/-0).
On ne viole ni les trolls, ni les ogres, ni les commissaires européens: les monstres sont égaux en droit !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.