Show HN : partage d’écran chiffré à 1 FPS pour les personnes introverties

 (1fps.video)
1 points par GN⁺ 2024-08-08 | 1 commentaires | Partager sur WhatsApp
  • 1fps.video est un outil de partage d’écran par lien, qui démarre immédiatement sous forme de binaire unique, conçu pour les collaborations où il faut surtout regarder un écran plutôt que tenir une réunion, comme chez les développeurs, les équipes IT et les spécialistes de la sécurité
  • Partant du principe qu’un faible FPS suffit souvent pour la collaboration autour du code, il réduit l’utilisation du CPU, de la mémoire et du réseau et allège la charge sur les vieux ordinateurs portables
  • L’écran est partagé à 1 FPS, mais le suivi du curseur basé sur WebSocket affiche les mouvements du pointeur à près de 30 FPS, ce qui compense pour les démonstrations précises
  • Offre un chiffrement de bout en bout ; la clé générée côté client est placée après le # dans l’URL et n’est pas envoyée au backend
  • Met l’accent sur les longues sessions et le partage à faible trafic grâce à la prise en charge de plusieurs moniteurs, au réglage de la qualité d’image et de la taille de capture, ainsi qu’à l’omission de l’envoi lorsque l’écran n’a pas changé

Le partage d’écran à 1 FPS

  • 1fps.video est un outil qui permet de lancer rapidement un partage d’écran ; le binaire est disponible dans Download
  • Il s’adresse principalement aux développeurs, aux équipes IT, aux spécialistes de la sécurité et aux utilisateurs qui préfèrent collaborer sans réunion
  • Il part du principe qu’un partage d’écran à faible FPS suffit souvent pour la plupart des tâches collaboratives, en particulier pour les développeurs qui passent beaucoup de temps à écrire du code
  • Cette approche vise à réduire les ressources et le trafic
    • Elle favorise une culture sans réunion, sans besoin d’audio
    • Elle réduit fortement l’utilisation du CPU, de la mémoire et du réseau
    • Même les vieux ordinateurs portables peuvent mieux fonctionner pendant le partage d’écran
    • La faible consommation de ressources la rend plus respectueuse de l’environnement
  • L’environnement de partage peut être ajusté selon les conditions réseau
    • Prise en charge du partage sur plusieurs moniteurs
    • Possibilité d’ajuster la qualité d’image pour optimiser l’utilisation du trafic
    • Sur les grands écrans, la taille de capture peut être ajustée afin de réduire encore le trafic
    • Utilise une comparaison intelligente de l’écran pour éviter les transferts de données inutiles lorsque l’écran ne change pas

Sécurité, confidentialité et modèle de partage

  • Pour la plupart des travaux de codage et de développement, 1 FPS est considéré comme suffisant, tandis que les mouvements du curseur sont fournis à près de 30 FPS grâce à un suivi basé sur WebSocket
  • Convient aux utilisateurs introvertis et aux télétravailleurs qui souhaitent uniquement partager leur écran, sans appel audio ni vidéo
  • Peut être utilisé avec les applications de chat d’équipe existantes, et les options de réglage multi-moniteurs, qualité d’image et taille d’écran permettent d’adapter l’expérience de partage aux conditions réseau
  • L’architecture de confidentialité et de sécurité repose sur des liens et une gestion des clés côté client
    • Toutes les données sont chiffrées de bout en bout
    • La clé de chiffrement est générée côté client et n’est pas envoyée au serveur
    • La clé est incluse après le # dans l’URL et n’est donc pas transmise au backend
    • Seules les personnes disposant du lien complet peuvent accéder à l’écran partagé
    • La comparaison de l’écran renforce la confidentialité en minimisant les transferts de données
  • Le chiffrement des coordonnées du curseur est actuellement en cours de développement
  • Le code source est disponible dans Source Code

À lire aussi

1 commentaires

 
GN⁺ 2024-08-08
Avis de Hacker News

  • Bravo pour la publication du projet. L’idée est sympa et étonnamment minimaliste, mais je vois dans le code plusieurs failles cryptographiques, donc il ne faut pas l’utiliser dans des situations où le chiffrement est essentiel.

    1. Vous générez une clé aléatoire puis [0] vous la passez à PBKDF2 pour [1] produire une clé AES-GCM de 32 octets, mais si vous pouvez utiliser 10 caractères ASCII limités et du key stretching, autant générer directement 32 octets aléatoires. PBKDF2 sert à transformer un mot de passe en clé et est loin des algorithmes recommandés aujourd’hui ; si vous avez besoin de ce genre d’opération, scrypt est préférable.
    2. Vous utilisez un nonce aléatoire de 12 octets avec AES-GCM. Avec GCM, il ne faut pas utiliser d’IV aléatoire, car l’authentification peut être compromise [2] [3]. Pour éviter les pièges d’AES-GCM liés aux nonces aléatoires, il vaudrait peut-être mieux passer à XSalsa20+Poly1305. XSalsa a l’avantage d’avoir une longueur de nonce étendue, ce qui permet d’utiliser des nonces aléatoires sereinement.
    3. Dériver une clé aléatoire à partir d’un jeu de caractères limité peut faciliter les attaques par force brute. Il faut une clé aléatoire de 256 bits, et si vous voulez la faire tenir dans un jeu de caractères donné, vous devez encoder la sortie en octets du générateur de nombres aléatoires cryptographique dans ce jeu de caractères.
    4. 1fps distribue la clé symétrique via le fragment identifier (« # ») de l’URL, et il me semble que cette partie n’est pas envoyée au serveur. Cela suppose donc un canal de distribution de clé sûr. Comme la clé est dans le lien, seuls les destinataires prévus doivent pouvoir voir ce qui se trouve après le « # ». Si le serveur est vraiment malveillant, il peut distribuer du JavaScript client qui envoie le fragment au serveur, ce qui lui donne alors accès à la clé et aux communications en clair.
      [0]: https://github.com/1fpsvideo/1fps/blob/main/1fps.go#L99
      [1]: https://github.com/1fpsvideo/1fps/blob/main/1fps.go#L287
      [2]: https://eprint.iacr.org/2016/475.pdf
      [3]: https://soatok.blog/2020/05/13/why-aes-gcm-sucks/
    • C’est justement pour recevoir ce genre de conseils que je suis venu ici, donc merci. Je vais intégrer ces changements dès que possible.
    • Les articles me semblent un peu difficiles. Peux-tu expliquer précisément quel est le problème ici avec l’utilisation d’un IV aléatoire ? Si je ne peux pas passer à chacha et que je dois me limiter à GCM, que devrais-je faire à la place ?
    • J’ai l’impression qu’il y a énormément de pièges quand on conçoit ce genre de chose. Existe-t-il une base standard et fiable sur laquelle construire une application ? Je me demande aussi si TLS pourrait convenir.
    • Merci d’avoir recommandé XSalsa20+Poly1305. La cryptographie m’a toujours intéressé, et je trouve passionnant d’apprendre les nombreuses raisons pour lesquelles il ne faut pas créer soi-même ses chiffrements et protocoles.
      Dans ce cas, je me demande si la principale raison de ne pas simplement corriger le problème de nonce tient aux pièges d’implémentation, ou si c’est lié plus subtilement aux problèmes généraux évoqués dans les articles ci-dessus.
      Vu naïvement, AES-GCM est utilisé dans beaucoup d’endroits comme TLS ou SRTP, donc quelqu’un qui ne connaît pas bien la cryptographie peut penser que c’est un bon choix.
    • Y a-t-il une méthode recommandée pour résoudre le problème n° 4 ? Cela ressemble à un problème intrinsèque des applications web, et ProtonMail semble similaire.

  • En regardant le code, il semble prendre et envoyer une capture d’écran (.jpg) chaque seconde. Je me demande si cette approche économise réellement de la bande passante par rapport à une compression vidéo moderne qui réutilise les informations des images précédentes.
    J’ai enregistré une vidéo d’une minute où j’édite du code dans VS Code, en 1440p à 10 fps avec encodage AV1, et elle faisait environ la moitié de la taille de 60 captures d’écran JPEG du même écran. Je serais curieux de voir des chiffres si vous en avez testé.

    • Il y a dix ans, j’ai expérimenté TimeSnapper Classic, un utilitaire gratuit pour Windows, et j’aimais bien sa fonction qui prenait une capture d’écran toutes les 5 secondes et permettait de revoir la journée en time-lapse.
      Les captures prenaient beaucoup d’espace disque, et en voyant qu’il y avait très peu de changements entre deux images, j’ai imaginé un algorithme qui ne stockerait que les différences avec l’image suivante. Quelques minutes plus tard, j’ai réalisé que j’étais en train de réinventer la compression vidéo.
      J’ai donc converti la séquence d’images en mp4 avec ffmpeg, et la taille du fichier a diminué d’environ 95 %. Avec ImageMagick, j’ai incrusté dans l’image les noms de fichiers horodatés ; au fond, je crois avoir recréé les fonctionnalités de TimeSnapper Classic avec deux commandes.
    • Ce n’est pas seulement une question de bande passante, c’est aussi une question d’utilisation CPU. J’ai essayé de passer les captures d’écran dans ffmpeg ou d’autres outils : ça fonctionnait, mais ça consommait tellement de ressources que c’était pratiquement inutilisable. En tout cas sur ma machine, un MacBook 13 pouces de 2019.
      D’un côté il y a l’utilisation CPU, de l’autre le réseau. À mon avis, le réseau est bon marché mais l’encodage est coûteux. Je n’ai pas de preuve, seulement des essais locaux, mais commencer à mesurer serait vraiment une très bonne idée.
      Il y a aussi une autre idée : scanner l’écran et n’envoyer que les parties modifiées. Même en n’envoyant que la moitié de l’écran, je pense qu’on pourrait battre l’encodage vidéo côté réseau. En revanche, l’algorithme de diff doit être très rapide. En 1280x720, cela fait 914400 pixels, et à 4 octets chacun, il faut traiter 3,49 Mo d’informations par seconde.
      Je suis aussi curieux de comparer l’efficacité de l’encodage vidéo au coût de génération de 60 JPEG. Les deux sont-ils comparables ?
    • C’est aussi la première chose à laquelle j’ai pensé. Je ne vois pas de raison de ne pas utiliser un codec standard en le réglant simplement sur 1 fps.
    • Cela ressemble moins à une minimisation de la bande passante qu’à un choix visant à éviter la persistance des données, c’est-à-dire remplacer et supprimer.
      On pourrait facilement faire les deux si on le voulait, mais je ne sais pas si cela vaut la peine de s’ajouter cette complexité. Je suis d’accord pour dire que cette approche pourrait devenir difficile à tenir si ça passe à l’échelle depuis la même IP.

  • Ça me plaît
    Notre flux de travail est pensé pour éliminer le besoin de bureaux et d’infrastructure technique. On diffuse en temps réel les sorties de timeline, c’est-à-dire les résultats de montage vidéo, et on garde un canal de communication ouvert. La plupart des membres de l’équipe sont plutôt introvertis, donc c’est en push-to-talk, et s’il n’y a pas besoin d’une discussion générale, on se contente généralement de laisser des notes dans le chat
    Les solutions rudimentaires finissent souvent par être adoptées

    • Ravi de l’entendre. Je viens de publier le côté serveur en open source, donc on peut jouer un peu plus avec. J’améliorerai la documentation avec le temps pour que ce soit plus facile à suivre

  • Quels sont les cas d’usage du partage d’écran sans audio ? Je ne vois pas bien quand ce serait utile. De toute façon, il faut bien communiquer avec l’autre personne d’une manière ou d’une autre, non ?

    • Il y en a beaucoup. Par exemple, quand on part au travail en laissant son ordinateur à la maison, on peut enregistrer le lien et voir ce qui s’y passe. Même chose pour le bureau à distance
      Même pendant de longues réunions, il arrive qu’on ait besoin que le partage d’écran reste actif. Parfois, on préfère coder plutôt que rester assis à écouter une réunion d’une ou deux heures
      Et ça convient aussi aux gens comme moi qui n’aiment pas l’audio. J’ai beaucoup d’étudiants que j’aimerais aider, mais je n’ai pas envie d’y ajouter l’audio. Mon chat vocal n’est pas une ressource qui se parallélise bien
    • D’après l’article, 1fps.video est adapté aux introvertis et aux télétravailleurs qui veulent partager leur écran sans la charge d’un appel audio ou vidéo, et c’est une solution polyvalente qui fonctionne avec les applis de chat d’équipe déjà utilisées
      Cela ressemble davantage à envoyer des captures d’écran tout en discutant par texte qu’à un « partage d’écran pendant un appel vocal ». Je comprends pourquoi certaines personnes peuvent préférer ça
    • Les escrocs utilisent parfois le partage d’écran sans audio tout en étant au téléphone avec leur cible
    • Pourquoi ne pas simplement appeler ? Tout le monde a toujours un téléphone portable, inutile de réinventer la roue

  • À propos de la partie « J’en ai marre du partage d’écran parce que Google Meet est limité à 1 heure et Zoom à 40 minutes », jitsi[0] est une alternative de visioconférence open source[1] basée sur WebRTC. C’est un substitut assez complet à des outils comme Zoom, Google Meet ou Slack
    On peut l’utiliser sur le site principal, ou l’auto-héberger si on le souhaite
    [0]: https://meet.jit.si/
    [1]: https://github.com/jitsi

  • Il pourrait être intéressant de créer une heuristique pour choisir quelle frame utiliser. Prendre systématiquement la frame la plus récente au hasard n’est probablement pas idéal ; il vaudrait peut-être mieux choisir une frame avec peu de mouvement, sans animation en cours, ou selon des métriques similaires
    Pour aller plus loin, on pourrait aussi analyser fenêtre par fenêtre, puis construire une forme d’agrégation pour l’ensemble de la frame

    • Analyser fenêtre par fenêtre puis créer une agrégation pour toute la frame, ça pourrait nous amener dans une zone comparable à celle des « appareils photo » de smartphones, où tellement de calcul est appliqué à la sortie du capteur lumineux qu’il devient presque difficile d’appeler ça une photo [0]
      C’est une idée intéressante, et j’ai entendu dire qu’aux échecs, une idée similaire s’appelle la recherche de quiescence (quiescence search)[1], mais ça ne vaut probablement pas l’effort
      [0] https://old.reddit.com/r/Android/comments/11nzrb0/samsung_sp...
      [1] https://en.wikipedia.org/wiki/Quiescence_search
    • Cela pourrait aller à l’encontre de l’objectif d’une utilisation minimale des ressources de calcul
      Cela dit, ça ressemble à une excellente idée et à un problème intéressant
    • En fait, j’aime bien cette idée. J’avais déjà pensé à détecter les changements possibles à l’écran en scannant, autour des zones où un changement avait été repéré auparavant, une matrice 100x100 clairsemée avec un pas de 5 à 10 pixels

  • J’ai une erreur de compilation dans github.com/go-vgo/robotgo indiquant qu’il manque X11/extensions/XTest.h
    https://github.com/go-vgo/robotgo?tab=readme-ov-file#require...
    Il y a des prérequis qui ne sont pas indiqués sur la page. Sur Mint 22, j’ai dû installer le paquet libxtst-dev

    • Je vais mettre à jour la documentation. robotgo a quelques problèmes sous Windows, donc je suis en train d’en examiner une partie

  • Je cherchais justement quelque chose comme ça aujourd’hui. Je surveille à distance des événements de tests physiques, et laisser un Google Meet enregistré ouvert est un bazar, mais il me fallait quand même un chat texte pour l’interface
    Ça ressemble à une très bonne interface minimaliste. Si l’envie me prend, je pourrais peut-être y ajouter d’une manière ou d’une autre de la persistance pour le chat
    Par ailleurs, faut-il considérer que le texte ou la voix synchronisés se font ailleurs, comme via un appel téléphonique ou une description textuelle sur Slack ?

    • Je fais parfois ça avec un ami. On utilise un appel WhatsApp avec un simple partage d’écran entre mon ordinateur portable et le PC de mon ami
    • Quand tu dis que tu cherchais ça aujourd’hui, est-ce que tu avais précisément pensé plus tôt aujourd’hui qu’il te fallait 1 fps ?

  • Pour mon usage, Moonlight Game Streaming a quasiment remplacé VNC. Il faudrait juste de meilleures fonctions comme le transfert de fichiers et le partage du presse-papiers

    • Franchement, il me suffit d’avoir le presse-papiers, et ce serait bien d’avoir un service qui gère la traversée de NAT

  • Il y a un problème avec le suivi du curseur. Je ne sais pas si c’est parce que j’ai plusieurs moniteurs
    Sur cette image, l’anneau correspond à la position réelle du curseur https://i.imgur.com/TvzskjS.png

    • Je promets de corriger au fil des principaux cas d’usage. N’hésite pas à revenir vérifier plus tard si c’est corrigé. Merci pour le retour