Hostile to privacy

For those who don't remember it, hostile to privacy is a code word, it stands for Google since they acquired doubleclick. To get over this negative image Google recently promoted privacy to one of the 28 words on their basic search form.

As user of several Google services I have vague ideas which host names have to be blocked at the network level for privacy, and what is anyway pointless, to some degree I trust them. Sadly, visitors of my Googlet pages will get a cookie. I have no idea why, and it is not obviously mentioned in Google's privacy policy. Likely I'm violating German privacy laws with this practise, and "but it is the server, not me" is a lame excuse. Having said this, if you don't trust Google, what do you expect here on blogger, or even on my pages dedicated to googlets ?

Another issue are third parties, just because I trust Google to some degree doesn't mean that I delegated this job to them, otherwise they could start a certificate authority in their quest to achieve world dominance. After a discussion with the HTML5 editor I feared that my trust in network.cookie.cookieBehavior 1 could be wrong, and switched this to "always ask". The effects are quite interesting, e.g., a Google search for network world tries to set a www.networkworld.com cookie. I didn't click or touch anything on the search results, but this third party tries to set a cookie.

So far still okay, switching to "always ask" is one of many ways to reset network.cookie.cookieBehavior 0, and Google offers an opt out cookie. Clearly opt out is a weasel word for net abuse today, and Google prefers to be a part of the problem.

When I set network.cookie.cookieBehavior 1 again the same site still offers its third party cookie on the search results. After some tests always restarting the browser my impression is that this setting has no effect in my BBFH. But "always ask" works, and it can be limited to "ask once" for any given site.

Secunia Psi RC3 and Psi IM v0.12

Secunia PSI RC3 0.9.0.4 is a brilliant tool to find insecure cruft on a box; it just helped me to get the latest XnView 1.94.2. But Psi is definitely a tool for folks with a vague idea what they need, e.g., it didn't tell me that some of my Sysinternals tools are not more up to date. I read the blog and decided to skip some minor fixes.

More serious, Psi still doesn't tell me that QT Lite 1.1.2 is insecure and past its end of live for W2K. A Real Alternative 1.60 Lite and a K-Lite codec pack 3.6.5 on my box were also horribly obsolete, but not reported by Psi. These unofficial alternatives are quite popular for various compelling reasons, but on W2K it's time to say good bye to QT including its lite alternative.

More on the funny side, and also reported again as missing, Secunia Psi still does not identify Psi IM, a jabber client, now at version 0.12. The release notes don't mention security issues in 0.11, they also didn't tell me that running install works as an upgrade (fortunately it did), and I still have no clue how to convince Firefox and/or W2K that Psi can handle xmpp URIs. If that is the case, the documentation is rather inconclusive.

Google mail security

Inspired by an Heisec article about the fine art of stealing insecure cookies I've upgraded the mailx googlet to use https for its Google mail mobile redirection. The settings allow to configure http instead of https.

A new entry in my googlet zoo is firxt.mobile for the firxt mobile OpenSearch portal. Often mobile also means accessible over slow connections and no nonsense. The googlet should work everywhere, check it out. Hint, what you see as "use this URL" within the googlet contains apparently a configuration number. Just in case this number can be stored in the googlet settings, maybe it helps when you delete your cookie.

Leader of the pack

Keeping Internet Drafts "active" with two updates per year is a subversive tactics, but apparently already in use: Version 02 and 04 of the pack URI drafts are identical. This draft cannot be published as RFC, because its proposed URI scheme syntax is in conflict with the generic syntax in STD 66 [RFC 3986]. This is not permitted in BCP 115 [RFC 4395] about the registration of URI schemes, as noted by the URI review expert.

The pack scheme has to be fixed before it can get a permanent registry entry. The current entry is provisional, and the unmodified draft could be an attempt to prevent the reclassification of this wannabe-scheme as historical. The greater picture is that the Open Packaging Convention is a part of ECMA 376, the fast track input for ISO 29500 also known as ooXML.

SPF EAI and IDN TLDs

SPF, EAI, and IDN TLDs are not directly related, but I ended up as author of two related Internet-Drafts: SPF EAI is now at version 03, and the IDN test TLDs are already at version 11.

The new 2606bis draft with the eleven IDN test TLDs now also covers the corresponding nine IDN example labels. Reserving the nine IDN example TLDs is one of those procedural stunts. The contributor tricking me into this adventure does this all the time, it's scaring.

For what's it worth, there is also a relatively new OpenSearch draft, most of it still TBD. It depends on a cleanup of the IANA Atom link-relation registry adding the mostly identical HTTP link-relations and other missing pieces.

No plans to transition management of the root zone file to ICANN

In a letter to the ICANN Chair published 2008-07-30 the U.S. DoC notes:

First, it is important to note that the IANA functions contract was not part of the JPA mid-term review and the Department views these as two distinct instruments. As the community is aware, the IANA functions contract covers the performance of a series of currently interdependent technical functions that enable the continued efficient operation of the Internet, including processing requests to change the authoritative root zone file. Implementations of changes to the authoritative root zone file are performed by VeriSign under the terms of a separate agreement with the Department.

The Department believes that it is important to clarify that we are not in discussions with either party to change the respective roles of the Department, ICANN or VeriSign regarding the management of the authoritative root zone file, nor do we have any plans to undertake such discussions. Consistent with public statements made by the United States governement starting in 2000 and reinforced by the 2005 U.S. Principles on the Internet's Domain Name and Addressing System, the Department, while open to operational efficiency measures that address governments' legitimate public policy and sovereignty concerns with respect to the management of their ccTLD, has no plans to transition management of the authoritative root zone file to ICANN as suggested in the PSC documents.

In an article about the All important IANA the author wrote: An ICANN that is completely privatised and does not behave well afterward also might easily be stripped from the IANA contract and therefore its grip on the root zone.