⚠️ Attention cet article sera un peu long et technico-philosophique.

Je viens de passer quelques heures à essayer de mettre en place un système de notifications push sur ce journal de bord, afin que celles et ceux que ça intéresse puissent s’abonner et être prévenu(e)s lors de la publication d’un nouvel article. Je ne parle ici évidemment que de mobile, même si la question d’un tel système fonctionnant aussi sur ordinateur n’est pas inintéressante.

Comment recevoir des notifications sur mobile

Sur mobile donc, il y a 3 manières d’accomplir cette tâche (ou plutôt ces 2 tâches, puisqu’en réalité on veut d’une part vérifier régulièrement si un nouvel article est apparu et d’autre part générer une notification chez toutes les personnes l’ayant demandé):

1. Créer une application mobile classique. C’est-à-dire qui se télécharge depuis un “magasin d’application” (store). Mais en fait 2 applications, puisqu’on sépare Android et Apple.
2. Rendre le journal de bord (un site web) installable, c’est-à-dire en faire une Progressive Web App (PWA), et la configurer pour qu’elle se réveille régulièrement pour vérifier s’il n’y a pas de nouveau contenu.
3. Faire une PWA mais plutôt créer un service externe qui viendrait lui pousser la notification lorsque nécessaire.

Chacune de ses options est viable techniquement et a ses avantages et ses inconvénients. Procédons par élimination et regardons uniquement les inconvénients.

Application mobile

Facile à mettre de côté: je ne vais pas m’amuser à développer 2 applications natives simplement pour embarquer un site web, et les maintenir dans 2 stores séparés, surtout que pour l’App Store il faut payer une certaine somme tous les ans.

Progressive Web App

Avant de parler des points 2 et 3, il convient d’expliquer rapidement ce qu’est une Progressive Web App (PWA). C’est un site web, qui, pour faire simple, a des fonctions particulières lui permettant d’être installé et fonctionner comme une application “classique”. Le principal intérêt est de n’avoir pas besoin de télécharger quoique ce soit en provenance d’un store, ni de lancer un quelconque installeur.

Dans ce mode de fonctionnement basé sur les standards du web, certaines beaucoup de fonctionnalité sont déjà disponibles, d’autres sont en cours d’études, et d’autres sont intrinsèquement impossibles.

Une fontionnalité en cours d’étude (depuis quelques années déjà) est donc l’API de tâche de fond périodique.

L’API de tâche de fond périodique

Comme son nom l’indique, c’est un mécanisme qui permet au site web d’exécuter une tâche en arrière-plan à intervalle régulier, ce qui tombe pile poil dans notre scénario de notification sur ce journal de bord. Cependant ce mécanisme ne fonctionne que dans Chrome (et Edge, mais bon, Edge quoi…) et pas dans Firefox et Safari. En creusant un peu, il s’avère que la position officielle de Mozilla par rapport à cette API est qu’ils ont des craintes qu’elle soit utilisée à des fins de pistage et qu’elle puisse révéler des informations sensibles comme la géolocalisation.

Service externe

Pour qu’un service externe puisse faire ce travail de vérification périodique, il faut qu’il soit hébergé quelque part. Il y a alors 2 options: utiliser un Raspberry Pi (que j’ai déjà), et à ce moment-là c’est gratuit, OU louer un VPS chez un fournisseur qui coûte quelques euros par mois.

• Pour le Raspberry Pi, je l’ai déjà fait et ça fonctionne, mais il y a 2 contraintes qui me rebutent: ouvrir mon réseau interne à l’extérieur (certes, un seul port, mais je suis parano) et laisser le Raspberry Pi allumé tout le temps. Ça arrive tellement facile de le débrancher et d’oublier de le rebrancher… L’hébergement avec un uptime garanti, c’est un métier!
• Pour l’hébergement sur un VPS, ça m’ennuie de payer, même quelques euros, pour juste des notifications…

Bref, j’ai passé pas mal de temps à trouver une solution basée sur un service externe mais sans utiliser mon réseau à domicile et sans dépenser un centime.

Begin.com

Et j’ai trouvé Begin.com, qui est un outil fullstack intégrant une couche de déploiement AWS (désolé pour le jargon technique) avec un premier palier d’utilisation gratuite, ce qui est devenu rare, en tout cas sans donner son code de carte bleue. Avant il y avait Heroku mais il n’y a plus de palier gratuit, et pour Azure, Netlify, Vercel ou AWS, il faut donner son code de carte, ce que je me refuse à faire.

Begin.com ne laisse pas toute liberté aux développeurs, mais offre tout de même la possibilité d’avoir une base de donnée et du réveil périodique, ce qui est parfait dans notre scénario.

Ne reste plus que la partie où ce service contact les abonné(e)s, et j’ai donc entrepris de creuser le fonctionnement de l’API des notifications Web Push, qui a le mérite d’être supporté par tous les navigateurs modernes, contrairement à l’API de tâche de fond périodique.

Scénario web push

En résumé, le scénario est le suivant (sur mobile, toujours):

1. l’utilisateur va sur 1665.re et l’installe comme PWA (“Add to Home Screen”)
2. l’utilisateur ouvre la PWA, et clique sur un bouton pour recevoir des notifications (obligatoire de recueillir le consentement pour l’API)
3. sur consentement, la PWA fait une souscription vers le service de web push du navigateur avec une clé publique
4. cette souscription sert à appeler un endpoint d’API (celui là-même qui doit être hébergé soit sur un Raspberry Pi, soit sur un VPS, soit sur Begin.com, soit autrement…) et qui contient la clé publique et la clé privée correspondante.
5. ce serveur stockera alors toutes les souscriptions, et périodiquement, vérifiera si le journal de bord contient un nouvel article. Si c’est le cas, il aura alors toutes les infos pour envoyer une notification Push à toutes les PWA souscrites.

Conclusion #1

Ce système 🌟fonctionne🌟, avec les 3 principaux navigateurs Firefox, Safari et Chrome. Sur Android et sur iOS (16.4+).

MAIS (parce qu’il y a un mais, sinon je n’aurais pas intitulé mon article “Pas de notifications sur ce journal de bord”):

• Ce système dépend de Begin.com, qui est une entreprise à but lucratif dont l’offre gratuite peut s’arrêter à tout moment. De plus, en ayant un service externe, j’ajoute un composant à mon journal de bord, et je m’éloigne donc forcément un peu plus d’un système simple, qui est un de ses principes qui me tient le plus à coeur.
• En fait ça ne fonctionne pas sur mon téléphone, ni avec Brave (qui est basé sur Chromium), ni avec Fennec (qui est basé sur Firefox). Par contre ça fonctionne avec Firefox.
• Surtout, en investiguant le point ci-dessus, je me suis rendu compte que le système d’API Web Push ne pouvait pas être totalement fiable en terme de protection de la vie privée.

Suffisamment d’arguments pour finir par me convaincre de laisser tomber.

Pour bien comprendre pourquoi l’API Web Push ne garantit pas la protection de la vie privée, faisons d’abord un tour d’horizon des navigateurs actuels.

Résumé de la situation des navigateurs Internet

Je vous épargne les débuts avec Netscape, qui date d’avant l’arrivée de Firefox (de la fondation à but non lucratif Mozilla) et d’Internet Explorer: arrivons tout de suite à la situation actuelle.

Les 4 navigateurs dominant le marché sont à l’heure où j’écris ces lignes:

• Google Chrome (loin devant)
• Safari
• Microsoft Edge
• Firefox

Safari et Edge obtiennent probablement leurs places grâce au fait qu’ils sont livrés par défaut avec MacOS et Windows, respectivement. Mais bon, puisqu’on parle ici de mobile, même si tout ce que je raconte jusqu’à présent vaut aussi pour les systèmes de bureau, écartons tout de suite Edge. Reste les 3 autres, ayant chacun un moteur différent: Blink pour Chrome (de loin le navigateur le plus utilisé au monde), Webkit pour Safari et Gecko pour Firefox. Ces navigateurs et leur moteur ont tous des forks plus ou moins populaires, comme Brave, le navigateur soi-disant respectueux de la vie privée.

Ces navigateurs sont tous maintenus par des structures énormes, avec des armées de développeurs, et pour cause: ils sont devenus au fil du temps des mastodontes à cause de ce qu’Internet est devenu, à savoir une vaste machine commerciale basée sur la publicité.

A part Mozilla, toutes ces structures sont des sociétés dont le but est le profit. Et en fait même Mozilla reçoit des fonds en grande partie de Google et met en avant le moteur de recherche par défaut dans leur navigateur. On peut les comprendre, car il faut bien chercher les fonds quelque part… Dans ce contexte, difficile de se passer de l’hégémonie des nombreux datacenters offerts via les différents services cloud existants. Quel rapport avec les notifications Web Push ? J’y arrive. Retenons simplement que les navigateurs sont des logiciels gratuits, mais qui ne vous veulent pas que du bien.

Pourquoi l’API Web Push ne garantit pas la protection de la vie privée

Chacun des 3 moteurs de navigateur qui nous intéressent ont implémenté leur service de notification: Firebase Cloud Messaging pour Google, Autopush pour Firefox, et plus récemment Apple ont annoncé avec la sortie d’iOS 16 la compatibilité de Safari avec les notifications Web Push (pas de nom donné à ce système ou alors recyclage de Apple Push Notifications Service ? Je ne sais pas…).

Cela signifie qu’à partir de l’étape 3 du scénario classique de souscription à des notifications web push décrit plus haut, un lien est fait entre le navigateur et un serveur géré par la société développant le navigateur. A partir du moment où ce lien est fait, alors le serveur à l’autre bout peut déduire énormément de choses sur le client, et ce malgré le standard de l’API: en haut de la liste, l’adresse IP, et donc la géolocalisation de l’utlisateur mobile.

Je vais probablement passer pour un parano, mais même en utilisant les services de Mozilla, qui sont tout de même un peu plus crédibles en terme de protection de la vie privée que les 2 autres, on est en droit de se demander à quel point ils n’utilisent pas en fait le système de notifications push de Google ultra-ubiquitaire FCM mentionné au dessus. Pour rappel, Google n’a qu’un seul intérêt: en savoir le plus possible sur vous afin de vendre votre profil a des publicitaires.

D’après cet article, pas de soucis concernant les notifications web push et le pistage, on peut faire confiance aux navigateurs. Sauf que Pushpad, l’auteur de l’article, est précisément une compagnie dont le modèle commercial repose sur les notifications…

Notifications et écologie

Admettons. Admettons qu’effectivement, tout ce beau monde derrière les navigateurs oeuvrent pour le bien de l’humanité et que les milliards de notifications qui doivent transiter tous les jours le font de manière strictement confidentielle.

Je ne suis pas sûr qu’on se rende bien compte de toutes les ressources en énergie pour le stockage, l’acheminement à haute vitesse et la résilience générale du système, que l’ensemble des notifications mobiles requiert. Alors certes, ça s’inscrit dans des rouages globalisés déjà en place: les réseaux 4G sont déjà déployés, les data centers sont déjà construits, il y a des milliards de smartphone en circulation, et on n’est pas à une notification près.

Sauf que moi, personnellement, je fais le choix de ne pas en proposer sur mon site personnel car malgré l’infime impact négatif que ça a, hé bien c’est tout de même négatif. Je réalise qu’avec cette logique, on pourrait dire que mon site a un impact négatif et que donc lui aussi devrait entièrement passer à la trappe. Mais en fait non, je parle bien du ratio bénéfice général apporté vs coût écologique global. Ce ratio est acceptable dans la version du site où il n’y a pas de notifications (car c’est un passe-temps qui me fait du bien, et qui me permet de donner des nouvelles aux gens, et que donc son hébergement a un coût environnemental raisonnable), mais il ne le devient plus dès lors qu’on y rajoute les notifications (du fait de la technologie sous-jacente et que l’information que les abonnés en retire est selon moi négligeable).

Notifications, anxiété et conclusion #2

Et puis au fond, est-ce qu’on ne reçoit pas tous assez de sollicitations quotidiennes comme ça ?

Entre les panneaux publicitaires en ville, les réclames à la télé ou à la radio, les pubs ou les sponsors sur les plateformes vidéo ou de musique, les injonctions à payer, la communication instantanée, les spams, les appels d’arnaqueurs, les gens qui sonnent à l’interphone pour X ou Y raisons, ne vit-on pas déjà dans un monde de fous ?

Personnellement ça fait déjà plusieurs années que mon téléphone n’est qu’en mode vibreur, que j’essaie de me débarrasser de la pub omniprésente (vive NewPipe) et que je restreins les notifications à uniquement la messagerie. C’est une lutte permanente contre tous ces mécanismes de manipulation et d’addiction mis en place par des gens aux intentions très douteuses, qui savent très bien s’y prendre.

Alors certes, chacun fait ce qu’il veut et sur mon site, l’ajout de notifications aurait de toute façon nécessité un consentement. Mais même en laissant le choix à l’utilisateur, est-ce que je n’aurais pas contribué à faire naître un besoin inutile ?

Coluche disait dans un de ses sketchs:

Ecrivez-nous de quoi vous avez besoin, on vous expliquera comment vous en passer.

Enfin, pour terminer ce très long article, j’aimerais plaider pour un internet à l’ancienne, celui où le modèle n’était pas push, mais pull: on ne demandait pas à être notifié, on allait directement chercher l’information à la source. On consultait régulièrement des sites qui n’avaient ni newsletter, ni flux RSS (que je recommande toujours, d’ailleurs). Et si on ne le faisait pas, rien ne ne venait nous le rappeler. Et oui, ça arrivait qu’on oublie l’existence de contenu intéressant, mais à mon avis ce n’est pas grave. Donc oubliez-moi, je ne vous en voudrai pas!

TL;PL: pas de notifications même si c’est possible, car overkill, inutile et même néfaste.