En lisant l'article, je me suis dit : bon, va falloir tout passer par un VPN et filtrer en sortie. Mais ça ne fonctionne pas : le trafic émis par le chipset Qualcomm passe en dehors de l'OS, et donc en dehors du VPN. Saloperie.
Posté par Xanatos .
Évalué à 7.
Dernière modification le 25 avril 2023 à 22:36.
Sans surprise pour un lecteur libre averti et/ou soucieux de sa vie privée, il est de notoriété publique que les baseband sont des boites noires; RMS en avait parlé il y a plus d'une décennie si je ne me trompe.
Là ou ce billet est intéressant c'est qu'il soulève que /e/OS n'est pas exempt de fuites malgré l'effort de degoogliser la Rom (dns, ntp, availability, middleware, etc) > https://doc.e.foundation/what-s-e#degoogling--ungoogling
Une réponse de /e/OS serait appréciable, peut-être un bug ?
J'y découvre Nitro, qui commercialise des Smartphones, mais pas que. Des Allemands, décidément > https://shop.nitrokey.com/shop
Ce sont des Google Pixel (sans Qualcomm donc) avec GrapheneOS avec la possibilité de physiquement supprimer les capteurs.
J'étais persuadé que GrapheneOS vendait des Pixels avec GrapheneOS instaallé de son côté, il n'en n'est rien.
40% plus onéreux que le Pixel, cela cible le prudent très aisé.
J'apprends par ailleurs le fonctionnement de A-GPS:
These new uses required GPS signals to penetrate overhead obstructions, such as trees and roofs. Thus, the “assisted GPS” or A-GPS solution was born. With A-GPS the phone downloads various files containing orbits and statuses of satellites with the approximate GPS satellite locations for the next 7 days to help quickly determine phone’s location.
Ce qui pourrait expliquer que lorsque que je n'utilise pas le GPS plusieurs semaines qu'il mette 3 plombes à se verrouiller.
Une réponse de /e/OS serait appréciable, peut-être un bug ?
C'est un truc qui vient avec le driver de la puce. Le problème c'est qu'avec une rom officielle du fabricant vient l'EULA nécessaire mais pas dans celle de /e/.
A noter que les dev de grapheneOS eux-même (dont l'OS est utilisé par la boite qui a écrit cet article et vend des smartphones fournis avec graphene) ont réagi pour dire que l'article fait dans le sensationnel:
"NitroKey n'a pas découvert de porte dérobée. Le message est très sensationnaliste et il est regrettable qu'ils ne nous l'aient pas adressé en premier."
(…) "Il n'y a pas de porte dérobée connue dans Snapdragon ou Tensor, et personne n'a trouvé de preuve de porte dérobée. Le titre du message ici est tout simplement faux".
j'ai édité mon message plus haut et je me suis emmêlé les pinceaux. Je voulais dire entreprise plutôt que fondation. L'association loi 1901 est justement la /e/ fundation.
Posté par Psychofox (Mastodon) .
Évalué à 3.
Dernière modification le 27 avril 2023 à 10:08.
Je suis perplexe. Son post est à la fois très honnête et terriblement naïf/dangereux pour sa fondation. Basiquement il dit:
on savait déjà que qualcomm récupérait des informationes personnelles et identifiables sur nos utilisateurs.
on n'a rien fait pour prévenir nos utilisateurs, on espérait que personne n'en parlerait.
on est sciemment complice d'un viol de la GPDR depuis des mois/années.
on va voir pour faire mieux mais sans vraiment faire de promesses.
À part chercher à ce que sa fondation et son association loi 1901 soit oblitérée par un procès, je ne suis pas sûr de comprendre ce qu'il cherche par ce message.
Où alors c'est qu'il fonctionne en roue libre façon Elon Musk sans prendre la peine de demander conseil à son service légal.
La première chose qui me dérange avec cet article, c'est que le seul fait sur lequel tout le raisonnement tient, c'est deux requêtes DNS qui ont été capturées par Wireshark. Le reste n'est que spéculation en se basant sur des "Terms of Service", des documents standard où vous vendez votre âme au diable. J'ai peut être raté quelque chose, il dit que des informations personnelles transitent de manière non chiffrée mais ne donne pas plus d'infos concrètes sur les données qu'il a réellement interceptées.
La deuxième chose, c'est que cet article est produit par un concurrent qui vends des produits soi-disant plus sûrs.
C'est pas pour défendre Qualcomm, l'impossibilité de bloquer ne serait-ce que des pings "vers la maison" est dérangeante, mais cet article me laisse sur ma faim.
Investigating this further we can see that the packages are sent via the HTTP protocol and are not encrypted using HTTPS, SSL or TLS. That means that anyone else on the network, including hackers, government agencies, network administrators, telecom operators, local and foreign can easily spy on us by collecting this data, store them, and establish a record history using the phone’s unique ID and serial number Qualcomm is sending over to their mysteriously called Izat Cloud.
Y a pas que les deux requêtes DNS !
Par contre, je peux comprendre que, si la puce Qualcomm contourne tout l'OS, ils aient choisi de faire du HTTP en clair. C'est compliqué de mettre du TLS dans une petite puce…
À priori c'est un programme en java privilégié dans android fourni avec le driver et pas le firmware de la puce elle-même qui communique.
Et c'est un service qui sert à faire une geolocalisation sommaire pour obtenir les meilleures satellites disponibles et "accrocher" plus vite. Alors certe le problème c'est la télémétrie qui n'est pas vraiment nécessaire à obtenir ces infos satellites mais on n'est pas dans le cas d'une puce qui outrepasse l'OS.
Au final, je pense que tu as raison : l'article est peut être juste sensationnaliste…
Pour ce qui est des requêtes vers les serveurs de Google, le dev de microg à répondu :
android.clients.google.com is used by many android related services by Google, not only Play Store. This specific request is likely coming from @microg, as is described in the /e/OS documentation
Et les devs de GraphenOS ont également répondu sur Reddit :
NitroKey did not discover a backdoor. The post is very sensationalized and it's unfortunate they didn't run this by us first. The title used for the post here is editorialized and doesn't match what the article actually states. This is not a backdoor. […]
Fairphone 2 sous LineageOS 17.1 (Android 10)
A l'allumage, des requêtes DNS sur des domaines appartenant à Google (connectivitycheck.gstatic.com, time.android.com…). Rien vers izatcloud.net. Si j'active la localisation :
Fairphone envoie une requète DNS sur xtrapath6.izatcloud.net.
Le serveur DNS répond 13.225.34.43.
Fairphone envoie GET /xtra2.bin avec le User Agent User-Agent : Dalvik/2.1.0 (Linux; U; Android 10; FP2 Build/QQ3A.200805.001).
Le serveur répond en envoyant son header et d'autres infos pas exploitables.
Après quelques échanges brefs, le serveur envoie 61 ko de données au Fairphone. Si ça vous intéresse, vous pouvez récupérer ce fichier bin en rentrant son URL dans Firefox.
Sony XPeria XA2 sous /e/ OS 1.8.1
A l'allumage, il y a des requêtes DNS vers murena.io et pool.ntp.org. J'ai aussi quelques requêtes vers Google à cause d'une appli installée dessus. Comme pour le FP2, la requête vers izatcloud.net se fait à l'activation de la localisation. Le XA2 envoie un GET /xtra3grc.bin. Il s'en suit le même type de dialogue qu'avec le FP2. Je ne vous recopie pas l'User Agent envoyé par le Sony vers izatcloud car il y a deux longues suites de caractères qui pourraient être uniques.
Conclusion : il semble s'agir de données nécessaire au fonctionnement du A-GPS. Si vous avez des recommandations sur les paquets à surveiller, n'hésitez pas.
Au delà de l'aspect technique, je m'interroge sur la manière de communiquer de Nitrokey et le dénigrement des rares solutions éthiques du monde des smartphones que sont Fairphone et /e/ OS. On n'imaginerait pas Red Hat écrire un communiqué sur une faille dans Debian ou Firefox tout en vantant leur immunité.
Sur le XA2, en utilisant le routage TOR fourni par /e/ OS, je ne vois plus de requête DNS vers Izatcloud ou d'échange avec une IP d'Izatcloud/Cloudfront.
# Bouh
Posté par cg . Évalué à 6.
En lisant l'article, je me suis dit : bon, va falloir tout passer par un VPN et filtrer en sortie. Mais ça ne fonctionne pas : le trafic émis par le chipset Qualcomm passe en dehors de l'OS, et donc en dehors du VPN. Saloperie.
# Baseband & co
Posté par Xanatos . Évalué à 7. Dernière modification le 25 avril 2023 à 22:36.
Sans surprise pour un lecteur libre averti et/ou soucieux de sa vie privée, il est de notoriété publique que les baseband sont des boites noires; RMS en avait parlé il y a plus d'une décennie si je ne me trompe.
Là ou ce billet est intéressant c'est qu'il soulève que /e/OS n'est pas exempt de fuites malgré l'effort de degoogliser la Rom (dns, ntp, availability, middleware, etc) > https://doc.e.foundation/what-s-e#degoogling--ungoogling
Pour vos filtres:
Une réponse de /e/OS serait appréciable, peut-être un bug ?
J'y découvre Nitro, qui commercialise des Smartphones, mais pas que. Des Allemands, décidément > https://shop.nitrokey.com/shop
Ce sont des Google Pixel (sans Qualcomm donc) avec GrapheneOS avec la possibilité de physiquement supprimer les capteurs.
J'étais persuadé que GrapheneOS vendait des Pixels avec GrapheneOS instaallé de son côté, il n'en n'est rien.
40% plus onéreux que le Pixel, cela cible le prudent très aisé.
J'apprends par ailleurs le fonctionnement de A-GPS:
Ce qui pourrait expliquer que lorsque que je n'utilise pas le GPS plusieurs semaines qu'il mette 3 plombes à se verrouiller.
[^] # Re: Baseband & co
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
https://community.e.foundation/t/connections-to-izatcloud-net/19219
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Baseband & co
Posté par Psychofox (Mastodon) . Évalué à 6.
C'est un truc qui vient avec le driver de la puce. Le problème c'est qu'avec une rom officielle du fabricant vient l'EULA nécessaire mais pas dans celle de /e/.
A noter que les dev de grapheneOS eux-même (dont l'OS est utilisé par la boite qui a écrit cet article et vend des smartphones fournis avec graphene) ont réagi pour dire que l'article fait dans le sensationnel:
https://www.reddit.com/r/privacy/comments/12yii9u/comment/jhojlr7/?context=1
[^] # Re: Baseband & co
Posté par Maderios . Évalué à 2.
Effectivement et c'est plutôt rassurant:
[^] # Re: Baseband & co
Posté par Psychofox (Mastodon) . Évalué à 3.
j'ai édité mon message plus haut et je me suis emmêlé les pinceaux. Je voulais dire entreprise plutôt que fondation. L'association loi 1901 est justement la /e/ fundation.
[^] # Re: Baseband & co
Posté par audionuma (site web personnel, Mastodon) . Évalué à 3.
Message de Gaël Duval :
Qualcomm chipsets data collection linked to the A/GPS service in /e/OS
https://community.e.foundation/t/qualcomm-chipsets-data-collection-linked-to-the-a-gps-service-in-e-os/48982
[^] # Re: Baseband & co
Posté par Psychofox (Mastodon) . Évalué à 3. Dernière modification le 27 avril 2023 à 10:08.
Je suis perplexe. Son post est à la fois très honnête et terriblement naïf/dangereux pour sa fondation. Basiquement il dit:
À part chercher à ce que sa fondation et son association loi 1901 soit oblitérée par un procès, je ne suis pas sûr de comprendre ce qu'il cherche par ce message.
Où alors c'est qu'il fonctionne en roue libre façon Elon Musk sans prendre la peine de demander conseil à son service légal.
# Qui me parle?
Posté par ted (site web personnel) . Évalué à 10.
La première chose qui me dérange avec cet article, c'est que le seul fait sur lequel tout le raisonnement tient, c'est deux requêtes DNS qui ont été capturées par Wireshark. Le reste n'est que spéculation en se basant sur des "Terms of Service", des documents standard où vous vendez votre âme au diable. J'ai peut être raté quelque chose, il dit que des informations personnelles transitent de manière non chiffrée mais ne donne pas plus d'infos concrètes sur les données qu'il a réellement interceptées.
La deuxième chose, c'est que cet article est produit par un concurrent qui vends des produits soi-disant plus sûrs.
C'est pas pour défendre Qualcomm, l'impossibilité de bloquer ne serait-ce que des pings "vers la maison" est dérangeante, mais cet article me laisse sur ma faim.
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Qui me parle?
Posté par Glandos . Évalué à 5.
Y a pas que les deux requêtes DNS !
Par contre, je peux comprendre que, si la puce Qualcomm contourne tout l'OS, ils aient choisi de faire du HTTP en clair. C'est compliqué de mettre du TLS dans une petite puce…
[^] # Re: Qui me parle?
Posté par Psychofox (Mastodon) . Évalué à 7.
À priori c'est un programme en java privilégié dans android fourni avec le driver et pas le firmware de la puce elle-même qui communique.
Et c'est un service qui sert à faire une geolocalisation sommaire pour obtenir les meilleures satellites disponibles et "accrocher" plus vite. Alors certe le problème c'est la télémétrie qui n'est pas vraiment nécessaire à obtenir ces infos satellites mais on n'est pas dans le cas d'une puce qui outrepasse l'OS.
[^] # Re: Qui me parle?
Posté par FLOZz (site web personnel) . Évalué à 6.
Au final, je pense que tu as raison : l'article est peut être juste sensationnaliste…
Pour ce qui est des requêtes vers les serveurs de Google, le dev de microg à répondu :
→ https://mastodon.social/@larma/110260138458948356
Et les devs de GraphenOS ont également répondu sur Reddit :
→ https://old.reddit.com/r/privacy/comments/12yii9u/german_security_company_nitrokey_proves_that/jhojlr7/
# Travaux pratiques
Posté par Thecross . Évalué à 10.
Avertissement : je ne maitrise pas Wireshark.
Fairphone 2 sous LineageOS 17.1 (Android 10)
A l'allumage, des requêtes DNS sur des domaines appartenant à Google (connectivitycheck.gstatic.com, time.android.com…). Rien vers izatcloud.net. Si j'active la localisation :
Sony XPeria XA2 sous /e/ OS 1.8.1
A l'allumage, il y a des requêtes DNS vers murena.io et pool.ntp.org. J'ai aussi quelques requêtes vers Google à cause d'une appli installée dessus. Comme pour le FP2, la requête vers izatcloud.net se fait à l'activation de la localisation. Le XA2 envoie un GET /xtra3grc.bin. Il s'en suit le même type de dialogue qu'avec le FP2. Je ne vous recopie pas l'User Agent envoyé par le Sony vers izatcloud car il y a deux longues suites de caractères qui pourraient être uniques.
Conclusion : il semble s'agir de données nécessaire au fonctionnement du A-GPS. Si vous avez des recommandations sur les paquets à surveiller, n'hésitez pas.
Au delà de l'aspect technique, je m'interroge sur la manière de communiquer de Nitrokey et le dénigrement des rares solutions éthiques du monde des smartphones que sont Fairphone et /e/ OS. On n'imaginerait pas Red Hat écrire un communiqué sur une faille dans Debian ou Firefox tout en vantant leur immunité.
[^] # Re: Travaux pratiques
Posté par raphj . Évalué à 6.
Oui, d'ailleurs sur le PinePhone (et tout appareil GNU/Linux muni d'un modem avec GPS ?), on peut injecter les données A-GPS avec ces lignes :
[^] # Re: Travaux pratiques
Posté par cg . Évalué à 5.
Si tu as la possibilité, peux-tu activer un VPN (ou Tor ?) et voir si les requêtes passent dans le VPN ou à côté ?
On se demande quand même pourquoi ce service, qui a l'air trivial, est planqué dans un blob au lieu de faire partie d'un composant de l'OS.
[^] # Re: Travaux pratiques
Posté par Thecross . Évalué à 3.
Sur le XA2, en utilisant le routage TOR fourni par /e/ OS, je ne vois plus de requête DNS vers Izatcloud ou d'échange avec une IP d'Izatcloud/Cloudfront.
[^] # Re: Travaux pratiques
Posté par cg . Évalué à 3.
Merci, j'ai donc probablement dit une connerie dans mon premier commentaire ("Bouh").
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.