Show HN: Berbagi layar terenkripsi 1-FPS untuk orang-orang introvert

 (1fps.video)
1 poin oleh GN⁺ 2024-08-08 | 1 komentar | Bagikan ke WhatsApp
  • 1fps.video adalah alat berbagi layar berbasis tautan yang dapat langsung dijalankan dari satu binary, cocok untuk kolaborasi yang lebih membutuhkan melihat layar daripada rapat, seperti bagi developer, tim IT, dan profesional keamanan
  • Berangkat dari asumsi bahwa FPS rendah sering kali sudah cukup untuk kolaborasi coding, alat ini mengurangi penggunaan CPU, memori, dan jaringan serta meringankan beban laptop lama
  • Layar dibagikan pada 1 FPS, tetapi pelacakan kursor berbasis WebSocket membuat gerakan pointer terlihat mendekati 30 FPS untuk melengkapi demo yang presisi
  • Menyediakan enkripsi end-to-end, dan kunci yang dibuat di klien ditempatkan setelah # pada URL sehingga tidak dikirim ke backend
  • Berfokus pada sesi panjang dan berbagi bertrafik rendah melalui dukungan multi-monitor, pengaturan kualitas gambar dan ukuran tangkapan, serta melewati pengiriman layar yang tidak berubah

Cara kerja berbagi layar 1 FPS

  • 1fps.video adalah alat untuk memulai berbagi layar dengan cepat, dan binary-nya dapat diunduh dari Download
  • Target utamanya adalah developer, tim IT, profesional keamanan, dan pengguna yang lebih menyukai kolaborasi tanpa rapat
  • Berbagi layar dengan FPS rendah sering kali dianggap cukup untuk sebagian besar pekerjaan kolaboratif, terutama bagi developer yang menghabiskan banyak waktu menulis kode
  • Pendekatan ini berfokus pada pengurangan resource dan trafik
    • Tidak memerlukan audio sehingga mendorong budaya tanpa rapat
    • Sangat mengurangi penggunaan CPU, memori, dan jaringan
    • Laptop lama pun bisa bekerja lebih baik saat sedang berbagi layar
    • Penggunaan resource yang rendah membuatnya lebih ramah lingkungan
  • Lingkungan berbagi dapat disesuaikan dengan kondisi jaringan
    • Mendukung berbagi multi-monitor
    • Kualitas gambar dapat diatur untuk mengoptimalkan penggunaan trafik
    • Pada layar besar, ukuran tangkapan layar dapat disesuaikan untuk lebih mengurangi trafik
    • Menggunakan perbandingan layar cerdas untuk menghindari pengiriman data yang tidak perlu saat layar tidak berubah

Keamanan, privasi, dan model berbagi

  • Untuk sebagian besar pekerjaan coding dan development, 1 FPS dianggap cukup, sementara gerakan kursor disediakan mendekati 30 FPS melalui pelacakan berbasis WebSocket
  • Cocok untuk pengguna introvert dan pekerja jarak jauh yang hanya ingin berbagi layar tanpa panggilan audio atau video
  • Dapat digunakan bersama aplikasi chat tim yang sudah ada, dengan opsi multi-monitor, kualitas gambar, dan penyesuaian ukuran layar agar pengalaman berbagi sesuai dengan kondisi jaringan
  • Struktur privasi dan keamanannya didasarkan pada tautan serta pengelolaan kunci di sisi klien
    • Semua data dienkripsi dengan end-to-end
    • Kunci enkripsi dibuat di sisi klien dan tidak dikirim ke server
    • Kunci disertakan setelah # pada URL sehingga tidak diteruskan ke backend
    • Hanya orang yang memiliki tautan lengkap yang dapat mengakses layar yang dibagikan
    • Perbandingan layar meminimalkan transmisi data untuk memperkuat privasi
  • Saat ini sedang dikerjakan enkripsi koordinat kursor
  • Kode sumber tersedia di Source Code

Bacaan terkait

1 komentar

 
GN⁺ 2024-08-08
Komentar di Hacker News

  • Bagus sudah merilis proyek ini. Idenya keren dan sangat minimalis, tetapi di sumbernya terlihat beberapa cacat kriptografis, jadi sebaiknya jangan dipakai untuk situasi ketika enkripsi adalah inti utamanya

    1. Setelah membuat kunci acak, kunci itu dimasukkan ke [0] PBKDF2 untuk membuat [1] kunci AES-GCM 32 byte. Kalau bisa memakai 10 karakter ASCII terbatas dan key stretching, lebih baik langsung buat angka acak 32 byte saja. PBKDF2 digunakan untuk mengubah kata sandi menjadi kunci, dan sudah jauh dari algoritma yang direkomendasikan saat ini; jika pekerjaan seperti ini memang diperlukan, scrypt lebih baik
    2. Menggunakan nonce acak 12 byte untuk AES-GCM. Dalam GCM, IV acak tidak boleh digunakan, karena autentikasi bisa rusak [2] [3]. Untuk menghindari jebakan AES-GCM terkait nonce acak, mungkin lebih baik beralih ke XSalsa20+Poly1305. XSalsa punya keunggulan panjang nonce yang diperluas, sehingga nonce acak bisa digunakan dengan aman
    3. Menurunkan kunci acak dari set karakter terbatas bisa mempermudah serangan brute force. Seharusnya gunakan kunci acak 256-bit, dan jika ingin memasukkan kunci itu ke dalam set karakter tertentu, output byte dari generator angka acak kriptografis harus dienkode ke set karakter tersebut
    4. 1fps mendistribusikan kunci simetris melalui fragment identifier ("#") pada URL, dan seingat saya bagian ini tidak dikirim ke server. Jadi ini mengasumsikan adanya kanal distribusi kunci yang aman. Karena kuncinya ada di tautan, hanya penerima yang dituju yang boleh melihat bagian setelah "#". Jika server benar-benar jahat, ia bisa mendistribusikan JavaScript klien yang membuat fragment dikirim ke server, dan dengan begitu server bisa mengakses kunci serta komunikasi plaintext
      [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/
    • Justru bagus, karena saya datang ke sini untuk mendapatkan saran seperti ini. Saya akan menerapkan perubahan-perubahan ini secepat mungkin
    • Makalah-makalahnya terasa agak sulit. Bisa jelaskan apa tepatnya masalah penggunaan IV acak di sini? Kalau tidak bisa beralih ke chacha dan hanya bisa memakai GCM, apa yang sebaiknya dilakukan sebagai gantinya?
    • Rasanya ada terlalu banyak jebakan saat merancang hal seperti ini. Apakah ada fondasi standar dan tepercaya yang bisa dipakai untuk membangun aplikasi di atasnya? Saya juga penasaran apakah TLS mungkin bisa digunakan
    • Terima kasih sudah merekomendasikan XSalsa20+Poly1305. Saya selalu tertarik pada kriptografi, jadi menarik mempelajari berbagai alasan mengapa kita tidak boleh membuat cipher dan protokol sendiri
      Dalam kasus ini, saya penasaran apakah alasan utama Anda tidak menyarankan sekadar memperbaiki masalah nonce adalah karena jebakan dalam implementasinya, atau karena ini terkait lebih halus dengan masalah umum yang dibahas di tulisan-tulisan di atas
      Secara naif, AES-GCM dipakai di banyak tempat seperti TLS atau SRTP, jadi orang yang tidak terlalu paham kriptografi bisa mengira ini pilihan yang bagus
    • Ada rekomendasi cara untuk menyelesaikan masalah nomor 4? Ini terlihat seperti masalah inheren pada aplikasi web, dan ProtonMail juga tampak mirip

  • Dari kodenya, tampaknya ini bekerja dengan mengambil dan mengirim screenshot (.jpg) setiap detik. Saya penasaran apakah cara ini benar-benar menghemat bandwidth dibanding kompresi video modern yang memakai ulang informasi dari frame sebelumnya
    Saya merekam video 1 menit saat mengedit kode di VS Code pada 1440p 10fps dengan encoding AV1, dan ukurannya sekitar setengah dari 60 screenshot JPEG untuk layar yang sama. Kalau ada angka hasil pengujian, saya ingin tahu

    • Saya pernah bereksperimen dengan TimeSnapper Classic, utilitas gratis untuk Windows dari 10 tahun lalu, dan saya suka fiturnya yang mengambil screenshot setiap 5 detik lalu memungkinkan melihat satu hari sebagai timelapse
      Screenshot itu memakan banyak ruang disk, dan setelah melihat bahwa hampir tidak ada yang berubah di antara gambar, saya terpikir algoritma yang hanya menyimpan perbedaan dengan gambar berikutnya. Beberapa menit kemudian saya sadar bahwa saya sedang menciptakan ulang kompresi video
      Jadi saya mengubah urutan gambar menjadi mp4 dengan ffmpeg, dan ukuran filenya berkurang kira-kira 95%. Dengan ImageMagick saya menanamkan nama file timestamp ke dalam gambar, jadi pada dasarnya saya mereplikasi fungsi TimeSnapper Classic dengan 2 perintah
    • Ini bukan hanya soal bandwidth, tetapi juga soal penggunaan CPU. Saya pernah memasukkan screenshot ke ffmpeg atau alat lain; memang berjalan, tetapi memakan sumber daya terlalu banyak sehingga praktis sulit dipakai. Setidaknya begitu di komputer saya, MacBook 13 inci keluaran 2019
      Di satu sisi ada penggunaan CPU, di sisi lain ada jaringan. Menurut saya jaringan itu murah, tetapi encoding itu mahal. Saya tidak punya bukti selain eksperimen lokal, tetapi mulai melakukan pengukuran benar-benar ide bagus
      Ada juga ide lain: memindai layar dan hanya mengirim bagian yang berubah. Bahkan jika hanya mengirim setengah layar, dari sisi jaringan rasanya bisa mengalahkan encoding video. Namun algoritma diff-nya harus sangat cepat. Untuk 1280x720 ada 914400 piksel, dan jika masing-masing 4 byte, berarti harus memproses 3,49 MB informasi per detik
      Saya juga penasaran pada efisiensi encoding video dan biaya membuat 60 JPEG. Apakah keduanya mirip?
    • Itu juga hal pertama yang terpikir oleh saya. Sepertinya tidak ada alasan untuk tidak memakai codec standar tetapi menyetelnya ke 1fps
    • Sepertinya tujuannya lebih ke mencegah persistensi data, yaitu memilih penggantian dan penghapusan, daripada meminimalkan bandwidth
      Kalau mau, keduanya mungkin bisa dilakukan dengan mudah, tetapi saya tidak yakin apakah kerepotannya sepadan. Saya setuju bahwa jika skalanya membesar dari IP yang sama, pendekatan ini bisa kewalahan

  • Suka
    Alur kerja kami memang dirancang untuk menghilangkan kebutuhan akan kantor dan infrastruktur teknis. Kami melakukan streaming real-time atas output timeline, yaitu hasil edit video, dan menyediakan kanal komunikasi terbuka. Sebagian besar anggota tim cukup introvert, jadi kami memakai cara push-to-talk, dan kalau tidak perlu diskusi bersama, biasanya cukup meninggalkan catatan di chat
    Solusi yang kasar justru sering kali diadopsi

    • Senang mendengarnya. Saya baru saja merilis sisi server sebagai open source, jadi bisa lebih banyak diutak-atik. Dokumentasinya akan saya perbaiki seiring waktu agar lebih mudah diikuti

  • Apa use case berbagi layar tanpa audio? Saya kurang paham kapan ini berguna. Bagaimanapun bukankah harus tetap berkomunikasi dengan lawan bicara dengan suatu cara?

    • Banyak. Misalnya, saat berangkat kerja dan meninggalkan komputer rumah, kamu bisa menyimpan link lalu melihat apa yang terjadi di rumah. Remote desktop juga sama
      Dalam rapat panjang, kadang screen sharing tetap perlu terus berjalan. Ada kalanya saya ingin coding daripada duduk mendengarkan rapat 1–2 jam
      Dan ini juga cocok untuk orang seperti saya yang tidak suka audio. Ada banyak mahasiswa yang ingin saya bantu, tapi saya tidak ingin ikut-ikutan memakai audio. Voice chat saya bukan resource yang mudah diparalelkan
    • Menurut tulisannya, 1fps.video adalah solusi serbaguna yang cocok untuk orang introvert dan pekerja remote yang ingin berbagi layar tanpa beban panggilan audio atau video, serta bekerja bersama aplikasi chat tim yang sudah dipakai
      Ini terlihat lebih dekat ke chat teks sambil mengirim screenshot daripada “berbagi layar saat panggilan suara”. Saya bisa mengerti kenapa ada orang yang menyukainya
    • Penipu juga kadang memakai berbagi layar tanpa audio sambil menelepon targetnya
    • Bukankah tinggal telepon saja? Semua orang selalu punya ponsel, jadi tidak perlu menemukan ulang roda itu

  • Terkait bagian “lelah berbagi layar karena Google Meet dibatasi 1 jam dan Zoom 40 menit”, jitsi[0] adalah alternatif konferensi video open source[1] berbasis WebRTC. Fiturnya cukup lengkap sebagai pengganti Zoom, Google Meet, Slack, dan semacamnya
    Bisa dipakai lewat situs utamanya, atau di-host sendiri kalau mau
    [0]: https://meet.jit.si/
    [1]: https://github.com/jitsi

  • Mungkin menarik untuk membuat heuristic untuk memilih frame mana yang dipakai. Selalu memilih frame terbaru secara membabi buta kemungkinan besar tidak ideal; mungkin lebih baik memilih frame dengan sedikit gerakan, tanpa animasi yang sedang berjalan, atau metrik serupa
    Kalau ingin lebih canggih, bisa juga dianalisis per jendela lalu disusun menjadi bentuk agregasi untuk keseluruhan frame

    • Menganalisis per jendela lalu membuat agregasi seluruh frame bisa mendekati wilayah ketika “kamera” smartphone menerapkan terlalu banyak komputasi pada keluaran sensor cahaya sampai hampir sulit disebut foto [0]
      Idenya keren, dan saya dengar dalam catur gagasan serupa disebut quiescence search[1], tapi mungkin tidak sepadan dengan usahanya
      [0] https://old.reddit.com/r/Android/comments/11nzrb0/samsung_sp...
      [1] https://en.wikipedia.org/wiki/Quiescence_search
    • Ini bisa bertentangan dengan tujuan penggunaan resource komputasi yang minimal
      Meski begitu, terdengar seperti ide bagus sekaligus masalah yang menarik
    • Sebenarnya saya suka ide ini. Dulu saya pernah terpikir untuk mendeteksi kemungkinan perubahan layar dengan memindai matriks 100x100 yang jarang, berjarak 5–10 piksel, di sekitar titik tempat perubahan sebelumnya ditemukan

  • Muncul error kompilasi di github.com/go-vgo/robotgo karena X11/extensions/XTest.h tidak ada
    https://github.com/go-vgo/robotgo?tab=readme-ov-file#require...
    Ada prasyarat yang tidak tertulis di halaman itu. Di Mint 22, saya harus memasang paket libxtst-dev

    • Saya akan memperbarui dokumentasinya. robotgo punya beberapa masalah di Windows, jadi saat ini saya sedang meninjau sebagian di antaranya

  • Hari ini saya memang sedang mencari sesuatu seperti ini. Saya sedang memantau jarak jauh event pengujian fisik, dan membiarkan Google Meet dengan perekaman menyala itu berantakan, tapi saya tetap butuh chat teks untuk antarmuka
    Kelihatannya seperti antarmuka minimalis yang sangat bagus. Kalau sedang bersemangat, mungkin bisa ditambahkan persistensi chat dengan suatu cara
    Selain itu, apakah teks atau suara yang tersinkron dianggap dilakukan di tempat lain, seperti panggilan telepon atau penjelasan teks lewat Slack?

    • Kadang saya melakukan ini dengan teman. Kami memakai panggilan telepon WhatsApp bersama screen sharing sederhana antara laptop saya dan PC teman
    • Kamu bilang hari ini mencari sesuatu seperti ini; apakah tadi pagi kamu memang berpikir butuh persis 1fps?

  • Untuk kebutuhan saya, Moonlight Game Streaming hampir menggantikan VNC. Tinggal perlu fitur seperti transfer file dan berbagi clipboard yang sedikit lebih baik

    • Jujur saja, saya hanya butuh clipboard, dan akan bagus kalau ada layanan yang menyediakan NAT traversal

  • Ada masalah pada pelacakan kursor. Entah apakah karena saya memakai beberapa monitor
    Di gambar ini, cincin menunjukkan posisi kursor sebenarnya https://i.imgur.com/TvzskjS.png

    • Saya berjanji akan memperbaikinya untuk tiap use case utama. Silakan cek lagi nanti untuk melihat apakah sudah diperbaiki. Terima kasih atas masukannya