PROJET AUTOBLOG


Le Blog de Genma

source: Le Blog de Genma

⇐ retour index

Lire de la presse en 2026 - Cafeyn

jeudi 1 janvier 1970 à 01:00

# Introduction

Durant mon enfance, adolescence et le début des mes années d'adulte, au siècle dernier, dans les années 80-90, à une époque où le web grand public n'existait pas (j'ai commencé à aller sur Internet à la fin des années 90), j'ai beaucoup lu de presse papier. Je peux en vrac et dans le désordre citer Sciences et Vie junior et Sciences et Vie, le Dorothée Magazine, Animeland, Linux Magazine et Linux Pratique...

En 2026, ère où tout est numérique, où je lis depuis plus de 20 ans beaucoup, beaucoup de choses uniquement en ligne (avec un agrégateur RSS...), ce rapport au magazine me manque.

Avec l'abonnement, gratuit au réseau de médiathèques de ma communauté de commune, j'ai un abonnement à Cafeyn (payé indirectement pas mes impôts).

# Cafeyn ?

Cafeyn regroupe plus de 2 500 titres de journaux et de magazines, français et internationaux en version digital. Cafeyn est accessible depuis tous vos appareils : smartphone, tablette ou ordinateur et via l'application ou le web. Vous pouvez commencer à lire un magazine sur un appareil et reprendre au même endroit sur un autre, pour une expérience de lecture optimale.

Il existe une offre payante pour s'abonner directement au service. Pour les abonnés chez Free (l'opérateur), il est également possible de souscrire à une offre https://www.free.fr/freebox/cafeyn

# Petit retour rapide d'expérience

J'ai donc deux usages /consultation à mon compte Cafeyn (lié à mon compte de la médiathèque).
– Un usage de consultation depuis un ordinateur, via un navigateur. Firefox sous Linux (Ubuntu). Et ça marche bien.
– Un usage sur tablette

Pour le mode tablette, avec l'application Cafeyn, ayant deux appareils sous 2 OS différents (un Ipad 9th génération sur Ios ; une tabelle VOLLA sous /e/OS de Murena - sur cette dernière, j'ai toute une série d'article à rédiger) j'ai suivi ce tutoriel Utilisateur médiathèque, puis-je utiliser Cafeyn depuis mon smartphone ? Et là encore ça marche.

Via le service en ligne, j'ai une synchronisation sur l'avancement de ma lecture de quelques magazines. Pas grand chose à dire de plus.

Adguard (PiHole), 2 smartphones : Android vs /e/OS

jeudi 1 janvier 1970 à 01:00

# Introduction

J'ai depuis un moment une instance Adguard (l'équivalent de Pihole) à la maison, et toutes les résolutions DNS des appareils connectés passent par ce Pihole, ce qui me permet de bloquer un certains nombres de trackers et autres pisteurs. J'utilise plusieurs listes de blocage dans la configuration, dont celle de SebSauvage (merci à lui). Je ne m'étends pas sur Adguard, j'ai une série d'articles en cours /à finaliser sur le sujet.

La question que je me suis posé et qui a valu la rédaction de cet article est la suivante : depuis mon passage d'Android (qui tournait sur un appareil Samsung S21) à Murena /e/OS (sur un Fairphone 6), avec les mêmes usages, et que cela change quelque chose pour ma vie privée etc. J'ai d'ailleurs documenté dans mes articles précédents la migration de l'un à l'autre.

# Protocole de tests

Le protocole est simple : j'ai 2 smartphones, le wifi est allumé au même moment pour comparer les requêtes au lancement de la connexion Wifi. Et ensuite je fais les mêmes actions sur les 2 téléphones et je compare dans Adguard. Et le résultat est assez intéressant

Sous /e/OS, voilà ce que ça donne dans Adguard :

Sous Android, voilà ce que ça donne dans Adguard :

# Est-ce que les demandes DNS sous Android ne se font pas sous /e/OS du fait du blocage des trackers ?

La réponse est clairement OUI.

Quand on compare ce qui est comparable, à savoir le lancement au même moment d'une application, le Bon coin (choisie car forcément elle a des trackers), si on compare la liste des requêtes DNS faite par l'appareil sous Android, on voit TRES clairement la différence.

Sous /e/OS, voilà ce que ça donne dans Adguard :

Sous Android, voilà ce que ça donne dans Adguard :

Le résultat attendu vs l'obtenu

Un écart de volume massif : l'Android stock va inonder AdGuard de requêtes DNS (majoritairement Google, dont une grosse part bloquée), tandis que le /e/OS sera quasi silencieux côté Google — mais attention, une partie de son silence vient d'un blocage en amont sur l'appareil lui-même.

# Côté Android stock (avec Play Services)

Dès la connexion Wi-Fi, il y a une rafale de dizaines/centaines de requêtes en quelques minutes, et ce même sans toucher au téléphone :
connectivitycheck.gstatic.com, play.googleapis.com, android.clients.google.com (enregistrement/check-in de l'appareil), mtalk.google.com (push), time.android.com (NTP)

Télémétrie : app-measurement.com, firebase-settings.crashlytics.com, doubleclick.net, googleadservices.com, pagead.googleswap.net...
Une grande partie sera bloquée par AdGuard (compteur "blocked" élevé), et ça continue en arrière-plan même idle : check-ins périodiques, vérifications des mise à jour Play, synchronisation des comptes "Google".

# Côté /e/OS

Presque aucun domaine Google par défaut : il n'y a pas de vérification de connectivité Google, pas de NTP non-Google, géolocalisation réseau via beaconDB au lieu de Google, DNS par défaut non-Google

Exceptions microG : android.clients.google.com environ une fois par jour (enregistrement d'appareil, identifiants tronqués) et mtalk.google.com pour les notifications push — désactivables dans microG ( appels anonymes aux serveurs de Google)

A la place des domaines Google, on a domaines de la e Foundation qui peuvnet êrte appelés, à savoir : e.foundation, gitlab.e.foundation (récupération des listes de filtrage), ecloud.global / murena.io (services Murena)

Le point clé est que la fonctionnalité native de /e/OS, Advanced Privacy, bloque déjà les trackers localement au niveau DNS de l'appareil (en se resposant sur une listes fusionnée Exodus Privacy / AdAway). Donc les requêtes DNS associées aux mouchards des applications ne sont souvent même jamais transmises à AdGuard, et par conséquence ils n'apparaîtront pas dans tes logs.

# Conclusions

En résumé, en lançant les mêmes applications, étant que donné que les applications identiques embarquent les mêmes SDK sur les deux téléphones,
* Android : leurs trackers (crashlytics, analytics, pubs) apparaîtront dans AdGuard, en partie bloqués
* /e/OS : une partie sera bloquée par Advanced Privacy avant d'arriver à AdGuard, et la télémétrie Firebase/Google est anonymisée par microG

# Pièges qui fausseraient le test, à prendre en compte

* DNS privé (DoT/DoH) : vérifie qu'il est désactivé sur les deux téléphones (Paramètres → Réseau → DNS privé), sinon les requêtes contournent AdGuard et l'un des deux paraîtra anormalement "propre". Chrome peut aussi faire du DoH dans l'app.
* Hide My IP sur /e/OS : si ces options liés à la vie privée sont activé, le trafic peut ne plus passer par AdGuard.
* Randomisation MAC : le smartphone change d'adresse MAC par SSID. Il faut bien identifier les clients par IP/nom dans AdGuard avant le test, ou fixer la MAC adresse privée utilisé.
* Cache DNS : il faut passer par le mode avion sur chaque téléphone avant le test pour repartir de zéro.

# Aller plus loin ?

L'étape d'après sera de passer par Wireshark pour voir les trafics réseaux.
Pour le protocole de test, lancer les mêmes applications, sur les 2 téléphones et voir les requêtes envoyées.

Adguard (PiHole), 2 smartphones : Android vs /e/OS

jeudi 1 janvier 1970 à 01:00

# Introduction

I have had an AdGuard instance (the equivalent of Pihole) at home for a while now, and all DNS resolutions from connected devices go through this Pihole, which allows me to block a certain number of trackers and other tracers. I use several blocklists in the configuration, including the one from SebSauvage (thanks to him). I will not elaborate on AdGuard ; I have a series of articles in progress/to be finalized on the subject.

The question I asked myself, which led to the writing of this article, is the following : since my switch from Android (running on a Samsung S21 device) to Murena /e/OS (on a Fairphone 6), with the same usage, does it change anything for my privacy, etc. I have in fact documented the migration from one to the other in my previous articles.

# Test protocol

The protocol is simple : I have 2 smartphones, the Wi-Fi is turned on at the same time to compare the requests at the launch of the Wi-Fi connection. Then I perform the same actions on the 2 phones and I compare in AdGuard. And the result is quite interesting

Under /e/OS, here is what it looks like in AdGuard :

Under Android, here is what it looks like in AdGuard :

Are the DNS requests under Android not made under /e/OS due to tracker blocking ?

The answer is clearly YES.

When comparing what is comparable, namely launching the same application at the same time, Le Bon Coin (chosen because it necessarily has trackers), if we compare the list of DNS requests made by the device under Android, we can VERY clearly see the difference.

Under /e/OS, here is what it looks like in AdGuard :

Under Android, here is what it looks like in AdGuard :

The expected vs the obtained result

A massive volume gap : stock Android will flood AdGuard with DNS requests (mostly Google, with a large portion blocked), while /e/OS will be almost silent on the Google side — but be careful, part of its silence comes from upstream blocking on the device itself.

# On the stock Android side (with Play Services)

As soon as the Wi-Fi connection is established, there is a burst of tens/hundreds of requests within a few minutes, even without touching the phone :
connectivitycheck.gstatic.com, play.googleapis.com, android.clients.google.com (device registration/check-in), mtalk.google.com (push), time.android.com (NTP)

Telemetry : app-measurement.com, firebase-settings.crashlytics.com, doubleclick.net, googleadservices.com, pagead.googleswap.net...
A large portion will be blocked by AdGuard (high "blocked" counter), and it continues in the background even when idle : periodic check-ins, Play update checks, "Google" account syncs.

# On the /e/OS side

Almost no Google domains by default : there is no Google connectivity check, non-Google NTP, network geolocation via beaconDB instead of Google, non-Google default DNS

microG exceptions : android.clients.google.com about once a day (device registration, truncated identifiers) and mtalk.google.com for push notifications — can be disabled in microG (anonymous calls to Google's servers)

Instead of Google domains, we have e Foundation domains that may be called, namely : e.foundation, gitlab.e.foundation (fetching the filtering lists), ecloud.global / murena.io (Murena services)

The key point is that the native /e/OS feature, Advanced Privacy, already blocks trackers locally at the device's DNS level (relying on a merged Exodus Privacy / AdAway list). So the DNS requests associated with the apps' spyware are often never even transmitted to AdGuard, and consequently they will not appear in your logs.

# Conclusions

In summary, when launching the same applications, given that identical apps embed the same SDKs on both phones,
* Android : their trackers (crashlytics, analytics, ads) will appear in AdGuard, partly blocked
* /e/OS : a portion will be blocked by Advanced Privacy before reaching AdGuard, and the Firebase/Google telemetry is anonymized by microG

# Pitfalls that would skew the test, to take into account

* Private DNS (DoT/DoH) : check that it is disabled on both phones (Settings → Network → Private DNS), otherwise the requests bypass AdGuard and one of the two will look abnormally "clean". Chrome can also do DoH within the app.
* Hide My IP on /e/OS : if these privacy-related options are enabled, the traffic may no longer go through AdGuard.
* MAC randomization : the smartphone changes its MAC address per SSID. You must properly identify the clients by IP/name in AdGuard before the test, or fix the private MAC address used.
* DNS cache : you need to go through airplane mode on each phone before the test to start from scratch.

# Going further ?

The next step will be to use Wireshark to look at the network traffic.
For the test protocol, launch the same applications on the 2 phones and look at the requests sent.

Ce que j'aime chez /e/OS (et ce que j'aimerais voir améliorer)

jeudi 1 janvier 1970 à 01:00

# Ce que j'aime chez /e/OS

Cette liste est non exhaustive et évoluera/grandira avec le temps.

Dans les fonctionnalités que j'apprécie, certains sont natives - ce qui rassure sur la migration vers cet Android alternatif, degooglisé, mais d'autres sont belles et bien spécifiques et caractéristiques à /e/OS.

# Des mises à jour régulières

J'ai régulièrement des mises à jour avec les correctifs de sécurité et quelques corrections de bugs. J'ai eu droit à une mise à jour majeure (passage de la branche 4.2 à la branche 4.3.x).

# La documentation, riche

Pour la plupart des fonctionnalités que je souhaite approfondir, il y a une page dédiée dans la documentation. Certes le projet n'est pas récent (et a quelques années), mais il est appréciable de pouvoir trouver des informations précises et pertinentes, succincte, en un endroit centralisé, à savoir : https://doc.e.foundation/fr/o

## L'agenda qui se cale sur l'heure locale

J'utilise l'application d'agenda, qui est synchronisé à mes agendas professionnels et personnels.

Je suis allé pour une mission professionnelle au Portugal, pays qui a une heure de décalage (en moins) avec la France. Le téléphone s'est calé sur l'heure locale. Et l'agenda s'est calé sur ces horaires, avec les rappels au bon moment. J'avais une réunion à 10h heure française, elle apparaissait comme ayant lieu à 9h heure locale dans l'agenda, et les rappels avant l'événement se sont eux aussi adaptés/calés, me permettant de ne pas rater mon rendez-vous !

## /e/OS et partage de connexion

Si la connexion VPN (Wireguard) est activé sur le smartphone partageant sa connexion en Wifi, les appareils connectés via le partage de connexion bénéficie également de cette connexion tunnelisée/sécurisée. Une bonne chose, car sur mon ancien smartphone sur la version Samsung d'Android, je devais activer sur l'appareil en lui-même (celui utilisant la connexion par le Wifi partagé) la connexion Wireguard.

## le voice to text en local pour les SMS

Comme indiqué dans la documentation, sous le capot, cette fonctionnalité exécute le modèle vocal open source NVIDIA Parakeet TDT (0,6 milliard de paramètres, quantifié en INT8) via ONNX Runtime, sous la forme d'un clavier /e/OS. J'avais déjà cette fonctionnalité sur mon ancien téléphone, sous Android, mais la fonctionnalité passait par les serveurs de Google, je ne l'avais donc jamais utilisé. Là, comme c'est en local. Et ça marche plutôt bien. Et ce même en environnement bruyant.
Cela me permet de faire de la prise de notes en marchant dans la rue, en me concentrant sur mon trajet et non sur la saisie au clavier sur mon smartphone.

## Les liens Google play

Sous /e/OS, dans le navigateur, un lien pour télécharger une application sur le store de Google, le “Google play”, s'ouvre bien dans le store alternatif "App Lounge" de /e/OS. C'est transparent et pratique.

# Les options liées à la vie privée

/e/OS se démarque des Android alternatifs par deux aspects forts : la degooglisation /indépendance aux fonctionnalités de Google et des options natives intégrées liées à la vie privée. Ces options liée à la vie privées sont documentées : Advanced Privacy

## Intégration des données d'Exodus privacy

/e/OS intègre les données d'Exodus Privacy directement au sein de sa boutique d'applications, App Lounge, pour afficher un score de confidentialité et lister les traceurs des applications avant même leur installation

## Blocage des trackers

Tous les trackers des applications sont bloqués par défaut. Il reste possible de les autoriser un par un, ponctuellement si besoin. Mais pour toutes les applications propriétaires que j'utilise pour lesquelles les trackers sont blockées, je n'ai pas eu à faire d'autorisation ; les applications marchent (du coup on peut se demander l'intérêt de ces trackers, pour la plupart non légitimes et clairement non nécessaires si ce n'est pour de la collecte de données à des fins publicitaires ou autre, et qui dans tous les cas sont des atteintes au droit à la vie priée).

## Falsifier son IP ou ma localisation GPS

/e/OS dispose d'une option "Falsifier ma Position". Les connexions passent alors par le réseau TOR (pour router l'intégralité du trafic de l'appareil Android via Tor)

## Adresse mac aléatoire

Il est possible de rendre aléatoire l'adresse Mac de la carte Wifi du smartphone, pour brouiller les pistes si besoin (je ne détaille pas le pourquoi).

# Ce qui me manque chez /e/OS

Tout n'est pas parfait dans /e/OS et voici quelques premiers éléments que j'ai relevé.

## Dans la galerie photos

Il n'y a pas de dossier et de classement possible des photos directement dans l'application de Galerie de /e/OS. Pour créer un nouvel album ou dossier dans la galerie Murena (/e/OS), il est nécessaire d'utiliser l'application gestionnaire de fichiers de l'appareil plutôt que la galerie elle-même. (Source. Du coup, comment procéder ?

Il faut ouvrir l'application Fichiers sur son appareil, accéder au dossier DCIM ou à tout emplacement où sont stockées les photos. Il faut alors créer un nouveau dossier et le nommer selon le nom de l'album que l'on souhaite avoir. Ensuite, il faut déplacer ou enregistrer des photos dans ce nouveau dossier.

Et quand on ouvre l'application Galerie, elle reconnaîtra et affichera automatiquement ce nouveau dossier sous l'onglet « Dossiers » (cela peut prendre un court instant pour se charger).

## Le support du RCS

Je m'étais habitué à avoir le fait que les personnes qui me contactent (mes parents) sont en train de répondre à mon message que je viens d'envoyer. Je ferai un article dédié sur ce sujet de RCS.

# Ce que je n'aime pas chez /e/OS

S'il y a bien une chose, que je n'aime pas chez /e/OS, c'est clairement la synthèse vocale dans l'outil de cartographie, que j'utilise lors des déplacements à vélo (j'utilise la navigation par GPS). La voix repose sur un équivalent à "espeak", l'outil de synthèse vocale qui a des voix robotiques des années 2000. Rien à voir avec des voix comme dans des applications propriétaires Waze par exemple. Et c'est un point que je dois voir pour régler, en téléchargeant des voix de synthèses de meilleure qualité si c'est possible.

What I like about /e/OS (and what I would like to see improved)

jeudi 1 janvier 1970 à 01:00

# What I like about /e/OS

This list is not exhaustive and will evolve/grow over time.

Among the features I appreciate, some are native — which is reassuring about the migration to this alternative, de-googled Android — but others are indeed specific to and characteristic of /e/OS.

# Regular updates

I regularly get updates with security patches and a few bug fixes. I received a major update (moving from branch 4.2 to branch 4.3.x).

# The rich documentation

For most of the features I want to explore further, there is a dedicated page in the documentation. Admittedly, the project is not recent (and has been around for a few years), but it is appreciable to be able to find precise and relevant, concise information in one centralized place, namely : https://doc.e.foundation/fr/o

## The calendar that adjusts to local time

I use the calendar app, which is synced with my professional and personal calendars.

I went on a business trip to Portugal, a country with a one-hour time difference (earlier) from France. The phone adjusted to the local time. And the calendar adjusted to these times, with reminders at the right moment. I had a meeting at 10 a.m. French time ; it appeared as taking place at 9 a.m. local time in the calendar, and the reminders before the event also adapted/adjusted themselves, allowing me not to miss my appointment !

## /e/OS and connection sharing

If the VPN connection (Wireguard) is enabled on the smartphone sharing its connection over Wi-Fi, the devices connected via connection sharing also benefit from this tunneled/secured connection. A good thing, because on my old smartphone running Samsung's version of Android, I had to enable the Wireguard connection on the device itself (the one using the shared Wi-Fi connection).

## Local voice-to-text for SMS

As indicated in the documentation, under the hood, this feature runs the open source NVIDIA Parakeet TDT voice model (0.6 billion parameters, quantized to INT8) via ONNX Runtime, in the form of a /e/OS keyboard. I already had this feature on my old phone, under Android, but the feature went through Google's servers, so I never used it. Here, since it is local. And it works quite well. Even in noisy environments.
This allows me to take notes while walking down the street, focusing on my route rather than typing on my smartphone's keyboard.

## Google Play links

Under /e/OS, in the browser, a link to download an app from Google's store, the "Google Play", does open properly in /e/OS's alternative store, "App Lounge". It is transparent and convenient.

# The privacy-related options

/e/OS stands out from alternative Android systems with two strong aspects : de-googling / independence from Google's features, and built-in native privacy-related options. These privacy-related options are documented : Advanced Privacy

## Integration of Exodus Privacy data

/e/OS integrates Exodus Privacy's data directly within its app store, App Lounge, to display a privacy score and list the trackers of apps even before installing them

## Tracker blocking

All app trackers are blocked by default. It is still possible to allow them one by one, occasionally if needed. But for all the proprietary apps I use whose trackers are blocked, I never had to grant any authorization ; the apps work (so one may wonder about the purpose of these trackers, most of them illegitimate and clearly unnecessary except for data collection for advertising or other purposes, and which in any case are violations of the right to privacy).

## Spoofing your IP or my GPS location

/e/OS has a "Spoof my Position" option. Connections then go through the TOR network (to route all of the Android device's traffic through Tor)

## Random MAC address

It is possible to randomize the MAC address of the smartphone's Wi-Fi card, to cover one's tracks if needed (I will not go into detail about why).

# What I miss in /e/OS

Not everything is perfect in /e/OS, and here are a few initial points I have noted.

## In the photo gallery

There is no folder or photo organizing feature directly in the /e/OS Gallery app. To create a new album or folder in the Murena (/e/OS) gallery, you need to use the device's file manager app rather than the gallery itself. (Source. So, how do you proceed ?

You need to open the Files app on your device, navigate to the DCIM folder or any location where photos are stored. You then need to create a new folder and name it after the name of the album you want to have. Next, you need to move or save photos into this new folder.

And when you open the Gallery app, it will automatically recognize and display this new folder under the "Folders" tab (it may take a short moment to load).

## RCS support

I had gotten used to seeing that people contacting me (my parents) were in the process of replying to the message I had just sent. I will write a dedicated article on the subject of RCS.

# What I don't like about /e/OS

If there is one thing I don't like about /e/OS, it is clearly the text-to-speech in the mapping tool, which I use when traveling by bike (I use GPS navigation). The voice relies on an "espeak"-like equivalent, the text-to-speech tool with robotic voices from the 2000s. Nothing like the voices in proprietary apps like Waze, for example. And this is a point I need to look into fixing, by downloading better quality synthetic voices if that is possible.