Show HN: compartilhamento de tela criptografado em 1 FPS para pessoas introvertidas

 (1fps.video)
1 pontos por GN⁺ 2024-08-08 | 1 comentários | Compartilhar no WhatsApp
  • 1fps.video é uma ferramenta de compartilhamento de tela baseada em link que inicia imediatamente com um único binário, voltada para colaboração em que ver a tela importa mais do que reuniões, como para desenvolvedores, equipes de TI e profissionais de segurança
  • Parte da premissa de que, para colaboração em programação, um FPS baixo muitas vezes é suficiente, reduzindo uso de CPU, memória e rede e diminuindo a carga em notebooks antigos
  • A tela é compartilhada a 1 FPS, mas o rastreamento de cursor via WebSocket mostra o movimento do ponteiro perto de 30 FPS, compensando demonstrações que exigem mais precisão
  • Oferece criptografia de ponta a ponta, e a chave gerada no cliente fica depois do # na URL, sem ser enviada ao backend
  • Foca em sessões longas e compartilhamento com baixo tráfego por meio de múltiplos monitores, ajuste de qualidade da imagem e do tamanho de captura, além de pular o envio quando a tela não muda

Como funciona o compartilhamento de tela em 1 FPS

  • 1fps.video é uma ferramenta para iniciar rapidamente o compartilhamento de tela, e o binário pode ser baixado em Download
  • O público principal são desenvolvedores, equipes de TI, profissionais de segurança e usuários que preferem colaboração sem reuniões
  • A proposta parte da ideia de que compartilhamento de tela com baixo FPS costuma ser suficiente para a maior parte do trabalho colaborativo, especialmente para desenvolvedores que passam muito tempo escrevendo código
  • Essa abordagem tem foco em reduzir recursos e tráfego
    • Como não precisa de áudio, incentiva uma cultura sem reuniões
    • Reduz bastante o uso de CPU, memória e rede
    • Mesmo notebooks antigos podem funcionar melhor durante o compartilhamento de tela
    • O baixo uso de recursos também é mais amigável ao meio ambiente
  • O ambiente de compartilhamento pode ser ajustado de acordo com as condições da rede
    • Suporta compartilhamento com múltiplos monitores
    • É possível ajustar a qualidade da imagem para otimizar o uso de tráfego
    • Em telas grandes, dá para ajustar o tamanho da captura para reduzir ainda mais o tráfego
    • Usa comparação inteligente de tela para evitar transmissão desnecessária de dados quando a tela não mudou

Segurança, privacidade e modelo de compartilhamento

  • A ideia é que 1 FPS seja suficiente para a maior parte do trabalho de programação e desenvolvimento, enquanto o movimento do cursor é fornecido perto de 30 FPS com rastreamento baseado em WebSocket
  • É adequado para usuários introvertidos e trabalhadores remotos que querem compartilhar apenas a tela, sem chamadas de áudio ou vídeo
  • Pode ser usado junto com aplicativos de chat de equipe já existentes, e a experiência de compartilhamento pode ser ajustada às condições da rede com opções de múltiplos monitores, qualidade de imagem e tamanho de tela
  • A estrutura de privacidade e segurança é baseada no link e no gerenciamento de chaves no lado do cliente
    • Todos os dados são criptografados de ponta a ponta
    • A chave de criptografia é gerada no cliente e não é enviada ao servidor
    • A chave fica incluída depois do # na URL, então não é repassada ao backend
    • Apenas quem tiver o link completo pode acessar a tela compartilhada
    • A comparação de tela minimiza a transmissão de dados e reforça a privacidade
  • No momento, o trabalho de criptografia das coordenadas do cursor está em andamento
  • O código-fonte está disponível em Source Code

Leituras relacionadas

1 comentários

 
GN⁺ 2024-08-08
Opiniões do Hacker News

  • Boa decisão em publicar o projeto. A ideia é legal e surpreendentemente minimalista, mas vi várias falhas criptográficas no código-fonte, então ele não deve ser usado em situações em que a criptografia seja essencial

    1. Depois de criar uma chave aleatória, ela é passada para [0] PBKDF2 para gerar [1] uma chave AES-GCM de 32 bytes, mas, se você pode usar 10 caracteres ASCII limitados e alongamento de chave, bastaria gerar 32 bytes aleatórios. PBKDF2 serve para transformar senhas em chaves e hoje está longe dos algoritmos recomendados; se esse tipo de operação for necessário, scrypt é uma opção melhor
    2. Está sendo usado um nonce aleatório de 12 bytes no AES-GCM. No GCM, não se deve usar IV aleatório, pois a autenticação pode ser quebrada [2] [3]. Para evitar as armadilhas do AES-GCM relacionadas a nonces aleatórios, talvez seja melhor trocar para XSalsa20+Poly1305. O XSalsa tem a vantagem de ter um nonce de tamanho estendido, então é possível usar nonce aleatório com tranquilidade
    3. Derivar uma chave aleatória a partir de um conjunto limitado de caracteres pode facilitar ataques de força bruta. Você deve ter uma chave aleatória de 256 bits e, se quiser colocar essa chave dentro de um conjunto específico de caracteres, deve codificar a saída em bytes de um gerador criptográfico de números aleatórios nesse conjunto de caracteres
    4. O 1fps distribui a chave simétrica pelo identificador de fragmento ("#") da URL; pelo que lembro, essa parte não é enviada ao servidor. Portanto, isso pressupõe um canal seguro de distribuição de chaves. Como a chave está no link, só o destinatário pretendido deve conseguir ver o que vem depois do "#". Se o servidor for realmente malicioso, ele pode distribuir JavaScript do cliente que envie o fragmento ao servidor, e então o servidor teria acesso à chave e à comunicação em texto claro
      [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/
    • É bom, foi para receber esse tipo de conselho que vim aqui. Vou incorporar essas mudanças o mais rápido possível
    • Os artigos me parecem um pouco difíceis. Você pode explicar qual é exatamente o problema de usar IV aleatório aqui? Se eu não puder trocar para chacha e só puder usar GCM, o que devo fazer no lugar?
    • Parece que há armadilhas demais ao projetar algo assim. Existe uma base padrão e confiável sobre a qual seja possível criar aplicações? Também fico me perguntando se TLS poderia funcionar
    • Obrigado por recomendar XSalsa20+Poly1305. Sempre tive interesse em criptografia, então é interessante aprender os vários motivos para não criar suas próprias cifras e protocolos
      Neste caso, fico curioso se o principal motivo para não simplesmente mandar corrigir o problema do nonce são as armadilhas de implementação, ou se isso está ligado de forma mais sutil aos problemas gerais descritos nos textos acima
      Olhando de forma ingênua, AES-GCM é usado em muitos lugares, como TLS ou SRTP, então alguém que não entende muito de criptografia poderia achar que é uma boa escolha
    • Há algum método recomendado para resolver o problema nº 4? Parece um problema inerente a apps web, e o ProtonMail parece fazer algo parecido

  • Olhando o código, parece que ele tira e envia uma captura de tela (.jpg) a cada segundo. Fico me perguntando se esse método realmente economiza largura de banda em comparação com a compressão de vídeo moderna, que reutiliza informações dos quadros anteriores
    Gravei um vídeo de 1 minuto editando código no VS Code em 1440p a 10 fps, codificado em AV1, e ele ficou com cerca de metade do tamanho de 60 capturas JPEG da mesma tela. Gostaria de ver números, se alguém tiver testado

    • Experimentei o TimeSnapper Classic, um utilitário gratuito para Windows de 10 anos atrás, e gostava da função de tirar uma captura de tela a cada 5 segundos e permitir ver o dia em timelapse
      As capturas ocupavam muito espaço em disco e, ao perceber que quase nada mudava entre as imagens, pensei em um algoritmo que salvasse apenas a diferença em relação à imagem anterior. Alguns minutos depois, percebi que estava reinventando a compressão de vídeo
      Então converti a sequência de imagens para mp4 com ffmpeg, e o tamanho do arquivo caiu cerca de 95%. Com ImageMagick, gravei o nome do arquivo com timestamp na própria imagem; no fim, acho que reproduzi a funcionalidade do TimeSnapper Classic com 2 comandos
    • Não é só uma questão de largura de banda, mas também de uso de CPU. Tentei passar as capturas de tela para o ffmpeg ou outras ferramentas e, embora funcionasse, consumia recursos demais e ficava praticamente inviável. Pelo menos foi assim no meu computador, um MacBook de 13 polegadas de 2019
      De um lado há o uso de CPU, do outro há a rede. Minha visão é que rede é barata, mas codificação é cara. Não tenho provas, só experimentos locais, mas começar a medir é uma ótima ideia
      Há também outra ideia: varrer a tela e enviar apenas as partes alteradas. Mesmo enviando só metade da tela, acho que daria para vencer a codificação de vídeo no aspecto de rede. Mas o algoritmo de diff teria que ser muito rápido. Em 1280x720 são 914400 pixels e, com 4 bytes cada, é preciso processar 3,49 MB de informação por segundo
      Também tenho curiosidade sobre a eficiência da codificação de vídeo e o custo de gerar 60 JPEGs. Será que são parecidos?
    • Esse também foi meu primeiro pensamento. Não vejo motivo para não usar um codec padrão, mas configurado para 1 fps
    • Parece mais uma escolha por evitar persistência de dados, ou seja, substituição e exclusão, do que por minimizar largura de banda
      Se quiser, dá para fazer os dois com facilidade, mas não sei se vale o incômodo. Concordo que, se escalar a partir do mesmo IP, essa abordagem pode ficar pesada

  • Gostei
    Nosso fluxo de trabalho é estruturado para eliminar a necessidade de escritório e de infraestrutura técnica. Fazemos streaming em tempo real da saída da timeline, ou seja, do resultado da edição de vídeo, e mantemos um canal de comunicação aberto. Como a maioria da equipe é bem introvertida, usamos push-to-talk e, se não for necessária uma discussão geral, normalmente deixamos apenas uma nota no chat
    Muitas vezes, a solução mais tosca acaba sendo adotada

    • Fico feliz em ouvir isso. Acabei de liberar o lado do servidor como open source, então dá para brincar um pouco mais com ele. Vou melhorar a documentação com o tempo para ficar mais fácil de seguir

  • Qual é o caso de uso de compartilhamento de tela sem áudio? Não consigo ver bem quando isso seria útil. De todo modo, você não precisa se comunicar de alguma forma com a outra pessoa?

    • Há muitos. Por exemplo, quando você sai para trabalhar deixando o computador de casa ligado, pode salvar o link e ver o que está acontecendo em casa. O mesmo vale para desktop remoto
      Mesmo durante reuniões longas, às vezes é preciso manter o compartilhamento de tela ativo. Há momentos em que você prefere programar em vez de ficar sentado ouvindo uma reunião de 1 a 2 horas
      E também serve para pessoas como eu, que não gostam de áudio. Tenho muitos alunos que quero ajudar, mas não quero envolver áudio nisso. Meu chat de voz não é um recurso que paraleliza bem
    • Segundo o texto, o 1fps.video é uma solução versátil para introvertidos e trabalhadores remotos que querem compartilhar a tela sem o peso de chamadas de áudio ou vídeo, funcionando junto com os apps de chat de equipe que já usam
      Parece mais próximo de enviar screenshots enquanto se conversa por texto do que de “compartilhar a tela durante uma chamada de voz”. Dá para entender por que algumas pessoas prefeririam isso
    • Golpistas às vezes usam compartilhamento de tela sem áudio enquanto falam ao telefone com o alvo
    • Não bastaria ligar por telefone? Todo mundo sempre está com o celular, então não há necessidade de reinventar a roda

  • Sobre a parte “cansei de compartilhar tela porque o Google Meet tem limite de 1 hora e o Zoom de 40 minutos”, o jitsi[0] é uma alternativa open source[1] de videoconferência baseada em WebRTC. É um substituto bem completo para coisas como Zoom, Google Meet e Slack
    Você pode usar pelo site principal ou hospedar por conta própria, se quiser
    [0]: https://meet.jit.si/
    [1]: https://github.com/jitsi

  • Poderia ser interessante criar uma heurística para escolher qual frame usar. Escolher cegamente sempre o frame mais recente provavelmente não é o ideal; talvez seja melhor escolher um frame com pouco movimento, sem animações em andamento ou com métricas semelhantes
    Para algo mais sofisticado, daria até para analisar por janela e depois compor uma agregação do frame inteiro

    • Analisar por janela e depois criar uma agregação do frame inteiro pode chegar a um território parecido com o das “câmeras” de smartphone, que aplicam tanto processamento à saída do sensor de luz que quase fica difícil chamar aquilo de foto [0]
      É uma ideia legal, e ouvi dizer que no xadrez existe um conceito parecido chamado busca de quiescência (quiescence search)[1], mas provavelmente não vale o esforço
      [0] https://old.reddit.com/r/Android/comments/11nzrb0/samsung_sp...
      [1] https://en.wikipedia.org/wiki/Quiescence_search
    • Isso poderia contrariar o objetivo de usar o mínimo de recursos computacionais
      Ainda assim, parece uma ótima ideia e um problema interessante
    • Na verdade, gostei dessa ideia. Já tinha pensado antes em detectar possíveis mudanças na tela escaneando, ao redor dos pontos onde mudanças foram encontradas anteriormente, uma matriz esparsa de 100x100 com intervalos de 5 a 10 pixels

  • Dá erro de compilação em github.com/go-vgo/robotgo dizendo que falta X11/extensions/XTest.h
    https://github.com/go-vgo/robotgo?tab=readme-ov-file#require...
    Há um pré-requisito que não está escrito na página. No Mint 22, precisei instalar o pacote libxtst-dev

    • Vou atualizar a documentação. O robotgo tem alguns problemas no Windows, então estou investigando algumas partes no momento

  • Eu estava procurando algo assim hoje. Estou monitorando remotamente um evento de teste físico, e deixar um Google Meet gravando aberto é uma bagunça, mas eu ainda precisava de chat de texto para a interface
    Parece uma interface minimalista muito boa. Se eu me animar, talvez tente adicionar algum tipo de persistência ao chat
    Além disso, devo entender que texto ou voz sincronizados ficam em outro lugar, como uma ligação telefônica ou uma explicação por texto no Slack?

    • Às vezes faço isso com um amigo. Uso uma ligação do WhatsApp junto com um compartilhamento de tela simples entre meu notebook e o PC dele
    • Você disse que estava procurando algo assim hoje; mais cedo hoje você tinha pensado que precisava exatamente de 1fps?

  • No meu uso, Moonlight Game Streaming praticamente substituiu o VNC. Só falta melhorar recursos como transferência de arquivos e compartilhamento de área de transferência

    • Sinceramente, só preciso da área de transferência, e seria bom ter um serviço que fizesse travessia de NAT

  • Há um problema no rastreamento do cursor. Não sei se é porque tenho vários monitores
    Nesta imagem, o anel é a posição real do cursor https://i.imgur.com/TvzskjS.png

    • Prometo que vou fazer correções para cada caso de uso principal. Pode verificar de novo mais tarde para ver se foi corrigido. Obrigado pelo feedback