February 8th, 2007
Had a new idea for the switter (twitter shell client) client.
What if you had a switch that enabled you to secretly send commands to the shell via twitter service ? Now, that can be (is) dangerous. But what if you defined an hash with predefined actions, and “secret” (remember, unsafe connection) codes ?
./switter -u test -p pwd -t me -w -cli -h --log
-cli or –command would activate the :CLI listener and switter would parse the next limited string.
-h or –hash would make :CLI search hash keys for the predefined commands.
Without -h, :CLI would execute “all” commands (no root access please!)
./switter -cli -h # login info comes from the .yaml configuration file
:CLI who # would execute hash value for key 'who'(scripts, etc)
:CLI who -u # would execute who -u
Limitations include security issues, twitter string limitation, etc. A secret account could be created for this, or a secret “activator” (:CLI ou :RUNTh1S) could be defined. This opens doors to new features like command categorization, meaning the creation of severall listeners types, like :CLI for a purpose, :RUNTh1s for another.
Hum… hey Twitter coders, some HTTPS ?
Severall oriented tools do this (safer), but Twitter can be used for such things, like Jabber does, etc.
A final consideration… open source software allows you to look at the code. A very few ammount of people does this, obviously, but using others code can be… let’s say, we don’t know every programmers intentions. Being open, allows a much faster discover of potential problems. Now, with proprietary software, we just don’t know. Cases of undisclosed “phone home” features were discovered on Microsoft sotware, HP drivers (a HP keyboard driver had a “phone home” feature created by the HP programmer “just to know how often special keys were pressed”), among (lots of) other. Now, let your imagination flow…