It's not really a hack. It's slowly printing a GIF for a kind of really limited server push. If you want to send someone messages via server-push in an old-school way, use multipart/x-mixed-replace.
A hack would be taking the input of a TV tuner card, converting the video to .gif frames, and printing that out slowly enough to view a slow video over a DSL line to watch TV without a media player.
It seems a bit arrogant to say "I don't like this particular article, therefore the community is primitive." An Animated GIF messaging library is certainly of interest to a majority of hackers.
I simply made an amusing (to me) observation. I had earlier thought Pinterest seemed like MacGyver for people into crafts (at least that's the kind of thing my wife kept getting excited about). That's not to disparage HN or Pinterest or MacGyver for that matter.
As a die hard McGyver fan, I'm offended you'd compare him to a subset of stay at home mom's pinning pictures of other women with flat abs as "motivation." Ok, occasionally they post some pretty cool stuff, but mostly it is the former.
Our Canadian office managed to convince a couple of team members in our American office that we ran on a 20 hour clock, with 72 minutes in an hour. That was fun for a week.
As a remarkable coincidence, another hack that Ka-Ping Yee did once was writing a nonstandard clock for his Palm. He spent a summer living 28-hour days: six 28-hour days per normal week, going in and out of phase with the sun once a week. So he needed a way to remember when to go to sleep, when to wake up, when to eat dinner, and so on. When it's 25:00, what do you do? We have a lifetime of intuition built up around clock times on a 24-hour clock.
So he wrote a digital clock that used standard-length seconds, but 70 of them per minute, 60 of those minutes per hour, and 24 of those hours per day. So when it was 10:30:59 by his nonstandard clock, he was at the phase of his nonstandard day that corresponds to 10:30 or so of the standard day --- but the clock would then roll over to 10:30:60, 10:30:61, ... 10:30:69, 10:31:00.
It was very amusing to see people's reactions upon watching the clock for a little while, especially at the time of week that it was more or less in phase with normal time.
I really hope this statement by the project author was intended to be funny (as opposed to a serious belief that there's another calendar for the southern hemisphere.) I laughed. And then I realized I know people who would find this epiphanic and insightful.
It's discontinuous. To make this work, stretch the months (add/subtract days) so the tropics only have July August and poles only have Jan/Feb. Adjust holidays appropriately.
For a while (they've changed clients a few times but it still might work) the last fallback of LogMeIn remote desktop software was a gif of your desktop in an image map. It was surprisingly usable!
This is awesome -- you never know when a solution like this might come in handy.
Wayyyyy back in the day (NS4, IE4 day) I used the width / height of an image the browser polled every few seconds as a transport mechanism... the only other option (refreshing a hidden frame) caused an irritating "page refresh" clicking noise. This was before XMLHttpRequest obviously and was enough bandwidth for our needs. It worked so well that I believe its still being used in production systems.
I haven't looked at the javascript generated in this animated gif solution, but I assume that it does some stuff that wouldn't work in the pre-IE6 browsers. It would be extremely amazing if it did though.
When we were doing Comet in Netscape 4 and IE4 at KnowNow (in 2000, although Rohit, Adam, and Peyman got the technique working in 1999), we used an endless HTML frame, which simply never stopped loading. We'd spit out a <script> tag whenever there was a new message to deliver. There was an annoying clicking noise in IE, but only when the frame did finish loading because you'd lost your network connection or restarted the server.
Ah, I just realized that this simply prints text out in a gif... it doesn't encode text in the gif and then decode it in the browser into text that javascript could manipulate. Too bad. I wonder if that's possible...
I did something similar for cheap (insecure) desktop streaming a few years ago.
Roughly, use scrot (or similar screen capturing command line tool) to take a screenshot of the desktop and then encode it into a gif frame. Repeat once per second. Boom, your desktop is now a gif.
The main problem with this approach is that transmitting stuff via gif (low-color bitmaps, remember) is painfully slow even with modern internet.
That said, could probably be very useful in some instances!
It is possible to do some interframe compression with gifs[1], so one can potentially reduce the data sent significantly, especially if one is typing or not changing the whole screen. (And gifs aren't "just" bitmaps, they have some compression[2].)
[1]: "Some economy of data is possible where a frame need only rewrite a portion of the pixels of the display, because the Image Descriptor can define a smaller rectangle to be rescanned instead of the whole image."https://en.wikipedia.org/wiki/Graphics_Interchange_Format#An...
No one has mentioned these specific use cases yet...
1) live charts and graphs of server loads
2) interactive maps (instead of loading new images, just append)
3) I'm also thinking of some kind of captcha, where the user waits for the server to show a certain image and then can submit a comment and the server would know which submits were valid based on timestamp... or something.
4) weather, temperature, stocks
5) collaborative drawing applet? (would still require ajax though)
Collaborative drawing would be possible without ajax. Just put a 1px image on the page and change its url to encode the drawing commands. Update the animated gif to show the users what was drawn.
I admit that I have only thought about this for a minute or two but I am thinking of something a little more complex than a hard coded image.
More like: Hit submit when a picture of a dog is shown in the slideshow, if its a cat, your comment will be denied. And these images of dogs and cats would be picked randomly by the server from a google image search (...or something). The vulnerability so far is that a bot could just keep trying until it got in but I'm sure a crafty programmer could come up with an attempt limiter.
Still a half-baked idea, but the tech does offer some interesting possibilities. I particularly like that this may work when AJAX/JS is disabled or otherwise not an option.
I worked on CAPTCHAs at Microsoft Research in a past life, and I can tell you, most original forms won't work. In the case of the one you described, I as an attacker can just put it through Tin Eye to find the original, and then do some semantic analysis on the page containing the image, or event just the URL, to figure it out. I have working code for this as a proof of concept for Microsoft's Kitten Auth.
If that is the best attack on my idea, then I'd say that's pretty good! A spammer would have to target the site specifically (for tailor-made script) and parse an animated gif into individual images, then send every image into Tin Eye (which is awesome but the API isn't free right?).
That said, I am a complete amateur at captcha design. Cool research though and I bet a lot of HN'ers would be interested in your PoC if you haven't already submitted it.
So when you read about countries like Venezuela installing proxies in front of Twitter before an upcoming election [1], is there a potential to use this technique to tunnel information into areas that normally would suppress it?
It would be much cooler if you were to send the video stream to the gif instead of the booring old messages. Very cool though. Just think if something like this with video was invented back in the days of IE6 , it would have been the skype of its day.
If realtime messaging is a new and cool thing, what were chat rooms back in the day? not realtime? Am I missing something? I don't remember needing reloading those pages...
I don't necessarily think they intend "realtime messaging" to be the focus here. We've had obvious IM for years and it didn't exactly lull as far as I know. Definitely cool that someone hacked around to learn the details about some bit of tech to make it do something it wasn't built for. I applaud this attitude.
That said, it seems that since the "digital revolution" we go through these re-inventions of basic ideas and tools quite frequently. We've had "email" since the time multiple people could use a computer; recently, I commented on HN about how someone reinvented server log analysis tools to find click fraud (they were outsourcing analytics and apparently were unaware that web server logs ever existed.)
Chat rooms 10 years ago weren't using web standards like HTML, GIF and Javascript. They were writing either in Java or in Flash.
However MSIE6 also supports XmlHttpRequest (though an Active-X Control), which you can also use for real-time communication. Just setup a XmlHttpRequest and let the request idle on the server-side until new data become available.
Only if your server code process each request in a separate thread. But that's also true, when using web-sockets or when using the GIF approach. When implementing real-time applications, you always have to write non-blocking asynchronous server code, for example using node.js or Twisted.
I get the humor of this library, but in reality wouldn't you just use HTTP 1.1 chunked transfer encoding instead? According to http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol, that would even work with your IE 2 users.
> if we add an animated GIF as the first source, every time a drawImage call happens it will render whatever the status of the GIF is at that very second
So if you call drawImage in a (timeout/setinterval) loop, you can get the frame's data, compare to the previous frame's data and if they're different you got a new frame-worth of data.
Considering that requires canvas support (with image-query capabilities) you're probably better off using websockets and the like.
"The awesome image that illustrates this page was given by the internet."
That excellent gif is from "Tim and Eric Awesome Show, Great Job!" Just thought I'd give proper credit where it's due.
I wrote the first (only?) GIF decoder for the Commodore 64 back in the day, including displaying animated frames. There was no 'live' delivery of images back then though; you had to download them in-full over FTP or a proprietary file transfer protocol before you started parsing. I suspect the encoding was too slow on most computers at the time to stream the file as it was encoded anyway. But yeah, the basic capability was present back then.
Once the WWW kicked off and GIFs started being served, and especially once cgi scripts started being written, someone could have had this idea and the software and hardware probably could have handled it. So we could have been doing this in the late 90's. I wish I had thought of it...
This is pretty cool. I don't know if I would use this in production, as people with epilepsy usually disable GIFs to protect themselves, so this tech would probably fail (usually people use an extension or set the browser to only load frame 1 of the GIF and stop).
Couldn't this be used to add another layer of security to a conversation? If there is a way to generate gifs on the fly that contained what you wished to say, it could be used to mask your message from basic text screening and copy/paste.
It wouldn't provide any meaningful security; think of how difficult it is to make a CAPTCHA that is both readable for humans and hard to beat for computers. Adding security to a conversation is a solved problem in the technical sense (use encryption such as GPG), the only reason that it's not in widespread use is that people can't be bothered.
Writing text onto an image is easy. Graphical hit counters are almost as old as the web. The first ones just lined up images with preprinted numbers on them, but as soon as CGI became popular, people had libraries to write the text on top of an image too.
How exactly is this a better approach than multipart/x-mixed-replace, which is designed to push new messages from the server to the client in a stream until the server decides to stop?
if flash wasn't dying already I would have asked if this could have been useful to enable flash games or videos on the ipad... but the answer would have probably been "no" anyway
Someone made a coffee table out of old crates? Pin. Someone made a fence out of old wood pallets? Pin.
Someone made a realtime messaging library out of animated gifs? Upvote.