In a comment on my post more about securing an office someone suggested using biometrics. The positive aspect of biometrics is that they can't be lost, no-one is accidentally going to leave a finger or an eye in their car while they go to a party while other authentication devices are regularly lost in such a manner.

The down-side is that having your finger or eye stolen would be a lot less pleasant than having a USB device, swipe-card, key, or other security device stolen. I think that it's good to have an option of surrendering your key when under threat (for the person who might be attacked at least).

Rumor has it that some biometric sensors look for signs of life (EG temperature and pulse), but I believe that these could be faked with a suitable amount of effort. A finger attached to a mini heart/lung machine should make it possible to pass the temperature and pulse checks (although I don't think that I have access to any data that is important enough to justify such effort on the part of an attacker).

One thing that biometrics could be useful for is screen-blankers. It would be good to be able to have a screen-blanker for your computer that operates when you go to get a coffee. For a period of 10 minutes after leaving a biometric method could be used to re-enable access. After that time a different method would ave to be used. This gives the convenience of biometrics for when you need it most (the many short trips away from your computer that you make during the day) but removes the benefit for an attacker who might consider removing part of your body. Also I am not convinced in the general security of biometrics. There are claims that you can make a finger based on a fingerprint which can fool a biometric sensor. If those claims are correct then a biometric sensor would still work for a coffee break (presumably you are not far away and will be back soon, and other people are in the area). The coffee break security is usually to prevent casual snooping such as colleagues who want to see what was on your screen but not actually do anything invasive to get it. Another benefit of biometrics for a screen saver is that although I trust people in the same office as me (whichever office that may be) not to try anything when they might get caught I still don't want them shoulder-surfing my password. Replacing the trivial authentication cases with a fingerprint reader would prevent that.

In the KDE 1.x days I had a shell script launched when the lid closed on my laptop which would lock the screen (the screen-saver ran in the background and a signal could make it lock the screen). This meant that I could merely close the lid of my laptop to lock the screen, this is fast and easy and also is not immediately recognised as locking the screen. Some people get offended if you lock your laptop screen when in their presence as they think that you should trust them enough to leave your most secret data open to them (generally people who aren't serious about computers - I'm sure that the same people would happily lock their diary if I was ever in the same room as it). Being able to lock the screen in a non-obvious way is a security benefit.

Regarding the comment about using a USB device to store passwords, there are two problems with this, one is that all passwords will be available all the time, this means a program that is permitted to access password A would also be given access to password B. The other is that the passwords can be accessed easily. The ideal solution is to have an encryption device that uses public key cryptography and stores the private keys on the device with no way of removing them. It would also permit the user to authorise each transaction.

I would like to see a USB device that stores multiple GPG keys and implements the GPG algorithm (with no way for anyone with less resources than the NSA to extract the keys). The device would have a display and a couple of buttons. When it is accessed it would display messages such as "signing attempt on key 1" and allow me to press a button to authorise or reject that operation.

This means that if I insert the key to sign an email I won't have a background trojan start issuing sign and decrypt commands. The only viable attack that would be permitted is the case where I want to sign a message and my message is sent to /dev/null and a message from an attacker is signed again. The non-arrival of my original message would hopefully alert me to this problem. I am not aware of any hardware which supports these functions.

Also I have just received a couple of RSA SecurID tokens as a sample. An RSA representative phoned me to ask about my use of the tokens, I said that I am an independent consultant and I have been having trouble getting my clients to accept my recommendations to use such devices and that I want to implement them on a test network so that I can give more detailed advice to my clients and hopefully get them to improve their security. For some reason the RSA rep found that funny, but I got my sample hardware so it's fine.

The Debconf team just announced that registration is now open for next year's Debconf7, to be held in Edinburgh next June. The preparations seem to go at good pace, and they already have a Travel wiki page with information so attendees can start looking for the best option for them. I am delighted to see they have been thinking about every case out there and it will be possible to swim all the way over to Leith, not even getting a bad cold. Thanks! This of course is yet another reason to plan ahead so I don't miss out, like last year in Mexico. Erinn, remind me about it in late May or so, mkay?

In some mailing list discussions recently some people demonstrated a lack of knowledge of the economics of a shop. Having run a shop for a few years (an Internet Cafe) I have some practical knowledge of this. I will focus on small businesses in this article, but the same economic principles apply to large corporations too.

When running a shop the main problem you have is in managing stock. There are two ways of getting stock, one is to have wholesalers give it to you for a period in which you can try to sell it and you pay for it when it's sold, this is probably quite rare (I don't know of an example of it being done - and probably no retailer wants to talk about it in case they lose it). Often retailers consider themselves to be privileged if they are permitted to pay for hardware one month after they receive it! The more common way of getting stock is simply to buy it and hope you can sell it in a reasonable period of time (often the wholesaler will offer to buy the stock back at a 10% discount if you can't sell it).

To buy stock you need money, this can come from money that has accrued in the business account (if things are going really well) or from a mortgage taken out by the business owner if things aren't going so well. For small businesses things usually don't go so well so the money used to buy stock is borrowed at an interest rate of about 7% or 8% (I'm using numbers based on the current economic conditions in Australia, different numbers apply to different countries and different times but the same principles apply). The ideal situation is when there is money in the company bank account to cover the purchase of all stock, this means that the cost of owning stock is that you miss out on the 5.5% interest that the money will get in a term deposit.

Almost all stock has a use-by date of some form. Some items have a very short expiry (EG milk used to make hot chocolate in an Internet cafe, some have a moderate expiry date (computer systems become almost unsellable in about 18 months and lose value steadily month after month), but in the computer industry nothing has a long expiry date.

Let's assume for the sake of discussion that you want to run a small computer store that is open to passing trade (this means that you must have stock for an immediate sale). Let's assume that all items of computer hardware lose half their value over the period of 20 months at a steady rate of 2.5% of the original price per month (I think that most computer hardware loses value faster than that, but it's just an assumption to illustrate the point).

The next major issue is the profit margin on each sale. If you can make a 20% profit on a sale then an item that has lost 10% of it's value while gathering dust in your store will still be profitable. However the profit margins on computer sales are very small due to having a small number of major manufacturers (Intel, AMD, nVidia, ATI, Seagate, and WD) that have almost cartel positions in their markets and there being little to differentiate the stores apart from price. I have been told that 3% profit is typical for retail computer hardware sales by the small companies nowadays! Now if the stock will lose 2.5% of it's value per month, you pay 0.5% interest per month and you make a 3% profit then if an item remains in stock for a month then you lose money. So on average (by value) you need to have stock spending significantly less than a month in your store. Cheap items such as low-quality cases and PSUs can stay in stock for a while. More expensive items such as new CPUs and the motherboards to house them must be moved quickly.

What's the first thing that you do to reduce stock? You can keep stocks low, but there is a limit to how low you can go without losing sales. The next thing to do is to not stock items that customers won't often buy or items where there is a similar item that you can stock as a substitute. The classic example of this is hard drives, a customer will want a certain capacity for a certain price - if their preferred brand is not in stock they will almost always take a different brand if it has the same capacity at the same price. Stores often advertise prices on multiple brands of hard drive in each capacity, but often only try to keep one brand in stock.

Of course this is a problem for the more fussy buyer. If you want to buy two identical parts from the same store on different days you might discover that they don't have the stock on the second day and that they instead offer you something equivalent. Not only do retailers have issues with managing their investment in stock but wholesalers have the same problem. So if a retailer runs out of WD drives and discovers that their preferred wholesaler has also run out of WD drives then they just buy a different brand - most customers don't care anyway.

There are some companies I deal with that have a business model based on services. One of them sells hardware to customers at cost, but charges them for the time spend assembling them, transporting them, etc. The potential for a 3% profit on the hardware isn't worth persuing, they prefer to just charge for work and also save themselves the sales effort. Another company I know operates almost exclusively on the basis of ordering parts when customers request them (but still make a small profit margin on the sales), this means that the customer can be invoiced as soon as the hardware arrives. The down-side to this is that wholesalers have the same stock issues and they sometimes have excessive delays before the wholesaler can deliver the hardware.

Dell is the real winner out of this. As they operate by mail-order they don't need to have the stock immediately available, they have a few days to deliver it which gets them time to arrange the supply. They can also have a central warehouse per region which reduces the stock requirements again. A 3% profit on items that rapidly decrease in value makes it almost impossible to sustain a small business. But an organization such as Dell can sustain a successful business at that level.

Of course the down-side for the end-user is that Dell doesn't want to have too many models as that just makes it more complex for the sales channel. Also they have deals with major suppliers which presumably give them deep discounts in exchange for not selling rival products (this is why some brands of parts are conspicuously absent from Dell systems).

10 years ago there used to be a small computer store in every shopping area. Now in Australia there are a few large stores (which often only have a small section devoted to computers) and mail-order. There seems to be much less choice in computer hardware than there was, but it is much cheaper.


PS I've attached a picture of day 39 of the beard.

So I am in Alberta, Canada but I decided not to get a local phone number mostly because I have a VOIP phone that works fine and it lets me call Puerto Rico for free, and allows my sister call me for free too. But not having an Alberta 780 area code can be quite problematic at times and the latest chapter in the confusion has come from trying to get the IBM warranty folks to accept that you can call from Alberta with a non Alberta area code and realze that even if they accept that, the computer is the one wearing the pants and thus making the decision…So even if you convince them that new technologies make this possible, the transaction is still sabotaged because in the end, they rely on computer to get the actual service repair person to call you and the computer relies, and can only rely on the area code., who can only see that an area code 773= USA, so then it gets a US rep to contact you back after the initial phone call. Here is an IRC transcript discussing the confusion, which I think is pretty amusing: m: they are so confused
m: the guys says “what province are you in?” I say “Alberta”
m: and then he gets my number and he says “You aren’t in Alberta, sir”
m: and I say “Yes I am, my phone number is a US phone number, but I assure you, I am in Edmonton, Alberta right now”
m: and he says “Are you a canadian citizen?”
m: and I say ‘no, do I need to be, in order to be in Alberta?” and he says “The problem is, you are actually in the US right now”
m: I AM NOT IN THE USA
biella: heh
m: so I had to say “You realize that cell phones and voip technology allow you to roam outside of the USA and still use the same phone number?!”
b: and then what?
m: well he said I needed a canada number or their system would send it to the states
m: regardless if thats where my address is
m: their computer is too smart
micah anyways
biella: or not smart enough Well, we are now using my office number so hopefully all will be OK.

I received a Freecom DVB-T stick last week (early wedding present). I've not actually played with DVB-T before, so I wasn't sure how much of a hassle it would be. My first act was to plug it into my laptop, with the aim of finding out the USB ID and thus which driver I'd need to compile up (I have a tendancy to build my own kernels with only drivers I think I'm likely to need). I did so and was greeted with:

dvb-usb: found a 'WideView WT-220U PenType Receiver (Typhoon/Freecom)' in cold state, will try to load a firmware
dvb-usb: did not find the firmware file. (dvb-usb-wt220u-02.fw) Please see linux/Documentation/dvb/ for more details on firmware-problems. (-2)
usbcore: registered new driver dvb_usb_dtt200u

Interesting, think I. I'm more organised than I thought and have already compiled up all the various v4l bits I thought I might end up using. So I go looking for the firmware file, find a copy, dump it in /usr/lib/hotplug/firmware/. Replug the device. And get:

dvb-usb: found a 'WideView WT-220U PenType Receiver (Typhoon/Freecom)' in cold state, will try to load a firmware
dvb-usb: downloading firmware from file 'dvb-usb-wt220u-02.fw'
usb 1-4: USB disconnect, address 15
dvb-usb: generic DVB-USB module successfully deinitialized and disconnected.
usb 1-4: new high speed USB device using ehci_hcd and address 16
usb 1-4: configuration #1 chosen from 1 choice
dvb-usb: found a 'WideView WT-220U PenType Receiver (Typhoon/Freecom)' in warm state.
dvb-usb: will use the device's hardware PID filter (table count: 15).
DVB: registering new adapter (WideView WT-220U PenType Receiver (Typhoon/Freecom)).
DVB: registering frontend 0 (WideView USB DVB-T)...

Rockin'. Now I need to tune it. I find Adam's DVB page which has the initial tuning file for the Tacolneston transmitter in Norfolk. I type scan uk-Tacolneston. It fails to find anything. I wonder if I'm using the wrong transmitter. I decide the supplied antenna is probably to blame and go to see about sorting out the one in the attic. I try again. I get a channels.conf containing 91 channels. Wooo. Copy this into ~/.mplayer/ and fire up mplayer dvb://. And have Freeview on my laptop. Nice. Unfortunately this requires me to have the loft aerial plugged into my laptop, which isn't very portable. Paddy tell me this will get better when the analogue transmitters get turned off and the digital power ramped up, so I look forward to that. Until then it should still prove useful to have a portable DVB-T stick - I intend to see if I can pick up BBC HD next time I'm staying in London, and check if Freeview coverage has made it to my parents' yet. Writing this all down makes it seem quite convoluted, but actually the process was a lot smoother than I expected; plug in stick, copy firmware, replug stick, scan for channels, watch tv. The issue that took most time to sort was the aerial. It's really quite cool to think about how easily you can get yourself an MPEG2 stream of TV to play with.

Ian Rawlings wrote in an article in uk.comp.os.linux that:

"There was a legal precedent set in the UK a little less than a year ago, in which the company's name and contact details in an email signature were taken as sufficient identification of the company for the contents of the email to be acceptable as a contract [...]"

and then helpfully provided some references about it. The headline on Disclaimers could make emails into contracts [The Register] seems a bit off. Even the article ends:

"The end result of this could be that people who include a signature and disclaimer at the bottom of their emails might actually be making themselves more liable than people who just send one line emails."

Note the might there. It's quite a leap, isn't it? Mehta v J Pereira Fernandes SA [2006] EWHC 813 (Ch) (07 April 2006) appears to have ruled that headers were not a sufficient signature, rather than that a plain text signature block (sig) is sufficient. Have I missed a key point here? AFAICS, the ruling contains the following key general points:

"28. I have no doubt that if a party creates and sends an electronically created document then he will be treated as having signed it to the same extent that he would in law be treated as having signed a hard copy of the same document. [...]"

"30. [...] if a party or a party's agent sending an e mail types his or her or his or her principal's name to the extent required or permitted by existing case law in the body of an e mail, then in my view that would be a sufficient signature for the purposes of Section 4. [...]"

I doubt that a sig is quite the same as a hand signature, as it doesn't necessarily 'serve as a method of authentication' as required by the Digital Signature Directive ( 1999/93/EC, Electronic Signatures Regulations 2002), but there are times when it could bind one to things. Essentially, using a sig is like using headed paper, not like hand-signing. Parts of the ruling (para.19) seem to argue that automatic insertions make things carry less weight AFAICT - does that hint at how futile those forced stupid disclaimers would be if relied upon in court? Does the same automatic-or-decision point also mean that using a electronic signature tool (gpg or whatever) selectively helps it carry more weight than signing everything automatically? I don't agree it ... signs death warrant for Digital Signatures [Financial Cryptography] Interesting questions. Anyone know if the answers are decided yet?

The stdarg API, which allows you to use a variable number of arguments to a function in C, is pretty fun. However, it's also pretty limited in what it allows, to a degree that it invites people to try and find workarounds to things you can't do with the API as it is documented. Unfortunately, this almost always breaks when the software is compiled on hardware that happens to be not your own, as there is a reason why stdarg is implemented the way it is: portability. A (not so) recent discussion on #debian-devel on OFTC showed to me how this confuses many people. Don't worry—it confused me too, the first time I had to think about it. The problem is that in order for stdarg to be able to do what it does, it needs to read function arguments from whereever they are stored. Where that actually is depends on the operating system and the hardware you're using; it could be on the stack, but e.g., the SPARC architecture actually has a mechanism to pass parameters using processor registers (although those are most likely not used when stdarg is in use, since the number of parameters that can be passed that way is obviously pretty limited). If parameters are on the stack, then you may be able to just access the memory as you would access any random variable; but it could also be the case that you need to take some specific steps to access the stack, or perhaps your architecture or operating system has some protection for stack-based security attacks, which would make it impossible to directly access memory on the stack that is actually part of another subroutine. So if you try to do anything that isn't defined in the stdarg api (like trying to figure out the number of arguments by peeking inside the va_list data type, or passing a va_list to another function without using the C99 va_copy macro) will break. Yes. Very sorry.

(For the grammar Nazis out there: no, that apostrophe is not misplaced)

---

There are times when a connectionless protocol almost doesn't seem worth the hassle. Take, for instance, the troubles of a round-trip communication, using UDP, where the initial request is sent to a secondary IP address on an interface. Your code, on the server, might look like this:

 s = UDPSocket.new
 s.bind('', 12345)
 loop   data, remote = s.recvfrom(65535); s.send(data, 0, remote[3], remote[1]  

This is a pretty simple Ruby fragment which just reflects your UDP packets back at you. It really doesn't get much simpler than that. Connect to this thing from somewhere else (using nc -u remoteip 12345) and you can reflect packets back and forth to your heart's content. Or so you'd think... When talking to a regular IP address, your packets probably look something like this (when viewed using tethereal):

 192.168.0.1 -> 192.168.0.2 UDP Source port: 35716 Destination port: 12345
 192.168.0.2 -> 192.168.0.1 UDP Source port: 12345 Destination port: 35716

Fantastic -- I send a packet, and get one back. In netcat, you see whatever you typed printed back out again. But, what if I add a secondary IP address to the server's interface (ifconfig eth0:1 192.168.0.5, for instance) and try sending packets to that IP address (with nc -u 192.168.0.5 12345)? I get this insanity:

 192.168.0.1 -> 192.168.0.5 UDP Source port: 35772 Destination port: 12345
 192.168.0.2 -> 192.168.0.1 UDP Source port: 12345 Destination port: 35772

And of course, no self-respecting network stack is going to accept a packet back from a totally different IP address, even if it did manage to get the ports right. Hence, the client never sees the return packets, and thinks that the server is snubbing it. What's happening here seems insane, but it's actually just a regular artifact of a connecntionless protocol like UDP. You see, we've bound our socket to the "any" address (the empty string in the call to #bind tells UDPSocket to bind to the "any" address -- no, I don't know why either, it's not a particularly intuitive interface). When we get the packet into our app via #recvfrom, we get no information on what address the packet was actually sent to, only that the OS decided that the packet was for us (yay for encapsulation). The only information we get is where the packet was coming from -- and due to the fact that the kernel keeps no connection-related information around for the socket (the kernel figures it'll hold us to our connectionless pledge), when the time comes for us to send a packet back, we have to explicitly say where we want that packet to go -- that's the remote[3], remote[1] arguments in the #send call. The brain-leakage starts when we work out where to say the packet is coming from. When we send the packet, a source address needs to calculated -- again, the kernel keeps no information on source or destination because we're connectionless. Because our socket is bound to the "any" interface, the OS thinks it has carte blanche to set whatever source address it likes. In Linux, the behaviour appears to be to pick the IP address set on the primary alias for the interface that will be used to send the packet out on. So for the common case (one IP address per physical interface) everything is fine. But those corner cases, gee, they're awfully sharp and pointy... The solution, of course, is to send the packet out through a socket that is bound to the particular address you want to use as the source address -- then the kernel knows what source address you want, and there's no confusion. Seems pretty trivial, right? Surely every sensible network application does that already, right? So obviously Ruby's UDPSocket implementation just sucks. That's what I thought, and I don't blame you if you think so too. But before you raise pitchforks and storm the gem-covered castle, try repeating our little experiment with some other widely-used UDP-based applications, such as net-snmpd or your ntp server. (The NTP server is a little different, in that to trigger the problem you need to start it and then setup the interface alias, for reasons I'll explain later). Both net-snmpd and ntpd exhibit the same behaviour as our trivial UDP echo service -- at least, the versions present in Ubuntu Breezy do, although I can't imagine everyone's suddenly cottoned onto this problem in the last 12 months or so and come out with a rash of fixes. So, basically, everyone seems to be suffering from the same malady. For values of "everyone" that equal "some UDP servers". There's some services that don't seem to have such troubles with alias interfaces -- the Bind DNS server comes immediately to mind, and ntpd works fine if you start the NTP server after you setup the interfaces. Why the difference? These services are clever and bind to each IP address on the system separately, like so:

 $ netstat -lun  grep :53
 udp        0      0 192.168.0.1:53          0.0.0.0:*                          
 udp        0      0 192.168.0.5:53          0.0.0.0:*                          
 udp        0      0 127.0.0.1:53            0.0.0.0:*                          

This is very cool, and solves the problem, except that if you add another interface after you start Bind, it doesn't pick up the new address, and you're boned until you restart the daemon. It also increases code complexity a bit, since you need add a select into your request handling loop (instead of just blocking on the #recvfrom call, like I've been doing thus far). Whilst I'm never happy about unnecessary complexity, I'll deal with it where I have to, but the real killer for this application is the "you can't change your interfaces after starting the daemon" rule -- my particular need is to make requests to a virtual service IP address, and restarting my service after each IP address change is going to suck hard. I mentioned ntpd earlier because it has some extra trickery at work. It's list of bound interfaces looks like this:

udp        0      0 10.6.66.6:123           0.0.0.0:*                          
udp        0      0 192.168.250.6:123       0.0.0.0:*                          
udp        0      0 172.14.16.6:123         0.0.0.0:*                          
udp        0      0 172.31.62.1:123         0.0.0.0:*                          
udp        0      0 192.168.37.179:123      0.0.0.0:*                          
udp        0      0 10.64.64.64:123         0.0.0.0:*                          
udp        0      0 127.0.0.1:123           0.0.0.0:*                          
udp        0      0 0.0.0.0:123             0.0.0.0:*                          

It listens to every IP address explicitly plus the "any" interface. I'm not quite sure why, either -- just listening to the specific addresses works for Bind, and if you add an interface alias after starting ntpd, it exhibits exactly the same problem as the trivial UDP echo service, so I don't think that listening on "any" is really gaining it anything. Listening on "any" does make ntpd behave differently to Bind: with Bind, if you send packets to an interface that wasn't available when Bind was started, it just completely ignores you (because it lacks a socket listening for packets to that address), while with ntpd the packets hit the "any" socket and suffer from the wrong-source-address bug. At the moment, my best chance of a solution appears to be to follow Bind and ntpd's lead and hook onto every address, but with the extra twist inspired by ntpd -- listen on the "any" address as well as all of the specific addresses. If I use any packets that arrive on the "any" socket as a trigger to rescan the available addresses (to add any new addresses that have been created since the last scan), that should solve all my problems. Now I only need to make it work (and deal with the insanities that will no doubt result). Wish me luck. The screams of pain and frustration you hear (no matter where you are in the world) are probably mine.

It is time for great evil to be unleashed onto the world. That is, I plan to write a bootloader for APUS systems that builds a proper flattened device tree and hands that off to the kernel, so APUS boards can boot the regular PowerPC multi-platform kernel.

The stdarg API, which allows you to use a variable number of arguments to a function in C, is pretty fun. However, it's also pretty limited in what it allows, to a degree that it invites people to try and find workarounds to things you can't do with the API as it is documented. Unfortunately, this almost always breaks when the software is compiled on hardware that happens to be not your own, as there is a reason why stdarg is implemented the way it is: portability. A (not so) recent discussion on #debian-devel on OFTC showed to me how this confuses many people. Don't worry—it confused me too, the first time I had to think about it. The problem is that in order for stdarg to be able to do what it does, it needs to read function arguments from whereever they are stored. Where that actually is depends on the operating system and the hardware you're using; it could be on the stack, but e.g., the SPARC architecture actually has a mechanism to pass parameters using processor registers (although those are most likely not used when stdarg is in use, since the number of parameters that can be passed that way is obviously pretty limited). If parameters are on the stack, then you may be able to just access the memory as you would access any random variable; but it could also be the case that you need to take some specific steps to access the stack, or perhaps your architecture or operating system has some protection for stack-based security attacks, which would make it impossible to directly access memory on the stack that is actually part of another subroutine. So if you try to do anything that isn't defined in the stdarg api (like trying to figure out the number of arguments by peeking inside the va_list data type, or passing a va_list to another function without using the C99 va_copy macro) will break. Yes. Very sorry.

I've seen the Parcel Delivery Services email hoax twice in the last few weeks. Premium telephone services regulator ICSTIS issued a press release debunking it on 1 November 2006:

"This is in fact an urban myth. It is not possible for a GBP 15 charge to be made on connection."

I added a new tip about telephone number warnings to my email page.

Long day today (yesterday, actually, but I'm post-dating this in the interest of chronological flow). The baby's having a hard time coming off of West Coast time; she got up late and took a loooong nap till half-past three. Which was fine, because I needed the time to work on my NSLU2, which needed some attention. The NSLU2, or "Slug", is a tiny Linux computer from Linksys, about the size of a two packs of Marlboros laid side-by-side. My brother Nate gave me one last year for Christmas (thanks, nate), and I've been using it for network backups, but on our trip to SF Nate showed me that he's running all kinds of wild services off of his. So I decided to start shifting over some responsibilities to the little bugger. Which was just about time. Sometime during our trip to San Francisco, my main home server started having fan problems; it kept overheating and shutting itself down. It's going to take some time to diagnose the problem, but I figured that this was as good a time as any to move the critical services over to the Slug. The main one that needed budging was DNS. Maj's main domain, as well as my two .san-francisco.ca.us domains, run from home, because it's too hard to get the registrar to change them. The Unslung system I use for the Slug has a BIND package, which is a good thing to run, anyways. I was running MaraDNS on the big server, because I always root for the underdog, but there wasn't a MaraDNS package for the Slug. So I rewrote my zone files and things are up and running now. I don't know what else I'm going to put on there. Jabberd? Asterisk? A home wiki? Just not sure. tags: nslu2 slug unslung baby

Blah blah blah When the baby got up, we went to our local Loblaws, out towards the end of rue Rachel across from Canadian Tire. It's a pretty fantastic place to buy groceries -- it's the old CPR Angus Shops, a repair and maintenance facility for the Canadian Pacific Railway. The building is huge, with giant cranes and beams still attached to the roof. Amita and I grabbed a crapload of groceries and brought them home to Maj, who'd just had a massage at the centre around the corner and was feeling really good. She'd rented Tristram Shandy, the 2005 movie based on the 18th-century level-twisting novel. Me and Amita June made some baked potatoes, and we all watched the movie, and a good time was had. tags: tristram shandy loblaws angus shops movie maj amitajune

H****e en vrac One thing I always want to buy when I'm at the store in Quebec is the quite commonly available communion wafers. Yeah, really! big ol' 5-inches-diameter communion wafers, in the snack section next to the Doritos and the Humpty Dumpty potato chips. Quebec society has a had a precipitous secularization -- from around 90% church attendance in the 1950s to less than 10% today. But Catholicism still infuses all parts of life. For example, in Quebec, you cuss by using words from the church, including, of course, hostie ("the host"). So I can't figure out why hostie are a tasty snack treat. Is it a deliberate snub to the sacrament of communion by a secular society? Or did the practice antedate the Quiet Revolution, and did the formerly religious Quebecois eat communion wafers for fun? Or is it just a snork-snork funny thing to do, when the name of the food is actually a naughty word? I dunno. I'm fascinated, but not enough to buy a big bag of communion wafers to eat. (They're never cheese- or BBQ-flavored, by the way; they have a pristine seriousness to them.) More info solicited. tags: hostie quebec snack food

Opinity One of the services mentioned in the Web 2.0 Summit infrastructure workshop was Opinity. Opinity seems to be a distributed reputation system, kind of like claimID but with a little more soft information. I think it looks pretty cool, and I'm glad to see another addition to the growing OpenID identity provider market. tags: openid opinity identity reputation

In the past and for my hacker course, I have taught Paul Ceruzzi’s History of Modern Computing but the book was a little too dry to fly high with first year students but thanks to Joe Reagle’s excellent syllabus on the Impacts of Technology, I read a short but very sweet (and teachable) piece by him entitled An Unforseen Revolution: Computers and Epectations that not only gives a window into the early history of the computer but provides a very nice conceptual entry as to why it is hard for inventors of a new technology, such as the computer, to foresee and fully come to terms with its future uses, full range of capabilities, and utlimately its impact. Basically the context of invention combined with the training of inventors (which in this case, the first American digital computer, the ENIAC was invented by a physicst and an engineer for mathematical computing) stitches and thus initially limits the vision (and thus use) of the technology largely to its original purpose, while precedding technologies provide the conceptual juice drunk to understand the meaning of new technologlogies. So while today we clearly think of computers as a meta-machine, that can be whatever-machine-in-the-world-we-so-desire (so long as someone programs it to be that machine), in its time, with people so accustomed to machines as having one function, the cultural imagination was stuck. As Ceruzzie humorously conveys, a machine having such general capabilities seemed absurd, like a toaster that could sew buttons on a shirt. But the computer was just such a device; it could do many things its designers never anticipated. p. 126 With the passing of time came new innovations (Ceruzzi identifies new developments in programming as key in this regard) and use in new settings (notably businesses), the stitches were loosened and finally unraveled so that the computer came to take on the meaning it has acquired today. One perennial topic of inquiry in the field of STS concerns how particular contexts and other factors shape new meanings, visions, and uses, or just limit them, along with unearthing the labor that goes into making new inventions or scientific theories more generally accepted. This is a great little piece to teach incoming students about some of these concerns in STS, and without a lot of heavy-handed anything. And to make the project of teaching really fun, add this short clip from the Muppets, where Dr. Bunsen Honeydew totally ignores the Very Large Gorilla about to gobble him up because of his blind faith in technology.

While anyone who has had a 1) medical condition and 2) access to Internet in the last five years probably knows that patients are increasingly using the net (and now google) to diagnose medical conditions, it is only now that the medial establishment is starting to recognize or really admit to the reality of this widespread phenomenon and even doing studies on them, such as the one released a few days ago by the BJP Googling for a diagnosis use of Google as a diagnostic aid: internet
based study. The study sought to ascertain how effective google was as an aid in medical diagnosis. As various new outfits are reporting it is moderately high. What I love about this study and the corollary reporting is the naive tone they have to assume, transmitting the news as if the public knew very little about this, and would in fact, be induced into surprise!!!!!!!!!! when first facing the new. But in fact, I think it works in the opposite way. The surprise is that they took so long to admit to what was in front of us for many years now. While the news articles reporting on the study stay within the province of doctors, the report acknowledges, in fact opens with, the fact that patients may be forging the path in Internet-diagnosis. The authors write in their second paragraph:

It seems that patients use Google to diagnose their own medical disorders too. After evaluating a 16 year old water polo player who presented with acute subclavain vein thrombosis, one of us (HT) started to explain that the cuase of the thrombosis was uncertain when the patients father blurted out But of course, he has paget-von Schrotter symdnome. Having previously googled the symptoms, he gave us a mini-tutorial.. and the correct treatment for the syndrome. This experience led us to ask How googe is google in helping doctors to reach the right diagnosis

Again, what I love about the tone of this opening is that it is as if these doctors stumbled on a great but deeply hidden fact to make a breath-taking discovery, one that, however, since is it is SO very emergent and thus still not *really* verified by Science, they must proceed with great caution, qualifying with phrasees like It seems that patients use Google to diagnose their own medical disorders too . I am sure they and most doctors are personally are not so na ve but since this has been something virtually without no official acknowledgment among professionals and in the journals, the genre of writing just requires it to be framed cautiously. As fun to read are the comments, for they stretch from moral panic:

The implication that ‘googling’ be an adjunct to proper medical school training, continuing medical education through courses and reading peer reviewed journals is laughable and bordering on dangerous. I am shocked that this has been published by the BMJ.

to celebration:

For the modern dermatologist, the internet is indispensible and google is only the start, and for this reason a desktop computer with high speed internet access is an essential tool for all clinicians. Long live the information superhighway!

While others muse on the broader emacipatory possibilities

One can imagine the benefit to young doctor in developing country who now have access to a grand medical library in their hands.

I am especially interested in this very dynamic because it is one pillar propping my next project on psychiatric survivors, which exceeds the particular topic of challenges to psychiatry in its general focus on medical/patient reconfigurations following from Intent-based activism, self-help, diagnosis, and critique. And for those who think I have made a radical departure from my last project, here is where I see one (of two or three) threads of continuity: for patients are generating an enormous amount of amateur knowledge, that I think is not unlike the peer-to-peer production of software hacking, and it is a form labor usually accompanied by a strong critique of expertise and other medical practices. I am now reading some literature on patient activism, like the issue from the February 2006 in Social Science and Medicine that collects 11 articles on patient organization movements. For those who work on this topic, the collection is worth your while and the editorial introduction by Kyra Landzelius is stellar. It is not only written beautifully (which I think is rare for these openings because it is often a rote, unimaginative regurgitation but this was a pleasure to read) but provides an engrossing overview of some new trends and some of the diverging forms of politics that arise from what is really a motley bunch of organizations and contests in patient and anti-patient activsm. She opens by defining four spheres that shape and inform the forms of contents that are part and parcel of these patient movements, the four being: 1. Revolutionary feats in technoscientific engineering
2. Restructuring of healthcare systems across industrialized nations
3. A Revised contract between science and the public stemming from a criss of confidence in science
4. An upsurge in the articulation and diversification of health activisms (p. 530) These four are key but I was shocked that there was no specific inclusion—though it comes out plenty in the introduction in other ways of the Internet. For while I am no techno-determinist, the Internet I think, can’t be ignored for it has fundamentally changed the map and tenor of patient activism, allowing for more rapid connections between various stakeholders, providing a medium by which those officially unrecognized illnesses are given shape and form, and where an ethical cultivation of self-help, self-diagnosis, self-medication, along with copious critique and forging of alternatives is happening, right before our eyes, virtually in real time. It is the medium by which a new chapter of patient activism is being written and I think it is a real mistake not to give it serious attention and credit. And perhaps one of the most interesting things about it is that it without it, it would leave many otherwise home-bound, sick folks, without a medium by which to engage in political activity or even community self-help, for let’s face it, these take a lot time and energy. When you are sick and home-bound, for example, there may be a limited number of types of engagements you literally have the energy to partiicpate in and the Internet lowers the barrier of political entry because of its ease and because you can still type away, even when feeling otherwise totally awful… This may be a brute material point but nonetheless, key to understanding the political power of the Internet. Now of course the question left is will Google capitalize on this and create “Google Diagnosis”?

We're back in Montreal again after more than two weeks in San Francisco. It was great being in the Bay Area, especially since this time of year in Montreal is kind of crappy. Cold rain knocks all the red-yellow-orange leaves off the trees and into the gutter, where they turn brown and gray. Everything's damp and muddy and icy, but there's no snow yet. Blech. Our friend John Usher stayed at our apartment while we were gone, which was great for us since he watched our cats. We had our regular Friday Night Pizza together last night at 9PM, after a very long day in the plane. Traveling eastward is hard on the sense of time. But pizza night made it a little better. We went up to Le Comptoir on rue Masson this morning for breakfast. It's a nice little place that you can always get into, regardless of the time of day (like, say, if you try going out for brunch at 11:30 on a Saturday...). The menu is a little too much in the Montreal Kitchen Sink style (10+ pages of every kind of food under the sun), but the b n dictines are good, they have mimosas, and they serve caf au lait in big bowls. So what's not to like? John rented a new apartment in Old Montreal while we were away. He's been a vagabond since early this summer when he left McGill and went back to his hometown of Beer in Devon. His new place is great -- 2000 ft top-floor loft around the corner from Basilisque Notre Dame. I plan to abuse his hospitality and throw big parties in his home, if I can get away with it. One nice thing is that he found the place on Montreal Craigslist. I think that's a pretty good sign that CL in MTL is becoming worth using, although they still don't have an interface in French. I don't know how you get away with an non-localized international Web site in 2006. tags: montreal john usher le comptoir old montreal craigslist i18n

Web 2.0 Summit Wrap-up LinuxWorld.com published my article on Day 1 of the Web 2.0 Conference, which I have to say I think is pretty OK good. I had originally written a gossipy article about who was where and who announced what and what it meant for Linux users and the Open Source community. Don Marti, who edited the article, didn't like it. He told me to identify the key technologies mentioned at the conference that people could actually use and should know about, and write more about them. So I did, and I think the article is much better for it. Days 2 and 3 of the conference coverage come out next week. I really liked writing about the Web 2.0 Summit; it gave me a chance to talk to people in-depth about their work. I didn't draw as much out of the conference itself as I would have liked, but by working press on it, I had to find stuff that interested me and communicate that interest. Which made it fun. tags: linuxworld.com web2con don marti web 2.0

Que Rico I'm pretty psyched that planning for next spring's Wikitravel Get-together 2007 is going so well. The Get-together (despite my finest effort, this seems to be the final name for the event) will be a convocation of Wikitravellers from all over the world on one spot to meet, talk about issues, but most of all, travel. Our chosen destination for this year's event is Puerto Rico (the product of a months-long selection process, with two rounds of voting). Our coverage of PR in English Wikitravel is sub-optimal, and we hope that by bringing a bunch of wiki people to the island for a week to hang out and explore, we can greatly improve the travel guide for this big area. Participants will be doing research before the event (April 14-22 2007) to determine those parts of the island that need better first-hand coverage. Then, we'll convene in San Juan (Puerto Rico) for a weekend before spreading out to cover the rest of the island. We'll meet back up in SJ the next weekend for some discussions and meetings before flying off to our respective homes. It should be a really fun trip -- I've never been to the Caribbean at all, and I think PR sounds like a really amazing place to visit. And I think this style of meetup for Wikitravellers could be super-fun for future events; it will be cool to see how this one goes. tags: wikitravel get-together puerto rico san juan

Poppies One endearing custom in Canada for Remembrance Day is wearing small, red poppies on one's lapel, evoking the classic Canadian poem ''In Flanders Fields''. It's a beautiful tradition, but hard to watch a bit on this day in 2006, when Canadian soldiers are being killed not in Ypres, but in Kandahar by, among others, heroin drug-lords, for whom poppies have other meanings. tags: poppies in flanders fields remembrance day canada afghanistan

Antiamericanism is a more and more widespread feeling, not only in eastern countries, but also here in Europe. Despite all the admiration for the achievements of americans throughout history, I have to confess that I increasingly share that feeling. (I've blogged about the USA before, so you probably already know this.) Most recently:

Es h ufen sich Klagen von Gesch ftsreisenden ber Zollbeamte, die Daten auf Mobilcomputern einsehen wollen. [ ] Regierungsbeamte haben das Recht, nicht nur das Reisegep ck, sondern auch elektronische Datentr ger zu durchsuchen. W hrend es konkreter Verdachtsmomente und einer richterlichen Anordnung bedarf, damit Beamte private E-Mails oder vertrauliche Computerdateien lesen d rfen, [haben] Z llner das Recht, die Computer auch unverd chtiger Reisender ohne Angabe von Gr nden zu durchsuchen oder gar zu konfiszieren. [Neue Z rcher Zeitung, 10.11.2006, edited]

(Complaints of business travelers about customs officers, who want to investigate data on mobile computers are accumulating. [ ] Government officials have the right, to search not only the luggage, but also electronic Data media. While specific suspiciouns and judicial orders are required, for governement officials to read private emails or confidential computer files, customs officers have the right, to scan or even confiscate computers of any traveler without giving any reasons.) This is not complaining about travel to China, Africa, Belorussia or whatever, but is a warning issued by the Association of Corporate Travel Executives about crossing the U.S. border. The ACTE is, by the way, an international organisation based in the U.S.A., so they should know.

My post about securing an office received many comments, so many that I had to write another blog entry to respond to them and also add some other things I didn't think of before.

One suggestion was to use pam_usb to store passwords on a USB device. It sounds like it's worth considering, but really we need public key encryption. I don't want to have a USB device full of keys, I want a USB device that runs GPG and can decrypt data on demand - the data it decrypts could be a key to unlock an entire filesystem. One thing to note is that USB 2.0 has a bandwidth of 30MB/s while the IDE hard drive in my Thinkpad can sustain 38MB/s reads (at the start - it would be slower near the end). This means that I would approximately halve the throughput on large IOs by sending all the data to a USB device for encryption or decryption. Given that such bulk IO is rare this is feasible. There are a number of devices on the market that support public-key encryption, I would be surprised if any of them can deliver the performance required to encrypt all the data on a hard drive. But this will happen eventually.

Bill made a really good point about firewire. I had considered mentioning it in my post but refrained due to a lack of knowledge of the technology (it's something that I would disable on my own machines but in the past I couldn't recommend that others disable without more information). Could someone please describe precisely which 1394 (AKA Firewire) modules should be disabled for a secure system? If you don't need Firewire then it's probably best to just disable it entirely.

To enable encryption in Fedora Core 6 you need something like the following in /etc/crypttab:

home_crypt /dev/hdaX /path/to/key
swap /dev/hdaX /dev/random swap

Debian uses the same format for /etc/crypttab.

The Peregrine blog entry in response to my entry made some really good points. I wasn't aware of what SUSE had done as I haven't done much with SUSE in the past. I'm currently being paid to do some SUSE work so I will learn more about what SUSE offers, but given the SUSE/MS deal I'm unlikely to use it when I don't have to. Before anyone asks, I don't work for SUSE and given what they have just done I will have to reject any offer of employment that might come from them.

I had forgotten about rsh and telnet. Surely those protocols are dead now? I use telnet as a convenient TCP server test tool (netcat isn't installed on all machines) and never use rsh. But Lamont was correct to mention them as there may be some people still doing such things.

The Peregrine blog made an interesting point about Kerberised NFS being encrypted, I wasn't aware of this and I will have to investigate it. I haven't used Kerberos in the past because most networks I work on don't have a central list of accounts, and often there is no one trusted host.

I strongly disagree with the comment about iSCSI and AoE "Neither protocol provides security mechanisms, which is a good thing. If they did, the additional overhead would affect their performance". Lack of security mechanisms allows replay attacks. For example if an attacker compromises a non-root account on a machine that uses such a protocol for it's root filesystem, the victim might change their password but the attacker could change the data back to it's original values even it if was encrypted. Encryption needs to have sequence numbers embedded to be effective, this is well known - the current dmcrypt code (used by cryptsetup) encrypts each block with the block ID number so that blocks can not be re-arranged by someone who can't decrypt them (a weakness of some earlier disk encryption systems). When block encryption is extended to a network storage system I believe that the block ID number needs to be used as well as a sequence ID number to prevent reordering of requests. CPU performance has been increasing more rapidly than hard drive performance for a long time. Some fairly expensive SAN hardware is limited to 40MB/s (I won't name the vendor here but please note that it's not a company that I have worked for), while there is faster SAN hardware out there I think it's reasonable to consider 40MB/s as adequate IO performance. A quick test indicates that the 1.7GHz Pentium-M CPU in my Thinkpad can decrypt data at a rate of 23MB/s. So to get reasonable speed with encryption from a SAN you might require a CPU which is twice as fast as in my Thinkpad for every client (which means most desktop machines sold for the last two years and probably all new laptops now other than the OLPC machine). You would also require a significant amount of CPU power at the server if multiple clients were to sustain such speeds. This might be justification for making encryption optional or for having faster (and therefore less effective) algorithms as an option.

I believe that the lack of built-in security in the AoE and iSCSI protocols gives a significant weakness to the security of the system which can't be fully addressed. The CPU requirements for such encryption can be met with current hardware even when using a strong algorithm such as AES. There are iSCSI accellerator cards being developed, such cards could also have built in encryption if there was a standard algorithm. This would allow good performance on both the client and the server without requiring the main CPU.

Finally the Peregrine blog entry recommended Counterpane. Bruce Schneier is possibly the most widely respected computer security expert. Everything he does is good. I didn't mention his company in my previous post because it was aimed at people who are on a strict budget. I didn't bother mentioning any item that requires much money, and I don't expect Counterpane to be cheap.

Simon noted that developing a clear threat model is the first step. This is absolutely correct, however most organizations don't have any real idea. When advising such organizations I usually just invent a few possible ways that someone with the same resources and knowledge as I might attack them and ask whether such threats seem reasonable, generally they agree that such things should be prevented and I give further advice based on that. It's not ideal, but advising clients who don't know what they want will never give an ideal result.

One thing that I forgot to mention is the fact that good security relies on something you have as well as something you know. For logging in it's ideal to use a hardware security token. RSA sells tokens that display a pseudo-random number every minute, the server knows the algorithm used to generate the numbers and can verify that the number entered was generated in the last minute or two. Such tokens are sold at low prices to large corporations (I can't quote prices, but one of my clients had prices that made them affordable for securing home networks), I will have to discover what their prices are to small companies and individuals (I have applied to evaluate the RSA hardware). Another option is a GPG smart-card, I already have a GPG card and just need to get a reader (this has been on my to-do list for a while). The GPG card has the advantage of being based on free software.

One thing I have believed for some time is that Debian should issue such tokens to all developers, I'm sure that purchasing ~1200 tokens would get a good price for Debian and the security benefits are worth it. The use of such tokens might have prevented the Debian server crack of 2003 or the Debian server crack of 2006. The Free Software Foundation Fellowship of Europe issues GPG cards to it's members, incidentally the FSFE is a worthy organisation that I am considering joining.

There are basically two kinds of setups for mailing lists managed using Mailman, regarding posts from non-members :

• Accept posts from non-members. This lead to quite a lot of spam on the list, but also to no work for the moderators.
• Put posts from non-members in a moderation queue. This result in a spam-free mailing list, but also in a lot of work for moderators, and in posts delayed for days.

It would be great if Mailman could ask the sender for confirmation (either email-based or web-based) before accepting the mail or putting it in the moderation queue. This would greatly reduce the amount of spam on the list or in the moderation queue. This is also known as Mailman feature request #673265. A similar feature has apparently been in Sympa for nearly 4 years.

I was in a discussion about flash on a closed mailing list, so I'll post my comments here.

I believe that flash will soon be suitable for main storage on most desktop and laptop machines (which means replacing the vast majority of the hard drive market). Flash survives mechanical wear much better than hard drives (flash storage in a camera will usually survive the destruction of the camera), it produces less heat and less noise, and it has better seek times. It is more expensive, although the price is coming down and the main problem now is the number of writes that can be made.

Flash is widely regarded as being slow for bulk IO (benchmark results I have seen approach 10MB/s - while 60MB/s is common for cheap desktop IDE disks). I am not sure how much of this is inherent to flash technology and how much is due to the interface used to access the flash. I often work with Gig-E networks, but for my home use I only have 100baseT, so I have little need for more than 10MB/s IO rates at home.

It is generally regarded that a sector of flash storage wears out at between 10,000 and 1,000,000 writes depending on how recent the hardware is and who you talk to (some vendors are more optimistic than others regarding the usable life of their devices).

Let's assume that you have a 32G flash module running JFFS2 with an average of 2G free (30G of long-term data that doesn't change and 2G of space that is used for new files). Let's assume that the most pessimistic prediction for flash reliability of 10,000 writes happens to be correct. So if 10,000 writes are to be made to that 2G of space that means 20T of data written! If we assume that the machine will be obsolete in 5 years then that allows us an average of just over 10G of data written per day (20,000/365/5=10.9). On my laptop iostat reports the following after 5 days of uptime:

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
hda               1.94         9.94        20.33    4614118    9439808

I believe that this means an average of 20 blocks were written per second over the last 5 days with a block size of 4K (page size), this means 6.6G per day. Clearly something is wrong with my laptop as there should not be so many writes, but even so I wouldn't expect it to wear out within 5 years if I used only flash storage. Incidentally I do a lot of travelling and generally find that I'm lucky if a laptop hard drive lasts three years. So I could expect flash to last longer than a hard drive for my laptop use.

When flash fails I believe that only a small part of the data will be lost, which is better than the hard drive failure condition which is often to lose everything!

Also there is nothing preventing you from creating a RAID-1 of flash devices. Last time I checked the JFFS2 kernel code didn't support such things but that could be fixed if there was suitable hardware.

Note that JFFS2 is vastly preferable to using Ext3 or similar filesystems on a flash device. Flash needs wear-levelling (spreading the write load over all parts of the disk) for sane operation. JFFS2 has this built in to the filesystem, while Ext3 etc are designed to repeatedly write the same parts of the disk. This means that to use Ext3 you need a mapping layer that does wear-levelling which causes inefficiency. Also JFFS2 has compression built in (same method as gzip). This is good for smaller flash devices (EG the 32M storage that was common in iPaQs), and also reduces the wear on larger storage.

The biggest problem for me in using flash at the moment is the lack of support for XATTRs (needed for SE Linux) in JFFS2. KaiGai Kohei has been working on this, it's been a while since I checked on the progress so I'm not sure if it's got into the kernel.org repository yet.

Another problem with flash is that it is totally unsuitable for use as a swap device. This means that you need to have so much RAM that swap is not needed. Fortunately desktop machines with 2G of RAM are becoming common.

I finally got myself a nice digital camera. Nice as in, it fits in a pocket, it takes reasonably good-looking pictures, ant it's not a Canon so I can access it as an USB mass storage device. (For those who care, it's a Kyocera/Contax U4R.) So I've started using F-Spot (which is tremendously cool) and Gallery a bit more intensively than previously, and I noticed something curious: my pictures had wrong times. I thought that digital cameras stored them inside the picture files... Hmm. On to investigate. Time passes as I follow the threads of the information flow (use the source, Luke). Then I scream in horror. Then I go see something I hope is authoritative and therefore likely to have been well thought-out (read the spec, Luke). Then I scream some more. Let it be widely known that the Exif specification, which is the standard for embedding metadata into image files from digital cameras, encodes the date and time of the picture as a string. A fat, ugly, 20-character string. More precisely, the format is YYYY:MM:DD HH:MM:SS. I don't have anything against strings, they are rather easy to parse by humans (as demonstrated by strings /home/roland/images/photos/contax-u4r/kicx0700.jpg head). But they should be done right. In this case, it would have made a lot of sense to enlarge that string to 26 characters and add +ZZZZ or something similar. So as to be able to encode, say, a timezone, for instance, in order to, say, have dates and times that actually mean something, instead of something that may or may not be the current time plus or minus a random number of hours and minutes. I thought I could cheat by starting F-Spot with TZ=UTC f-spot (among my electronic gadgets, those that can't cope with timezones are set to UTC, with the exception of my alarm clock). The result is bizarre: the date is shown as being one hour late. I could understand if it were two (I'm at UTC+2 these days), but where does that one come from? I suppose I'll have to cheat differently, by keeping a patched version of F-Spot that interprets the TimeDate data from Exif as UTC, instead of using the current timezone. Or maybe I could do that in my hotplug script: it already rsyncs images from the digicam to the harddisk then makes sure the digicam's memory has at least $foo megabytes of free space on the card memory. I suppose it could also fiddle with the Exif tags on the fly. Anyway. People need to learn: text without encoding information is useless, cryptography without a web of trust is useless, and date/times without timezone info is useless. If one of my esteemed readers happens to be (or know) a member of the Exif specification group (I understand it's called "JEITA"), please tell them that this needs to be fixed in a future version of the spec. I suppose I'll have to live with it with my current digicam, but maybe the next one will be better in that regard. The pictures themselves are nice, though.