Monday, January 31, 2011

Remote control over RSS

I've been pondering ways of remote controlling a computer in an environment that is hostile towards incoming connections (e.g. behind a router, behind a firewall, lacking previlegies to open ports, etc.) without the use of external servers dedicated to offer a connection between the two, and believe I've come up with something that would work.

Web 2.0 is very much designed to be machine friendly. So much so it should be possible to feed instructions to a computer over an RSS feed (twitter, blogger, most forums, ...). The problem with this is that these feeds are made for text (which can be transformed fairly freely without degrading the message), whereas computer instructions are very sensitive to changes in case and the insertion or removal of newlines or spaces.

So another layer is necessary. Suppose a message is encoded in base16 or base64, that way we can strip all non-significant symbols before parsing the message. But then the problem becomes identifying the message. To do that, a magic token can be attached to the beginning of the message. Say 'sgurocks' (as it's previously been established that praise of SGU is rare indeed, we an assume it won't appear in any text). Next, a 4-digit hexadecimal length is added. Next a hash (md5? Again hex-encoded) is applied to verify that this is indeed a valid message. Finally, the message itself is appended.

This message encoding protocol has the benefit of being possible to scrape off any text-based medium, be it XML or HTML or whatever, and it's easy enough to encode that it should be possible to do with a greasemonkey script. Of course the computer we wish to control should only poll the RSS feed one or two times a minute to spare the server unnecessary traffic, so there would be a significant delay to this.

The server could use one of the many APIs available for webservices to respond in kind (except, without the encoding.)

I've done proof of concept testing on the RSS-scraping and decoding part, and the scheme seems to work fairly well.

Saturday, January 29, 2011

Impressive Dutch coin, courtesy of Free Software

I was doing an unrelated google image search when an unusual looking coin caught my eye.

I was intrigued, and found my way to a blog post by the coin's designer, who it turns out created it with open source software and python code (and this is a real coin that's gone to production, not just a mock up that stayed on a computer). A lot of thought went into the design, and the blog post was well worth the read.

The post in question can be found here: How to Make Money with Free Software @

Tuesday, January 18, 2011

"Security"-pestering, follow up

It would seem that there's a final step as part of the pester-into-change strategy outlined in the previous blog post. When you've had your pester screen up for a month or two, you force the change upon everyone who didn't yield to the pester screen. Both of the sites I listed in the previous post (youtube and facebook) just pulled that.

So the strategy for introducing potentially unwelcome changes as a whole seems to look like this:

  1. Introduce new feature, allowing people to use it if they want to.
  2. Add annoying screen after every log-in that urges people to adopt feature for "security" reasons.
  3. Force the change on everyone, whether they want it or not.