Send As SMS

Saturday, October 28, 2006

Using wget in scripts

Wget, or at least the version of it in Debian Sarge, does not adhere to the usual UNIX norms (if all goes well then generate no error messages and exit zero, if there's a problem then generate error message(s) and exit non-zero). Here is how to use it to emulate this behaviour:
wget URL &>log || ( cat log >&2 ; rm -f log ; false )
The problem is that wget is built to be chatty and, although it does exit non-zero on error, it does not appear to be possible to reliably configure it to emit an error message in this case but emit nothing in the non-error cases:
  • -q silences all messages
  • -nv, which is supposed to silence the chatter also appears to silence error messages. I'd say that this is a bug, however the GNU folks appear to lack a current maintainer for wget.
UPDATE 2006-10-28: Close, but no cigar.
wget URL &>log && rm -f log || ( cat log >&2 ; rm -f log ; false )
Now the log file now disappears on success, as well as on failure.

Friday, October 27, 2006

Pitt St...

Cool video of a guy giving away free hugs in Pitt St., being stopped because he didn't have public liability insurance to cover people who may be injured while being hugged (!), getting 10 000 signatures on a petition to get the council to change its mind and ultimate success.





TEN News covers it.



Voices that I've listened to for most of my life without noticing accents (Tim Bailey, Angela Bishop, ...) now sound very Australian!

UPDATE 2006-10-27: (thanks to Anand for the link)

Preventing Flash from wedging with esd

This is a "I've fixed it before, and may need to fix it again" memo.

From time to time I wish to use Flash in an environment where esd controls audio. esddsp should do this, but doesn't. In order to get this to work correctly, it is neccessary to install the development libraries "apt-get install libesd0-dev".

(I'm using esd both to allow multiple apps to use the device and because, at present, my notebook's audio hardware is not supported, so a combination of esd/esdmon/liveice/icecast turns output to esd into a network stream which my MediaMVP can play.)

(Although I've not retained the links to the relevant pages, the problem is a known bug. It appears that a combination of nonfree-ness, extreme technical ugliness of esddsp (diverts lots of system calls, doesn't participate in LD_PRELOAD chaining, ...) and a claim that Macromedia is aiming to fix this in an upcoming release means that this is about the only workaround that's available at present.)

Carbonado, another approach to Java persistence, by Amazon

This looks like quite a tight marriage of objects and relations. Joins are specified in the definitions of the joined classes, in much the same way that foreign keys might be specified in an SQL schema, but are apparently automatically used when querying. Carbonado provides its own query implementation, so it does not even require a SQL backend (although integration concerns may mandate the use of one).

I have dreamed about an approach like this for a while. Now I can dream instead about making the time to study it...

Wednesday, October 25, 2006

Australian Standard Classification of Religious Groups, 2005

The current clasification is here.

Perhaps unsurprisingly, the word Jedi does not appear anywhere in the entire 132 pages of it. The number "1000" is mentioned as the usual size of the smallest group for which an identifying code is issued, and mention is made of exceptions being made for smaller groups of interest; there appear to be thousands of groups in total.

The implication appears to be that anyone answering Jedi is not answering honestly, which is probably true, but seems a rather cavalier attitude to take toward someone's profession of belief, no matter how absurd-seeming; even the "Aetherius Society (Flying Saucer Group)" merits a mention.

Friday, October 20, 2006

Retro-animation, and breast-cancer awareness

Εμμα (Emma) forwarded me an email a couple of weeks ago which was a breast-cancer awareness raiser (the idea is to get people to click the "Fund Free Mammograms" button daily to earn advertising revenue; hopefully the money is actually spent as described ...). This would not normally prompt me to post, but included a really cool animated GIF of a walking woman (well person) that appears to have started life as an ASCII animation.


There's something pleasingly absurd about using an animated GIF for ASCII animation, in much the same sense that playing noughts and crosses (tic-tac-toe) in/from hot-air ballons by dropping markers onto open fields would be.

Apparently the GIF patent expired a few weeks ago. (Hmm, Unisys just keeps popping up for me lately.)

Oh, needless to say, this image has been around for a while. HoaxBusters includes it in their catalogue of interesting chain letters, from 2003.

10097 32533 the sequel: 76520 13586!

I decided to post this one as a puzzle to see whether anyone would work it out. Ed did so pretty promptly.

So, for everyone else. 10097 32533 76520 13586 are the first twenty digits of Rand's classic A Million Random Digits with 100,000 Normal Deviates.

Twenty years ago I read a novel (called "The Consultant", I think) which detailed the tracking down of a criminal who was using a bank's internal communication network to deliver a program which stole money to a computer which was able to process the fraudulent transactions. The program was known to be delivered encrypted and the security analyst was having serious trouble decrypting it. Someone else who, coincidentally, had been idly perusing a book of random numbers (possibly Rand's) looked at the block of digits representing the "encrypted" program and immediately recognised it as a page of the book of random numbers, which of course put the analyst back on track; seeking a copy of the actual encrypted program to work on rather than wasting time trying to decrypt the block of random numbers that was being used as cover between thefts.

The idea of a published group of actually random numbers struck a chord with me. I never pursued it, but spotting Schneier's post last week brought this memory back. Naturally, posting an open description and link would not have been in the spirit of the book, so I merely posted the opening digits. I'm guessing Ed used Google rather than recognising them on sight, but we'll never know for certain.

Oh, and kudos to Rand for freely the publishing the digits in machine-readable form too.

UPDATE 20-Oct-2006: While searching for some of the links above, I also discovered a source of allegedly random data from fourmilab. (I say "allegedly" because if you're going to depend upon it, you need to trust not only that they are getting the data from where they say they are getting it, and that it is a truly random process (this seems certain), but that the path between it and you has not been compromised.)

More on on-card displays

These are some followup thoughts to my previous post about the availability of smart cards with builtin displays and keypads.

Yesterday, I finally read Schneier's 1999 Breaking Up Is Hard to Do: Modeling Security Threats for Smart Cards which actually describes the same threats that I was talking about as particular cases of the more general problem of "splits" where things that are all under the [nominal] control of one party in classical computer security (CPU, storage, I/O, power supply, software, data) are under the control two or more parties in smart card systems. This broadended my understanding of the problem, supported my idea that keeping the terminal under the cardholder's control is an important threat-reduction measure and reminded me that Ed had made some interesting comments that I'd meant to respond to. So:

Schneier suggests that the two largest areas of improvement are:

(i) per my own intuition, to place the terminal under the cardholder's control, whether with a seperate device (e.g. a Vasco-Digipass-800-series type device) or with the terminal on the card itself (he actually talks about the now-departed REX personal organiser; of course the newly-available on-card devices have a better shot of mass-market success), and

(ii) to make the cardholder also be the data-owner. This is trickier because it's very tempting for the card-issuer to see the card as a trusted computing device doing its bidding while in the hands of its customer. Mobile phone companies explicitly talk about the SIM as the one thing that they can reliably control (because customers do change phones, sometimes to phones not supplied by the telco), subscription TV services embed crypto keys in the card, etc. There are even offline digital cash systems that depend upon the smart card containing an "observer" module that represents the bank; the rest of the software on the card can do whatever it wishes, but the bank's observer will only generate "this looks reasonable" signatures for transactions that look reasonable. For this to work, the observer needs to possess a key, stored in the card somewhere, that must not be available to the user. The mere presence of this element provides an incentive for cardholders to invest effort in gaining unauthorised access to the key and using this to cheat the system.

He also points out some potentally surprising consequences of collaboration between apparently seperate and potentially hostile parties (e.g. card manufacturers and software developers could collaborate in ways invisible, but harmful, to card issuers and/or cardholders.)

On my earlier post, Ed suggested that the mobile phones that most of us now carry could be used in the role of trusted terminal. My concern with this is the same as my concern with trusting one's own PC in this role; PCs are so complex, and run software from so many sources (if you are reading this with a web-browser then it is likely that you are also running some Javascript that it's downloaded from somewhere...) that it is difficult to be confident that a PC's owner is truly in control of it. This is in fact a large part of the importance of external security tokens (think SecureID) in the first place. An important characteristic of the Vasco (and other) devices is that they are not field-upgradeable. From the day that they're shipped until the day that they're discarded, they'll run exactly the same software. This is problematic if they contain a vulnerability which becomes known (mass recall time!), but does mean that no adversary can ever replace the software in the terminal, an event that would reintroduce the very split that having a cardholder-owned terminal was intended to remove. This weakness in PCs has not been lost on malware authors; there have been reports of malware found in the wild which waits until a compromised browser is used to log in to a particular bank's web-banking interface and then proceeds immediately to milk the user's account while the user is logged in (more broadly, all phishing and pharming are examples of this). The same weakness exists in mobile phones, albeit to a lesser degree at present. The non-field-upgradeability of the software in the Vasco-type device or the newer on-card devices is a potent protection against this form of attack.

Ed made another great suggestion about placing the real keypad under the counter with a set of solenoids to operate its buttons and to present the customer with a fake keypad (which controlled the solenoids). This would actually have worked against the EFTPOS machines that I worked on at Burroughs, as the card was swiped through a slot at the bottom of the checkout operator's interface, however it would not work against the newer terminals which have the card slot in the keypad. This is in part about the requirements of chip+PIN smart cards (instead of being swiped, the card is inserted for the duration of the transaction and, I suspect, receives the cleartext PIN) but would also thwart the attack that Ed suggests. On the flipside of course, some merchants (notably Waitrose) no longer put the keypad on a cable; instead it's on an arm attached to the wrong side of the checkout counter, so it's not possible to block sight of the keypad with your body, and the side-guards only block visibility from a viewing angle so steep that a snoop viewing at that angle would probably not have been able to work out which keys you were pressing anyway; while the angle that the next person in line at the checkout views it from is unobstructed. Perhaps this is intended to make life slightly trickier for corrupt checkout operators, who are probably a more serious threat than opportunistic customers anyway.

Saturday, October 14, 2006

10097 32533

:-)

Any takers?

Friday, October 13, 2006

MediaMVP and DVDs, via VLC

I've been playing for a little while with a Hauppauge MediaMVP (running mvpmc).

Amongst several other things that I wanted it to do was to play a DVD sitting in my notebook's drive on the MVP (and thus on my TV+stereo). The device is supposed to be capable of playing DVDs directly from the VOBs (via NFS or SMB) but I was also interested in using VLC's transcoding. There is built in support for using VLC on a more powerful machine to perform various sorts of on-the-fly transcoding, but the cases in which it will do so are hard-coded and not at all user controlled. After a while, I realised that I could get VLC to make the stream available via HTTP and just connect the MVP to the HTTP stream, as long as the stream was one that the MVP's hardware could decode in real time. To find out what parameters to use I poked around inside the mvpmc source. Here is what I came up with:

$ /usr/bin/vlc --vlm-conf vlc.cfg -v -I telnet

(the "-I telnet" prevents a gui from appearing) where vlc.cfg contains:

new foo broadcast enabled
setup foo input dvd:@2:1-
setup foo output #transcode{vcodec=mp2v,vb=2048,scale=1,acodec=mpga,ab=192,channels=2}:duplicate{dst=std{access=http,mux=ts,dst=:5212}}
setup foo option sout-http-mime=video/mpeg
control foo play

This is pretty much a template for setting up network streams in VLC; note in particular the 2Mb/s MPEG-2 video- and 192Kb/s MPEG audio- streams in a Transport Stream (TS) container, per the MVP's hardware spec. The resulting stream is available to the MVP as http://notebook:5212/. There are some open problems, of course:

  • No DVD menus.
  • Playing starts immediately when vlc is launched, rather than waiting for the MVP to connect. There are options for VLC to provide video-on-demand, however the documented examples that I've found so far all depend on RTSP which mvpmc doesn't support.
  • Somewhere a codec is playing up, there's a lot of green as new objects enter a scene. It looks as though the green remains until the next I-frame. This is apparently not uncommon for broken codecs, but I've not yet isolated the at-fault component.
  • (Not critical) The VLC in Debian Sarge (0.8.2) doesn't appear to be able to do this. Instead I fished whatever version happened to be in sid yesterday (0.8.6).
UPDATE 2006-11-17: New improved all-in-one script:

#! /bin/sh

if [ $# -eq 0 ]
then
source=dvd:@2-
else
source="$1"
shift
fi

/usr/bin/vlc "$@" --audio-language eng -v -I telnet --vlm-conf /dev/fd/0 <<EOF
new S broadcast enabled
setup S input "$source"
setup S output #transcode{vcodec=mp2v,vb=4096,scale=1,acodec=mpga,ab=160,channels=2}:standard{access=http,mux=ts,dst=:5212}
setup S option sout-http-mime=video/mpeg
control S play
EOF

Friday, October 06, 2006

What Straw actually wrote

This will primarily be of interest to UK residents who are hearing about Straw's alleged call to cease-requiring/start-prohibiting the wearing of veils by muslim women in the UK. Here is what Straw actually wrote to the Lancashire Telegraph.

Needless to say he is in reality neither advocating a ban, nor implying that any muslim women in the UK are currently required to veil. He is instead asking a question about whether full veiling is
bound to make better, positive relations between the two communities more difficult.
Most of the mass-media reporting and responses have been about rather more headline-grabbing distortions of his claims, and only those activist organisations who are speaking with the most venom are getting airtime.

I don't have a clear opinion either way about Straw's question (how does one definitively balance a conjectured improvement in relations brought about by ending veiling with the antogonism that would be engendered by rendering socially unacceptable an ancient cultural practice?), my point in posting is merely to provide a pointer to what Straw actually said.