Month: March 2004

The not entirely planned outage is over. If you notice any quirks, please let me know.

The server on which this weblog (and the aggregator) are running will have an outage of several hours later today, due to hardware changes.

If you’re interested in following the advancement of tests intended to tell humans and computers apart, www.captcha.net is a good place to start. You will, for instance, learn that some more or less simple tests that involve reading characters displayed as graphics, and entering these characters into forms, have been broken. Accredited registrars still use this kind of test, though, to protect Web access to their whois databases.The same people that are behind the CAPTCHA project are also behind the ESP game which is about describing pictures in text. It’s no coincidence that the latest captcha that they are beta-testing also involves describing images: Users are shown a collection of images, and they have to pick a word that describes what these images have in common. If that word matches, they pass, if it doesn’t match, you have failed the test.The problem with this test is that it requires an active command of written English, and that it is purely visual.(More notes on the accessibility problems with CAPTCHAs here.)

Here‘s a policy proposal that ALAC just injected into WHOIS Task Forces one and two: Collect as little as possible, display even less. What is displayed goes into two tiers: A public one (with just the technical stuff) and an authenticated one (where some personal data may go). Whoever wants to use the authenticated tier needs to identify themselves and their purpose. Purpose and identity of data users are made accessible to registrants.In response to other proposals that are floating around, we strongly recommend against a “shut down port 43, and do web interfaces with CAPTCHAs” approach,” and make some comments on the IP constituency’s call for more telephone numbers in WHOIS.

The random freezes after suspend/resume are still there, but Wi-Fi is getting better: The ndiswrapper problems have been fixed in the latest code revision of that module, so the Windows driver has become quite usable. (Although you can’t use it for any kind of serious wardriving activity.)

The R40 is still a pleasure to use, with one exception: Seems that the freezes I have observed before (and blamed on shaky wireless drivers) are related to the X server — or at least, that’s my culprit of the day. Freezes usually occur some time after a suspend/resume cycle, and I changed the pattern somewhat by removing gpm from the system and installing a new touchpad driver directly into X: Now, applications will be unresponsive, and the keyboard won’t react (no switching to a different console, but it’s still possible to turn on the keyboard light with Fn-F12); the mouse pointer can still be moved.On the positive side, the new synaptics driver is extremely nice — moving the finger along the right side of the touchpad, for instance, can be used for scrolling inside windows.I’m also playing around more with wireless drivers for the Centrino. There’s progress in fixing the ndiswrapper rmmod issue; also, the Intel driver works amazingly well — when I grumbled about it the other day, I had just experienced another frozen X server, and that pattern has now turned out to be independent of the wireless driver.

Turns out that Linux on the R40 isn’t entirely without problems: I finally got bitten by some pretty bad interactions between USB, suspend/resume, and my PCMCIA WLAN card (from SMC, with an Atmel chipset; there’s an open-source Linux driver for this card). It helps greatly to use the built-in Wi-Fi instead. And, yes, that’s indeed possible if you are willing to use a Windows XP driver under Linux. Just install ndiswrapper, and the driver you got with Windows XP. And it just works.(Additionally it’s a good idea to disable USB before suspending the machine. /etc/sysconfig/apm-scripts/apmcontinue-pre here. That way, one can upload Photos without rebooting…)Later: Turns out that ndiswrapper is sticky the ugly way — removing the module leads to various kinds of crashes. And the Intel driver isn’t mature enough, either… Bad luck with wireless for the moment.

So the new Laptop is an IBM Thinkpad R40, and I’m pleasantly surprised how smoothly Fedora Core 1 works with this machine. While some stumbling blocks remain in getting Linux to run smoothly, solutions for most are readily available — and the rest just works.Some lessons: In order to actually use the entire mouse assembly (touchpad with two mouse buttons, trackpoint with three (!) mouse buttons), it’s best to use a patched version of GPM in repeater mode. For the internal modem, the only thing that works so far is a recent SmartLink driver. Note that the Agere drivers recommended by IBM don’t seem to work. The final and surprising problem was getting the laptop’s infrared to work: An old-style IRQ collision between te IRDA chipset and a PCMCIA card was the problem; to solve this, I just made sure that PCMCIA isn’t started before IRDA.The one thing that isn’t working, yet, is the built-in Centrino Wi-Fi. But there is hope.

Chris Ambler discusses TLD strings and is concerned that ICANN could worry too much about the problems new TLDs have had in the past, with code that would claim that anything with a TLD segment of more than two or three characters was an invalid domain name.I sincerely hope that Chris is wrong about that — for two reasons: One, fools are inventive enough to not just assume 2 and 3 letter TLDs (Google hit #1 for address validation javascript), but to also check for the now-existing gTLDs, while essentially sticking to the same broken design — or, worse, not even being flexible with three-letter TLDs. Two, what I’ve heared on this topic in Rome sounded extremely reasonable. While John Klensin’s RFC 3696 on the topic wasn’t mentioned there — at least in the public forum –, others have recognized that the easiest cure is probably to implement (or just find) free sample code for domain name and e-mail address verification, and to Google-bomb that code.In other words: Let’s help the market take care of that.

Via comp.risks: Netcraft: SSL’s Credibility as Phishing Defense Is Tested. The unsurprising news: SSL certificates (mostly) deal with domain names. Only that match can be verified by a web browser, and signalled by a closed pad-lock. The security is ultimately based on a match between a domain name and the “site” the user wants to visit — that is, “Amazon,” “Deutsche Bank,” “Earthlink,” “Microsoft,” “IBM”, as opposed to, e.g., “ibm.de” or maybe “ibm.com.” Linking the “site” (i.e., the user’s idea of who the merchant is) to a domain name is, realistically, left to trademark law and the UDRP. This doesn’t work for little-known marks. Less realistically, it is left to WHOIS, which, as many proponents of open access tell us ever again, is used by consumers to “verify” online merchants. This doesn’t work at all — most “ordinary” net users I know don’t even have an idea what WHOIS is, and then again, we all know the database is inaccurate, can’t be made accurate, and doesn’t even have the data elements you’d ask for. When consumers are confused about the domain name they are visiting — be it due to typo-squatting, be it due to cleverly crafted deceptive URLs –, though, SSL, WHOIS, trademarks, and all that stuff don’t even have a chance to help them. It’s this kind of confusion that the latest phising expeditions exploit.How do you fix this? Make sure users can’t easily ignore information about the merchant that’s behind a site. Display it in a state bar that can’t be scripted. And don’t take it from WHOIS, but take it from the SSL certificate.