Show HN: İçe dönükler için 1-FPS şifreli ekran paylaşımı

 (1fps.video)
1 puan yazan GN⁺ 2024-08-08 | 1 yorum | WhatsApp'ta paylaş
  • 1fps.video, tek bir ikili dosyayla hemen başlatılabilen bağlantı tabanlı bir ekran paylaşım aracı; geliştiriciler, IT ekipleri ve güvenlik uzmanları gibi toplantıdan çok ekranı görmeye ihtiyaç duyan iş birlikleri için tasarlanmış
  • Kodlama iş birliğinde düşük FPS’nin çoğu zaman yeterli olduğu varsayımıyla CPU, bellek ve ağ kullanımını azaltır ve eski dizüstü bilgisayarların yükünü hafifletir
  • Ekran 1 FPS ile paylaşılır; ancak WebSocket tabanlı imleç takibi sayesinde işaretçi hareketleri neredeyse 30 FPS’ye yakın gösterilerek hassas demolar desteklenir
  • Uçtan uca şifreleme sunar; istemcide oluşturulan anahtar URL’deki # işaretinden sonra yer alır ve arka uca gönderilmez
  • Çoklu monitör, görüntü kalitesi ve yakalama boyutu ayarı ile değişmeyen ekranların gönderimini atlama özellikleri sayesinde uzun oturumlara ve düşük trafikli paylaşıma odaklanır

1 FPS ekran paylaşımı yaklaşımı

  • 1fps.video, ekran paylaşımını hızlıca başlatmaya yarayan bir araçtır; ikili dosya Download sayfasından indirilebilir
  • Başlıca hedef kitlesi geliştiriciler, IT ekipleri, güvenlik uzmanları ve toplantısız iş birliğini tercih eden kullanıcılardır
  • Düşük FPS’li ekran paylaşımının çoğu iş birliği işi için, özellikle de zamanının büyük kısmını kod yazarak geçiren geliştiriciler için çoğu durumda yeterli olduğu varsayılır
  • Bu yaklaşım kaynakları ve trafiği azaltmaya odaklanır
    • Ses gerekmediği için toplantısız kültürü teşvik eder
    • CPU, bellek ve ağ kullanımını belirgin biçimde azaltır
    • Eski dizüstü bilgisayarlar da ekran paylaşımı sırasında daha iyi çalışabilir
    • Düşük kaynak kullanımı sayesinde çevre açısından daha dosttur
  • Paylaşım ortamı ağ koşullarına göre ayarlanabilir
    • Çoklu monitör paylaşımını destekler
    • Trafik kullanımını optimize etmek için görüntü kalitesi ayarlanabilir
    • Büyük ekranlarda ekran yakalama boyutu ayarlanarak trafik daha da azaltılabilir
    • Ekran değişmediğinde gereksiz veri aktarımını önleyen akıllı ekran karşılaştırması kullanır

Güvenlik, gizlilik ve paylaşım modeli

  • Çoğu kodlama ve geliştirme işi için 1 FPS’nin yeterli olduğu düşünülür; imleç hareketleri ise WebSocket tabanlı takip ile neredeyse 30 FPS’ye yakın sağlanır
  • Sesli veya görüntülü arama olmadan yalnızca ekran paylaşmak isteyen içe dönük kullanıcılar ve uzaktan çalışanlar için uygundur
  • Mevcut ekip sohbet uygulamalarıyla birlikte kullanılabilir; çoklu monitör, görüntü kalitesi ve ekran boyutu ayarlama seçenekleriyle paylaşım deneyimi ağ koşullarına uyarlanabilir
  • Gizlilik ve güvenlik yapısı bağlantılara ve istemci taraflı anahtar yönetimine dayanır
    • Tüm veriler uçtan uca şifrelenir
    • Şifreleme anahtarı istemci tarafında oluşturulur ve sunucuya gönderilmez
    • Anahtar, URL’deki # işaretinden sonra yer alır ve arka uca iletilmez
    • Yalnızca tam bağlantıya sahip kişiler paylaşılan ekrana erişebilir
    • Ekran karşılaştırmasıyla veri aktarımı en aza indirilerek gizlilik güçlendirilir
  • Şu anda imleç koordinatlarını şifreleme çalışması devam etmektedir
  • Kaynak kod Source Code üzerinden sunulmaktadır

İlgili okumalar

1 yorum

 
GN⁺ 2024-08-08
Hacker News yorumları

  • Projeyi yayımlamanız iyi olmuş. Fikir harika ve şaşırtıcı derecede minimal; ancak kaynakta birkaç kriptografik kusur görüyorum, bu yüzden şifrelemenin kritik olduğu durumlarda kullanılmamalı

    1. Rastgele bir anahtar üretip [0] PBKDF2’ye vererek [1] 32 baytlık bir AES-GCM anahtarı üretiyorsunuz; oysa 10 adet sınırlı ASCII karakteri ve key stretching kullanabiliyorsanız, doğrudan 32 baytlık rastgele sayı üretmek yeterli. PBKDF2 parolaları anahtara dönüştürmek içindir ve günümüzde önerilen algoritmalardan oldukça uzaktır; böyle bir iş gerekiyorsa scrypt daha iyi olur
    2. AES-GCM’de 12 baytlık rastgele nonce kullanıyorsunuz. GCM’de rastgele IV kullanılmamalı; kimlik doğrulama bozulabilir [2] [3]. Rastgele nonce ile ilgili AES-GCM tuzaklarından kaçınmak için XSalsa20+Poly1305’e geçmek daha iyi olabilir. XSalsa’nın nonce uzunluğu genişletildiği için rastgele nonce’u güvenle kullanabilme avantajı var
    3. Sınırlı bir karakter kümesinden rastgele anahtar türetmek brute-force saldırılarını kolaylaştırabilir. 256 bitlik rastgele bir anahtarınız olmalı; bu anahtarı belirli bir karakter kümesinin içine koymak istiyorsanız, kriptografik rastgele sayı üretecinin bayt çıktısını o karakter kümesine kodlamalısınız
    4. 1fps simetrik anahtarı URL’nin fragment identifier’ı ("#") üzerinden dağıtıyor; hatırladığım kadarıyla bu kısım sunucuya gönderilmez. Dolayısıyla güvenli bir anahtar dağıtım kanalı varsayılıyor. Anahtar linkin içinde olduğundan, "#" sonrasını yalnızca hedeflenen alıcı görebilmelidir. Sunucu gerçekten kötü niyetliyse, fragment’ı sunucuya gönderecek istemci JavaScript’i dağıtabilir; bu durumda sunucu anahtara ve düz metin iletişime erişebilir
      [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/
    • Buraya tam da böyle tavsiyeler almak için geldim, o yüzden güzel oldu. Bu değişiklikleri mümkün olan en kısa sürede uygulayacağım
    • Makaleler bana biraz zor geldi. Burada rastgele IV kullanmanın tam olarak ne sorunu olduğunu açıklayabilir misiniz? chacha’ya geçemeyip yalnızca GCM kullanabildiğimizi varsayarsak, bunun yerine ne yapmak gerekir?
    • Böyle şeyler tasarlarken çok fazla tuzak varmış gibi geliyor. Üzerine uygulama inşa edilebilecek standart ve güvenilir bir temel var mı? TLS’in mümkün olup olmadığını da merak ediyorum
    • XSalsa20+Poly1305’i önerdiğin için teşekkürler. Kriptografiye hep ilgim vardı; kendi şifrelerimi ve protokollerimi yapmamam gerektiğinin çeşitli nedenlerini öğrenmek ilginç
      Bu durumda nonce sorununu düzelt dememenin başlıca nedeni uygulama sürecindeki tuzaklar mı, yoksa yukarıdaki yazılarda anlatılan genel sorunlarla daha incelikli bir bağlantısı mı var, merak ediyorum
      Naif bakınca AES-GCM TLS veya SRTP gibi pek çok yerde kullanılıyor; kriptografiyi iyi bilmeyen biri bunun iyi bir tercih olduğunu düşünebilir
      1. sorunu çözmek için önerilen bir yöntem var mı? Web uygulamaları için doğası gereği var olan bir sorun gibi görünüyor; ProtonMail de benzer görünüyor

  • Koda bakınca her saniye ekran görüntüsü (.jpg) alıp gönderiyor gibi görünüyor. Bu yöntemin önceki kare bilgisini yeniden kullanan modern video sıkıştırmaya göre gerçekten bant genişliği tasarrufu sağlayıp sağlamadığını merak ediyorum
    VS Code’da kod düzenlediğim 1 dakikalık bir videoyu 1440p 10fps, AV1 kodlama ile kaydettim; aynı ekranın 60 JPEG ekran görüntüsünün yaklaşık yarısı kadar boyuttaydı. Test edilmiş sayılar varsa merak ederim

    • 10 yıl önce Windows için ücretsiz bir yardımcı program olan TimeSnapper Classic’i denemiştim; her 5 saniyede bir ekran görüntüsü alıp günü timelapse olarak izletebilmesi hoşuma gitmişti
      Ekran görüntüleri diskte çok yer kaplıyordu ve görüntüler arasında değişen kısmın neredeyse hiç olmadığını görünce yalnızca sonraki görüntüyle farkı kaydeden bir algoritma düşündüm. Birkaç dakika sonra video sıkıştırmayı yeniden icat ettiğimi fark ettim
      Bu yüzden ffmpeg ile görüntü dizisini mp4’e çevirdim ve dosya boyutu yaklaşık %95 küçüldü. ImageMagick ile zaman damgalı dosya adlarını görüntünün içine yerleştirerek, aslında TimeSnapper Classic’in işlevini 2 komutla yeniden üretmiş gibi oldum
    • Bu yalnızca bant genişliği meselesi değil, aynı zamanda CPU kullanımı meselesi. Ekran görüntülerini ffmpeg’e veya başka araçlara vermeyi denedim; çalıştı ama o kadar çok kaynak tüketti ki pratikte kullanmak zordu. En azından benim bilgisayarım olan 2019 model 13 inç MacBook’ta böyleydi
      Bir tarafta CPU kullanımı, diğer tarafta ağ var. Bana göre ağ ucuz, kodlama pahalı. Kanıtım yok, yalnızca yerel deneylerim var; ama ölçmeye başlamak gerçekten iyi bir fikir
      Ekranı tarayıp yalnızca değişen kısımları gönderme fikri de var. Ekranın yalnızca yarısını göndermek bile ağ açısından video kodlamayı yenebilir gibi geliyor. Ancak diff algoritması çok hızlı olmalı. 1280x720 ise 914400 piksel eder; her biri 4 baytsa saniyede 3,49 MB bilgi işlemek gerekir
      Video kodlama verimliliğiyle 60 JPEG üretmenin maliyetini de merak ediyorum. İkisi benzer mi?
    • Benim de ilk aklıma gelen buydu. Standart bir codec kullanıp 1fps’e ayarlamamak için bir neden yok gibi görünüyor
    • Bant genişliğini en aza indirmekten çok veri kalıcılığını önlemeyi, yani değiştirme ve silmeyi seçmiş gibi görünüyor
      İstenirse ikisi de kolayca yapılabilir; ama zahmetine değip değmeyeceğinden emin değilim. Aynı IP’den ölçek büyürse bu yöntemin zorlanabileceğine katılıyorum

  • Hoşuma gitti
    İş akışımız, ofis ve teknik altyapı ihtiyacını ortadan kaldıracak şekilde tasarlanmış. Zaman çizelgesi çıktısını, yani video kurgu sonucunu gerçek zamanlı olarak stream ediyoruz ve açık iletişim kanallarımız var. Ekip üyelerinin çoğu oldukça içe dönük olduğu için push-to-talk kullanıyoruz; genel bir tartışma gerekmiyorsa çoğunlukla sohbete not bırakıyoruz
    Kaba çözümler çoğu zaman daha kolay benimseniyor

    • Bunu duymak sevindirici. Sunucu tarafını az önce açık kaynak yaptım, böylece biraz daha kurcalanabilir. Belgeleri zamanla iyileştirip takip etmesi kolay hale getireceğim

  • Ses olmadan ekran paylaşımının kullanım senaryosu nedir? Ne zaman işe yarayacağını pek anlayamadım. Sonuçta karşı tarafla bir şekilde iletişim kurmak gerekmiyor mu?

    • Çok var. Örneğin ev bilgisayarını açık bırakıp işe giderken bağlantıyı kaydedebilir ve evde neler olduğunu görebilirsin. Uzak masaüstü de aynı şekilde
      Uzun toplantılar sırasında da ekran paylaşımının sürekli gerekli olduğu durumlar oluyor. 1-2 saatlik bir toplantıyı oturup dinlemektense kod yazmak istediğim zamanlar oluyor
      Ayrıca benim gibi sesten hoşlanmayan kişilere de uyuyor. Yardım etmek istediğim çok öğrenci var ama işin içine sesi de katmak istemiyorum. Sesli sohbetim iyi paralelleştirilebilen bir kaynak değil
    • Yazıya göre 1fps.video, sesli veya görüntülü aramanın yükü olmadan ekran paylaşmak isteyen içe dönük kişiler ve uzaktan çalışanlar için uygun; ayrıca zaten kullanılan ekip sohbet uygulamalarıyla birlikte çalışan çok amaçlı bir çözüm
      “Sesli görüşme sırasında ekran paylaşımı”ndan çok, ekran görüntüleri göndererek metin sohbeti yapmaya benziyor. Bazı insanların bunu neden tercih edeceğini anlayabiliyorum
    • Dolandırıcılar, hedefleriyle telefonda konuşurken ses olmadan ekran paylaşımını da kullanabiliyor
    • Sadece telefonla aramak yetmez mi? Herkesin her zaman yanında telefonu var; bu tekerleği yeniden icat etmeye gerek yok

  • “Google Meet 1 saatle, Zoom 40 dakikayla sınırlı olduğu için ekran paylaşımından yoruldum” kısmı için, jitsi[0] WebRTC tabanlı açık kaynak[1] bir video konferans alternatifi. Zoom, Google Meet, Slack gibi şeylerin yerine geçebilecek kadar özellikleri epey tamamlanmış durumda
    Ana siteden kullanabilirsiniz; isterseniz kendiniz de barındırabilirsiniz
    [0]: https://meet.jit.si/
    [1]: https://github.com/jitsi

  • Hangi karenin kullanılacağını seçmek için bir heuristic oluşturmak ilginç olabilir. Her zaman körlemesine en son kareyi seçmek muhtemelen ideal değildir; hareketin az olduğu, devam eden animasyonun olmadığı ya da benzer göstergelere sahip kareleri seçmek daha iyi olabilir
    Daha gösterişli yapmak isterseniz pencere bazında analiz edip ardından tüm kare için bir toplama biçimi oluşturabilirsiniz

    • Pencere bazında analiz edip tüm kare için bir özet oluşturmak, akıllı telefon “kameralarının” ışık sensörü çıktısına o kadar çok hesaplama uygulayıp artık neredeyse fotoğraf denemeyecek bir alana girmesine benzeyebilir [0]
      Güzel bir fikir; satrançta benzer bir fikre quiescence search (durgunluk araması)[1] dendiğini duydum ama muhtemelen uğraşmaya değmez
      [0] https://old.reddit.com/r/Android/comments/11nzrb0/samsung_sp...
      [1] https://en.wikipedia.org/wiki/Quiescence_search
    • Bu, en az hesaplama kaynağı kullanımı hedefiyle çelişebilir
      Yine de harika bir fikir ve ilginç bir problem gibi duruyor
    • Aslında bu fikri sevdim. Daha önce, olası ekran değişimlerini tespit etmek için değişimin daha önce saptandığı noktaların çevresini 5-10 piksel aralıklı seyrek bir 100x100 matrisle tarama fikrini düşünmüştüm

  • github.com/go-vgo/robotgo içinde X11/extensions/XTest.h bulunamadığına dair derleme hatası alıyorum
    https://github.com/go-vgo/robotgo?tab=readme-ov-file#require...
    Sayfada yazmayan bir ön koşul var. Mint 22’de libxtst-dev paketini kurmam gerekti

    • Belgeleri güncelleyeceğim. robotgo Windows’ta birkaç sorun çıkarıyor; şu anda bir kısmına bakıyorum

  • Bugün tam böyle bir şey arıyordum. Fiziksel test olayını uzaktan izliyorum; kaydı açık bir Google Meet bırakmak berbat, ama arayüz için yine de metin sohbetine ihtiyacım vardı
    Çok iyi bir minimal arayüz gibi görünüyor. Canım isterse sohbet kalıcılığını bir şekilde eklemeyi de deneyebilirim
    Ek olarak senkronize metin ya da sesin telefon görüşmesi veya Slack’te metinle açıklama gibi başka bir yerde yapılacağını varsayabilir miyiz?

    • Bazen bir arkadaşımla bunu böyle yapıyorum. WhatsApp telefon görüşmesini, dizüstü bilgisayarım ile arkadaşımın PC’si arasında basit ekran paylaşımıyla birlikte kullanıyorum
    • Bugün böyle bir şey aradığını söylemişsin; bugün daha erken saatlerde tam olarak 1fps gerektiğini mi düşünmüştün?

  • Benim kullanımımda Moonlight Game Streaming neredeyse VNC’nin yerini aldı. Sadece dosya aktarımı ve pano paylaşımı gibi özelliklerin biraz daha iyi olması gerekiyor

    • Dürüst olmak gerekirse sadece pano yeterli; NAT aşımı sağlayan bir servis de olsa güzel olurdu

  • İmleç takibinde bir sorun var. Birden fazla monitörüm olduğu için mi bilmiyorum
    Bu görselde halka gerçek imleç konumu: https://i.imgur.com/TvzskjS.png

    • Başlıca kullanım senaryolarının her biri için düzeltme yapacağıma söz veriyorum. Daha sonra tekrar kontrol edip düzelip düzelmediğine bakabilirsiniz. Geri bildirim için teşekkürler