VNC over gif
github.com
github.com
Don't know why it was taken down. Here is the old thread : https://news.ycombinator.com/item?id=5543465
which mentions the Content-Type "multipart/x-mixed-replace" technique used to constantly update jpegs in the browser.
They're very easy to find as most vendors have a URL pattern. For example, here're a bunch of public security cameras made by Axis: https://www.google.com/#output=search&q=inurl:axis-cgi%2...
This is perfect.
Instead of waiting for upload to finish before giving you a URL.
But you'd need control over the image hosting backend cuz ImageShack won't let you do it.
[1] https://github.com/shurcooL/InstantBackgroundUploader_OS-X https://github.com/shurcooL/InstantBackgroundUploader_Window...
It may be a little complicated to make it do this, given how it works currently, but I might try it out.
However, I also thought about using long-loading animated gifs, because:
1. Run-length encoding seems to be ideal for screenshots.
2. You can use transparency to only update pixels that changed between frames without need for an alpha layer.
3. Palette-based does not seem to be a big issue for screenshots, which typically have few colors.
4. You use an additional frames to update colors that are off [1]. That way you get the best of both worlds: low latency and high quality images.
Do you have any issues using gifs? Memory usage, closing connections, etc...?
Edit: Apparently they're related to unistd.h, which doesn't exist on Windows platforms. Too bad.
This sort of thing is common in Ruby and Python-land. And infinitely better than the `curl foo.io/trolol.sh | sh` we've seen emerge in the last couple of years.
This kind of thing was somewhat common back when rsh / telnet were the usual ways of accessing remote systems.
As some module mature, they do offer bre-built binaries as needed.
More info if you're interested: http://zachcimafonte.com/GIF-Window-Server
The protocol is 50 pages long with pretty reasonable margins and it even has pictures: http://www.realvnc.com/docs/rfbproto.pdf
It is an afternoon read. Most desktop environments in Linux implement their own VNC server just because it isn't that complex and you can implement a subset of the protocol for a server anyway.
I imagine if there was a protocol flaw revealed (or even in the many implementations like libvncserver) it would be patched overnight. All of them support viewer-only mode. I like krfb, because by default it only uses access passes rather than a global password, so unless you give someone credentials of an access ticket nobody can login.
I bet an exploitation in the way gifs download and how http resolves file transfers in the dozens of implementations of both is much more likely to have an exploitable man in the middle or other mechanism to eavesdrop, if not take remote control.
We probably are assuming very different tolerance thresholds on security. But even so, I don't think you can argue for any security advantages of typical implementations for a 50-page protocol when comparing them to a one-way simple GIF sender.
Made me chuckle, but probably quite accurate.