Système d'alerte de disponibilité de RDV

[hzba1]

Cette issue a pour but de centraliser les idées remontées dans le groupe de travail:

Pré-requis:

• Pas de données personnelles ou identifiables stockées côté serveur
• Traitement effectué côté client
• Compatibilité multi-plateforme

Idées:

• PWA avec Push Notification
  • PRO: Interropérabilité, paramètres stockées côté navigateur
  • CON: Portée limitée sur navigateur mobile à cause des politiques de Power Saving
• Extension XPI pour Firefox/Chrome
  • PRO: Adhésion importante, pris en main assez rapide
  • CON: Adaptée aux navigateurs "desktop" majoritairement
• Flux RSS
  • PRO: Format universel et interopératable, peut servir de sources aux autres intégrations, et peut être adapté sur Mobile
  • CON: Nécessite une interface, ou un client RSS.

A vos claviers.

[Toomaaa]

Il y a un protocole de notifications push qui est devenu presque un standard, tout du moins sur les navigateurs les plus communs :
https://caniuse.com/push-api

De la doc : https://developers.google.com/web/fundamentals/push-notifications

L'utilisateur doit autoriser les notifications dans son browser. Côté serveur on ne garde qu'un ID, donc pas de données personnelles. Lorsqu'une notification est pushée cela appelle un service worker côté browser, même si le site en question n'est pas ouvert.

Du coup on a le "PRO" de la première solution mais pas le "CON" car c'est spécialement fait pour fonctionner même si le site n'est pas ouvert.

[hzba1]

Web Push API semble être une bonne alternative mais peut être compliqué à mettre en place à une large échelle car cela nécessite une connexion "persistante" et donc d'une infrastructure pour encaisser les "subscribers".

Si nous avons 150k visites par jour, prenons 10% d'abonnements, cela fait 15k connexions actives en permanence. Soit une moyenne de 250 requêtes/seconde pour un équilibrage parfait, ce qui est rarement le cas.

[Toomaaa]

Non pas besoin de connexion persistantes avec ce protocole (où alors j'ai mal compris).
Je remets le résumé que j'ai fait sur Telegram :

• Il faut appeler en front une méthode pour demander l'autorisation à l'utilisateur
• A l'acceptation, ça stocke un fichier .js (le service worker) dans le client
• Côté serveur, on récupère 2-3 datas par subscriber (une URL à appeler + des clés), qu'on stocke (on peut les stocker par département du coup)
• Quand on veut envoyer une notif, on appelle un endpoint API push avec les subscribers qu'on veut notifier (donc on peut les prévenir par département)
• Les browsers vont requêter l'API Push quand ils sont online (je n'arrive pas à voir la fréquence de polling par contre, mais c'est fait pour être assez réactif)
• Quand ils détectent une nouvelle notification, ils exécutent le service worker (le fichier .js stocké), qui permet d'effectuer si on veut de l'analytics ou autres tâches en background et de poper la notification

[hzba1]

Il semble qu'il soit possible de choisir le délai de vérification côté client: https://w3c.github.io/push-api/#subscription-refreshes

[Toomaaa]

Il semble qu'il soit possible de choisir le délai de vérification côté client: https://w3c.github.io/push-api/#subscription-refreshes

Non, il s'agit du renouvellement de la souscription, au cas où celle-ci est expirée.
Le client ne s'adresse pas au serveur pour poller ses push, il s'adresse à l'API, il n'y a pas de connexion directe entre VMD et le client

[DavidLibeau]

Je suis d'avis qu'il faut prioriser l'ouverture des données (utiliser un format libre ou standard), ce qui permettra de pourvoir interfacer avec d'autres systèmes permettant les notifications ou même l'automatisation.
Comme ce sont des données calendaires, il existe aussi le format ICS (que j'ai notamment utilisé pour AgendaDeMinistre) et tout ce qui est CalDAV ou Web Calendar Access Protocol. A voir si c'est pertinent ici.

[V0lantis]

Cette issue a pour but de centraliser les idées remontées dans le groupe de travail:

Pré-requis:

• Pas de données personnelles ou identifiables stockées côté serveur
• Traitement effectué côté client
• Compatibilité multi-plateforme

Je crains que ces prérequis soient trop contraignants pour une facilitée d'utilisations d'une majorité de personnes.
Ne pouvons pas faire des prérequis moins contraignants ?

Exemple : base de données avec expirations de données, E.g. auto-suppression de la donnée au bout de 15 jours.
Ainsi, on peut stocker l'adresse mail (pour une durée temporaire). À mon humble avis, ça faciliterait grandement les choses...

Bien évidemment, ça vient avec un bouton "Unsuscribe" sur chaque mail + un moyen de le faire également au travers de la plate-forme web vitemadose

[Maijin]

Pour info covidlist est de nouveau ouvert https://github.com/hostolab/covidliste

[V0lantis]

Pour info covidlist est de nouveau ouvert https://github.com/hostolab/covidliste

C'est pas exactement pareil je dirais. L'objectif serait d'informer automatiquement lors d'ouvertures de nouveaux créneaux

[Maijin]

oui oui j'ai bien compris - mais comme c'etait l'un des probleme (y en a d'autres) qui ont lancés cette discussion je voulais passer l'info 😉

[rozierguillaume]

Pour info on avait plutôt prévu d’implémenter les alertes dans les apps mobiles (ça nous permettrait de ne collecter qu’un identifiant anonyme).

Personnellement je ne suis pas fermé à l’idée de collecter les mails pour envoyer des alertes (on le fait déjà pour la newsletter après tout).

[DavidLibeau]

Il faudra garder en tête la définition de données de santé "les informations relatives à une personne physique collectées lors de son inscription en vue de bénéficier de services de soins de santé" https://www.cnil.fr/fr/quest-ce-ce-quune-donnee-de-sante, même si je ne sais pas trop si cela s'applique ici.

[V0lantis]

Il faudra garder en tête la définition de données de santé "les informations relatives à une personne physique collectées lors de son inscription en vue de bénéficier de services de soins de santé" https://www.cnil.fr/fr/quest-ce-ce-quune-donnee-de-sante, même si je ne sais pas trop si cela s'applique ici.

Ce n'est pas vraiment en vue de bénéficier de services de soins de santé, mais pour bénéficier d'informations relatives aux disponibilités de centre de vaccination. La différence est subtile. Par exemple, je peux très bien à titre personnelle me renseigner sur les disponibilités d'un centre du nord pas de calais sans pour autant avoir quelconque intention de m'y faire vaccinée.

[fcamblor]

Sur l'API PUSH, on a un moyen de détecter un "plaisantin" qui viendrait s'inscrire des millions de fois aux abonnements et mettrait à genoux le système de notifications ?

Un truc basé sur l'IP serait suffisant (mais pour ça, il faudrait stocker l'IP, et c'est mal)

J'ai du mal à voir comment on pourrait stocker une référence unique qui soit à la fois :

• mis à dispo par l'appelant à l'API (donc un appelant malicieux pourrait faire n'importe quoi)
• sans données personnelles

[DavidLibeau]

Pour info, j'ai créé un front perso qui envoie des notification web en utilisant les données scrappées ViteMaDose : https://framagit.org/DavidLibeau/notification-vaccin. C'est uniquement pour les rdv dans les 24h (rdv du lendemain) suite à la mise en place de cette décision le 12 mai prochain. La confidentialité est garantie car tout est géré côté navigateur. Par contre, il faut que l'utilisateur·rice garde son onglet ouvert.

[fcamblor]

@DavidLibeau Il y a une branche avec des notifications PUSH qui fonctionnent (et ça inclut le background pour les tels Android) dans cette PR : CovidTrackerFr/vitemadose-front#134

Pour les utilisateurs Safari (qui représentent un gros tier de nos visiteurs) le fait de garder l'onglet ouvert est rédhibitoire, ce n'est pas comme ça que les gens voudront être notifiés pour moi
=> Les applis mobile joueront un bien meilleur rôle que le site sur le terrain des notifications à mon avis

[DavidLibeau]

Merci pour l'information. Comme aucune mention n'a été faite sur l'issue, je ne savais pas.
Votre solution implique un serveur qui distribue les notification via le service worker et donc il y a stockage sur serveur + l'utilisation des services des navigateur (donc Google pour Chrome, Mozilla pour Safari, Apple pour Safari). Je trouve que c'est quand même problématique. De mon côté, c'est bien une solution 100% anonyme sans stockage de données personnelles.
Entre temps, j'ai fait une petite API avec une distribution d'événements en ICS comme je l'avais proposée ici #40 (comment). Ça permet les notifications via les applications calendriers sans avoir d'onglet ouvert : https://framagit.org/DavidLibeau/notification-vaccin/-/tree/main/ics-api. C'est cross plates-formes vu que c'est standardisé.
Je préfère personnellement utiliser ce genre de solutions sans données personnelles récupérées plutôt que vos apps avec du Google Firebase sans demander le consentement. 😞

[fcamblor]

J'avais une implémentation à base de setInterval + service workers + periodicSync qui fonctionnait dans l'historique de la PR mentionnée plus haut (je suis comme vous, je préférais éviter Firebase)

Le soucis, c'est que la réalité terrain m'a rattrapé : l'implémentation basée sur la synchronization dans le service worker :

• Ne fonctionnait que sur Android (periodicSync n'existe pas sous les autres navigateurs)
• Lorsque la page VMD était dans le background pendant plus de 5min (environs), le periodic sync ne fonctionnait plus : du coup, plus aucune notification, ce qui rendait la fonctionnalité totalement inutile sur mobile (je ne vois pas quelqu'un laisser son téléphonne allumé en permanence sur la page de vitemadose pour trouver un créneau de vaccination...)

Autre point : vous mentionnez le stockage de données personnelles, nous n'en stockons aucune.
L'implémentation basée sur firebase se base uniquement sur un enregistrement auprès des centres (on stocke un identifiant de centre sur le device de l'utilisateur) et on s'enregistre auprès de firebase avec un token généré complètement aléatoirement, rattaché au device, et possédant un TTL.
À aucun moment nous ne stockons de données personnelles de l'utilisateur, même sa localisation précise nous est inconnue car nous nous reposons uniquement sur la latng de la Commune sélectionnée (correspondant à son barycentre).
Il ne me semble pas opportun de demander un quelconque consentement dans ce cas de figure.

Dernier point : votre implémentation nécessite un serveur PHP pour pouvoir s'exécuter.
Je doute qu'une telle implémentation puisse absorber la charge que sera la notre le 12 Mai prochain.
Il aurait été préférable de tout mettre dans un fichier servi par un simple serveur HTTP (d'une car en terme de confiance, l'ensemble de votre code pourrait être lisible sans être "caché" derrière un serveur, de deux parce que vous pourriez faire héberger votre code sur une plateforme cloud destiné à simplement servir des assets statiques, type github/gitlab pages)

[DavidLibeau]

Oui, le service worker avec sync, ce n'est pas un standard et peu supporté.

Pour les données personelles, il y a cette définition : https://www.cnil.fr/fr/identifier-les-donnees-personnelles ("identifiant de connexion informatique").

Non, mon implémentation ne nécessite pas de serveur PHP. J'ai deux fichiers index.php (mais il n'y a pas de PHP, d'ailleurs je voulais mettre .html) et api.php qui est un simple proxy pour ne pas se connecter à GitLab. Mais l'utilisateur·rice peut auto-héberger la page web et utiliser GitLab (j'ai d'ailleurs laissé la ligne commentée pour ça).

[Maijin]

La discussion continue côté front :) (voir aussi le mattermost)