No Such Weblog

The non-commercial constituency is visiting the registrars; the meeting is joined by George Papapavlou from the European Commission. Papapavlou tries to explain main legal conocepts that determine European approach to WHOIS. One of the task forces of GNSO has asked GAC some questions. Papapavlou will try to give replies in this meeting. Main starting point for European thinking on WHOIS: "What is the purpose of WHOIS?" Answer this question, then you can answer second question: "What data are we talking about?" In European legal framework, processing of personal data is possible for specific purpose. Once purpose has been defined, you know what data is relevant. Purpose of WHOIS is not really clear. Initial idea: Need contact data on specific domain names in case something gets wrong -- reach technical contact point. If this is purpose of WHOIS, that's good starting point.

It's workshop day in Rome today, and we're through the new registry services session and WHOIS Task Force 1.

The biggest news from the registry services session was a constituency statement submitted by the gTLD registries' constituency. At the TF1 session, there was some interesting discussion about possible approaches for tiered access. It appears like the basic concept of having an anonymous tier and an authenticated tier of access with different data sets displayed in each is gaining some traction.

I'm told that the Rome webcast is now supposed to be up and running. Go to http://media.icann.org/ramgen/encoder/rome.rm to tune in to the realmedia webcast.

WHOIS Task Force #3 is now holding its workshop. Bernard Turcotte is presenting on the verification mechanisms employed by CIRA, the .ca registry. My point in response to that, from the floor, is that by requiring "accurate" or at least plausible contact information bad actors are being driven underground, and that there are then incentives for them to use the contact details of innocent third parties. Similar experience exists elsewhere: In the fields of money laundering, where we have identity theft, and in the spam area, where plausibility filters on readers' inboxes have brought us "joe jobs" in which a third party's e-mail address is being abused. And the crack-down on open e-mail relays has brought us the abuse of home computers hijacked by worms and viruses for sending out spam.

It's not inconsistent with this that .ca is not experiencing identity theft cases, as Turcotte reported in response to a follow-up question by Sarah Deutsch: As long as there are places where bad actors can register domain names without giving "accurate" contact information, it's rational for a bad actor to simply go there, and not bother stealing someone else's contact information.

The non-commercial users' constituency has arranged a session on privacy laws and whois with Giovanni Buttarelli, secretary general of the Italian Data protection authority. The session will take place from 0930 until 1030 in Room Velazquez.

(Note the room change from earlier announcements!)

In late January, B has changed IP addresses. I don't remember that I've seen anything about that on the ICANN web page. Why?

Paul Twomey is giving his report to the public forum in Rome, and just discussed the memorandum of understanding. He reports that there are statements from the highest levels in the US department of commerce that the US government believes that ICANN's functions should be performed in a multi-stakeholder, private-sector body, and not by the US government, and that the USG would like to see the MoU concluded and the transfer of responsibility take place.

Elliot Noss at the microphone in Rome: Increase in registrar accreditation, but not showing up in marketing data. "Other reasons" for registrar accreditation? Twomey: There are incentives in the market that reward having more accreditation, relating to the batch pool operations around dot-com etc. Cerf: Gaming the system?

Bruce Tonkin's GNSO report at the public forum was a masterpiece both in terms of public speaking and analysis.

Tonkin starts by noting that litigation is moving decision-making to a different forum. It means decision-making mechanisms within ICANN failed. Why did the Roman Empire fail? Watch some movies. Also: Star Wars. Jedi Council eliminated, hope that does not happen here. ... Public input: Too little data, too much speaking. Registrar won best actor and best supporting actor awards at public forum. Don't behave like used car dealers.

WHOIS -- try to collect actual data. No responses. Why not? Manager of public participation. Bring more actors for the awards, or analyze? Policy development and analysis: Less public speaking. More analysis. Need staff support with strong analytical and writing skills. Spend money now and properly resource the analysis and policy development -- or spend money later; spend it in another decision-making process.

Seek return of the Jedi to ICANN. What does that mean? Analysis skills. Too much public speaking skills.

Decisions. Clear criteria. Measurable objectives. There have been decisions, but there are no success metrics. Clearly document basis for decisions, so they can stand up to a separate decision-making process outside of ICANN.

Wait Listing Service. 2001 -- issue first raised. 2002 -- General Counsel, Names Council, Transfers TF analyses, Council resolution on WLS: Don't implement. But no clear set of criteria established. Seeking to get these criteria in the new registry services process.

Appeals.

Implementation: Less public speaking. Not an extended appeal process. Little experience on this in ICANN. Get people in there who actually implement, not policy developers.

Compliance -- worth trying. Not in the used cars sales industry. Review outcomes. Define success metrics. Review. Look at new TLDs: Reviewing now, but no review criteria developed at time of implementation. Resource process from public import through to implementation up front instead of spending on litigation later.

Hope ICANN survives, does not share fate of other empires. Finally, thanks to one of the Jedi: Elizabeth Porteneuve. Extended applause.

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.

... that's the ALAC statement that Karl Auerbach suggests we make everywhere until we have all the regional organizations in place. I'm sure that this input would be appreciated. But I'm also sure that it would have precisely zero influence.

The GNSO policy processes are not waiting until we can convince enough at-large structures to join ALAC and to provide some legitimacy. The processes are running. We have some ways to lobby participants and to provide some analysis from an individual user's point of view. In my view, it would be entirely irresponsible not to make use of the -- admittedly limited -- possibilities we have.

(Also, "we are involved there and there and there" is a much sexier -- but maybe not sexy enough -- marketing message than "with a lot of luck, we might have a chance to get involved there, but we haven't tried yet, so we can't tell you.")

On the IP list, Karl Auerbach explains why a TLD for "mobile content" is a bad idea, even though it's backed by major industry players. Karl's arguments are convincing.

But whom could Karl convince? I hope he does not convince ICANN: Because it is not (or, rather, should not be) ICANN's business to decide whether a TLD proposal is a good or a bad idea. ICANN's task should be to enable bad proposals to fail in the marketplace.

Question: What should ICANN do when a seemingly "good" idea and a "bad" idea compete for the same TLD string? Auction?

I've started looking for a new laptop -- that trusty old Dell is asking ever louder questions about retirement benefits and less travel.

There are three key criteria: The machine must be robust. It must have a good and extremely robust keyboard, since I'm typing much and fast. And Linux must run on it. By "Linux must run on it", I don't just mean "Linux boots", but rather "can be used as a daily Linux workhorse." That includes well-working networking and Wi-Fi equipment (though continued use of the good old PCMCIA cards I use with the Dell is an option), and that also includes that the graphics adapter must be supported by X11 -- including that external VGA plug I need to plug in a beamer now and then! (Bad past experience with the Dell.) I don't care much about Megahertz numbers and the like -- in terms of processing power, about anything that's availabe now would do.

I don't think a new Dell is an option -- I've made some bad experiences in terms of hardware robustness (including a mouse button breaking off just because it's being used), and the keyboard is so worn off it's torturing me daily (after two years of not being used by the original owner, and one and a half years of heavy use under my hands). Right now, an IBM Thinkpad looks tempting; maybe one of the R40 or R50 devices.

Thoughts, experiences, recommendations?

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.

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.

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.

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.

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.

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.)

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.

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.)

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

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

ICANN has posted another update on transfers. Part of that update is a letter from NSI's Champion Mitchell (aka Best Actor Rome 2004). In that letter, NSI suggests that a default-ack mechanism (as agreed on in the new policy) will lead to fraud and slamming. NSI essentially suggests adopting a default-nack policy with standardized forms instead. At the very least, it seems, NSI would prefer another delay until all dispute resolution and appeals processes are in place, and until everything is implemented on the registry side.

Of course, this discussion has been going on since at least summer 2001. It's fascinating (I'm avoiding the word "frustrating") that NSI is now attempting to reopen this policy issue, and it is even more fascinating that they have succeeded in causing another delay in the implementation process of a consensus policy adopted by GNSO Council (in February 2003) and Board (in April 2003), and brought into implementation shape by a hard-working assistance group since July 2003.