Show HN: Compartir pantalla cifrado a 1 FPS para personas introvertidas

 (1fps.video)
1 puntos por GN⁺ 2024-08-08 | 1 comentarios | Compartir por WhatsApp
  • 1fps.video es una herramienta de pantalla compartida basada en enlaces que arranca de inmediato como un binario único, pensada para colaboraciones donde hace falta revisar la pantalla más que tener reuniones, como en equipos de desarrollo, TI y especialistas en seguridad
  • Parte de la idea de que, para colaborar programando, un FPS bajo suele ser suficiente, y reduce el uso de CPU, memoria y red, disminuyendo la carga en laptops antiguas
  • La pantalla se comparte a 1 FPS, pero el seguimiento del cursor basado en WebSocket muestra el movimiento del puntero casi a 30 FPS, complementando las demostraciones que requieren precisión
  • Ofrece cifrado de extremo a extremo; la clave generada en el cliente se incluye después del # en la URL y no se envía al backend
  • Se enfoca en sesiones largas y en compartir con poco tráfico, con soporte para múltiples monitores, ajuste de calidad de imagen y tamaño de captura, y omisión del envío cuando la pantalla no cambia

Cómo funciona el uso compartido de pantalla a 1 FPS

  • 1fps.video es una herramienta para iniciar rápidamente una pantalla compartida; se puede obtener el binario en Download
  • Sus principales destinatarios son desarrolladores, equipos de TI, especialistas en seguridad y usuarios que prefieren colaborar sin reuniones
  • El uso compartido de pantalla con bajo FPS parte de la premisa de que suele ser suficiente para la mayoría de las tareas colaborativas, especialmente para desarrolladores que pasan mucho tiempo escribiendo código
  • Este enfoque se centra en reducir recursos y tráfico
    • Al no requerir audio, fomenta una cultura sin reuniones
    • Reduce considerablemente el uso de CPU, memoria y red
    • Las laptops antiguas pueden funcionar mejor durante la pantalla compartida
    • Al usar menos recursos, también es más amigable con el medio ambiente
  • El entorno de uso compartido se puede ajustar según las condiciones de la red
    • Admite compartir múltiples monitores
    • Permite ajustar la calidad de imagen para optimizar el uso de tráfico
    • En pantallas grandes, se puede ajustar el tamaño de captura para reducir aún más el tráfico
    • Usa comparación inteligente de pantalla para evitar transmitir datos innecesarios cuando la pantalla no ha cambiado

Seguridad, privacidad y modelo de uso compartido

  • Considera que 1 FPS es suficiente para la mayoría de las tareas de programación y desarrollo, mientras que el movimiento del cursor se ofrece casi a 30 FPS mediante seguimiento basado en WebSocket
  • Es adecuado para usuarios introvertidos y trabajadores remotos que quieren compartir solo la pantalla, sin llamadas de audio ni video
  • Puede usarse junto con aplicaciones de chat de equipo existentes, y sus opciones de múltiples monitores, calidad de imagen y ajuste de tamaño de pantalla permiten adaptar la experiencia de uso compartido a la situación de la red
  • La estructura de privacidad y seguridad se basa en enlaces y en la gestión de claves del lado del cliente
    • Todos los datos están cifrados de extremo a extremo
    • La clave de cifrado se genera del lado del cliente y no se envía al servidor
    • La clave se incluye después del # en la URL, por lo que no se transmite al backend
    • Solo quienes tengan el enlace completo pueden acceder a la pantalla compartida
    • La comparación de pantalla minimiza la transmisión de datos y refuerza la privacidad
  • Actualmente se está trabajando en el cifrado de coordenadas del cursor
  • El código fuente está disponible en Source Code

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-08-08
Opiniones de Hacker News

  • Hiciste bien en publicar el proyecto. La idea es genial y sorprendentemente minimalista, pero en el código fuente se ven varias fallas criptográficas, así que no debería usarse en situaciones donde el cifrado sea algo central.

    1. Están creando una clave aleatoria y luego [0] la pasan por PBKDF2 para crear [1] una clave AES-GCM de 32 bytes, pero si se pueden usar 10 caracteres ASCII limitados y estiramiento de clave, bastaría con generar 32 bytes aleatorios. PBKDF2 sirve para convertir contraseñas en claves y está lejos de los algoritmos recomendados hoy; si necesitan hacer algo así, scrypt es mejor.
    2. Están usando un nonce aleatorio de 12 bytes en AES-GCM. En GCM no se debe usar un IV aleatorio, porque la autenticación puede romperse [2] [3]. Para evitar las trampas de AES-GCM relacionadas con nonces aleatorios, quizá convenga cambiar a XSalsa20+Poly1305. XSalsa tiene la ventaja de que la longitud del nonce está extendida, así que se pueden usar nonces aleatorios con tranquilidad.
    3. Derivar una clave aleatoria a partir de un conjunto limitado de caracteres puede facilitar ataques de fuerza bruta. Deberían tener una clave aleatoria de 256 bits y, si quieren meter esa clave dentro de un conjunto de caracteres específico, deben codificar la salida en bytes del generador criptográfico de números aleatorios en ese conjunto de caracteres.
    4. 1fps distribuye la clave simétrica mediante el fragment identifier ("#") de la URL, que según recuerdo no se envía al servidor. Por lo tanto, presupone un canal seguro de distribución de claves. Como la clave está en el enlace, solo los destinatarios previstos deberían poder ver lo que viene después de "#". Si el servidor fuera realmente malicioso, podría distribuir JavaScript del cliente para hacer que el fragment se envíe al servidor, y entonces el servidor tendría acceso a la clave y a la comunicación en texto plano.
      [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/
    • Vine aquí justamente para recibir consejos como estos, así que me parece excelente. Incorporaré estos cambios lo antes posible.
    • Los papers se me hacen algo difíciles. ¿Podrías explicar exactamente cuál es el problema de usar un IV aleatorio aquí? Si no pudiera cambiar a chacha y solo pudiera usar GCM, ¿qué debería hacer en su lugar?
    • Siento que hay demasiadas trampas al diseñar algo como esto. ¿Existe una base estándar y confiable sobre la cual se pueda construir una aplicación? También me pregunto si TLS podría servir.
    • Gracias por recomendar XSalsa20+Poly1305. Siempre me ha interesado la criptografía, así que me resulta fascinante aprender las muchas razones por las que no hay que crear cifrados y protocolos propios.
      En este caso, me pregunto si la razón principal para no recomendar simplemente arreglar el problema del nonce es por las trampas de implementación, o si está conectada de forma más sutil con los problemas generales mencionados en los artículos anteriores.
      Visto ingenuamente, AES-GCM se usa en muchos lugares, como TLS o SRTP, así que alguien que no sepa mucho de criptografía podría pensar que es una buena elección.
    • ¿Hay algún método recomendado para resolver el problema del punto 4? Parece un problema inherente a las apps web, y ProtonMail se ve parecido.

  • Al ver el código, parece que toma y envía una captura de pantalla (.jpg) cada segundo. Me pregunto si este método realmente ahorra ancho de banda frente a la compresión de video moderna, que reutiliza información de cuadros anteriores.
    Grabé un video de 1 minuto editando código en VS Code a 1440p 10fps con codificación AV1, y resultó tener aproximadamente la mitad del tamaño que 60 capturas JPEG de la misma pantalla. Me interesaría ver cifras si las han probado.

    • Hace 10 años probé TimeSnapper Classic, una utilidad gratuita para Windows, y me gustó su función de tomar capturas cada 5 segundos y permitir ver el día como un timelapse.
      Las capturas ocupaban mucho espacio en disco y, al ver que casi nada cambiaba entre fotos, se me ocurrió un algoritmo que guardara solo las diferencias con la imagen siguiente. Unos minutos después me di cuenta de que estaba reinventando la compresión de video.
      Así que convertí la secuencia de imágenes a mp4 con ffmpeg, y el tamaño del archivo se redujo aproximadamente un 95%. Con ImageMagick incrusté los nombres de archivo con timestamp en las imágenes, y creo que básicamente repliqué la funcionalidad de TimeSnapper Classic con 2 comandos.
    • No es solo un problema de ancho de banda, sino también de uso de CPU. Probé pasar las capturas por ffmpeg y otras herramientas, y aunque funcionaba, consumía tantos recursos que en la práctica era difícil de usar. Al menos así fue en mi computadora, una MacBook de 13 pulgadas de 2019.
      De un lado está el uso de CPU y del otro la red. Mi opinión es que la red es barata, pero la codificación es cara. No tengo pruebas, solo experimentos locales, pero empezar a medir sería una muy buena idea.
      También hay otra idea: escanear la pantalla y enviar solo las partes que cambiaron. Incluso enviando solo la mitad de la pantalla, creo que podría superar a la codificación de video desde el punto de vista de la red. Eso sí, el algoritmo de diff tendría que ser muy rápido. En 1280x720 hay 914400 píxeles y, a 4 bytes cada uno, habría que procesar 3.49 MB de información por segundo.
      También me interesa cuánto cuesta generar 60 JPEG frente a la eficiencia de la codificación de video. ¿Son parecidas?
    • Esto también fue lo primero que pensé. No veo razón para no usar un códec estándar y configurarlo a 1fps.
    • Más que minimizar el ancho de banda, parece que eligieron evitar la persistencia de los datos, es decir, reemplazarlos y borrarlos.
      Si uno quisiera, probablemente podría hacer ambas cosas fácilmente, pero no sé si valdría la pena la molestia. Coincido en que, si escala desde la misma IP, este enfoque podría volverse pesado.

  • Me gusta
    Nuestro flujo de trabajo está diseñado para eliminar la necesidad de una oficina y de infraestructura técnica. Transmitimos en tiempo real la salida de la línea de tiempo, es decir, el resultado de la edición de video, y mantenemos un canal de comunicación abierto. La mayoría del equipo es bastante introvertida, así que usamos push-to-talk, y si no hace falta una discusión grupal, por lo general solo dejamos notas en el chat
    Muchas veces las soluciones toscas terminan siendo las adoptadas

    • Me alegra oír eso. Acabo de publicar como open source la parte del servidor, así que se puede experimentar un poco más. Iré mejorando la documentación con el tiempo para que sea fácil de seguir

  • ¿Cuál es el caso de uso de compartir pantalla sin audio? No termino de ver cuándo sería útil. De todos modos, ¿no hay que comunicarse de alguna forma con la otra persona?

    • Hay muchos. Por ejemplo, cuando sales a trabajar y dejas tu computadora de casa, puedes guardar el enlace y ver qué está pasando en casa. Lo mismo aplica para escritorio remoto
      También hay veces en que necesitas mantener la pantalla compartida durante reuniones largas. A veces prefieres programar en vez de sentarte a escuchar una reunión de 1 o 2 horas
      Y también encaja con gente como yo, a la que no le gusta el audio. Hay muchos estudiantes a los que quiero ayudar, pero no quiero meter audio en el medio. Mi chat de voz no es un recurso que se paralelice bien
    • Según el artículo, 1fps.video está pensado para personas introvertidas y trabajadores remotos que quieren compartir pantalla sin la carga de una llamada de audio o video, y es una solución versátil que funciona junto con la app de chat de equipo que ya usan
      Parece más cercano a chatear por texto enviando capturas de pantalla que a “compartir pantalla durante una llamada de voz”. Entiendo por qué algunas personas lo preferirían
    • Los estafadores a veces usan compartir pantalla sin audio mientras hablan por teléfono con su objetivo
    • ¿No bastaría con llamar por teléfono? Todo el mundo siempre tiene el celular encima, así que no hace falta reinventar la rueda

  • Sobre la parte de “estoy cansado de compartir pantalla porque Google Meet tiene límite de 1 hora y Zoom de 40 minutos”, jitsi[0] es una alternativa open source[1] de videoconferencia basada en WebRTC. Es bastante completa como reemplazo de Zoom, Google Meet, Slack y similares
    Puedes usarla desde el sitio principal o alojarla tú mismo si quieres
    [0]: https://meet.jit.si/
    [1]: https://github.com/jitsi

  • Podría ser interesante crear una heurística para elegir qué frame usar. Elegir siempre a ciegas el frame más reciente probablemente no sea lo ideal; podría ser mejor escoger un frame con poco movimiento, sin animaciones en curso o con métricas similares
    Si quisieras hacerlo más sofisticado, también podrías analizar por ventana y luego construir algún tipo de agregación para el frame completo

    • Analizar por ventana y luego crear una agregación del frame completo podría acercarse al terreno en que la “cámara” de un smartphone aplica tanto cómputo a la salida del sensor de luz que ya casi no se puede llamar fotografía [0]
      Es una idea interesante, y en ajedrez he oído que un concepto similar se llama búsqueda de quietud (quiescence search)[1], pero probablemente no valga el esfuerzo
      [0] https://old.reddit.com/r/Android/comments/11nzrb0/samsung_sp...
      [1] https://en.wikipedia.org/wiki/Quiescence_search
    • Eso podría ir en contra del objetivo de usar la menor cantidad posible de recursos de cómputo
      Aun así, suena como una gran idea y un problema interesante
    • De hecho me gusta esta idea. Antes había pensado en detectar posibles cambios en la pantalla escaneando alrededor de los puntos donde se había encontrado cambio, con una matriz dispersa de 100x100 a intervalos de 5 a 10 píxeles

  • Me da un error de compilación en github.com/go-vgo/robotgo porque falta X11/extensions/XTest.h
    https://github.com/go-vgo/robotgo?tab=readme-ov-file#require...
    Hay un prerrequisito que no aparece en la página. En Mint 22 tuve que instalar el paquete libxtst-dev

    • Actualizaré la documentación. robotgo tiene algunos problemas en Windows, así que ahora estoy revisando parte de eso

  • Justo hoy estaba buscando algo así. Estoy monitoreando remotamente un evento de pruebas físicas, y dejar abierto un Google Meet con grabación activada es un desastre, pero aun así necesitaba chat de texto para la interfaz
    Parece una interfaz minimalista muy buena. Si me da la gana, quizá podría agregarle algún tipo de persistencia al chat
    Además, ¿se supone que el texto o la voz sincronizados van por otro lado, como una llamada telefónica o una explicación por texto en Slack?

    • A veces hago esto con un amigo. Usamos una llamada de WhatsApp junto con una pantalla compartida simple entre mi laptop y la PC de mi amigo
    • Dijiste que hoy estabas buscando algo así; ¿hoy más temprano habías pensado que necesitabas exactamente 1fps?

  • Para mi uso, Moonlight Game Streaming casi reemplazó a VNC. Solo haría falta que mejoren un poco funciones como transferencia de archivos y compartir el portapapeles

    • Honestamente, solo necesito el portapapeles, y sería bueno tener un servicio que haga traversal de NAT

  • Hay un problema con el seguimiento del cursor. No sé si será porque tengo varios monitores
    En esta imagen, el anillo marca la posición real del cursor https://i.imgur.com/TvzskjS.png

    • Prometo ir haciendo correcciones para los principales casos de uso. Si quieres, vuelve a revisarlo más adelante para ver si ya está arreglado. Gracias por el feedback