No Such Weblog

I just trackback-spammed another weblog, inadvertently: Movable Type believed the ping was unsuccessful when it had been successful, and trackback autodiscovery kept adding the URL to the list of sites to be pinged. I've now turned off track-back autodiscovery.

Feature wish for Movable Type: Dedupe trackback pings.

We spent quite some time today tracking down an obscure Linux problem: With the commonly-used user space NFS daemon, quota doesn't seem to propagate over NFS. In theory, quota is enforced on the server-side.

We think we have found the bug; it's in the 2.4 kernel (but we couldn't test that, yet): The user space NFS daemon runs as root, and protects system calls that affect the file system by calling setfsuid(2) in order to drop privileges. setfsuid(2) to a non-root user will clear all capability bits in CAP_FS_MASK. The CAP_SYS_RESOURCE bit (1 << 24) is not included in that mask, and it controls (besides no less than 7 actual capabilities) whether or not quota is enforced.

It's amazing how the complexity introduced by the capability system leads to new bugs, instead of increasing system security.

One of the more interesting slashdot stories of the week-end dealt with the suspected relationship between the sobig worms and the recent series of denial of service attacks against various spam-blocking services.

The slashdot item was triggered by this article from the register; in a comment, Kristian Köhntopp points to some interesting analysis of the various Sobig variants.

Memo to anyone who ever sets up a mailing list: Never, ever let the envelope sender for list messages point back to the list.

Princeton University Computer Science Technical Report TR 679-03 by John Halderman (discussion at Ed Felten's Freedom To Tinker) dissects a CD copy protection scheme by Sunncomm Technologies that is based on Windows' and MacOS X's autorun features: When you insert a protected CD into a computer, drivers are installed that give access to DRM-protected versions of the CD's content, and interfere with attempts to access the CD's audio tracks.

The scheme can be "broken" by disabling these drivers, or by turning off autorun. Also, the scheme is completely ineffective when Linux or MacOS 9 is run.

SunnComm has now threatened to sue the technical report's author for violation of the Digital Millennium Copyright Act.

EFF press release.

Later: Reactions, summarized by Donna Wentworth.
Still later: Sunncomm says it won't sue Halderman.

Discussion on how to block blog spam is going on over at Feedster.

Here's one thing I found remarkable about the comment spam I got so far: Every single notification e-mail MT sent me about such comments was caught by spamassassin. The best way to attack this is probably by not reinventing the wheel, but marrying e-mail anti-spam tools with blogging software. Could be as easy as turning a comment into a fake e-mail message and handing that off to spamd before you accept a comment.

Also, the blog world might wish have a look at some of the other lessons learned by the e-mail antispamming community. One of these: When there is a central point of failure that can make many spam filters fail at the same time (like a block list), then that service is attacked until it's unavailable.

Habeas attempts to fight spam with haikus: The theory is that whoever puts a habeas header into e-mail without having received a license gets sued by the corporation. Unfortunately, most of the spam that currently gets past my spam filter has the magical haiku -- and, even worse, is autolearned as "ham" by spamassassin.

score HABEAS_SWE -1.0

It seems that some criminal is using my e-mail address, roessler@does-not-exist.org, as a sender address for (so far) body-part enlargement spam; typically, my address shows up both as the envelope sender, and in the From header of the messages in question. I'm, of course, not involved with that -- I'm just getting the bounces.

Things are, so far, on a much smaller scale than what happened to others, but it's still annoying. I'm not planning to change either my domain name, or my e-mail address; bounce messages that were not generated in response to messages I sent are discarded automatically.

The latest worm (called Novarg.a, Mydoom, or MIMAIL_R) is big news all over the place; technical analysis here and here and later here. In a nutshell, the virus uses tech babble as its social engineeering trick, claiming that some message couldn't be transported and had to be wrapped into an attachment. Once people fall for that trick (and amazingly many seem to do that), MyDoom apparently installs a key stroke logger and a network backdoor, and prepares to launch a DoS attack on sco.com.

Being armed with good filters, a mail client I trust, and an operating system that won't run Windows viruses, I normally consider e-mail virus outbreaks as part of the general noise that gets thrown away automatically.

So, what makes this one special and worth a blog item? First, it has a new approach to social engineering. No more sex and crime (we recently had a relatively successful worm here which claimed -- in German -- that the recipient had been indicted for file sharing), but dry tech babble instead. And that approach works surprisingly well, leading to bombardment rates and bandwidth consumption last reached by Sobig.F last summer.

Also, the large scale of this outbreak makes it interesting to look at e-mail statistics again. I received the first instance at roughly 9pm CET, that's 3pm EST. Within just an hour, the bombardment peaked at several pieces of the virus per minute; fortunately (and somewhat surprisingly) much of this was caught by spamassassin. The virus scanner I'm also running kicked in at about 1 am, and has been catching the actual virus traffic since. Junk background noise is still far above the usual numbers, mostly due to bounce messages generated in response to viruses sent out with my e-mail address as the sender.

What are the lessons? First, hardly news, but still worth repeating: Virus scanners don't prevent infections, and -- even when updated within hours -- leave a huge window of opportunity for spreading a virus. Second, considerable annoyance is caused by virus scanning systems that still believe that they need to notify a message's alleged sender of infections. Third, spamassassin's heuristics prove surprisingly effective against much of the incoming virus flood.

As a follow-up to Tuesday's notes on Novarg, some MRTG plots that illustrate what happened in my inbox this week. The blue curve is legitimate mail; green is spam (and other junk), or recognized virulent material.

First, spam (and other junk that's automatically recognized). Note the peak on Monday evening, when Novarg first appears, and also the substantially higher junk bandwidth ever since -- due to notifications about the worm:

Second, recognized viruses (getting really interesting later in the same night):

If you want to compare the effect to Sobig.F, here's a similar plot showing Sobig's last days.

Spammers cause ever new embarassments. This week-end, we were visiting my parents. Thanks to Apple's excellent OS X, they are reasonably comfortable with their computer (well, mostly) which mostly serves as a repository for digital photography, and for exchanging e-mail and instant messages with me. Fortunately, their e-mail addresses haven't made it onto any spammers' lists, yet. You can probably imagine my surprise when I was suddenly questioned about some porn they had recently found in their inbox. The solution: This wasn't porn addressed to them, but a bounce message. Some spammer had, apparently, guessed my father's e-mail address (<first name>@does-not-exist.org; the first name isn't that rare), and had been using it as the sender's address for obscene spam. That spam hadn't reached the intended recipient, though, but my parents. No, I'm not suggesting that "adult content", "obscenity", or whatever you want to call it be banned online. But I don't want to be asked by my parents where that porn in their inbox comes from, either.

In more pleasant news on the spam front, Wired reports that Dutch police have arrested 52 people suspected of being involved with Nigerian scam schemes.

Seems like someone complained to the bugtraq moderators about this message, claiming that it was spam, presumably abusing my e-mail address. Of course, the message was indeed legitimate, it was indeed sent by me, and it was not fake.

After last night's blog spam attack has painfully exposed the lack of rate limiting in the version of movable type that I was using (and the lack of resource limits on my web server), I've gotten a little paranoic about my web server logs. One particularly remarkable feature that only seems to show up quite recently consists in "random" user-agent strings; there are numerous queries of this kind from a relatively small number of IP addresses, apparently DSL-connected machines.

It's relatively obvious that some kind of robot is behind this -- does anyone have an idea what's going on here, or does this sound familiar in any way?

Later: Things should be somewhat more robust now. Resource limits are in place, the back-end has moved to MySQL, and blog items are automatically closed for comment after seven days.

First, as an all-time favorite, most corkscrews. The classical waiter's knife with corkscrew is about the best thing you can get (and you can get it much cheaper than Google's first hit for "sommelier knife"!), but that does not keep suppliers from flooding the marketplace with useless alternatives that usually tear the cork apart, or leave cork rests in the wine. The one on the photograph is kept for educational purposes only.

Second, a recently-discovered stupidity, Samsonite's Malaga travel bag. This bag comes with a small padlock (the same lock and key is used for all Samsonite products, it seems, but then again, this lock does not even try to look like it offers serious protection), a more robust combination lock, and a back zipper which can't be locked, and gives easy access to the bag's main compartment.

Third, the keyboard in my trusty Dell laptop. A critical part of the mechanism is a relatively thin piece of tin that must be bent in the right way -- and, of course, is distorted over time, with all kinds of not so funny effects on my typing habits. The distortion effect is particularly strong with the shift and control keys, but can fortunately be fixed with a little bit of tinkering. The stupid assumption, though, that tin doesn't exhibit unelastic distortions, seems to have been commonplace in Dell hardware design for quite some time. I still remember some "workstations" which provided comfortable access to the PCI bus, but required re-bending some critical tin parts after the third exchange of a faulty PCI card.

I'm now sitting at Munich airport, using Vodafone's hot-spot here. 30 minutes Internet access cost me about 4 Euros (1,300 Star Alliance miles would have been the alternative -- quite a price tag) -- and several minutes for figuring out how to deal with the billing system that Vodafone put in place here. The system works by submitting credit card information through a web form, and then receiving a PIN through SMS on a mobile phone.

For the customer, this system brings a large number of disadvantages over an open WLAN network; also, it's unaccessible for anyone but subscribers of a few domestic mobile phone operators. What's so difficult about providing free and open WLAN access as a commodity that just works when you neeed it?

Later: It fits into the picture that the e-mail receipt arrives two days later and consists of a PDF file that's tagged as plain text.

Take an Apple Macintosh bought in Europe. Insert a European-bought DVD for the first time. The DVD drive is encoded for region 1. The DVD is region 2. You can change the drive's region code 4 more times. Enter your password to change the drive's region code.

Why, precisely, is this kind of hassle necessary, again? And why, precisely, is it that this particular industry can't leave its consumers alone with the products they have bought, but always finds another way to harass them?

Trying to be a good network citizen, I tend to make sure that I report ongoing fraud attempts and phishing expeditions that make it into my inbox. Today, two messages posing as eBay, and trying to get eBay login information and credit card information; the server used runs on a DSL line in Latin America. The fake was obvious since I'm a member of eBay Germany (and they talk German to me, not English) -- still, it's a bad thing, others may fall for it, and (unlike myself) eBay has the incentives, means, and resources to make sure the proper investigations are launched, and measures are taken to shut this down.

On to ebay.de we go. After about 5-10 pointless pages, a web form. The e-mail message and relevant log file entries are cut and pasted, the "submit" button is clicked -- and then I'm just told that my message can't be accepted.

The only other means of contact: A 0900-* phone number at 59 Euro Cents per minute -- and then, all you get is a pointer to <spoof (at) ebay.de>, by e-mail, after you have expensively spelt your e-mail address to the customer services representative.

Why isn't <spoof (at) ebay.de> featured prominently on their web site? Why are they bothering people with web forms when they have to forward the messages in question by e-mail anyway? Why do I have to spend several minutes on the phone before I get the necessary e-mail address? Why do I have to pay for that, at rates an order of magnitude more expensive than international calls?

Today, (presumably) the second instance of Mahler's Beethoven's 9th arrived here. It's the first one I ordered, also at Amazon marketplace. That particular merchant first sent a confirmation for the wrong CD, and -- upon my complaint -- notified me that the CD was not available; the money was returned. Two weeks later -- I had now ordered elsewhere, and their delivery was underway --, I received a "status message". I responded that I considered the contract voided by the merchant, and would return any delivery from them. No response.

Today, a shipping confirmation was in my e-mail, and another CD in my physical mailbox. This particular merchant will now have to pay the return postage back to them.

Oh, just in case you're wondering: I'm talking about www.germanmusicexpress.com.

The absurdities and chilling effects of today's intellectual property environment: Let's assume you buy a CD (say, "feels like home" by Norah Jones) online, but it turns out to be a non-CD that you can't listen to (you missed the fine print). Let's assume you rip it on some old PC, and then copy the MP3s to your laptop -- so you can actually listen to the music you paid for. Because the technology put in place by the control freaks at IFPI is much more effective at keeping people from playing the music (in particular on modern devices) than it is at keeping them from copying it.

Just assume all this. Could you do and blog it, without risking legal trouble? Could you discuss the software you used for ripping the CD?

To stay out of this kind of questions, stay away from copy-controlled CDs. Also, spend at least as much money on funding the excellent people at EFF as you spend on funding an incredibly arrogant cartel that happily takes your money, but delivers crap.

WLAN is insecure, and should be secured by adding a VPN as an additional layer of security, says conventional wisdom. An approach that's still being deployed uses pre-shared keys for ISAKMP phase 1, and XAUTH in phase 2.

As has been pointed out by others before, these setups are inherently insecure: Any party with access to the IPSec shared "secret" (often found on public web servers) can impersonate the VPN gateway; clients will happily supply the fake gateway with login credentials. Frequently, these are persistent passwords that can also be used to access anything else in the networks affected.

Theoretically, the easiest exploit of this kind of problem consists in setting up an access point and a machine that runs a DHCP server and an off-the-shelf ISAKMP/IKE daemon which doesn't really do XAUTH, but just records passwords. This isn't a real MITM attack -- but then again, the credentials one can reap are considerably more valuable than the additional data that one could get by doing a true MITM, so even this straight-forward reference attack can do considerable damage. (Think about some thousand Kerberos passwords.)

Unfortunately, it turns out that this theoretical attack fails due to (1) idiosyncrasies of the CISCO VPN client (bad packet lengths), and (2) due to the fact that none of the easily available open source IPSEC implementations appear to implement both XAUTH and ISAKMP's aggressive exchange (which seems to be typically used by the CISCO client, and is always used by vpnc) -- openswan-1 may be an exception to this, but I wasn't able to get it to run here. I can only speculate that the lack of availability of a ready-to-use attack tool contributes to the continued deployment of this kind of systems.

Still, it is relatively easy to implement the simple attack: vpnc comes with all the library routines one needs to comfortably manipulate ISAKMP packets. Starting from vpnc, implementing a simple ISAKMP responder that takes the client through phase 1 and obtains credentials in phase 2 is a matter of a couple of hours on a lazy holiday.

The message here is that the attacks against pre-shared key networks with XAUTH are anything but academic or difficult: Implementation is easy. I would be extremely surprised if no implementations were floating around in black-hat circles. It will only be a matter of time before one of these programs becomes readily available.

One of the ever-returning topics in computer security fora looks at "full disclosure": Is it ethical to release tools that exploit a security vulnerability? Is it ethical to release information that makes it trivial to produce an exploit? One side of the argument basically says that it's not ethical because releasing exploits doesn't add anything for the white-hat consumer of the news, but makes attacks easy for script kiddies. The other side of the argument often talks about suppliers who don't move swiftly to fix problems unless an exploit is known and publicly available. This side of the argument also notes that it's often not possible to describe a fix without making an exploit obvious.

There is another angle to this, though: Where vulnerabilities are due to design issues, and workarounds are expensive, unavailability of public exploits may lead to continued deployment of insecure setups, despite awareness that security design is flawed. Of course, it's a dangerous assumption to conclude that just because there is no publicly available exploit, possible attackers aren't able to get access to a private one.

"Hi, you realize that your recently-deployed WLAN+VPN setup can be used to steal user names and passwords, possibly on a massive scale?" -- "Well, yeah, we knew about the vulnerability, but it didn't look like it's easily exploitable, and after all, there are no exploits out there." -- "It's extremely easy to exploit. Look, here's how it goes, and yes, I have the software I need to do this. Want a demo?" -- "duh. But we'd be interesting to learn about secure setups."

I wonder, can it be unethical to keep an exploit to a well-known security weakness private?

... then you are probably using a commercial hot-spot, or maybe someone has tried to provide some "security."

The last couple of days gave me a chance to experience a variety of Wi-Fi setups. Besides the generally working open conference network at WOS (hidden behind a NAT box, of course), there were the insecure, but cumbersome security mechanisms at TU-Berlin (ultimately circumvented for many people in the room by setting up a laptop as a router between an ad-hoc open network and the official Internet access), and airport Wi-Fi at CGN and TXL.

CGN is in T-Mobile's hands. The design of the payment process looked reasonable, at least as long as you are a T-Com or T-Mobile subscriber. Random 404 errors and wrong host names in SSL certificates (hotspot.t-mobile.net vs. hot-spot.t-mobile.net) pointed towards a rather unprofessional implementation, though.

(The Vodafone setup in MUC about which I ranted in March had a more cumbersome billing design, but was implemented better.)

TXL (where the photo was taken this morning) is more open to a number of wireless providers. Access points are shared between providers; users are then supposed to pick providers from some web page. When trying to go further than that, I got inconsistent and irreproducible behavior, including 404 messages, transparent proxies complaining, and timeouts. The "wlan-zone" was useless for me.

Open and free Wi-Fi should be a convenience at airports -- spending the waiting time attempting to debug a network is not a productive activity at all.

From Apple's Tiger Preview - Safari RSS page:

Safari protects your personal information on shared or public Macs when surfing the Web. Go ahead and check your bank account and .Mac email at the library or shop for birthday presents on the family Mac. Using Safari’s new privacy feature, no information about where you visit on the Web, personal information you enter or pages you visit are saved or cached. It’s as if you were never there.

Who guarantees that the Safari you see on that public computer hasn't been changed? Who guarantees that there are no programs which sniff the keyboard, and the screen? Who guarantees that no hidden cameras are hidden in strategic places?

Privacy features in some particular piece of software don't mean that software is running in a trustworthy environment. Suggesting that users perform sensitive activities (such as banking) in untrusted environments, using untrusted computers, is terribly bad advice.

I finally had to get myself a tri-band mobile phone -- goodbye to my trusty and robust ME45 which will enter history as the perfect mobile phone with just one frequency band too few. While browsing the manual of the successor, I noticed a full page of legal caveats related to using WAP. Most importantly, I'm told, any repair or exchange of the new device is likely to erase everything I've downloaded, so I should better keep backup copies on a PC. Siemens takes no liability for this.

However, I'm told, the new mobile comes with DRM technology included, so I may just be unable to make any copies at all of DRM protected content that I've downloaded through WAP, not even for backup purposes. And they don't make any representations (and don't take any liability) that I'll be able to get the same for-pay content again.

So I'm supposed to pay for stupid ringtones and wallpapers that I'm going to lose when I switch to the next mobile phone, and that I'm going to lose if I have to turn in this one for repair? I'm supposed to pay for crippled content when there's a wealth of MIDI files available online freely, and when creating a wallpaper is as easy as firing up Gimp and creating a small JPG that's then transferred to the phone with obexftp?

Building a business model on customers' stupidity looks like a bad idea to me.

Then you must be joking -- or so, T-Mobile seems to believe.

Playing around with my new mobile phone a little more, I attempted to send an MMS (a multimedia message sent from a mobile phone) to a mobile phone in Luxembourg. First surprise, the phone launches GPRS in order to send the message -- it seems this is actually an Internet-based service. Second surprise, the recipient didn't get the image she was supposed to get, but instead an SMS telling her at what URL she could view the MMS that had been sent to her.

I'm amazed ever again by the unflexibility often found in so-called "intelligent" network designs, and amused by the fact that smart services deployed there have to resort to the well-functioning "stupid" Internet under the hood. (But at least they have DRM (specifications here), so the controlled, intelligent mobile phone networks must be a much better environment for commerce than that stupid, uncontrolled Internet thing is, don't you think?)

Related reading elsewhere: Decentralization and Commodification, Cell phone user rights considered harmful.

I'm sitting at Boston's Logan airport's Terminal E, and have been sitting here for too many hours now: My flight back across the Atlantic, NW 38, is delayed by no less than five hours. At check-in (where they could not accept checked luggage for the moment, because the transport tape was broken), I was told that the flight would be delayed by one hour, and would be operated by a KLM 747 instead the scheduled NW DC-10. Boarding passess were issued for the 747, of course. At the scheduled time of departure, we were told that, unfortunately, they had no crew for that KLM 747 waiting at the gate. Now, nine out of ten crew members are allegedly here, and (breaking news) a DC-10 has landed.

By courtesy of NW's unfriendly and arrogant personnel (what's a five-hour delay for a six-hour flight, after all?), passengers were offered $10 in food vouchers as consolation for making an already-unpleasant red-eye even worse. Non-McDonalds dinner around here costs $20.

Later, from Schiphol: NW 38 arrived in Amsterdam 6 hours late. KLM distributed 10¤ food vouchers and a 50¤ voucher to be used for future KLM flights (as if). They weren't even willing to exchange that voucher for lounge access, which is worth 45¤. "Lounges are not intended for service recovery." The story behind the delay appears to be that the originally-planned DC-10 (the last of these machines were built in 1989) had maintenance problems in Amsterdam, and was replaced by the KLM 747 we saw. Unfortunately, nobody paid attention to the need for a crew that was able to operate the machine on the way back from Boston. So they brought another DC-10 from Memphis, and that's the machine in which I spent last night.

I'm in Karlsruhe for a day, staying at the Queens Hotel, with its amazingly boring architecture. I picked it because its additional comfort is only moderately more expensive than the old-fashioned, family-run three-star house I'd normally have chosen, and because there is Wi-Fi in the rooms.

Or so I thought: The Wi-Fi here is actually operated by Swisscom Eurospot. Unfortunately, the server certificate used by the provider is issued by ipsca.com, a CA that is unknown to my recently updated Mozilla 1.7 -- so, as far as I'm concerned, this could just be a spoof designed to get my credit card information. (And yes, such a spoof is entirely feasible, since all it takes is an access point and a laptop.)

But, just as bad, the pricing structure: The smallest unit of Internet access one can purchase here is half an hour for 4.50¤; two hours cost 9.50¤. The clock for these "packages" starts ticking when they are used initially. So downloading your e-mail, writing answers offline, and sending them easily costs 9¤ for two 1/2h vouchers, or 9.50¤ for two full hours.

This is too high a price for my taste. So, I'm back to GPRS for now -- here, that's actually less expensive (and less risky!) than Wi-Fi.

I'm looking forward for the day when hotels in Europe finally understand the idea behind free Wi-Fi in the room. As far as I'm concerned, if I return to this particular hotel, Wi-Fi won't be the reason...

One of the funnier aspects of staying at Logan for far too many hours was the chance to see some of their luggage handling: In plain view from the terminal E area where I spent my time was a transport tape apparently used to distribute checked luggage between different planes. For most of the time I was waiting, this transport tape wasn't moving.

Nor were the suitcases that had found a permanent residence on that tape. At that moment, I was grateful that NWA's broken transport tape at check-in had caused me to take my suitcase as carry-on luggage.

TDC has spread its hotspots all over Denmark -- at all Statoil gas stations, and at all McDonald's restaurants. This could be the perfect choice for foreign travelers who want Internet access.

But, unfortunately, these hotspots are unprepared to deal with foreigners: Not only is the subscription form available in Danish only (we can cope with that). In addition to that, address information collected during registration (why?) is assumed to be in Denmark. Luxembourg is a suburb of Copenhagen, in the world according to TDC.

Once we were through with this part of the registration process (we didn't really care that TDC was confused about the address), we were directed to a web page with a user id and password supposed to finally enable us to pay, and use the Internet. For us, authentication just failed.

At that point, we settled for a pre-paid GSM SIM card from CBB. These guys offer reasonably-priced GPRS once you "activate" it by a short phone call. According to their documentation, activation can take up to 24h; for us, it worked instantaneously.

Majordomo 2 is the latest piece of e-mail forwarding software at least one of whose authors considers it a "good thing" to re-encode any MIME parts they touch, and argues that cryptographic signatures that are invalidated in the process are to blame on "broken" software on the sender's end.

The argument is bogus: Ever since 1995's RFC 1847 (which first specified multipart/signed), not treating the first part of a multipart/signed as opaque has been a violation of applicable standards. RFC1847 is the basis of both OpenPGP/MIME and S/MIME. The basic idea is to encrypt and hash MIME bodies as they {would be, are} transferred over the wire, with some additional constraints.

But why is multipart/signed the right approach?

First, the "defensive" argument: Re-encoding messages adds complexity to e-mail transport, hence makes errors and problems more likely, without adding any demonstrable benefit. Hence, it is generically evil. Given the elegance and simplicity of RFC 1847, designing MIME signatures in a way that is friendly to re-encoding transport or forwarding agents would be wasteful, add no visible benefit, and make generically evil practices appear less evil. Besides, it's hardly an option at this point of time.

On the feature side, multipart/signed has the important property to include meta information with a signature: Is this postscript code to be interpreted as text, or as postscript? Did they mean to discuss postscript coding standards, and sign that, or did they really sign the contract that is rendered when you interpret the PostScript code? Building a "canonical format" that lets MIME signatures assure the same set of information would amount to designing a feature-complete replacement for MIME. So, why not just use MIME itself?

(This is not to say that there are no problems with MIME and digital signatures -- I'll be the first to say that MIME's ambiguities are a real problem. But these are not degrees of freedom that MIME encoders get to choose -- these are degrees of freedom introduced by MIME's "gentle" handling of misformatted messages.)

Says the Hitchhiker's Guide to the Galaxy, in introducing the SEP field (the Somebody Else's Problem field):

Sometimes, it is much cheaper and easier to make people think that something works, rather than actually make it work. After all, the result is, in all important aspects, the same.

In the Grand-Duchy of Luxembourg, SEP fields are in high demand, and often used as a replacement for electromagnetic fields. One of the more trivial examples is local GSM operator Tango whose engineering department apparently considers the entire MMS service (and much of its data service) to be an SEP -- more precisely, the marketing department's. These services are advertised, but seem to be non-operational.

Sligtly more bizarre, the local P&T's business customer department, which erected an SEP field to deflect any possibility of putting up DSL for us. After four weeks of waiting time, the problem hit two unsuspecting technicians who were unable to put the necessary cabling in place, erected another SEP field, and deflected the problem at the local soccer club. By an unlikely, but only almost improbable, coincidence, the problem hit the right person there, and cabling was put in place last week. We are told that the problem is going to bounce around inside P&T for another week, at the end of which time we might actually get decent Internet connectivity at home.

Meanwhile, competitiveness with regard to technology and innovation (see page 6) is considered somebody else's problem, too, in particular by these people.

(True Hitchhiker aficionados will notice that Luxembourg shares a significant border with Belgium. The landscape is beautiful, though.)

At least, that's what we've been told for the past three weeks, in varying words. Last week was the first time that they gave us a precise time line -- according to which things should work now, as in, "this minute." Today, we called to "activate" DSL (another of these useless extra hassles which P&T Luxembourg forces on its customers) , and were told that we should rather wait another week (or maybe longer), so they could actually do the work they were supposed to do last week.

Update, Tuesday: After bugging more people over the phone, it's now "no later than Friday afternoon; the letter with new access data has been sent out." I have no idea what we need new access data for, but hey, that counts as a minor problem.

The DSL-in-Luxembourg saga continues: Apparently, the final steps of the relevant business process are based on the customer regularly calling some hotline number. This call is entirely futile unless engineering has put in place some missing cable, somewhere. Only after the customer's call, another, final engineering step is possible. The only way for the customer to detect whether that damned cable is in place is calling, and being placed on hold until the customer service representative has talked to the engineering department.

Six weeks. What a day.

These are the nights when I regret my decision not to go for a Mac as my Laptop: As if it was 1995, I'm sitting here, sleepy, waiting for my PC to finish compiling the Linux kernel -- which takes eternities.

The reason? I was stupid enough to install Redhat's Fedora Core 3 on that truly cutting edge thinkpad I use, without checking that this problem (which is the same as this problem) was actually fixed -- it isn't, not even in the latest "testing" kernel. Linux has been running rock-solid on this machine for the past six months, until the latest so-called stable kernel, which will leave the keyboard in a completely useless state after any APM suspend/resume.

So I'm now rebuilding the last useable FC2 kernel (which doesn't seem to be available in binary RPM form any more) for use on FC3, to get back my laptop's full functionality.

(Meanwhile, the PDA is still in the process of being repaired; replacement devices can't be made available, I'm told.)

After the kernel compilation orgy last night, Fedora Core 3 now runs reasonably stable -- sort of, since OpenOffice has some problems. Not only do the same documents look different now when printed -- most of the user interface is displayed in a way that's somewhere between ridiculous and unreadable.

As I said yesterday: These are the things that make me wish I had taken a Mac.

(Turns out this is an X server problem; thanks to the people at RedHat, I now have a work-around.)

Tonight, I have shut down the mutt bug tracking system: The system (a debbugs installation) wasn't able to cope with the spam thrown at it, and I didn't have the resources needed to harden it against the assault.

It's sad that spam makes e-mail-based automated systems increasingly useless.

Mainstrem media talk about evil twins, the security monkey points to stories of hotspot billing systems being so widely open that users can easily reconfigure hotspots to free-of-charge mode. Hotspots are insecure, it seems.

But what does "insecure" or "secure" mean when you talk about a wireless hotspot?

When trying to log into Orkut today, I was prompted to link Orkut to my Google account. In practical terms, this means that Google moves even closer to linking search history, e-mail, chat, and social networking information to each other. Reading their privacy policy and FAQ, I'm irritated by not seeing a straight answer about whether or not that linkage is actually done. I'm also irritated by the "this is good for you, so we won't give you a choice about it" attitude of the change.

I'm tempted to delete my Orkut and Gmail accounts.

So my T43 lost its partition table upon reboot, again. It took me too long to find the note where I had jotted it down; next time, it'll be easier to just search here.

sda1   1 ... 13
sda2  14 ... 4864

The recipe is to re-boot the machine from the rescue DVD, use fdisk to write a new partition table. Reboot in rescue mode, let the rescue system mount the "old" system, chroot into it, run grub-install /dev/sda. Reboot again.

(Yes, that can be done more elegantly, but I don't want to remember all the lvm commands.)

klm.sucks (despite being half of my preferred airline these days) has launched a new web site which is so heavy on JavaScript that it doesn't even accept known browsers (Firefox) on unknown platforms (Linux). The solution: Set the configuration variable general.platform.override to the string Windows, and things will work. Of course, all this is, actually, entirely unnecessary.

ObW3CLink: Device Independence

The most fascinating phishing message in a long time is aimed at Barclays' customers. It's remarkable for moving away from fake web pages: Instead, it squats on UK area code 870 phone numbers used by Barclays' by trying to convince recipients to fax a ton of personal information to a country code 870 phone number -- an Inmarsat fax number, it seems. The difference that you can spot is a single digit 0 more in front of the fax number.

The fax form itself includes bullet points with good advice on how to avoid web-based phishing attacks.

The GPLv3 draft analysis at newsforge kind of proudly proclaims that the GPLv3 draft has 4500 words, when GPLv2 was less than 3,000. That means, there's 50% more legalese to understand for the non-lawyers who deal with open source software.

I'm not a lawyer. I'm a fan of concise and understandable legal text. I have seen the confusions that GPLv2 creates: For instance, Debian felt they were unable to distribute a version of mutt that was dynamically (!) linked against an OpenSSL library that was licensed under an advertising-encumbered BSD style license. (The success of dynamic linking depends on two libraries having precisely the same ABI. Theoretically, it's possible to build an unencumbered library with the same interface. Hence, the SSL library was part of the system context that mutt expected, nothing more, nothing less.)

But a new GPL with 4500 words and a hard to understand DRM clause makes me extremely nervous. It makes it ever more tempting to go for a concise BSD style license instead - but then again, the "virality" of the GPL is a good thing.

My bank has gotten two-factor authentication badly wrong: In a move to have "what you know" and "what you get", they've introduced "TAN cards". These cards have a login and a 12 letter code printed on them. For each login, you need to type in three randomly choosen letters. In addition to that, you have to enter a password; this is also used to confirm every single transaction.

Leaving the fact aside that nothing in these "TAN" cards is transaction-specific, the "system" is topped by demanding that the password is at least 10 characters long, and high-entropy -- and that is even enforced.

The result? Pretty much nobody can memorize a high-entropy password with 10 letters reliably. Hence, the system degenerates into two times "what you have."

Remember: If you want to do "what you know" style authentication, make the shared secret something that people *can* know.

One of the few things that have been bugging me for a while about my Treo is the fact that the stylus that is shipped with the device has a tendency to slip out and get lost. Last week, I seem to have lost it for good, so i ordered an entirely overpriced set of replacement styli from Palm.

Surprise of surprises: These beasts fit properly, and don't feel like I might lose them any time soon.

Why not do it properly in the first place?

I'm running Fedora Core on my laptop. One of the habits of that distribution is to install the kernel du jour as part of the usual upgrade process, and to let old ones stick around -- including the kernel-devel packages which tend to have a lot of files with precisely the same names.

After a year or two, trying to remove some old kernel-devel packages will lead to a nasty surprise: rpm needs 1G of memory. My laptop doesn't have that.

Turns out that rpm doesn't deal particularly well with lots of files in lots of packages that have the same or almost the same name. For that reason, there's a list of directories where rpm gets sloppy about checking for duplicates; /usr/src is among them. Unfortunately, this sloppiness leads to loss of files during upgrades. Therefore, some bright engineer decided to deactivate the sloppiness when packages are removed. The result: 1GB of virtal memory is needed to clean up the kernel-devel packages.

There doesn't seem to be a clean work-around -- except possibly in the latest "forked" rpm. My way out of this mess was to download the sources for rpm, disable patch #12 ("exclude") in the spec file, rebuild, and then run rpm using the newly-built instances of librpm and librpmdb. I got rid of the kernel-devel packages quickly, and continue to use the "usual" instance of rpm for everyday purposes.

Thanks for the folks on #rpm for their help!

Still, this entire story points to several instances of rather poor engineering in rpm: The duplicate handling was implemented without any regard for memory consumption or efficiency; the workaround breaks upgrades; and the workaround to the workaround breaks removal of packages again.

Sometimes, I'd wish I was using a Debian-based system.

Imagine my surprise when my attempt to buy a good friend dinner failed that way earlier this year. Imagine my dismay when (after said friend had put the bill on her card; different brand) my ATM card failed, too, and I suddenly seemed stranded without access to money. All that was, incidentally, right in the middle of a longer trip abroad, and I knew I'd still have a bunch of hotel bills to pay -- and no way to just walk to my local bank branch and get cash, since that was some 4000 miles away. Fortunately, things had sorted themselves out the next day; when I called, I was told they had a "computer outage" that night.

Disquieting, though, that a single computer outage was enough to knock out both my ATM card and the Mastercard. One might have hoped these were running on different systems.

A similar (but less embarrassing) experience today: Amazon bounced a Visa card that I'm essentially only ever using with them. When I called CETREL, I was told that, well, all was right with my card, but "Visa International is down today." When I grumbled that this was the second bounced card this year, the reply was a stunning, "well, ya know, they're down the third time today."

I can't think of any better advertising for having credit cards with more than one company (and ideally in more than one country), but I'm also surprised how the systems that we've come to rely on for payment seem to have significant single points of failure built in -- unfortunately, points of failure that apparently can collapse without the impact of major catastrophic events.

I, for one, am now seriously considering to get another card from another brand, and am also thinking of keeping a reserve of travelers cheques or cash around when I'm on the road.

Seems as if the kernel included with Fedora 7 has more problems than I anticipated: Suspend/Resume isn't alone in leading to lockups; disabling Bluetooth using the appropriate keyboard combination has the same effect.

I'm back to the last FC6 kernel until this gets sorted out. Yet, I'm surprised how reasonably usual activities still lead to regressions like this, on common hardware (a T43 isn't that unusual).

It seems like the combination of a somewhat dated Linksys WRT54G and the MacBook wasn't made in heaven. Every once in a while, I find something like this in my laptop's log files:

Jan 23 11:04:27 iCoaster kernel[0]:
 ath_reset: unable to reset hardware; hal status 3
Jan 23 11:04:28 iCoaster kernel[0]:
 ath_chan_set: unable to reset channel 1 (2412 Mhz)
Jan 23 11:04:29 iCoaster kernel[0]:
 ath_chan_set: unable to reset channel 6 (2437 Mhz)
Jan 23 11:04:30 iCoaster kernel[0]:
 ath_chan_set: unable to reset channel 11 (2462 Mhz)
Jan 23 11:04:30 iCoaster kernel[0]:
 ath_chan_set: unable to reset channel 7 (2442 Mhz)
Jan 23 11:04:30 iCoaster configd[50]:
 posting notification com.apple.system.config.network_change
Jan 23 11:04:32 iCoaster kernel[0]:
 ath_chan_set: unable to reset channel 13 (2472 Mhz)
Jan 23 11:04:33 iCoaster kernel[0]:
 ath_chan_set: unable to reset channel 52 (5260 Mhz)
Jan 23 11:04:34 iCoaster kernel[0]:
 ath_chan_set: unable to reset channel 56 (5280 Mhz)
Jan 23 11:04:35 iCoaster kernel[0]:
 ath_chan_set: unable to reset channel 60 (5300 Mhz)

These effects occur once or twice a week, and aren't really helpful in the middle of trying to work. Overall, this has the stink of a driver issue. Googling around shows that there have been dropped connection issues between Linksys routers and Apple wireless cards for a long time, without Apple coming up with a useful fix.

Update, 2008-02-13 -- the woes continue on MacOS 10.5.2. They seem strangely correlated to the presence of a "secure" ad-hoc network here which, I believe, is caused by some Philips entertainment electronics. The name is WASC-.....

I had ranted before about the occasional trouble that I'm experiencing with the MacBook's wireless card.

The symptoms continue to occur: Typically at home (when the machine is in the same place and sits on my desk for extended amounts of time, sometimes days), typically during work hours, often when somebody else toys around with a network nearby, and only reproducible when I really can't use them. In other words: At least here, the MacBook isn't reliable accessing the wireless network during work hours, and I can't figure out anything in particular that I can do to trigger or avoid the problem.

(It's also clear that the problem isn't with the access point, as other machines here have no problem. Including a wifi enabled mobile phone and the Thinkpad. This is a genuine client issue, genuinely on the Mac.)

Searching around online has been a fool's errand and a time sink as well: While there are quite a few examples of similar problem (and while discussion threads often have a "yeah, I have the same problem"), none of them yield useful information about either causes or cures for the problem. The only consolation is, maybe, that the trouble seems to be common across the BSDs and Linux, and is certainly not just a Mac problem. (That consolation is rather immaterial, though -- we are, after all, talking about a problem with the (Atheros) wireless card that ships in these machines. By default.)

From what I've seen so far, this could be a Heisenbug anywhere between overheating (a bad fan?), a loose contact, a bit of conducting dust on the motherboard, a buggy driver, neighbors' secretly building and testing EMP weapons while cooking pancakes, or sun spot activcity -- even though some general instability (two panics and a freeze within two hours or so, anyone?) this morning points at hardware troubles close to the motherboard. (Oh, of course all is stable now that I'm sitting in elsewhere and have the laptop balanced on my leg -- overheating, after all?)

The next step is presumably AppleCare -- and I'll probably have to see how well my environment is back-ported to Linux on the Thinkpad, since travel and work won't wait for Apple to get it's act together.

PS: A crack that occurs on the right-hand palm rest, toward the front, on about every MacBook I've seen, doesn't count as quality hardware either.

PS2: I do like MacOS's, and the overall machine's usability. Really. But, please, not in a less stable environment than what Linux on the Thinkpad gave me. Till that machine's motherboard broke, that is. 2 weeks repair time there.