No Such Weblog

The group of people formerly known as WHOIS Task Forces 1 & 2 met today for its first two-hour conference call after Council's decision to formally merge the groups. The group received a briefing on what happened in KL, spent too much time on debating whether the two Task Force chairs should continue as co-chairs (they will do so), and finally addressed "prioritizing."

While in Boston two weeks ago, I walked along the "Freedom Trail" and also visited the USS Constitution -- a strange superposition of a commissioned warship, a national park, and a well-guarded national symbol. While Freedom Trail's red trace runs straight to the ship, visitors have to pass by blocks of concrete, an armed soldier standing by a camouflage colored Hummer, and finally through security screening: Empty all pockets, remove the belts, and have some Navy soldiers hand-search all bags -- while here is a metal detector gate in place, no x-ray device is available.

These hand-searches are, on the one hand, intimidating, and ineffective on the other hand: The soldier who searched my laptop bag (used for tourist equipment that day), for instance, would play around with my mobile phone -- apparently, he hadn't seen a Siemens SL55 before --, but would both miss the front compartment of the bag, and the Palm in the main compartment, which -- in a consistent security control -- should have warranted the same kind of inspection as the mobile phone.

Ultimately, one has to wonder what the actual point of this kind of control is, and what kind of attack model is behind it. Terrorists hijacking the Constitution and using it to attack the Fleet Center?

Looks a lot like security theater to me.

The GNSO Council today accepted the .net criteria (draft resolution text) designed by its .net criteria subcommittee. Due to conflicts of interest, Alick Wilson carried the proxies of all three registrar representatives on Council, and Amadeu Abril i Abril's proxy. The registry vote was split.

Council also adopted a position submitted by the registry constituency during the conference call. This position calls for all material provisions of the future .net contract, including the proposed fee structure (?), to be published in the draft and final RFPs. It will form part of the cover letter for the report on the .net criteria. There was little discussion on the substance of this; procedurally, there was considerable confusion: Only some council members had received the proposal prior to the call. One joined as late as during the vote, and didn't even know what it was all about. The vote was then cast as instructed by the single representative of the same constituency who had attended the entire call.

MP3 recording here.

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.

There was some fascinating discussion on the registrars list on thick vs. thin WHOIS models for .net.

Particularly amazing: The position of Key Systems' Jens Wagner, who suggested that a thick WHOIS was a good way to cope with privacy problems -- not in the sense of actually increasing registrant privacy and designing systems that enable registrars to comply with applicable law, but rather in the sense of attempting to design systems that make compliance infeasible.

Now, that's a registrar who cares about its customers...

The registrars discussion -- despite the occasional bizarrity -- mostly demonstrates that there is no unanimity among registrars on this issue. So, what arguments can be made in favor of either model, from a registrant's point of view?

The thick registry model -- under the assumption that registries are more diligent with registrant data than some registrars may be -- helps take care of escrow concerns: When a registrar goes out of business or experiences some other kind of desaster that removes its data store, the data kept at the registry can help transfer registrations to a different registrar, and help registrants keep their domain names. Besides that, keeping registrant information at the registry helps registry operators enforce the new transfers policy, and may generally contribute to making the transfers process run more smoothly.

On the other hand, the thick model often involves transfer of registrant data (both the identifying information, and the sensitive information that is constituted by the link between a domain name and the registrant's identifying information) across jurisdictional boundaries that may separate very different privacy regimes. This concern should weigh even heavier when the registry is not just keeping the thick data set, but actually uses these data for making its own WHOIS service available to the public at large. As Jens Wagner's comment shows, thick registries can be used to design systems which make it hard for registrars to comply with applicable privacy legislation.

The thin model, on the other hand, keeps ultimate control over the publication, transfer and use of data with registrars, and with law enforcement authorities and courts that have jurisdiction over them. Registrants in many jurisdictions get the chance to chose a registrar in the same jurisdiction, and have assurance that their data don't leave that jurisdiction as part of the registration process. The thin model also makes it easier to implement alternative WHOIS models like ALAC's proposal, in which registrants are notified when their data are accessed.

Maybe it's best to start thinking about thick registry designs that quack like thin WHOIS systems. Either by keeping the thin WHOIS paradigm despite thick registry design, or by actually giving the registrar fine-grained control over what data elements are actually displayed in thick registries' WHOIS services. EPP certainly looks like it is prepared for this approach.

Verisign's response to SSAC is a messy combination of very few good arguments (just why was the limited IDN wildcard so much better than sitefinder, again?), silly distractions, and simple misstatements. The purpose of this entry is to address some plainly misleading parts of the document.

On page 6, for instance, the report takes up SSAC's footnoting of my presentation in Carthage, and claims that the comments summarized there were somehow triggered by ALAC's statement on sitefinder. We're flattered by the impact that is attributed to ALAC's statement -- but I didn't summarize the few comments ALAC received on the topic, but the 200+ ones sent to ICANN's overall wildcard-comments address.

Verisign (on page 9) continues to claim high user acceptance based on some polling, and alleges that it made sufficient information about the surveys available. That's a bad joke: I still haven't even seen a public, on-the-record answer to the question in what languages the survey was conducted (the answer is: English) -- an important factor when VeriSign claims user satisfaction with an English-language service forced on users in countries such as Germany or China. Also, the questions asked in the surveys still haven't been published, to the best of my knowledge. As far as I'm concerned, Verisign is still in the how to lie with statistics department here.

On page 5, VeriSign complains that SSAC didn't follow up on offers by VeriSign to make relevant data available. Elsewhere, there are complaints about lack of transparency. So, why doesn't Verisign just publish these data?

There's more to be said about other parts of the report -- claiming that Sitefinder fixes 404 errors generated by web servers (after successful resolution of a domain name), talking about format and protocol compliance when operational procedures are at issue, going to great lengths of discussing the confines of SSAC's mission while avoiding to reply on substance, conflating changes close to the network's center (sitefinder) with changes close to the edges (firewalls), claiming that hacks deployed at ISP name servers equate end user choice.

Tonight, I have sent final messages to the icann-europe and atlarge-discuss mailing lists, both of which were sponsored by FITUG. Both lists were dead for months or even years. Both are gone now.

icann-europe was the first thing ICANN I did: I set it up during the nomination phase of 2000's at-large elections, as a tool to enable informed discussion between potential candidates and the interested part of the community. Many candidates joined, and for some time, this list was one of the better places for talking about ICANN. The list slowly degraded after the elections, until the only remaining traffic was spam, and the occasional lunatic. In a way, this list marks the missed opportunity to turn the traction generated by the elections in 2000 into a viable mechanism for public input into ICANN.

atlarge-discuss was started shortly after the board dismissed the ALSC report in Accra, when some 1,000 people subscribed to the effort at icannatlarge.com. A number of mistakes were made there, and I feel responsible for some of the early ones.

Given that the GNSO's GA list is dysfunctional (or at least it was when I left), this means that, to the best of my knowledge, there are no mailing lists that enable public, cross-constituency debate of ICANN topics. ICANNwatch is the closest thing to this. (I don't know what the BWG is doing these days, since I was never subscribed to its list.)

I find this development worrisome: I continue to believe that ICANN needs public input. I continue to believe that it needs open and, also, online discussion. I continue to believe that it needs accountability and fresh blood. What we see instead is ever-decreasing interest in ICANN (after all, it's not as bad as, say, recent developments in copyright), and a nominating committee that extends the deadline for statements of interest.

What can we do about that?

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.