Show HN: Chia sẻ màn hình mã hóa 1 FPS dành cho người hướng nội

 (1fps.video)
1 điểm bởi GN⁺ 2024-08-08 | 1 bình luận | Chia sẻ qua WhatsApp
  • 1fps.video là công cụ chia sẻ màn hình dựa trên liên kết, khởi chạy ngay bằng một binary duy nhất, phù hợp cho kiểu cộng tác cần xem màn hình hơn là họp, như lập trình viên, đội IT và chuyên gia bảo mật
  • Dựa trên giả định rằng FPS thấp thường là đủ cho cộng tác lập trình, công cụ này giảm mức sử dụng CPU, bộ nhớ và mạng, đồng thời giảm tải cho laptop cũ
  • Màn hình được chia sẻ ở 1 FPS, nhưng nhờ theo dõi con trỏ dựa trên WebSocket, chuyển động con trỏ được hiển thị gần như 30 FPS, bổ trợ cho các phần trình diễn cần độ chính xác
  • Cung cấp mã hóa đầu cuối, trong đó khóa được tạo ở phía client nằm sau dấu # trong URL và không được gửi đến backend
  • Tập trung vào các phiên dài và chia sẻ lưu lượng thấp thông qua hỗ trợ nhiều màn hình, điều chỉnh chất lượng ảnh/kích thước capture, và bỏ qua việc gửi màn hình khi không có thay đổi

Cách chia sẻ màn hình 1 FPS

  • 1fps.video là công cụ giúp bắt đầu chia sẻ màn hình nhanh chóng; có thể tải binary tại Download
  • Đối tượng chính là lập trình viên, đội IT, chuyên gia bảo mật và người dùng thích cộng tác không họp
  • Chia sẻ màn hình FPS thấp dựa trên giả định rằng nó thường đủ cho hầu hết công việc cộng tác, đặc biệt với lập trình viên dành nhiều thời gian để viết code
  • Cách này tập trung vào việc giảm tài nguyên và lưu lượng
    • Không cần âm thanh, thúc đẩy văn hóa không họp
    • Giảm đáng kể mức sử dụng CPU, bộ nhớ và mạng
    • Laptop cũ cũng có thể hoạt động tốt hơn trong khi chia sẻ màn hình
    • Thân thiện với môi trường hơn nhờ mức sử dụng tài nguyên thấp
  • Môi trường chia sẻ có thể được điều chỉnh theo điều kiện mạng
    • Hỗ trợ chia sẻ nhiều màn hình
    • Có thể điều chỉnh chất lượng ảnh để tối ưu hóa lưu lượng sử dụng
    • Trên màn hình lớn, có thể điều chỉnh kích thước capture màn hình để giảm thêm lưu lượng
    • Sử dụng so sánh màn hình thông minh để tránh truyền dữ liệu không cần thiết khi màn hình không thay đổi

Bảo mật, quyền riêng tư và mô hình chia sẻ

  • Công cụ này cho rằng 1 FPS là đủ cho hầu hết công việc coding và phát triển, còn chuyển động con trỏ được cung cấp gần như 30 FPS nhờ theo dõi dựa trên WebSocket
  • Phù hợp với người dùng hướng nội và người làm việc từ xa muốn chỉ chia sẻ màn hình mà không cần cuộc gọi âm thanh hay video
  • Có thể dùng cùng các ứng dụng chat nhóm hiện có, và các tùy chọn nhiều màn hình, chất lượng ảnh, kích thước màn hình giúp điều chỉnh trải nghiệm chia sẻ theo tình trạng mạng
  • Cấu trúc quyền riêng tư và bảo mật dựa trên liên kết và quản lý khóa phía client
    • Toàn bộ dữ liệu được mã hóa đầu cuối
    • Khóa mã hóa được tạo ở phía client và không được gửi lên server
    • Khóa được đưa vào sau dấu # trong URL nên không được chuyển đến backend
    • Chỉ những người có liên kết đầy đủ mới có thể truy cập màn hình được chia sẻ
    • Tối thiểu hóa truyền dữ liệu bằng so sánh màn hình để tăng cường quyền riêng tư
  • Hiện đang thực hiện mã hóa tọa độ con trỏ
  • Mã nguồn được cung cấp tại Source Code

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-08-08
Ý kiến trên Hacker News

  • Làm tốt khi công bố dự án. Ý tưởng rất hay và tối giản đến đáng ngạc nhiên, nhưng nhìn vào mã nguồn thì thấy một số lỗi về mật mã học, nên không nên dùng trong các tình huống mà mã hóa là phần cốt lõi

    1. Sau khi tạo khóa ngẫu nhiên, bạn đưa nó vào [0] PBKDF2 để tạo khóa AES-GCM 32 byte [1], nhưng nếu đã có thể dùng 10 ký tự ASCII giới hạn và key stretching thì chỉ cần tạo luôn 32 byte ngẫu nhiên là được. PBKDF2 dùng để biến mật khẩu thành khóa, và hiện nay đã khá xa các thuật toán được khuyến nghị; nếu cần làm việc kiểu này thì scrypt tốt hơn
    2. Đang dùng nonce ngẫu nhiên 12 byte cho AES-GCM. Với GCM không nên dùng IV ngẫu nhiên, vì xác thực có thể bị phá vỡ [2] [3]. Để tránh các cạm bẫy của AES-GCM liên quan đến nonce ngẫu nhiên, có thể nên chuyển sang XSalsa20+Poly1305. XSalsa có ưu điểm là độ dài nonce được mở rộng, nên có thể yên tâm dùng nonce ngẫu nhiên
    3. Dẫn xuất khóa ngẫu nhiên từ một tập ký tự giới hạn có thể khiến tấn công vét cạn dễ hơn. Bạn nên có khóa ngẫu nhiên 256 bit, và nếu muốn đưa khóa đó vào một tập ký tự cụ thể thì cần mã hóa đầu ra byte của bộ sinh số ngẫu nhiên mật mã học sang tập ký tự đó
    4. 1fps phân phối khóa đối xứng qua fragment identifier ("#") của URL; theo tôi nhớ thì phần này không được gửi lên máy chủ. Vì vậy nó giả định một kênh phân phối khóa an toàn. Vì khóa nằm trong liên kết, chỉ người nhận dự định mới được thấy phần sau "#". Nếu máy chủ thật sự độc hại, nó có thể phát JavaScript phía client để gửi fragment về máy chủ; khi đó máy chủ sẽ truy cập được khóa và nội dung trao đổi dạng rõ
      [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/
    • Tôi đến đây chính là để nhận những lời khuyên như thế này, nên rất tốt. Tôi sẽ đưa các thay đổi này vào sớm nhất có thể
    • Các bài báo hơi khó hiểu với tôi. Bạn có thể giải thích chính xác vấn đề của việc dùng IV ngẫu nhiên ở đây là gì không? Nếu không thể chuyển sang chacha và chỉ dùng được GCM thì nên làm thế nào thay vào đó?
    • Cảm giác có quá nhiều cạm bẫy khi thiết kế những thứ như thế này. Có nền tảng tiêu chuẩn, đáng tin cậy nào để xây ứng dụng lên trên không? Tôi cũng tò mò liệu TLS có dùng được không
    • Cảm ơn vì đã gợi ý XSalsa20+Poly1305. Tôi luôn quan tâm đến mật mã học, nên việc học được nhiều lý do vì sao không nên tự tạo mật mã và giao thức của riêng mình rất thú vị
      Trong trường hợp này, tôi tò mò lý do chính để không chỉ bảo sửa vấn đề nonce là do các cạm bẫy khi triển khai, hay nó còn liên quan tinh tế hơn đến những vấn đề chung được nêu trong các bài viết trên
      Nhìn một cách ngây thơ thì AES-GCM được dùng ở nhiều nơi như TLS hay SRTP, nên người không rành mật mã học có thể nghĩ đây là lựa chọn tốt
    • Có cách khuyến nghị nào để giải quyết vấn đề số 4 không? Với ứng dụng web thì trông như một vấn đề mang tính bản chất, và ProtonMail cũng có vẻ tương tự

  • Nhìn mã thì có vẻ nó chụp ảnh màn hình (.jpg) mỗi giây rồi gửi đi. Tôi tò mò liệu cách này có thực sự tiết kiệm băng thông hơn nén video hiện đại vốn tái sử dụng thông tin từ khung hình trước không
    Tôi đã ghi một video 1 phút cảnh chỉnh sửa mã trong VS Code ở 1440p 10fps, mã hóa AV1, và nó có kích thước chỉ khoảng một nửa so với 60 ảnh chụp màn hình JPEG của cùng màn hình đó. Nếu có số liệu thử nghiệm thì tôi rất muốn xem

    • Tôi từng thử TimeSnapper Classic, một tiện ích miễn phí cho Windows từ 10 năm trước; tôi thích tính năng chụp ảnh màn hình mỗi 5 giây và cho xem cả ngày dưới dạng timelapse
      Ảnh chụp màn hình chiếm khá nhiều dung lượng đĩa, và khi thấy giữa các ảnh gần như không có gì thay đổi, tôi nghĩ ra một thuật toán chỉ lưu phần khác biệt so với ảnh sau. Vài phút sau tôi nhận ra mình đang phát minh lại nén video
      Vì vậy tôi dùng ffmpeg để đổi chuỗi ảnh thành mp4, và kích thước tệp giảm khoảng 95%. Tôi dùng ImageMagick để nhúng tên tệp timestamp vào ảnh, nên về cơ bản có lẽ đã tái tạo chức năng của TimeSnapper Classic chỉ bằng 2 lệnh
    • Không chỉ là vấn đề băng thông mà còn là vấn đề mức sử dụng CPU. Tôi đã thử đưa ảnh chụp màn hình vào ffmpeg hoặc công cụ khác; dù chạy được nhưng ngốn tài nguyên quá nhiều, gần như khó dùng thực tế. Ít nhất là trên máy của tôi, MacBook 13 inch đời 2019
      Một bên là mức dùng CPU, bên kia là mạng. Theo tôi, mạng thì rẻ còn mã hóa video thì đắt. Tôi không có bằng chứng, chỉ có thử nghiệm cục bộ, nhưng bắt đầu đo đạc thật sự là ý tưởng rất hay
      Cũng có ý tưởng khác là quét màn hình và chỉ gửi những phần đã thay đổi. Chỉ cần gửi một nửa màn hình thì về mặt mạng có lẽ đã có thể thắng mã hóa video. Tuy nhiên thuật toán diff phải rất nhanh. 1280x720 là 914400 pixel, mỗi pixel 4 byte thì phải xử lý 3,49MB thông tin mỗi giây
      Tôi cũng tò mò hiệu quả mã hóa video và chi phí tạo 60 ảnh JPEG. Hai thứ đó có tương đương nhau không?
    • Đây cũng là điều đầu tiên tôi nghĩ đến. Tôi không thấy lý do gì để không dùng codec tiêu chuẩn nhưng đặt ở 1fps
    • Có vẻ họ chọn tránh lưu dữ liệu lâu dài, tức là thay thế và xóa, hơn là tối thiểu hóa băng thông
      Nếu muốn thì làm cả hai chắc cũng dễ, nhưng tôi không rõ có đáng chịu thêm phiền phức không. Tôi đồng ý rằng nếu mở rộng quy mô trên cùng một IP thì cách này có thể trở nên quá tải

  • Thích
    Quy trình làm việc của chúng tôi được thiết kế theo hướng loại bỏ nhu cầu về văn phòng và hạ tầng kỹ thuật. Chúng tôi stream theo thời gian thực timeline output, tức kết quả dựng video, và có kênh liên lạc mở. Phần lớn thành viên trong nhóm khá hướng nội nên dùng kiểu push-to-talk, và nếu không cần thảo luận toàn nhóm thì thường chỉ để lại ghi chú trong chat
    Những giải pháp thô sơ đôi khi lại dễ được chấp nhận hơn

    • Rất vui khi nghe vậy. Tôi vừa open source phần server, nên bạn có thể nghịch thêm. Tôi sẽ cải thiện tài liệu theo thời gian để dễ làm theo hơn

  • Use case của chia sẻ màn hình không có audio là gì? Tôi không chắc khi nào nó hữu ích. Dù sao thì chẳng phải vẫn phải giao tiếp với đối phương theo cách nào đó sao?

    • Nhiều lắm. Ví dụ khi đi làm và để máy tính ở nhà, bạn có thể lưu link lại để xem ở nhà đang xảy ra chuyện gì. Remote desktop cũng tương tự
      Trong các cuộc họp dài, đôi khi vẫn cần chia sẻ màn hình liên tục. Có lúc tôi muốn code hơn là ngồi nghe cuộc họp 1–2 tiếng
      Và nó cũng hợp với những người không thích audio như tôi. Tôi có nhiều sinh viên muốn giúp, nhưng không muốn phải kèm cả audio. Voice chat của tôi không phải là tài nguyên dễ song song hóa
    • Theo bài viết, 1fps.video là giải pháp đa dụng dành cho người hướng nội và người làm việc từ xa muốn chia sẻ màn hình mà không chịu áp lực của audio hay video call, và hoạt động cùng các ứng dụng chat nhóm họ đang dùng
      Nó có vẻ giống chat bằng văn bản kèm gửi screenshot hơn là “chia sẻ màn hình trong cuộc gọi thoại”. Tôi hiểu vì sao có người thích như vậy
    • Kẻ lừa đảo đôi khi cũng dùng chia sẻ màn hình không có audio trong khi gọi điện với mục tiêu
    • Chỉ gọi điện là được mà? Ai cũng luôn có điện thoại di động, không cần phát minh lại bánh xe

  • Về đoạn “mệt mỏi với chia sẻ màn hình vì Google Meet giới hạn 1 giờ, Zoom giới hạn 40 phút”, jitsi[0] là một lựa chọn họp video mã nguồn mở[1] dựa trên WebRTC. Nó khá đầy đủ tính năng để thay thế những thứ như Zoom, Google Meet, Slack
    Có thể dùng trên trang chính, hoặc tự host nếu muốn
    [0]: https://meet.jit.si/
    [1]: https://github.com/jitsi

  • Sẽ thú vị nếu xây dựng một heuristic để chọn frame nào sẽ dùng. Việc luôn chọn bừa frame mới nhất nhiều khả năng không phải tối ưu; có thể tốt hơn nếu chọn frame ít chuyển động, không có animation đang chạy, hoặc có các chỉ số tương tự
    Nếu muốn cầu kỳ hơn, có thể phân tích theo từng cửa sổ rồi tạo một dạng tổng hợp cho toàn bộ frame

    • Phân tích theo từng cửa sổ rồi tạo tổng hợp cho toàn bộ frame có thể đi vào vùng giống như “camera” smartphone áp dụng quá nhiều tính toán lên output của cảm biến ánh sáng đến mức gần như khó gọi là ảnh nữa [0]
      Ý tưởng hay, và tôi nghe nói trong cờ vua có khái niệm tương tự gọi là quiescence search[1], nhưng có lẽ không đáng công
      [0] https://old.reddit.com/r/Android/comments/11nzrb0/samsung_sp...
      [1] https://en.wikipedia.org/wiki/Quiescence_search
    • Như vậy có thể đi ngược mục tiêu sử dụng tài nguyên tính toán tối thiểu
      Dù vậy nghe vẫn là một ý tưởng tuyệt vời và một bài toán thú vị
    • Thật ra tôi thích ý tưởng này. Trước đây tôi từng nghĩ đến việc quét một ma trận 100x100 thưa, cách nhau 5–10 pixel, quanh những điểm đã phát hiện có thay đổi trước đó để nhận biết các thay đổi màn hình có thể xảy ra

  • Gặp lỗi biên dịch ở github.com/go-vgo/robotgo báo thiếu X11/extensions/XTest.h
    https://github.com/go-vgo/robotgo?tab=readme-ov-file#require...
    Có một điều kiện tiên quyết không được ghi trên trang. Trên Mint 22, tôi phải cài gói libxtst-dev

    • Tôi sẽ cập nhật tài liệu. robotgo có vài vấn đề trên Windows nên hiện tôi đang xem xét một số phần

  • Hôm nay tôi đang tìm đúng thứ như thế này. Tôi đang monitor từ xa một sự kiện thử nghiệm vật lý, mà để Google Meet đang ghi hình mở suốt thì rất lộn xộn, nhưng vẫn cần text chat cho giao diện
    Trông như một giao diện tối giản rất tốt. Nếu có hứng, có thể tôi sẽ thử gắn thêm dạng persistence nào đó cho chat
    Ngoài ra, có thể hiểu rằng phần văn bản hoặc âm thanh đồng bộ sẽ được thực hiện ở nơi khác, như gọi điện thoại hoặc mô tả bằng text trên Slack không?

    • Thỉnh thoảng tôi làm vậy với bạn. Dùng cuộc gọi WhatsApp cùng với chia sẻ màn hình đơn giản giữa laptop của tôi và PC của bạn tôi
    • Bạn nói hôm nay đang tìm thứ như thế này, nghĩa là hồi sớm hôm nay bạn đã nghĩ chính xác rằng mình cần 1fps à?

  • Với nhu cầu của tôi, Moonlight Game Streaming gần như đã thay thế VNC. Chỉ cần các tính năng như truyền file, chia sẻ clipboard tốt hơn nữa là được

    • Thành thật mà nói, chỉ cần clipboard là đủ, và sẽ rất hay nếu có dịch vụ hỗ trợ NAT traversal

  • Có vấn đề với việc theo dõi con trỏ. Không rõ có phải vì tôi dùng nhiều màn hình không
    Trong ảnh này, vòng tròn mới là vị trí con trỏ thực tế https://i.imgur.com/TvzskjS.png

    • Tôi hứa sẽ sửa theo từng use case chính. Bạn có thể quay lại kiểm tra sau xem đã sửa chưa. Cảm ơn phản hồi