Show HN: 내성적인 사람들을 위한 1-FPS 암호화 화면 공유

 (1fps.video)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 1fps.video는 단일 바이너리로 바로 시작하는 링크 기반 화면 공유 도구로, 개발자·IT 팀·보안 전문가처럼 회의보다 화면 확인이 필요한 협업에 맞춰짐
  • 코딩 협업에는 낮은 FPS도 충분한 경우가 많다는 전제에서 CPU·메모리·네트워크 사용량을 줄이고 오래된 노트북의 부담을 낮춤
  • 화면은 1 FPS로 공유하되 WebSocket 기반 커서 추적으로 포인터 움직임은 거의 30 FPS에 가깝게 보여 정밀한 시연을 보완함
  • 종단 간 암호화를 제공하며, 클라이언트에서 생성된 키는 URL의 # 뒤에 들어가 백엔드로 전송되지 않음
  • 다중 모니터, 이미지 품질·캡처 크기 조절, 변경 없는 화면 전송 생략을 통해 긴 세션과 저트래픽 공유에 초점을 둠

1 FPS 화면 공유 방식

  • 1fps.video는 화면 공유를 빠르게 시작할 수 있는 도구로, Download에서 바이너리를 받을 수 있음
  • 주요 대상은 개발자, IT 팀, 보안 전문가, 회의 없는 협업을 선호하는 사용자임
  • 낮은 FPS 화면 공유는 대부분의 협업 작업, 특히 코드를 작성하는 시간이 많은 개발자에게 충분한 경우가 많다는 전제를 둠
  • 이 방식은 리소스와 트래픽을 줄이는 데 초점을 맞춤
    • 오디오가 필요 없어 회의 없는 문화를 촉진함
    • CPU, 메모리, 네트워크 사용량을 크게 줄임
    • 오래된 노트북도 화면 공유 중 더 잘 동작할 수 있음
    • 낮은 리소스 사용으로 더 환경 친화적임
  • 공유 환경은 네트워크 조건에 맞게 조정 가능함
    • 다중 모니터 공유를 지원함
    • 이미지 품질을 조절해 트래픽 사용량을 최적화할 수 있음
    • 큰 디스플레이에서는 화면 캡처 크기를 조절해 트래픽을 더 줄일 수 있음
    • 화면이 바뀌지 않았을 때 불필요한 데이터 전송을 피하는 지능형 화면 비교를 사용함

보안, 프라이버시, 공유 모델

  • 대부분의 코딩·개발 작업에는 1 FPS가 충분하다고 보며, 커서 움직임은 WebSocket 기반 추적으로 거의 30 FPS에 가깝게 제공함
  • 오디오나 비디오 통화 없이 화면만 공유하려는 내성적인 사용자와 원격 근무자에게 적합함
  • 기존 팀 채팅 애플리케이션과 함께 사용할 수 있으며, 다중 모니터·이미지 품질·화면 크기 조절 옵션으로 공유 경험을 네트워크 상황에 맞출 수 있음
  • 프라이버시와 보안 구조는 링크와 클라이언트 측 키 관리에 기반함
    • 모든 데이터는 종단 간 암호화됨
    • 암호화 키는 클라이언트 측에서 생성되며 서버로 전송되지 않음
    • 키는 URL의 # 뒤에 포함되어 백엔드로 전달되지 않음
    • 전체 링크를 가진 사람만 공유 화면에 접근할 수 있음
    • 화면 비교로 데이터 전송을 최소화해 프라이버시를 강화함
  • 현재 커서 좌표 암호화 작업이 진행 중임
  • 소스 코드는 Source Code에서 제공됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 프로젝트 공개 잘했음. 아이디어가 멋지고 놀랄 만큼 미니멀하지만, 소스에서 여러 암호학적 결함이 보여서 암호화가 핵심인 상황에는 쓰면 안 됨

    1. 무작위 키를 만든 뒤 [0] PBKDF2에 넣어 [1] 32바이트 AES-GCM 키를 만들고 있는데, 10개의 제한된 ASCII 문자와 키 스트레칭을 쓸 수 있다면 그냥 32바이트 난수를 만들면 됨. PBKDF2는 비밀번호를 키로 바꾸는 용도이고 요즘 권장 알고리즘과는 거리가 있으니, 이런 작업이 필요하면 scrypt가 더 나음
    2. AES-GCM에 12바이트 무작위 nonce를 쓰고 있음. GCM에서는 무작위 IV를 쓰면 안 되고, 인증이 깨질 수 있음 [2] [3]. 무작위 nonce와 관련한 AES-GCM의 함정을 피하려면 XSalsa20+Poly1305로 바꾸는 편이 나을 수 있음. XSalsa는 nonce 길이가 확장되어 있어서 무작위 nonce를 안심하고 쓸 수 있다는 장점이 있음
    3. 제한된 문자 집합으로 무작위 키를 파생하면 무차별 대입 공격이 쉬워질 수 있음. 256비트 무작위 키를 가져야 하고, 그 키를 특정 문자 집합 안에 넣고 싶다면 암호학적 난수 생성기의 바이트 출력을 그 문자 집합으로 인코딩해야 함
    4. 1fps는 URL의 fragment identifier("#")로 대칭키를 배포하는데, 이 부분은 서버로 전송되지 않는 것으로 기억함. 따라서 안전한 키 배포 채널을 전제로 함. 링크에 키가 들어 있으니 "#" 뒤를 의도한 수신자만 볼 수 있어야 함. 서버가 정말 악의적이라면 클라이언트 JavaScript를 배포해 fragment를 서버로 보내게 만들 수 있고, 그러면 서버가 키와 평문 통신에 접근 가능해짐
      [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/
    • 이런 조언을 받으려고 여기 온 거라 좋음. 가능한 한 빨리 이 변경들을 반영하겠음
    • 논문들이 좀 어렵게 느껴짐. 여기서 무작위 IV를 쓰는 게 정확히 뭐가 문제인지 설명해 줄 수 있나? chacha로 바꾸지 못하고 GCM만 쓸 수 있다고 하면 대신 어떻게 해야 하나?
    • 이런 걸 설계할 때 함정이 너무 많은 느낌임. 애플리케이션을 그 위에 만들 수 있는 표준적이고 신뢰할 만한 기반이 있나? TLS가 가능할지도 궁금함
    • XSalsa20+Poly1305를 추천해 줘서 고마움. 암호학에 늘 관심이 있어서, 직접 암호와 프로토콜을 만들면 안 되는 여러 이유를 배우는 게 흥미로움
      이 경우 nonce 문제를 고치라고 하지 않는 주된 이유가 구현 과정의 함정 때문인지, 아니면 위 글들에 나온 일반적인 문제들과 더 섬세하게 연결되어 있는지 궁금함
      순진하게 보면 AES-GCM은 TLS나 SRTP처럼 많은 곳에서 쓰이니, 암호학을 잘 모르는 사람은 이게 좋은 선택이라고 생각할 수 있음
    • 4번 문제를 해결할 추천 방법이 있나? 웹 앱에는 본질적인 문제처럼 보이고, ProtonMail도 비슷해 보임

  • 코드를 보니 매초 스크린샷(.jpg)을 찍어 보내는 방식으로 보임. 이 방식이 이전 프레임 정보를 재사용하는 현대적인 동영상 압축보다 실제로 대역폭을 아끼는지 궁금함
    VS Code에서 코드를 편집하는 1분짜리 영상을 1440p 10fps, AV1 인코딩으로 녹화했더니 같은 화면의 JPEG 스크린샷 60장보다 절반 정도 크기였음. 테스트한 수치가 있다면 궁금함

    • 10년 전 Windows용 무료 유틸리티인 TimeSnapper Classic을 실험해 봤는데, 5초마다 스크린샷을 찍고 하루를 타임랩스로 볼 수 있게 해주는 기능이 좋았음
      스크린샷이 디스크 공간을 많이 차지했고, 사진 사이에 바뀌는 부분이 거의 없다는 걸 보고 이후 이미지와의 차이만 저장하는 알고리즘을 떠올렸음. 몇 분 뒤 내가 동영상 압축을 재발명하고 있다는 걸 깨달음
      그래서 ffmpeg로 이미지 시퀀스를 mp4로 바꿨고, 파일 크기가 대략 95% 줄었음. ImageMagick으로 타임스탬프 파일명을 이미지에 박아 넣어서, 사실상 TimeSnapper Classic의 기능을 명령어 2개로 재현했던 것 같음
    • 대역폭만의 문제가 아니라 CPU 사용량 문제이기도 함. 스크린샷을 ffmpeg나 다른 도구에 넣어 봤는데, 동작은 해도 자원을 너무 많이 먹어서 사실상 쓰기 어려웠음. 적어도 내 컴퓨터인 2019년형 MacBook 13인치에서는 그랬음
      한쪽에는 CPU 사용량이 있고 다른 한쪽에는 네트워크가 있음. 네트워크는 싸지만 인코딩은 비싸다는 게 내 생각임. 증거는 없고 로컬 실험뿐이지만, 측정을 시작하는 건 정말 좋은 아이디어임
      화면을 스캔해서 바뀐 부분만 보내는 다른 아이디어도 있음. 화면의 절반만 보내도 네트워크 측면에서는 동영상 인코딩을 이길 수 있을 것 같음. 다만 diff 알고리즘은 매우 빨라야 함. 1280x720이면 914400픽셀이고, 4바이트씩이면 1초에 3.49MB 정보를 처리해야 함
      동영상 인코딩 효율과 JPEG 60장 생성 비용도 궁금함. 둘이 비슷한가?
    • 나도 가장 먼저 든 생각이 이거였음. 표준 코덱을 쓰되 1fps로 설정하지 않을 이유가 없어 보임
    • 대역폭 최소화보다는 데이터 지속성 방지, 즉 교체와 삭제를 택한 것처럼 보임
      원하면 둘 다 쉽게 할 수 있겠지만, 번거로움을 감수할 만한지는 잘 모르겠음. 같은 IP에서 규모가 커지면 이 방식이 버거울 수 있다는 데는 동의함

  • 마음에 듦
    우리 작업 흐름은 사무실과 기술 인프라의 필요성을 없애는 쪽으로 짜여 있음. 타임라인 출력물, 즉 영상 편집 결과를 실시간 스트리밍하고 열린 커뮤니케이션 채널을 둠. 팀원 대부분이 꽤 내향적이라 push-to-talk 방식이고, 전체 토론이 필요하지 않으면 대체로 채팅에 메모만 남김
    투박한 해법이 오히려 채택되는 경우가 많음

    • 그렇게 들으니 기쁨. 방금 서버 쪽을 오픈소스로 공개했으니 좀 더 가지고 놀 수 있음. 문서는 시간이 지나며 개선해서 따라 하기 쉽게 만들겠음

  • 오디오 없는 화면 공유의 사용 사례가 뭔가? 언제 유용할지 잘 모르겠음. 어쨌든 상대와 어떻게든 소통해야 하지 않나?

    • 많음. 예를 들어 집 컴퓨터를 두고 출근할 때 링크를 저장해 두고 집에서 무슨 일이 일어나는지 볼 수 있음. 원격 데스크톱도 마찬가지임
      긴 회의 중에도 화면 공유가 계속 필요한 경우가 있음. 1~2시간짜리 회의를 앉아서 듣기보다는 코딩하고 싶을 때가 있음
      그리고 나처럼 오디오를 좋아하지 않는 사람에게도 맞음. 도와주고 싶은 학생들이 많지만 오디오까지 끼고 싶지는 않음. 내 음성 채팅은 병렬화가 잘 되는 자원이 아님
    • 글에 따르면 1fps.video는 오디오나 영상 통화의 부담 없이 화면을 공유하고 싶은 내향적인 사람과 원격 근무자에게 맞고, 이미 쓰는 팀 채팅 앱과 함께 동작하는 다목적 솔루션이라고 되어 있음
      “음성 통화 중 화면 공유”보다는 스크린샷을 보내며 텍스트 채팅하는 것에 가까워 보임. 왜 선호하는 사람이 있을지 이해됨
    • 사기꾼들은 표적과 전화 통화하면서 오디오 없는 화면 공유를 쓰기도 함
    • 그냥 전화하면 되지 않나? 모두가 항상 휴대폰을 갖고 있으니, 그 바퀴를 다시 발명할 필요는 없음

  • “Google Meet은 1시간 제한, Zoom은 40분 제한이라 화면 공유에 지쳤다”는 부분에 대해, jitsi[0]는 WebRTC 기반의 오픈소스[1] 화상회의 대안임. Zoom, Google Meet, Slack 같은 것의 대체재로 기능이 꽤 완비되어 있음
    메인 사이트에서 써도 되고, 원하면 직접 호스팅할 수도 있음
    [0]: https://meet.jit.si/
    [1]: https://github.com/jitsi

  • 어떤 프레임을 쓸지 고르는 휴리스틱을 만들어 보면 흥미로울 수 있음. 항상 최신 프레임을 무작정 고르는 건 이상적일 가능성이 낮고, 움직임이 적거나 진행 중인 애니메이션이 없거나 비슷한 지표를 가진 프레임을 고르는 편이 나을 수 있음
    더 화려하게 하려면 창 단위로 분석한 뒤 전체 프레임에 대한 집계 형태를 구성할 수도 있음

    • 창 단위로 분석한 뒤 전체 프레임 집계를 만든다는 건, 스마트폰 “카메라”가 광센서 출력에 너무 많은 계산을 적용해서 거의 사진이라고 부르기 어려워지는 영역과 비슷해질 수 있음 [0]
      멋진 아이디어이고, 체스에서는 비슷한 발상을 정지 탐색(quiescence search)[1]이라고 들었지만, 아마 수고할 만한 가치는 없을 듯함
      [0] https://old.reddit.com/r/Android/comments/11nzrb0/samsung_sp...
      [1] https://en.wikipedia.org/wiki/Quiescence_search
    • 이러면 최소한의 계산 자원 사용이라는 목적과 어긋날 수 있음
      그래도 훌륭한 아이디어이자 흥미로운 문제처럼 들림
    • 사실 이 아이디어 마음에 듦. 이전에 변화가 발견된 지점 주변을 5~10픽셀 간격의 희소한 100x100 행렬로 스캔해서 가능한 화면 변화를 감지하는 생각을 했었음

  • github.com/go-vgo/robotgo에서 X11/extensions/XTest.h가 없다는 컴파일 오류가 남
    https://github.com/go-vgo/robotgo?tab=readme-ov-file#require...
    페이지에 적히지 않은 선행 조건이 있음. Mint 22에서는 libxtst-dev 패키지를 설치해야 했음

    • 문서를 업데이트하겠음. robotgo는 Windows에서 몇 가지 문제가 있어서 현재 일부를 살펴보는 중임

  • 오늘 이런 걸 찾고 있었음. 물리 테스트 이벤트를 원격 모니터링 중인데 녹화 켠 Google Meet을 열어 두는 건 엉망이고, 그래도 인터페이스용 텍스트 채팅은 필요했음
    아주 좋은 미니멀 인터페이스처럼 보임. 기분이 내키면 채팅 지속성을 어떤 식으로든 붙여볼 수도 있겠음
    추가로 동기화된 텍스트나 음성은 전화 통화나 Slack 텍스트 설명처럼 다른 곳에서 한다고 보면 되나?

    • 가끔 친구와 이렇게 함. WhatsApp 전화 통화와 내 노트북과 친구 PC 사이의 단순 화면 공유를 같이 씀
    • 오늘 이런 걸 찾고 있었다고 했는데, 오늘 일찍이 정확히 1fps가 필요하다고 생각했던 건가?

  • 내 용도에서는 Moonlight Game Streaming이 거의 VNC를 대체했음. 파일 전송, 클립보드 공유 같은 기능만 좀 더 좋아지면 됨

    • 솔직히 클립보드만 있으면 되고, NAT 통과를 해 주는 서비스가 있으면 좋겠음

  • 커서 추적에 문제가 있음. 모니터가 여러 대라서 그런 건지 모르겠음
    여기 이미지에서 링이 실제 커서 위치임 https://i.imgur.com/TvzskjS.png

    • 주요 사용 사례마다 수정이 들어가게 하겠다고 약속함. 나중에 다시 확인해서 고쳐졌는지 봐도 좋음. 피드백 고마움
답변달기