Show HN: 1-FPS encrypted screen sharing for introverts

Original Article ↗ Hacker News Discussion ↗

Concept & Intended Use Cases

  • Tool shares encrypted screenshots at ~1 FPS plus smooth cursor tracking, pitched as “screenshots + chat” rather than full video calls.
  • Suggested uses:
    • For introverts or people who dislike calls but still want to show what’s on screen.
    • Long meetings where someone wants to keep sharing their screen but focus on coding.
    • Lightweight remote monitoring of a home or work machine, including checking on bots or long-running tasks.
  • Some see it as a neat, minimalist workflow that pairs well with existing chat tools.

Skepticism & Privacy / Management Concerns

  • Some question screensharing without audio: text-chat plus delayed visuals can be clumsy; sometimes a static screenshot may be easier.
  • Concerns raised about potential misuse for workplace surveillance (continuous desktop feeds) and ethical / legal boundaries (e.g., GDPR, worker rights). Others argue that collaboration tools can be policy‑bound and even monetized in enterprise settings.

Compression, Bandwidth & Performance

  • Implementation appears to take periodic JPEG screenshots. Commenters question efficiency versus real video codecs (AV1, H.264/HEVC) that exploit frame-to-frame similarity.
  • JPEG is noted as suboptimal for UI/text; PNG or screen-optimized codecs (like those used in VNC/RDP or game streaming) may yield better quality and bandwidth use.
  • Author notes experiments with ffmpeg felt too CPU‑heavy on their hardware; prefers trading extra bandwidth for simplicity and low CPU.
  • Ideas floated:
    • Detect and transmit only changed regions of the screen.
    • Heuristics to pick “stable” frames.
    • Hardware-accelerated encoding and codec tuning for low-latency, low-CPU use.

Cryptography & Security Model

  • Detailed critique finds several crypto issues: misuse of PBKDF2 on already-random keys, unsafe AES-GCM nonce strategy, reduced keyspace due to character-set restrictions, and the risk that a malicious server could exfiltrate keys embedded in URL fragments via injected JS.
  • Recommendations include using XSalsa20-Poly1305 via a misuse-resistant library (e.g., NaCl secretbox), generating full-entropy keys then encoding them, and rethinking how the web UI is delivered (e.g., from a trusted local binary).
  • Broader discussion underscores that “don’t roll your own crypto” applies to protocols and key distribution, not just primitives.

Implementation & Ecosystem Issues

  • Linux users report needing extra X11/XTest dev packages; Wayland support is unclear.
  • Windows users encounter build and cursor-position issues; some dispute characterizations of the Go Windows toolchain as “often broken.”
  • Multi-monitor cursor tracking bugs are reported.
  • The service domain is flagged as malware by OpenDNS in at least one environment.

Alternatives & Distribution

  • Comparisons and alternatives mentioned: VNC/RDP variants, WebRTC tools (Jitsi, Brave Talk, Nextcloud Talk), Moonlight/Parsec/game-streaming style solutions.
  • WebRTC scaling and TURN/SFU infrastructure costs are highlighted as a barrier for free, large-scale screen-sharing services.
  • Some dislike requiring a Go toolchain for installation and urge distributing self-contained binaries; others accept this for hobby projects.