Notifications de Status App sur iOS

By Heritier Mawandu | Status Network | 7 Nov 2020


Les notifications sont une fonctionnalité indispensable pour les applications de messagerie. Ils jouent un rôle intrinsèque, car autrement les utilisateurs sauront-ils quand ils ont reçu des messages.

L'importance des notifications est encore plus grande sur Status Messenger étant donné son architecture P2P décentralisée (comme décrit cet article en Anglais). Par exemple, si un utilisateur Status est hors ligne lorsque des messages sont envoyés à cet utilisateur, l'implémentation actuelle stocke ces messages temporairement sur un nœud Historique pendant 30 jours avant de les supprimer. Donc, si l'utilisateur ne se connecte pas dans ces 30 jours (peu probable mais plausible) et s'il n'y a pas eu de notifications envoyées à propos de ces messages entrants, l'utilisateur n'a aucun moyen de recevoir ces messages. Ceci est différent des architectures typiques de messagerie client-serveur où les serveurs stockent les messages (presque) indéfiniment.

La version 1.4 de l'application Status a apporté un support de notification sur Android dont vous pouvez lire ici. La version 1.7 de l'application Status apporte la prise en charge des notifications sur iOS.

Alors que les implémentations client-serveur typiques de la notification iOS permettent au serveur de lier les clients d'envoi et de réception de notification, Status Messenger l'implémente d'une manière respectueuse de la confidentialité en utilisant une notification push décentralisée et le protocole Waku.

Cet article se penche sur la mise en œuvre des notifications sur l'application Status iOS. Nous commençons par comparer les notifications locales aux notifications push et en décrivant le fonctionnement des notifications push sur les appareils Apple. Nous expliquons les détails de la façon dont les notifications iOS sont implémentées dans l'architecture P2P décentralisée de Status Messenger, puis concluons en discutant des considérations de sécurité et de confidentialité de cette approche.

Jusqu'à maintenant

Jusqu'à présent, les utilisateurs de l'application Status iOS ne recevaient aucune indication lorsque des messages leur étaient envoyés. S'ils utilisaient l'application lorsque quelqu'un leur a envoyé un message, ils le recevraient. Sinon, ces messages se propageraient entre les nœuds de relais pendant un petit moment, jusqu'à ce que leur durée de vie (Time-To-Live) expire (qui est actuellement définie sur 15 secondes), puis seraient enregistrés temporairement dans les nœuds d'historique pendant 30 jours maximum. .

Les nœuds d'historique enregistrent les messages des utilisateurs lorsqu'ils sont hors ligne. Ces nœuds ne peuvent pas connaître le contenu ou le destinataire des messages et n'ont accès qu'à la rubrique du message. (Ces concepts sont expliqués en détail dans un article à lire ici.)

Si les destinataires prévus n'utilisaient pas leur application Status iOS dans les 30 prochains jours, leurs messages (ainsi que d'autres) seraient supprimés des nœuds Historique et ils ne les recevraient jamais. Ce serait clairement une expérience utilisateur terrible pour une application de messagerie. L'hypothèse est que la plupart des utilisateurs vérifieraient leur application pour les messages dans un délai d'un mois. Même dans ce cas, les utilisateurs voudraient naturellement lire leurs messages en temps opportun.

Notifications: Local vs Push

Les notifications peuvent être déclenchées localement à partir de l'application / l'appareil ou elles peuvent être `` transmises '' à l'application à distance à partir des serveurs associés, même lorsque l'application n'est pas en cours d'exécution. Les notifications générées par l'application Status elle-même lors de la réception de messages sont appelées notifications locales. Les notifications envoyées à l'application Status à partir de serveurs de notification push spécifiques, séparément des messages eux-mêmes, sont appelées notifications push.

Status implémente des notifications locales sur les applications Android et de bureau. Les notifications locales nécessitent que l'application soit toujours en cours d'exécution pour recevoir des messages et ensuite déclencher des notifications. Bien que cela soit facile à réaliser sur le bureau, l'application Android nécessite un service de premier plan fonctionnant en continu spécifiquement pour recevoir des messages même lorsque l'application est en arrière-plan afin de pouvoir déclencher les notifications correspondantes.

Status implémente des notifications push sur son application iOS. En effet, iOS n'autorise que certains types d'applications, par exemple VOIP, pour garder une connexion ouverte en arrière-plan. Les applications iOS peuvent demander le temps d'exécution lorsqu'elles sont en arrière-plan, mais elles ont un ensemble limité de cas d'utilisation et ne sont généralement pas suffisamment réactives pour implémenter un système de notification push. De plus, contrairement à Android, iOS ne fournit pas de capacité de service de premier plan pour nous permettre de mettre en œuvre des notifications locales. Cela nous oblige effectivement à implémenter des notifications push.

Notifications Push sur iOS

Apple Push Notification service (APNs) est la technologie qui permet les notifications à distance sur les appareils iOS et macOS. Le service APN se situe entre le fournisseur de l'application et les appareils de l'utilisateur.

Lorsque l'utilisateur lance initialement l'application, une connexion chiffrée et persistante est établie entre l'application et les APN, ce qui lui permet de recevoir des notifications. Le fournisseur d'applications à l'autre extrémité configure un canal sécurisé permanent entre les serveurs d'applications et les APN à l'aide de certificats cryptographiques fournis par Apple.

Le fournisseur de l'application envoie des demandes de notification aux APN qui les transmettent à leur tour aux appareils ciblés. À la réception d'une notification, l'appareil la transmet à l'application appropriée et gère les interactions avec l'utilisateur. Ces notifications ont des privilèges spéciaux qui leur permettent d'être reçues et affichées même lorsque l'application n'est pas en cours d'exécution ou est en arrière-plan. Même si l'appareil est éteint, les APN mettent en mémoire tampon toutes les notifications et les renvoient plus tard. Toutes les applications iOS qui nécessitent des notifications utilisent des APN.

Notifications de Status iOS

Status utilise les APN pour les notifications sur iOS. La mise en œuvre comprend deux autres composants importants: Status Push Notification (SPN) serveurs et serveurs Gorush. Les serveurs SPN sont utilisés pour gérer les inscriptions / requêtes des clients pour les notifications tandis que Gorush est utilisé pour la livraison réelle des notifications.

Gorush est un microserveur de notification push open-source écrit en Go (Golang) en utilisant le framework Gin. Le reste de cette section décrit les aspects d'enregistrement des clients et de notification du service SPN. Les flux détaillés, les formats de message et les détails du protocole sont disponibles dans la spécification.

Inscription du Client

Un client peut s'inscrire auprès d'un ou plusieurs serveurs SPN de son choix. Un message d'enregistrement de notification push ou Push Notification Registration en Anglais (PNR) est envoyé sur la rubrique partitionnée pour la clé publique du serveur SPN.

Le message PNR contient des informations telles que les APN émis device_token, installation_id de l'appareil et access_token qui seront requis par d'autres clients pour envoyer des notifications push. Il peut inclure allowed_key_list qui est une liste de jetons d'accès chiffrés avec la clé AES générée par Diffie-Hellman entre le client et des contacts spécifiques qui sont autorisés à envoyer des notifications. Il peut également inclure une blocked_chat_list qui est une liste de hachages SHA2-256 d'identifiants de chat qui ne déclenchera pas de notification. Il permet également au client de spécifier s'il souhaite être notifié sur les mentions avec une allowed_mentions_chat_list spécifique qui est une liste de hachages SHA2-256 des identifiants de chat où il souhaite recevoir des mentions.

Le serveur SPN effectue les vérifications requises sur ce message et répond avec succès / échec. Un client peut s'inscrire auprès de plusieurs serveurs SPN pour augmenter la disponibilité.

Chaque utilisateur enregistré sur un ou plusieurs serveurs SPN en fera régulièrement la publicité. Si aucun filtrage n'est effectué sur la base de clés publiques, le access_token sera inclus dans cette annonce. Cela sera annoncé sur le sujet du code de contact en couplant avec la publicité de code de contact normale. Cela permet aux autres de découvrir les détails des notifications push pour l'utilisateur.

Envoyer une notification

Un client qui souhaite envoyer des notifications push doit disposer du jeton d'accès (access_token) requis à partir des publicités des utilisateurs correspondants ou de l'interrogation d'un serveur SPN. Ceci est utilisé pour créer un message de notification push qui est envoyé au serveur SPN.

Le serveur SPN valide le jeton d'accès (access_token) puis transmet la demande de notification au serveur Gorush qui délivre le message de notification réel. Status Messenger active l'envoi de notifications par défaut, mais l'utilisateur doit accepter de recevoir des notifications.

Considérations de Sécurité et de Confidentialité

Jeton d'accès

 Le spam est relativement plus facile sur notre plate-forme de messagerie P2P décentralisée ouverte, sans autorisation et centrée sur la confidentialité, comme décrit dans notre article précédent. Access_token est utilisé pour ajouter un contrôle d'accès au flux de notification afin que le protocole puisse appliquer des politiques telles que la réception de notifications uniquement de contacts spécifiques. Cela réduit les notifications de spam dans une certaine mesure.

On peut générer une clé de chat aléatoire, obtenir le access_token pour un autre utilisateur, puis spammer cet utilisateur avec des notifications. L'utilisation de access_token chiffré dans la allowed_key_list atténue cette situation mais cela implique de divulguer au préalable la clé de discussion réelle (du client, lors de l'enregistrement) au serveur SPN (voir Mode anonyme ci-dessous).

L'utilisation d'un access_token augmente également le déni car le serveur SPN saurait qui a demandé le jeton mais pas nécessairement qui a envoyé une notification push. La corrélation entre les deux peut cependant être insignifiante dans certains cas.

Confidentialité

Lorsque les clients interagissent avec le service SPN, ils divulguent certaines informations nécessaires au fonctionnement du protocole de notification, ce qui réduit leur confidentialité dans une certaine mesure.

Lors de l'inscription sur un serveur SPN, un client divulgue sa clé de discussion et les appareils qui recevront des notifications. Un client peut également divulguer le hachage des identifiants de chat qui l'intéressent (allowed_mentions_chat_list) et le hachage des identifiants de chat qu'il souhaite filtrer (block_chat_list).

Lors de l'interrogation d'un serveur SPN, un client révélera qu'il est intéressé par l'envoi de notifications push à un autre client, mais la clé de discussion du client interrogateur n'est pas divulguée.

Mode anonyme

Un mode de fonctionnement anonyme est disponible pour une confidentialité accrue. Un client dans ce mode peut s'inscrire auprès du service SPN à l'aide d'une nouvelle clé de notification différente de sa clé de discussion. La clé de notification est effectivement un secret et ne doit être divulguée qu'aux clients par lesquels l'utilisateur souhaite être averti. Un client peut partager cette clé directement via des mises à jour de contact et publier le jeton d'accès sur le sujet de code de contact de cette clé.

Ce mode anonyme ne partage effectivement pas l'identité de chat de l'expéditeur ou du destinataire avec le serveur. Cependant, cela peut entraîner des notifications push manquées car la publication de la clé de notification est laissée au client sans l'implication du serveur SPN.

Décentralisation

Bien que Status exécute les serveurs SPN aujourd'hui, les serveurs de notification push peuvent techniquement être exécutés par n'importe qui. Les serveurs Gorush peuvent également être exécutés par n'importe qui, mais ils auront besoin du certificat émis par Apple pour pouvoir notifier les clients Status.

Conclusion

Dans les implémentations client-serveur typiques de la notification iOS, le client A s'enregistre auprès du serveur d'application S en donnant son jeton d'appareil et est connecté aux APN. Lorsque le client B envoie un message au client A, le serveur S remet le message au client A et envoie également une notification push au client A via APN, ce qui permet au serveur S de relier facilement les clients émetteurs et récepteurs.

Status utilise une architecture P2P décentralisée pour la livraison de messages entre pairs sur Waku, où aucun serveur ne peut relier les nœuds d'envoi et de réception de messages. Nous obtenons la même chose avec les notifications utilisant des serveurs SPN.

Les avantages sont quadruples

  • Un client peut choisir le serveur SPN avec lequel interagir et peut même en exécuter un lui-même;
  • Les serveurs SPN sont décentralisés sur le plan architectural et ne peuvent donc pas facilement relier l'expéditeur et le destinataire de la notification;
  • Les serveurs SPN n'ont pas accès aux messages correspondant aux notifications, ce qui rend la liaison plus difficile;
  • L'interrogation du serveur SPN ne révèle pas l'identité de l'expéditeur.

Cette architecture nous permet d'atteindre la capacité de notification sur iOS tout en maintenant les considérations de confidentialité les plus élevées.

Sommaire

La version 1.7 de l'application Status apporte la prise en charge des notifications sur iOS. Status Messenger propose désormais les notifications très attendues sur les applications de bureau, Android et iOS.

Dans cet article, nous avons différencié les notifications locales des notifications push et décrit la justification de la mise en œuvre des notifications push sur notre application iOS. Nous avons décrit les aspects clés de cette implémentation en mettant en évidence le service Status Push Notification et les serveurs Gorush. Enfin, nous avons discuté des considérations de sécurité et de confidentialité de cette approche pour justifier comment Status réalise des notifications respectueuses de la confidentialité sur iOS.

Alors maintenant, les utilisateurs de Status sur iOS peuvent profiter des notifications de leur réseau Status et ne plus jamais manquer un message. Ping!

Installez le statut pour Android et iOS ici

How do you rate this article?

2


Heritier Mawandu
Heritier Mawandu

Blockchain Enthusiast and Syntropy Agent


Status Network
Status Network

Transcription du contenu Français du Status Network

Send a $0.01 microtip in crypto to the author, and earn yourself as you read!

20% to author / 80% to me.
We pay the tips from our rewards pool.