Show HN: 1-FPS encrypted screen sharing for introverts

Good job releasing your project! It's a cool idea and surprisingly minimalist. That said, I've found a number of cryptographic flaws in the application source. This should not be used in instances where the encryption is mission-critical.

1) You generate a random key [0] and then feed it into PBKDF2 [1] to generate a 32-byte AES-GCM key. If you can generate 32 random bytes instead of 10 reduced-ASCII characters and a key stretch, just do that. PBKDF2 is for turning a password into a key, and it's far from the recommended algorithm nowadays; prefer scrypt if you need to do this sort of thing.

2) AES-GCM with random 12-byte nonces. Never use random IVs with GCM; this breaks the authentication [2] [3]. Given the pitfalls of AES-GCM with respect to random nonces, you might prefer switching to XSalsa20+Poly1305. The advantage of XSalsa is it has an extended nonce length, so you can use random nonces without fear.

3) Random key derivation with a restricted character set can make brute force attacks easier. You should have a 256-bit random key, and if you want that key to be within a certain character set, then encode the byte output from the CSPRNG using that character set.

4) 1fps achieves symmetric key distribution via a URL with a fragment identifier ("#") which IIRC is not sent to the server. Therefore it assumes you have a secure key distribution channel - the link contains the key, so it's important that only the intended recipient can view the part after the "#". If the server is truly malicious, it can deploy client-side Javascript to send the fragment to the server, allowing the server to access the key (and thus cleartext communication).

[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/

From reading the code it looks like it's just taking a screenshot (.jpg) and sending it once a second. Does doing it that way actually save on bandwidth compared to modern video compression (that re-use information from previous frames)?

I recorded a one minute video clip of me editing some code in VS Code (1440p 10fps, using AV1 encoding) and it was about half the size of 60 JPEG screenshots of the same screen. I would be curious to see your numbers if you've done any tests.

I love it.

Our workflow is built around removing the need for an office and technical infrastructure. We have live streams of our timeline output (video editing) and an open comms channel. Most of our team is pretty introverted, so it's a push to talk system. We mostly just leave notes in the chat if it doesn't warrant a full discussion.

Crude solutions are often the ones that get adopted.

What is your use case for screensharing without audio? I can't figure out when that would be useful, you have to communicate with the other person somehow.

> I tired of sharing screen via Google Meet with 1-hour limitation, with Zoom and 40-minute limitation, etc.

FWIW, jitsi[0] is an open source[1] WebRTC based, full featured, video conference/meeting alternative to zoom, google-meet, slack, etc.

You can use it via the main site, or self-host it if you like.

[0]: https://meet.jit.si/ [1]: https://github.com/jitsi

could be interesting concept to try to make some heuristics for picking which frame to use; just blindly picking always the latest frame is unlikely to be ideal, instead you might want to pick frames where there is little movement, or no ongoing animations, or some other similar metrics. if you want to be super fancy, you could try to do this analysis per-window and then construct some sort of aggregate for the whole frame.

# github.com/go-vgo/robotgo In file included from go/pkg/mod/github.com/go-vgo/robotgo@v0.110.1/key.go:15: ./key/keypress_c.h:22:18: fatal error: X11/extensions/XTest.h: No such file or directory 22 | #include <X11/extensions/XTest.h> | ^~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated.

https://github.com/go-vgo/robotgo?tab=readme-ov-file#require...

There are some prereqs not listed your page. On Mint 22 I had to install the libxtst-dev package.

I was looking for something like this today because we’re remote monitoring a physical test event and having an open google meet with recording is a mess - however we would still want to be able to have text chat for the interface

Seems like this is a really good minimal interface - if I’m feeling wonky I might extend it with chat persistence somehow

I am assuming any additional synchronized text or voice is done elsewhere like calling someone on the phone or clarification via text on slack right?

Moonlight Game Streaming has pretty much displaced VNC for my uses. It just needs some better features for things like file transfer, clipboard sharing, etc...

I'm having issues with the cursor tracking, I don't know if it's because I have multiple monitors or something like that?

Here's a pic, the ring is where my cursor actually is https://i.imgur.com/TvzskjS.png

1 FPS screen sharing? Isn't that just MS Teams on a tuesday?

Does it support wayland?

This is awesome - and you've got some great advice.

The following was just inspired by the idea of yours "1fps screen sharing":

If you do 1FPS screen sharing - then create a private gallery on imgur.com - and have a thing update screenshots in a single gallery with a garbage collecting thread deleting a screenshot every 30 seconds/interval...

then have user have hidden gallery url and auto refresh browser tab.

This might work well actually if you have a small data connector and a device that can upload like only when event occurs.

Just upload that to replace the file in the imgur gallery - and you have a free cloud cam.

Cool! Been working on some automation bots in golang lately, so could I use your program to monitor my screen on the go over the phone? cheers

OpenDNS is reporting this domain as malware :(

https://malware.opendns.com/main?url=1fps.video&server=nyc4&... - not sure if that's viewable elsewhere, but if so there's a report link there.

>limited proprietary GNU-nonfrenly screensharing

Was Rustdesk on-radar?

> You need Golang installed for this command to work.

What makes all these newfangled language ecosystems think this is an acceptable way to distribute your software. No, I don't want to install yet another giant tree of language specific crap. Learn to distribute self-contained binaries please.

does not work on windows

very cool idea, and the pro-introverts pitch is very interesting

I really appreciate the discussion about the tech involved, especially non-go lang info and advice. peak HN imo

Does it use WebRTC? The last time I've looked at this - and what stopped me from releasing a more polished MVP of the same low impact continuous meeting-not-a-meeting concept - is that the only way to scale WebRTC is to use your own paid infrastructure. The only peer to peer topology available WebRTC clients support is a star, so without a multiplexing server you are practically limited to a handful of peers in any session.

So you are either offering a slow and very limited free service, or you need to pay hand over fist and burn venture capital to basically compete with Zoom and WebRTC. Slowing the video stream to very low FPS does help somewhat with scaling, but makes for a niche product.

If you can crack P2P multiplexing and offer an unlimited free service, and tack on some fremium model on that, that this thing can take off like a rocketship, if for no other reason that every team leader in the world wants a continuous feed of their remote worker's desktop. A free and capable screen sharing app can become THE tool for collaboration, disrupting things like Slack if the right features are there.

I'm seriously interested to cofound something like that, let me know if anything I've said makes sense to you.