Show HN: 1-FPS-verschlüsselte Bildschirmfreigabe für introvertierte Menschen

 (1fps.video)
1 Punkte von GN⁺ 2024-08-08 | 1 Kommentare | Auf WhatsApp teilen
  • 1fps.video ist ein linkbasiertes Bildschirmfreigabe-Tool, das als einzelne Binärdatei sofort startet und sich für Zusammenarbeit eignet, bei der eher ein Blick auf den Bildschirm als ein Meeting nötig ist, etwa für Entwickler, IT-Teams und Sicherheitsexperten
  • Ausgehend davon, dass für die gemeinsame Arbeit am Code oft auch eine niedrige FPS ausreicht, reduziert es CPU-, Speicher- und Netzwerkauslastung und entlastet ältere Laptops
  • Der Bildschirm wird mit 1 FPS geteilt, aber dank WebSocket-basierter Cursorverfolgung werden Zeigerbewegungen mit nahezu 30 FPS angezeigt, um präzise Demos zu unterstützen
  • Es bietet Ende-zu-Ende-Verschlüsselung, und der im Client erzeugte Schlüssel steht hinter # in der URL und wird nicht an das Backend gesendet
  • Mit Fokus auf lange Sitzungen und traffic-arme Freigabe unterstützt es mehrere Monitore, die Anpassung von Bildqualität und Aufnahmegröße sowie das Auslassen von Übertragungen bei unverändertem Bildschirminhalt

1-FPS-Bildschirmfreigabe

  • 1fps.video ist ein Tool, mit dem sich Bildschirmfreigabe schnell starten lässt; die Binärdatei kann unter Download heruntergeladen werden
  • Die wichtigsten Zielgruppen sind Entwickler, IT-Teams, Sicherheitsexperten und Nutzer, die Zusammenarbeit ohne Meetings bevorzugen
  • Es basiert auf der Annahme, dass Bildschirmfreigabe mit niedriger FPS für die meisten kollaborativen Aufgaben oft ausreicht, insbesondere für Entwickler, die viel Zeit mit dem Schreiben von Code verbringen
  • Dieser Ansatz konzentriert sich darauf, Ressourcenverbrauch und Traffic zu senken
    • Da kein Audio nötig ist, fördert er eine meetingfreie Kultur
    • CPU-, Speicher- und Netzwerknutzung werden deutlich reduziert
    • Auch ältere Laptops können während der Bildschirmfreigabe besser arbeiten
    • Der geringe Ressourcenverbrauch ist umweltfreundlicher
  • Die Freigabeumgebung lässt sich an die Netzwerkbedingungen anpassen
    • Mehrere Monitore werden unterstützt
    • Die Bildqualität kann angepasst werden, um den Traffic zu optimieren
    • Bei großen Displays kann die Größe der Bildschirmaufnahme angepasst werden, um den Traffic weiter zu reduzieren
    • Es wird ein intelligenter Bildschirmvergleich verwendet, um unnötige Datenübertragungen zu vermeiden, wenn sich der Bildschirminhalt nicht geändert hat

Sicherheit, Privatsphäre und Freigabemodell

  • Für die meisten Coding- und Entwicklungsaufgaben werden 1 FPS als ausreichend angesehen; Cursorbewegungen werden per WebSocket-basierter Verfolgung mit nahezu 30 FPS dargestellt
  • Es eignet sich für introvertierte Nutzer und Remote-Arbeitende, die nur ihren Bildschirm teilen möchten, ohne Audio- oder Videoanruf
  • Es kann zusammen mit bestehenden Team-Chat-Anwendungen verwendet werden, und die Optionen für mehrere Monitore, Bildqualität und Bildschirmgröße erlauben es, das Freigabeerlebnis an die Netzwerksituation anzupassen
  • Die Struktur für Privatsphäre und Sicherheit basiert auf Links und clientseitiger Schlüsselverwaltung
    • Alle Daten sind Ende-zu-Ende-verschlüsselt
    • Der Verschlüsselungsschlüssel wird clientseitig erzeugt und nicht an den Server übertragen
    • Der Schlüssel ist hinter # in der URL enthalten und wird nicht an das Backend weitergegeben
    • Nur Personen mit dem vollständigen Link können auf den geteilten Bildschirm zugreifen
    • Der Bildschirmvergleich minimiert die Datenübertragung und stärkt so die Privatsphäre
  • Derzeit wird an der Verschlüsselung von Cursor-Koordinaten gearbeitet
  • Der Quellcode ist unter Source Code verfügbar

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-08-08
Hacker-News-Kommentare

  • Gut, dass das Projekt veröffentlicht wurde. Die Idee ist cool und überraschend minimalistisch, aber im Source sind mehrere kryptografische Schwächen zu sehen, daher sollte man es nicht in Situationen einsetzen, in denen Verschlüsselung zentral ist.

    1. Es wird ein zufälliger Schlüssel erzeugt und dann [0] in PBKDF2 gesteckt, um [1] einen 32-Byte-AES-GCM-Schlüssel zu erzeugen. Wenn man 10 eingeschränkte ASCII-Zeichen und Key Stretching verwenden kann, kann man auch einfach 32 Byte Zufallsdaten erzeugen. PBKDF2 ist dafür gedacht, Passwörter in Schlüssel umzuwandeln, und ist von heute empfohlenen Algorithmen weit entfernt; wenn so etwas nötig ist, ist scrypt besser.
    2. Es wird ein zufälliger 12-Byte-Nonce für AES-GCM verwendet. Bei GCM sollte man keine zufälligen IVs verwenden, da die Authentifizierung brechen kann [2] [3]. Um die Fallstricke von AES-GCM im Zusammenhang mit zufälligen Nonces zu vermeiden, wäre ein Wechsel zu XSalsa20+Poly1305 möglicherweise besser. XSalsa hat den Vorteil einer erweiterten Nonce-Länge, sodass man zufällige Nonces bedenkenlos verwenden kann.
    3. Wenn man zufällige Schlüssel aus einem eingeschränkten Zeichensatz ableitet, kann das Brute-Force-Angriffe erleichtern. Man sollte einen zufälligen 256-Bit-Schlüssel haben, und wenn man diesen Schlüssel in einem bestimmten Zeichensatz unterbringen will, sollte man die Byte-Ausgabe eines kryptografischen Zufallszahlengenerators in diesen Zeichensatz kodieren.
    4. 1fps verteilt den symmetrischen Schlüssel über den Fragment Identifier ("#") der URL; soweit ich mich erinnere, wird dieser Teil nicht an den Server übertragen. Es setzt also einen sicheren Kanal zur Schlüsselverteilung voraus. Da der Schlüssel im Link steckt, darf nur der beabsichtigte Empfänger den Teil nach dem "#" sehen können. Wenn der Server wirklich bösartig ist, könnte er Client-JavaScript ausliefern, das das Fragment an den Server schickt; dann hätte der Server Zugriff auf den Schlüssel und die Klartextkommunikation.
      [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/
    • Genau wegen solcher Hinweise bin ich hier, also gut. Ich werde diese Änderungen so schnell wie möglich übernehmen.
    • Die Paper wirken etwas schwierig. Kannst du erklären, was genau hier das Problem daran ist, einen zufälligen IV zu verwenden? Wenn man nicht auf ChaCha wechseln kann und nur GCM verwenden darf, was sollte man stattdessen tun?
    • Beim Entwurf solcher Dinge fühlt es sich an, als gäbe es sehr viele Fallstricke. Gibt es eine standardisierte und vertrauenswürdige Grundlage, auf der man Anwendungen bauen kann? Ich frage mich auch, ob TLS möglich wäre.
    • Danke für die Empfehlung von XSalsa20+Poly1305. Ich war schon immer an Kryptografie interessiert, und es ist spannend, die vielen Gründe zu lernen, warum man keine eigenen Chiffren und Protokolle bauen sollte.
      Mich würde interessieren, ob der Hauptgrund, hier nicht einfach zu sagen „behebe das Nonce-Problem“, in den Fallstricken der Implementierung liegt oder ob er subtiler mit den allgemeinen Problemen aus den obigen Artikeln zusammenhängt.
      Naiv betrachtet wird AES-GCM an vielen Stellen verwendet, etwa in TLS oder SRTP, daher könnte jemand ohne viel Kryptografie-Wissen denken, dass es eine gute Wahl ist.
    • Gibt es eine empfohlene Methode, Problem 4 zu lösen? Für Web-Apps wirkt das wie ein inhärentes Problem, und ProtonMail scheint ähnlich zu sein.

  • Beim Blick auf den Code scheint es so zu funktionieren, dass jede Sekunde ein Screenshot (.jpg) aufgenommen und gesendet wird. Ich frage mich, ob das tatsächlich Bandbreite gegenüber moderner Videokompression spart, die Informationen aus vorherigen Frames wiederverwendet.
    Ich habe ein einminütiges Video aufgenommen, in dem ich in VS Code Code editiere, 1440p mit 10 fps und AV1-Encoding; es war etwa halb so groß wie 60 JPEG-Screenshots desselben Bildschirms. Falls es dazu Messwerte gibt, würden sie mich interessieren.

    • Ich habe vor 10 Jahren mit TimeSnapper Classic experimentiert, einem kostenlosen Windows-Tool, und fand die Funktion gut, alle 5 Sekunden einen Screenshot zu machen und den Tag als Timelapse ansehen zu können.
      Die Screenshots nahmen viel Speicherplatz ein, und als ich sah, dass sich zwischen den Bildern kaum etwas änderte, kam mir ein Algorithmus in den Sinn, der nur die Unterschiede zum nachfolgenden Bild speichert. Ein paar Minuten später merkte ich, dass ich gerade Videokompression neu erfand.
      Also habe ich die Bildsequenz mit ffmpeg in mp4 umgewandelt, und die Dateigröße sank um ungefähr 95 %. Mit ImageMagick habe ich die Zeitstempel-Dateinamen in die Bilder eingebettet; im Grunde habe ich damit wohl die Funktionen von TimeSnapper Classic mit zwei Befehlen nachgebaut.
    • Es ist nicht nur eine Frage der Bandbreite, sondern auch der CPU-Auslastung. Ich habe versucht, Screenshots in ffmpeg oder andere Tools zu stecken; es funktionierte zwar, verbrauchte aber so viele Ressourcen, dass es praktisch kaum nutzbar war. Zumindest auf meinem Computer, einem 13-Zoll-MacBook von 2019, war das so.
      Auf der einen Seite steht die CPU-Auslastung, auf der anderen das Netzwerk. Meine Einschätzung ist: Netzwerk ist billig, Encoding ist teuer. Ich habe keine Belege, nur lokale Experimente, aber mit Messungen anzufangen ist wirklich eine gute Idee.
      Es gibt auch die Idee, den Bildschirm zu scannen und nur geänderte Bereiche zu senden. Wenn man nur die Hälfte des Bildschirms sendet, könnte das aus Netzwerksicht meiner Meinung nach Video-Encoding schlagen. Allerdings müsste der Diff-Algorithmus sehr schnell sein. Bei 1280x720 sind das 914400 Pixel, und bei jeweils 4 Byte müssen pro Sekunde 3,49 MB an Informationen verarbeitet werden.
      Mich interessiert auch die Effizienz von Video-Encoding und die Kosten, 60 JPEGs zu erzeugen. Sind beide ähnlich?
    • Das war auch mein erster Gedanke. Es scheint keinen Grund zu geben, nicht einen Standard-Codec zu verwenden und ihn auf 1 fps einzustellen.
    • Es wirkt eher so, als habe man sich für das Vermeiden von Datenpersistenz entschieden, also für Ersetzen und Löschen, statt für minimale Bandbreite.
      Wenn man wollte, könnte man vermutlich beides leicht machen, aber ich bin mir nicht sicher, ob sich der Aufwand lohnt. Ich stimme zu, dass dieser Ansatz bei größerer Skalierung von derselben IP aus an seine Grenzen kommen könnte.

  • Gefällt mir
    Unser Workflow ist darauf ausgelegt, die Notwendigkeit für ein Büro und technische Infrastruktur zu beseitigen. Wir streamen Timeline-Outputs, also die Ergebnisse des Videoschnitts, in Echtzeit und haben offene Kommunikationskanäle. Die meisten Teammitglieder sind ziemlich introvertiert, daher nutzen wir push-to-talk, und wenn keine allgemeine Diskussion nötig ist, hinterlassen wir meist nur Notizen im Chat.
    Grobe Lösungen setzen sich oft eher durch.

    • Freut mich, das zu hören. Ich habe gerade die Serverseite als Open Source veröffentlicht, damit man ein bisschen mehr damit herumspielen kann. Die Dokumentation werde ich mit der Zeit verbessern, damit sie leichter nachzuvollziehen ist.

  • Was ist der Use Case für Bildschirmfreigabe ohne Audio? Ich bin mir nicht sicher, wann das nützlich wäre. Man muss doch ohnehin irgendwie mit der anderen Person kommunizieren, oder?

    • Es gibt viele. Wenn man zum Beispiel den Heimcomputer stehen lässt und zur Arbeit fährt, kann man den Link speichern und sehen, was zu Hause passiert. Dasselbe gilt für Remote Desktop.
      Auch während langer Meetings muss die Bildschirmfreigabe manchmal weiterlaufen. Manchmal möchte man lieber coden, als in einem ein- bis zweistündigen Meeting zu sitzen und zuzuhören.
      Und es passt auch zu Leuten wie mir, die Audio nicht mögen. Es gibt viele Studierende, denen ich helfen möchte, aber ich will nicht auch noch Audio dabeihaben. Mein Voice-Chat ist keine Ressource, die sich gut parallelisieren lässt.
    • Dem Beitrag zufolge richtet sich 1fps.video an Introvertierte und Remote-Arbeitende, die ihren Bildschirm ohne die Belastung durch Audio- oder Videoanrufe teilen möchten, und ist eine vielseitige Lösung, die zusammen mit den Team-Chat-Apps funktioniert, die man bereits nutzt.
      Es wirkt eher wie Textchat mit Screenshots als wie „Bildschirmfreigabe während eines Sprachanrufs“. Ich verstehe, warum manche das bevorzugen.
    • Betrüger nutzen auch Bildschirmfreigabe ohne Audio, während sie mit ihren Zielpersonen telefonieren.
    • Kann man nicht einfach telefonieren? Alle haben immer ein Handy dabei, also muss man das Rad nicht neu erfinden.

  • Zu der Stelle „Google Meet hat ein 1-Stunden-Limit, Zoom ein 40-Minuten-Limit, deshalb habe ich genug von Bildschirmfreigabe“: jitsi[0] ist eine Open-Source-[1]-Videokonferenz-Alternative auf Basis von WebRTC. Als Ersatz für Zoom, Google Meet, Slack und Ähnliches ist es ziemlich funktionsreich.
    Man kann es über die Hauptseite nutzen oder, wenn man möchte, selbst hosten.
    [0]: https://meet.jit.si/
    [1]: https://github.com/jitsi

  • Es könnte interessant sein, eine Heuristik dafür zu entwickeln, welchen Frame man auswählt. Immer blind den neuesten Frame zu nehmen, ist wahrscheinlich nicht ideal; besser könnte es sein, einen Frame mit wenig Bewegung, ohne laufende Animationen oder mit ähnlichen Metriken zu wählen.
    Wenn man es aufwendiger machen möchte, könnte man auch fensterweise analysieren und daraus eine Aggregation für den gesamten Frame bilden.

    • Fensterweise Analyse und daraus eine Gesamt-Frame-Aggregation zu machen, könnte in einen Bereich geraten, in dem die „Kamera“ eines Smartphones so viel Berechnung auf den Output des Lichtsensors anwendet, dass man es kaum noch ein Foto nennen kann [0].
      Coole Idee, und ich habe gehört, dass es beim Schach einen ähnlichen Ansatz namens Ruhesuche (quiescence search)[1] gibt, aber wahrscheinlich ist es den Aufwand nicht wert.
      [0] https://old.reddit.com/r/Android/comments/11nzrb0/samsung_sp...
      [1] https://en.wikipedia.org/wiki/Quiescence_search
    • Das könnte dem Ziel widersprechen, möglichst wenig Rechenressourcen zu nutzen.
      Trotzdem klingt es nach einer großartigen Idee und einem interessanten Problem.
    • Eigentlich gefällt mir die Idee. Ich hatte früher daran gedacht, mögliche Bildschirmänderungen zu erkennen, indem man in der Nähe von Stellen, an denen zuvor Änderungen entdeckt wurden, eine dünn besetzte 100x100-Matrix in 5- bis 10-Pixel-Abständen scannt.

  • Bei github.com/go-vgo/robotgo bekomme ich einen Kompilierfehler, dass X11/extensions/XTest.h fehlt.
    https://github.com/go-vgo/robotgo?tab=readme-ov-file#require...
    Es gibt eine Voraussetzung, die auf der Seite nicht aufgeführt ist. Unter Mint 22 musste ich das Paket libxtst-dev installieren.

    • Ich werde die Dokumentation aktualisieren. robotgo hat unter Windows ein paar Probleme, daher sehe ich mir gerade Teile davon an.

  • Genau so etwas habe ich heute gesucht. Ich überwache remote ein physisches Testereignis, und ein aufgezeichnetes Google Meet offen zu lassen ist ein ziemliches Durcheinander, aber ich brauchte trotzdem Textchat für die Oberfläche.
    Sieht nach einem sehr guten minimalistischen Interface aus. Wenn mir danach ist, könnte ich vielleicht auf irgendeine Weise Chat-Persistenz ergänzen.
    Außerdem kann man davon ausgehen, dass synchroner Text oder Sprache anderswo stattfindet, etwa per Telefonanruf oder Slack-Textbeschreibung?

    • Mache ich manchmal so mit einem Freund. Wir nutzen einen WhatsApp-Anruf zusammen mit einfacher Bildschirmfreigabe zwischen meinem Laptop und seinem PC.
    • Du sagtest, du hättest heute genau so etwas gesucht — hattest du früher am Tag wirklich gedacht, dass du genau 1fps brauchst?

  • Für meinen Anwendungsfall hat Moonlight Game Streaming VNC fast ersetzt. Nur Funktionen wie Dateiübertragung und Clipboard-Sharing müssten noch etwas besser werden.

    • Ehrlich gesagt brauche ich nur die Zwischenablage, und ein Dienst für NAT-Traversal wäre schön.

  • Es gibt ein Problem mit der Cursor-Verfolgung. Ich weiß nicht, ob es daran liegt, dass ich mehrere Monitore habe.
    In diesem Bild ist der Ring die tatsächliche Cursorposition: https://i.imgur.com/TvzskjS.png

    • Ich verspreche, für die wichtigsten Use Cases Korrekturen einzubauen. Schau später gern noch einmal nach, ob es behoben ist. Danke für das Feedback.