Note
À l'heure où j'écris ces lignes, une autre version de Conversations a été remise en ligne sur le magasin Play, ce qui n'empêche pas de se pencher sur l'incident et j'avais déjà bien commencé la rédaction de toutes façons.
Conversations
Pour celles et ceux qui ne connaîtraient pas, Conversations est un client XMPP pour Android.
L'application prend en charge, outre la messagerie instantanée, le chiffrage bout-à-bout et les appels audios et vidéos. Elle est optimisée pour être légère pour les batteries.
C'est certainement le client Android le plus populaire à l'heure actuelle!
GooglePlay et permissions
Le magasin Google Play exige des développeurs qu'ils déclarent ce que font les applications des données auxquelles elles ont accès. Bien souvent, il y a une collecte qui est faite en sus de l'usage pour les besoins de l'application elle-même.
Pour le cas qui nous intéresse ici, il s'agissait de l'accès au Carnet de Contacts et son téléversement.
Quand le magasin Play imagine des violations…
Dans la dernière version de Conversations, le développeur a ajouté une fonction qui va chercher des correspondances entre la liste de contacts XMPP et les contacts du Carnet de Contacts, afin de récupérer une miniature associée si une telle image existe et l'associer aux messages des contacts dans Conversations.
Mais à aucun moment dans cette opération le Carnet de Contacts n'est téléversé, et certainement pas vers le serveur du développeur (XMPP étant décentralisé, le client Conversations peut être connecté à n'importe quel serveur XMPP).
Il s'agit pourtant de la violation retenue par Google pour retirer l'application sans même, semble-t-il avoir donné une chance au développeur de résoudre le problème.
Source Mastodon:
https://gultsch.social/@daniel/111929074071688694
Google has just removed #Conversations_im from the Play Store because they think we are uploading the user’s contact list. We don’t.
Google vient de retirer #Conversations_im du Catalogue Play parce qu'ils pensent que nous téléversons la liste de contacts de l'utilisateur. Nous ne le faisons pas.
To be clear: They didn’t just reject an update. They outright removed the app entirely. Otherwise my plan B would have been to remove the contacts permission which is used to display the name and profile picture locally if the XMPP address matches an entry in the users address book.
Pour être clair: Ils n'ont pas simplement refusé une mise à jour. Ils ont immédiatement retiré l'app entièrement. Autrement mon plan B aurait été de retirer la permissions Contacts, qui est utilisée pour afficher le nom et la photo de profil localement si l'adresse XMPP correspond à une entrée dans le Carnet de Contacts des utilisateurs.
Conséquences
Conversations est disponible gratuitement sur F-Droid, mais la version Play est elle payante, le développeur principal du projet en tire une rémunération. Difficile de savoir aujourd'hui combien de fois l'app a été téléchargée depuis le catalogue Play. Mais il s'agit certainement d'un coup dur.
Comble de l'ironie, le dév a une autre app sur le magasin Play: Quicksy. Quicksy est une branche de Conversations qui utilise le numéro de téléphone de l'utilisateur comme identifiant XMPP sur un serveur dédié, suivant le même principe que Signal ou Whatsapp.
Quicksy téléverse le Carnet de Contacts des utilisateurs afin de remplir la liste de contacts XMPP avec d'autres utilisateurs de Quicksy ou d'autres contacts qui auraient volontairement enregistré un compte XMPP sur le serveur de Quicksy.
Le magasin Play n'a pas autorisé de nouvelles versions de Quicksy depuis un certain temps, mais l'application n'a pas été retirée du magasin, elle y est restée!
Dénouement
Il y avait deux façons de répondre aux exigences de Google: prétendre que le Carnet de Contacts était bien téléversé quand bien même il ne l'était pas. Mais cette affirmation (fausse) aurait pu ternir l'image de l'app en termes de respect de la vie privée. L'autre solution était de renoncer à la fonctionnalité qui va chercher des infos sur les contacts déjà présentes dans l'appareil.
C'est cette dernière solution qui a été retenue. Le développeur a pu remettre Conversations dans le magasin. Ceci s'est fait sans que Google admette l'erreur.
Et dans la foulée, une mise à jour pour Quicksy a été acceptée.
Mot de la fin
Cet incident survient alors que l'Union Européenne légifère pour briser le monopole des magasins d'applications pour ordiphones. On pense surtout ici à Apple, mais cet évènement rappelle douloureusement que sous Android, l'accès au marché des utilisateurs est presque totalement contrôlé par Google, et il n'y a que peu d'incitatif à réviser les procédures pour éviter ce genre de problème.
Remerciements
J'aurais certainement raté cette nouvelle sans le commentaire ci-dessous:
# Monopole
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10 (+8/-0).
J'avais loupé cette information ! Voilà une très bonne nouvelle en effet.
Mais de façon débrayable, donc ce n'est pas aussi grave que chez Apple. Ce qui est plus grave à mes yeux, c'est plutôt des logiciels comme l'Identité numérique la Poste, qui exige d'être installée via Google Play Store.
[^] # Re: Monopole
Posté par nathanaelh . Évalué à 6 (+6/-0).
Puisque tu évoques l'app de l'identité numérique (pour la France), je peux vous dire que j'ai pu l'installer sur mon tél qui marche avec Murena /e/ OS, via l'app store intégré et que ça marche :) J'étais assez inquiet que ça ne marche pas vu qu'il n'y a pas les Google Play Services sur mon téléphone.
[^] # Re: Monopole
Posté par pas_pey . Évalué à 3 (+3/-0).
Il y a microG qui remplace les principaux services google il me semble ?
https://microg.org/
[^] # Re: Monopole
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 8 (+5/-0).
Ou encore les applis bancaires !
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Monopole
Posté par tkr (Mastodon) . Évalué à 7 (+6/-0).
personnellement je boycotte juste de bout en bout toutes les "applis" google sur mobile.
google, si vraiment ultra-nécessaire et dans l'urgence, reste cantonné à la navigation privée dans firefox ; jamais "en dur" sur un android.
l'identité numérique/la poste requièrent les services google? je boycotte.
le CPF dont nous cotisons requiert l'identité numérique, donc les services google?
parfait, je boycotte le CPF, au grand dam de notre startup-ultra-google-nation.
quitte à ce que ca me coute cher en cotisations, ca m'économise une énorme charge mentale.
# Téléverser ?
Posté par Vlobulle . Évalué à -4 (+4/-10).
J'ai raté un terme technique ? Ou c'est une circonvolution pour éviter le mot uploder ?
[^] # Re: Téléverser ?
Posté par dovik (site web personnel) . Évalué à 10 (+18/-0).
Ce n'est pas pour éviter "uploader", c'est juste le mot français pour le dire (comme "téléchargement" pour "download").
cf :
https://www.larousse.fr/dictionnaires/francais/t%C3%A9l%C3%A9verser/188203
ou
https://fr.wiktionary.org/wiki/t%C3%A9l%C3%A9verser
[^] # Re: Téléverser ?
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 9 (+7/-1).
Et il est très utilisé !
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Téléverser ?
Posté par Vlobulle . Évalué à -8 (+1/-11). Dernière modification le 15 février 2024 à 11:48.
Oh, d'accord, merci. Je n'avais jamais rencontré le terme. C'est juste un synonyme du coup. Parce que bon, uploader aussi c'est français tout de même, c'est pas non plus un dictionnaire qui conditionne la langue ^^
[^] # Re: Téléverser ?
Posté par arnaudus . Évalué à 5 (+5/-3).
Il faut admettre que "téléverser" est assez rare, même sur les sites spécialisés, et quasiment absent des sites grand public. Il faut comprendre son utilisation comme une démarche un peu militante, comme l'orthographe inclusive. Chacun écrit comme il veut, et si les gens souhaitent encourager un usage, ils peuvent le faire, et ils assument éventuellement les problèmes de compréhension (comme celui que tu remontes).
Le problème est que "download" / "upload" est particulièrement clair et élégant, la symétrie est évidente, et la signification est assez transparente. En français, "verser" n'est pas le contraire de "charger", et dans le langage courant "charger" a les deux sens, même si ça crée des ambiguités. Peut-être "télédécharger"? Ça fait penser à un choc électrique :-)
[^] # Re: Téléverser ?
Posté par Vlobulle . Évalué à 4 (+2/-0).
Ton explication vient de me faire comprendre/réaliser la construction de téléverser (enfin, le pourquoi le mot a été construit de la sorte). C'est définitivement plus clair.
[^] # Re: Téléverser ?
Posté par BAud (site web personnel) . Évalué à 5 (+3/-0).
qui est un faux-ami de traduction de definitely ;-)
[^] # Re: Téléverser ?
Posté par ted (site web personnel) . Évalué à 3 (+1/-0).
Ce qui est embêtant c'est quand des sites utilisent le mot "télécharger" au lieu de "téléverser", car ils ne connaissent pas le bon terme français.
Pour rester plus ou moins dans le sujet, moi ça me bugue quand j'entends les termes "podcaster" et "streamer" pour l'action de télécharger des médias: dans mon esprit ces termes sont plutôt pour l'action inverse (envoi de données)
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Téléverser ?
Posté par arnaudus . Évalué à 3 (+0/-0).
Podcaster, je ne sais pas trop, mais streamer, en effet, c'est forcément du "téléversement". Je pense que là c'est plus une erreur qu'un changement de sens.
[^] # Re: Téléverser ?
Posté par jeberger (site web personnel) . Évalué à 2 (+1/-0).
Marrant, je dirais le contraire: « podcaster » a la racine « cast » qui signifie « jeter » avec donc le sous-entendu que quelque chose est envoyé par le sujet, alors que « streamer » a pour racine « stream » qui signifie juste « flux » sans notion de direction…
[^] # Re: Téléverser ?
Posté par Maclag . Évalué à 10 (+7/-0).
En plein dans le mille. Je trouve dommage qu'on utilise tellement de mots anglais en Français.
Je n'ai rien contre l'Anglais. Je travaille presque exclusivement en Anglais.
Mais j'aime ma langue maternelle, et j'essaie d'en prendre soin un minimum.
De même, j'écris ordiphone plutôt que smartphone (ou pire encore "téléphone intelligent", comme ils disent au Québec).
Si du monde découvre le mot "téléverser" ici, tant mieux. C'est à force de s'en servir qu'on en obtiendra l'usage courant!
C'est vrai que les mots "télécharger" et "téléverser" ne sont pas tellement intuitifs. Mais c'est aussi ça une langue vivante, ça n'a pas à être logique et systématique tout le temps. Je le trouve élégant, le mot "téléverser".
[^] # Re: Téléverser ?
Posté par Stinouff . Évalué à 6 (+4/-0).
La première fois que j'ai entendu "téléverser", cela provenait d'une dame à la retraite qui savait très bien de quoi elle parlait sur l'instant…et j'ai compris directement. J'aime bien.
[^] # Re: Téléverser ?
Posté par Wrap . Évalué à 1 (+0/-0).
Je ne sais pas pourquoi ils veulent toujours créer de nouveaux mots … "Envoyer" et "Récupérer" aurait été tellement plus clair.
[^] # Re: Téléverser ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Envoyer sur ma machine ou sur leur machine ?
Quand on te propose de récupérer un fichier dans ton Drive en ligne, ce devrait être le même mot que quand le dit Drive te propose ensuite de récupérer une copie sur le système de fichier …ou sur le Drive d’un autre compte que tu viens de lier ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Téléverser ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 10 (+7/-0).
Le logiciel propriétaire Sharepoint de Microsoft souffrait (souffre ?) d'un souci de traduction du terme : sur la même page listant le contenu d'un répertoire, deux boutons dits Télécharger, mais l'un pour télécharger (je récupère la version du document sur le serveur), l'autre pour téléverser (je soumets une nouvelle version du document). C'est particulièrement pénible à l'utilisation de se gourrer une fois sur deux, jusqu'à ce que la charge mentale de se rappeler quel bouton à quel endroit sert à quoi dans l'interface soit complètement intégrée par la victime… euh la personne utilisatrice.
Ça peut devenir encore plus conceptuel quand il s'agit de transférer d'un stockage distant vers un service en ligne ou bien l'inverse (surtout si leur stockage est en fait le même au final…).
Bref distinguer télécharger/téléverser est utile (comme avoir download/upload en anglais).
# De nouveau dispo
Posté par Sylvain Berfini (site web personnel) . Évalué à 0 (+0/-1).
On dirait que l'app est de nouveau dispo non ?
https://play.google.com/store/apps/details?id=eu.siacs.conversations
[^] # Re: De nouveau dispo
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 5 (+2/-0).
C'est ce que dit le journal !
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
# Description objective du problème?
Posté par arnaudus . Évalué à 2 (+3/-4). Dernière modification le 15 février 2024 à 16:18.
Ce qui est dommage, c'est que je ne trouve pas d'explication technique sur le problème et la manière dont il a été réglé. On comprend bien que Google est méchant, mais à part ça?
Je n'y connais rien en permissions Android, mais je ne retrouve que deux permissions associée aux contacts, c'est android.permission.READ_CONTACTS et android.permission.WRITE_CONTACTS. En particulier, je ne vois rien de lié à l'upload des contacts.
Du coup, je me demande si ça n'est pas juste un problème de communication. L'auteur du logiciel doit déclarer la permission READ_CONTACTS s'il veut aller trifouiller quelque chose dans les contacts, ce qui était le cas. Google, par une analyse automatique du code, s'aperçoit que l'application accède aux contacts sans demander la permission READ_CONTACTS, et ban direct (ce qui me semble logique). Ma question, c'est un peu pourquoi l'auteur n'a pas simplement ajouter la permission READ_CONTACTS à l'application? Dans le PlayStore, l'accès aux contacts n'est pas indiqué, donc la dernière version de l'application ne le fait pas.
Je n'ai pas compris pourquoi insister sur l'upload, puisque rien de ce que j'ai trouvé ne différencie l'accès aux contacts et l'upload. Du coup, c'est possible que cette histoire d'upload ne change rien.
Du coup, je ne comprends pas réellement quel est le problème. Soit il y a deux permissions (READ_CONTACTS et UPLOAD_CONTACTS (?)), auquel cas Google a réellement fait une erreur en banissant l'application de leur store. Soit il n'y a qu'une permission, READ_CONTACT, qui couvre tous les usages qu'on peut faire avec les contacts, et dans ce cas, c'est l'auteur de l'app qui a fait une boulette (il n'a pas déclaré READ_CONTACTS alors que l'application le faisait). On peut alors critiquer le manque de granularité des permissions, mais ça n'a rien à voir avec Google.
Je ne suis pas sûr que mon interprétation soit bonne, parce que je n'ai pas trouvé les détails de cette histoire. Par contre, si elle est bonne, c'est juste une succession d'incompréhensions grossières du développeur de l'appli sur les permissions, qu'il monte ensuite en mayonnaise sur les réseaux sociaux.
[^] # Re: Description objective du problème?
Posté par Psychofox (Mastodon) . Évalué à 10 (+11/-0). Dernière modification le 15 février 2024 à 17:02.
Google part du principe que si ton applis a l'accès aux contacts et au réseau, c'est pour les aspirer et les garder sur ton serveur. Parce que accessoirement c'est ce qu'eux-même et la plupart des entreprises font. L'idée qu'une appli ne puisse utiliser les contacts que localement leur est totalement étrangère.
À vrai dire ils s'en foutent que tu le fasses, ils veulent juste te forcer à le dire pour se protéger légalement.
C'est aussi simple que ça.
[^] # Re: Description objective du problème?
Posté par arnaudus . Évalué à 6 (+4/-1).
Je ne comprends pas ce qui te fait dire ça, ils n'ont juste pas ce niveau de granularité. Ce qu'ils peuvent garantir à l'utilisateur, c'est si oui ou non l'appli a accès aux contacts. Dès que l'appli a accès aux contacts, c'est évident que tu ne peux plus rien garantir: peut-être que l'appli ne fait rien de ces données, peut-être qu'elle fait un calcul en local et c'est tout, peut-être qu'elle balance tout en clair sur ses serveurs, peut-être qu'elle fait remonter les données après avoir caché les infos dans des paquets qui ont l'air innocent… À moins d'analyser en détail le code de l'appli, tu ne peux rien garantir. D'où le niveau de permission qui me semble tout à fait logique: permettez-vous à l'appli d'accéder à vos contacts et d'en faire ce que le développeur veut bien en faire?
Ce que je n'ai pas compris, c'est si le sujet du conflit vient de la permission READ, auquel cas c'est à mon avis le dev qui est complètement responsable, ou si Google a en plus une couche d'analyse du code qui lui a fait penser à tort que les données issues des contacts était envoyée sur un serveur tiers. Là, sans analyser le truc en détail, c'est dur de conclure. Possibilité 1: Le dev dit que l'analyseur de code de Google a picolé et que le système d'appel est foireux, c'est bien possible. Possibilité 2: Le dev est démoniaque et remontait bien les contacts sur un serveur Ouzbeck par un moyen détourné, il s'est fait gauler par l'analyse du code et a monté un bateau pour se justifier (ça me semble peu probable, mais on ne sait jamais, je ne connais pas ce gars-là). Possibilité 3: il y a une faille de sécu qui fait que la remontée des contacts est théoriquement possible, bien que ça ne soit pas la volonté du dev. Honnêtement, ça ne me parait pas impossible, l'appli manipule des flux venant de sources non contrôlées, et les attaques par buffer overflow et autres, c'est réel.
En gros, comme on n'a qu'une version de l'histoire, on peut conclure que "c'est aussi simple que ça", mais ça ne parait pas impossible que ça ne soit pas aussi simple que ça.
Dans tous les cas, le workflow de Google semble être typique d'une entité en position de monopole: si tu fais la moindre erreur (ou que Google fait la moindre erreur), t'es ban sans discussion, et derrière le service pour rectifier est merdique. On ne peut pas donner tort à l'auteur sur le fait qu'ils auraient très bien pu ne pas accepter la mise à jour et laisser la version précédente dans leur store.
[^] # Re: Description objective du problème?
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0).
On ne parle pas de permission mais d'annoncer une potentielle collecte. Ou pas.
Je crois que son appli n'a pas été bannie sur une maj en particulier. C'est plutôt au niveau de google que le contrôle a du changer. La fonctionnalité existait il me semble déjà.
[^] # Re: Description objective du problème?
Posté par Sylvain Berfini (site web personnel) . Évalué à 2 (+1/-0).
La permission android.permission.READ_CONTACTS tu es obligé de la demander à l'utilisateur (sauf pour les téléphones avec une vieille version d'Android dans ce cas là tu l'as direct), et ça Google le sait.
Peut-être le problème est-il simplement que le développeur à oublié de le préciser dans la fiche Play Store de renseignements sur les données collectées ? Ou alors il s'agit un algorithme de Google d'analyse automatique qui a mal fait son travail peut être ? Enfin il est possible que la personne en charge de tester l'application ait mal compris l'intention de l'application quand elle lui a demandé l'accès aux contacts et qu'elle ait fait preuve de zèle ?
Avec Linphone on collecte les contacts et on envoie les numéros de téléphone à un serveur (de manière sécurisée), et on a jamais eu de soucis avec Google et le Play Store.
[^] # Re: Description objective du problème?
Posté par Psychofox (Mastodon) . Évalué à 5 (+3/-1).
Mais vous le dites:
Image de l'icône
Cette appli peut recueillir ces types de données
Informations personnelles, Contacts et Appareil ou autres ID
L'auteur de Conversation ne voulait pas le dire parce que c'est faux et que son appli n'utilise les contacts que localement.
[^] # Re: Description objective du problème?
Posté par arnaudus . Évalué à 4 (+2/-1).
Est-ce la distinction existe pour Google? Est-ce qu'il y a deux niveaux d'accès aux contacts? (lecture seule ou lecture + upload)? Si ça n'est pas le cas et que tout tombe dans "recueillir", je ne vois pas comment un dev pourrait expliquer à Google qu'il veut lire les données des contacts tout en ne demandant pas le seul niveau de permission qui permet de le faire…
[^] # Re: Description objective du problème?
Posté par Psychofox (Mastodon) . Évalué à 6 (+4/-1). Dernière modification le 15 février 2024 à 18:47.
Ça ne peut pas exister ce type de permission (lecture + upload) et je ne vois pas vraiment comment ça pourrait être mis en place.
Une appli a accès au réseau ou pas.
Une appl a accès aux contacts ou pas.
Ce sont deux permissions distinctes et indépendantes.
Note que dans tous les cas c'est l'utilisateur qui donne l'accord à l'utilisation d'accéder ou non aux contacts. Ce n'est pas caché. Google veut en plus qu'on déclare qu'on collecte des données sur un serveur tiers…même si on ne le fait pas.
[^] # Re: Description objective du problème?
Posté par Maclag . Évalué à 10 (+9/-0).
De ce que j'ai compris du fil, l'appli déclarait bien qu'elle accédait aux contacts, mais dans la description de la politique sur le respect de la vie privée, il n'était pas mentionné qu'elle téléversait la liste de contacts, précisément parce qu'elle ne le fait pas.
Comme écrit dans un autre commentaire, Google n'est pas câblée pour prévoir une app qui accède à la liste sans la collecter côté fournisseur de l'app, et leurs procédures doivent être plus ou moins automatisées: si tu accèdes à la liste de contacts, tu DOIS mentionner que tu la téléverses et quel usage tu en fais.
En fait il aurait aussi pu résoudre le problème en téléversant les liste de contacts et écrire dans la politique de respect de la vie privée:
"Nous collectons la liste de vos contacts parce que Google est incapable de supposer qu'on puisse y accéder sans la siphonner et nous jette si on ne le fait pas. Nous la détruisons immédiatement parce que nous n'avons aucun intérêt à la garder"
et ça passait…
[^] # Re: Description objective du problème?
Posté par Arkem . Évalué à 3 (+2/-0). Dernière modification le 17 février 2024 à 14:31.
Ne serait-il pas possible, en ne téléversant rien du tout, d'indiquer plutôt que "l'autorisation d'accéder aux donnée de contacts nous permet de les récupérer, mais que nous ne le faisons pas par respect pour la vie privée de nos utilisateurs" ?
Vu comme ça, l'utilisateur est bien averti de ce qu'on fait de ses données, ce qui devrait satisfaire la politique de Google, non ?
[^] # Re: Description objective du problème?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Il est possible d’indiquer sur le site officiel l’usage qui est fait de chaque permission. Encore faudrait-il que les usagers du store aillent sur le dit site (ou ça pourrait être dans le descriptif au détriment des autres informations de présentation…)
Par contre les applis ne contrôlent pas les chaînes que le système présent aux usager par rapport aux permissions déclarées.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Description objective du problème?
Posté par Tibo cocoecolo (site web personnel) . Évalué à 3 (+2/-0).
Petit indice dans le journal pour la résolution :
Pour être clair, la permission READ_CONTACTS était bien présente avant que Google retire l’application de Google Play. Le développeur a retiré cette permission de la version Google Play pour permettre son retour. https://codeberg.org/iNPUTmice/Conversations/commit/85984627370e48af55d77159fe7f4b332ab28482
# App gratuite
Posté par anubis . Évalué à 3 (+2/-0).
Pour fêter le retour, l'app est gratuite sur le PlayStore jusqu'à ce soir (annonce : https://gultsch.social/@daniel/111933922710829462)
Profitez-en pour la faire installer à vos proches qui n'utilisent pas F-Droid :)
Et à bientôt sur linuxfr@chat.jabberfr.org !
aussi sur le salon xmpp:linuxfr@chat.jabberfr.org?join
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.