Show HN: 内向的な人のための1 FPS暗号化画面共有
(1fps.video)- 1fps.video は、単一バイナリですぐに起動できるリンクベースの画面共有ツールで、開発者・ITチーム・セキュリティ専門家のように、会議よりも画面確認が必要なコラボレーションに向いている
- コーディングでの共同作業では低いFPSでも十分な場合が多いという前提で、CPU・メモリ・ネットワーク使用量を減らし、古いノートPCへの負荷を下げる
- 画面は 1 FPS で共有しつつ、WebSocketベースのカーソル追跡によりポインターの動きはほぼ30 FPSに近く表示し、精密なデモを補完する
- エンドツーエンド暗号化を提供し、クライアントで生成されたキーはURLの
#以降に入り、バックエンドには送信されない - マルチモニター、画像品質・キャプチャサイズの調整、変更のない画面の送信省略により、長時間セッションと低トラフィック共有に重点を置く
1 FPSの画面共有方式
- 1fps.video は画面共有を素早く開始できるツールで、Downloadからバイナリを入手できる
- 主な対象は開発者、ITチーム、セキュリティ専門家、会議なしのコラボレーションを好むユーザー
- 低FPSの画面共有は、ほとんどの共同作業、とくにコードを書く時間が多い開発者にとって十分な場合が多いという前提に立っている
- この方式はリソースとトラフィックの削減に重点を置く
- 音声が不要なため、会議なしの文化を促進する
- CPU、メモリ、ネットワーク使用量を大幅に削減する
- 古いノートPCでも画面共有中により快適に動作できる
- リソース使用量が少ないため、より環境にやさしい
- 共有環境はネットワーク条件に合わせて調整できる
- マルチモニター共有に対応する
- 画像品質を調整してトラフィック使用量を最適化できる
- 大型ディスプレイでは画面キャプチャサイズを調整し、トラフィックをさらに減らせる
- 画面が変わっていないときに不要なデータ送信を避けるインテリジェントな画面比較を使用する
セキュリティ、プライバシー、共有モデル
- ほとんどのコーディング・開発作業には 1 FPS で十分だと考えており、カーソルの動きはWebSocketベースの追跡でほぼ30 FPSに近く提供する
- 音声やビデオ通話なしで画面だけを共有したい内向的なユーザーやリモートワーカーに適している
- 既存のチームチャットアプリケーションと併用でき、マルチモニター・画像品質・画面サイズ調整オプションにより、共有体験をネットワーク状況に合わせられる
- プライバシーとセキュリティの構造は、リンクとクライアント側のキー管理に基づく
- すべてのデータはエンドツーエンド暗号化される
- 暗号化キーはクライアント側で生成され、サーバーには送信されない
- キーはURLの
#以降に含まれ、バックエンドには渡されない - 完全なリンクを持つ人だけが共有画面にアクセスできる
- 画面比較によりデータ送信を最小化し、プライバシーを強化する
- 現在、カーソル座標の暗号化作業が進行中
- ソースコードは Source Code で提供されている
1件のコメント
Hacker News のコメント
プロジェクト公開おめでとう。アイデアは素晴らしく、驚くほどミニマルだが、ソースを見るといくつもの暗号学的な欠陥があり、暗号化が重要な場面では使うべきではない
"#")で対称鍵を配布しているが、この部分はサーバーには送信されないはず。したがって、安全な鍵配布チャネルを前提としている。リンクに鍵が入っているので、"#"以降は意図した受信者だけが見られる必要がある。サーバーが本当に悪意を持っていれば、クライアント JavaScript を配布してフラグメントをサーバーへ送るようにでき、その場合サーバーは鍵と平文通信の両方にアクセスできてしまう[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/
この場合、nonce の問題を自分で直せとはあまり言われない主な理由が、実装時の落とし穴にあるのか、それとも上の記事にある一般的な問題ともっと微妙な形で結び付いているのか気になる
素朴に考えると、AES-GCM は TLS や SRTP など多くの場所で使われているので、暗号に詳しくない人はこれが良い選択だと思ってしまいそうだ
コードを見ると、毎秒スクリーンショット（
.jpg）を撮って送る方式のようだ。この方式が、前のフレーム情報を再利用する現代的な動画圧縮より本当に帯域を節約できるのか気になるVS Code でコードを編集する 1 分間の動画を 1440p・10fps・AV1 エンコードで録画したところ、同じ画面の JPEG スクリーンショット 60 枚より半分ほどのサイズだった。もしテストした数値があれば知りたい
スクリーンショットがディスク容量をかなり食い、画像間で変わる部分がほとんどないのを見て、後続画像との差分だけを保存するアルゴリズムを思いついた。数分後、自分が動画圧縮を再発明していると気付いた
そこで ffmpeg で画像シーケンスを mp4 に変換したところ、ファイルサイズはおよそ 95% 減った。ImageMagick でタイムスタンプ付きファイル名を画像に焼き込んで、実質的に TimeSnapper Classic の機能をコマンド 2 つで再現していたようなものだ
一方には CPU 使用率があり、もう一方にはネットワークがある。ネットワークは安いがエンコードは高くつく、というのが自分の感覚だ。証拠はなくローカル実験だけだが、測定を始めるのは本当に良い考えだと思う
画面を走査して変化した部分だけを送る別案もある。画面の半分だけ送るだけでも、ネットワーク面では動画エンコードに勝てるかもしれない。ただし diff アルゴリズムは非常に高速である必要がある。1280x720 なら 914400 ピクセルで、1 ピクセル 4 バイトなら 1 秒あたり 3.49MB の情報を処理することになる
動画エンコード効率と JPEG 60 枚生成のコストも気になる。両者は近いのだろうか？
望むなら両方とも簡単にできるだろうが、その手間に見合うかはわからない。同じ IP から規模が大きくなると、この方式が厳しくなるだろうという点には同意する
いいね
私たちのワークフローは、オフィスや技術インフラの必要性をなくす方向で組まれている。タイムラインの出力物、つまり動画編集結果をリアルタイムでストリーミングし、オープンなコミュニケーションチャネルを用意している。チームメンバーの大半はかなり内向的なので push-to-talk 方式で、全体での議論が必要ない限り、たいていはチャットにメモを残すだけだ
無骨な解決策のほうが、かえって採用されることが多い
オーディオなしの画面共有の ユースケース は何だろう？ いつ役立つのかよく分からない。とはいえ、結局は相手と何らかの形でやり取りしないといけないのでは？
長い会議の最中でも、画面共有を続けておく必要があることがある。1〜2時間の会議に座って聞いているより、コーディングしていたいこともある
それに、私のようにオーディオが好きではない人にも向いている。助けたい学生はたくさんいるが、オーディオまで含めたくはない。私の音声チャットは並列化しやすいリソースではない
音声通話中の画面共有 というより、スクリーンショットを送りながらテキストチャット するのに近く見える。これを好む人がいる理由は分かる
「Google Meet は1時間制限、Zoom は40分制限なので画面共有にうんざりした」という点については、jitsi[0] は WebRTC ベースのオープンソース[1]ビデオ会議代替だ。Zoom、Google Meet、Slack のようなものの代替として、かなり機能がそろっている
メインサイトで使ってもいいし、望むなら自分でホスティングすることもできる
[0]: https://meet.jit.si/
[1]: https://github.com/jitsi
[1] https://github.com/strukturag/nextcloud-spreed-signaling
どのフレームを使うか選ぶ ヒューリスティック を作ってみると面白いかもしれない。常に最新フレームを無条件に選ぶのが理想とは限らず、動きが少ない、進行中のアニメーションがない、あるいは似た指標を持つフレームを選んだほうがよいかもしれない
さらに凝るなら、ウィンドウ単位で分析してから全体フレームの集計のような形を組み立てることもできる
すばらしいアイデアだし、チェスでは似た発想を 静止探索（quiescence search）[1] と呼ぶと聞いたことがあるが、おそらく労力に見合う価値はないだろう
[0] https://old.reddit.com/r/Android/comments/11nzrb0/samsung_sp...
[1] https://en.wikipedia.org/wiki/Quiescence_search
それでも、すばらしいアイデアであり興味深い問題に聞こえる
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 のテキスト説明のように別の場所でやるという理解で合っている？
私の用途では Moonlight Game Streaming がほぼ VNC を置き換えた。ファイル転送やクリップボード共有のような機能がもう少し良くなれば十分だ
カーソル追跡に問題がある。モニターが複数あるせいかは分からない
ここにある画像では、リングが実際のカーソル位置だ https://i.imgur.com/TvzskjS.png