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.

RxWhois IETF 72 edition

Based on the latest DNSBL Internet-Draft rxwhois 2.1.2 now supports DNSBL queries for IPv6.

I've not yet found any black listed IPv6. The potential test entries ::FFFF:127.0.0.2 or ::2 are not listed on the nine pre-configured DNSBLs used by rxwhois.

The simple REXX code to transform an <IPv6address> into the reverse ip6.arpa format turned out to be more interesting than I thought; see procedure XIPV6 in the source… :-)

The classic SPF FAQ

After years on the SPF help list it is interesting that some folks still have difficulties with the very simple idea behind SPF. Modified question to protect the innocent:

my mail is MX relayed via anti.spam.example and then on to good.isp.example, and good.isp.example is reapplying SPF as if anti.spam.example were the originating MTA.

Answer: If anti.spam.example forwards mail to third parties it is the originating MTA as far as SPF checkers at these third parties are concerned.

can anyone say whether SPF would normally have any problems with mail relay?

Answer: No problems with mail relays on the side of the sender or on the side of the receiver. SPF is in essence for the one critical hop where two unknown strangers (sender and receiver) meet.

Now if you introduce a second critical hop in the form of "forwarding to third party" this will nowhere work "as is":

S -> F -> R instead of S -> R

The sender S defines S-IPs permitted to send MAIL FROM S. The sender S has no reason to permit sending IPs of any forwarder F or forger F, in fact S has no idea who F is.

The receiver R checks that MAIL FROM S comes from one of the S-IPs as defined in the sender policy of S. Without intervention sending IPs of forwarder F will FAIL, as for sending IPs of a forger F.

There is no difference between "forwarding to third party" and "forging" wrt SPF. Of course there are some things a legit F or R could optionally do:

• R could white list F as legacy forwarder (legit forger).
• F could rewrite MAIL FROM S to S@F (like mailing lists).
• F could store mails, and let R use say POP3 to fetch it.

If F and R do nothing about this situation – and that is perfectly allowed – R sees a FAIL, and hopefully rejects the MAIL FROM S actually sent from F.

After that F is obliged to send an error report (bounce) back to S. The sender S can then bypass the forwarder F and send the mail directly to R (if the bounce contained the real address at R).

If you think that there is a problem, then your problem is almost certainly with forwarder F, not with S or R.

It is up to you how you solve your problem with F. In my opinion an entity using the name anti.spam.example should know that forwarding mail "as is" to third parties is a part of the problem, YMMV.

Frisian frs vs. stq

Before 2006 there was only one language tag for the Frisian languages, fy. 2005-11-16 ISO 639.2 identified fy as Western Frisian, adding frr for Northern Frisian, and frs for Eastern Frisian. So far it is clear, ignoring the detail that Northern Frisian consists of several rather different dialects.
 
After the publication of RFC 4646 the IANA language subtag registry now contains fy, frr, and frs. But not fry, this is an alpha-3 alias of fy, and the RFC 4646 rules are roughly that shorter alpha-2 ISO 639 codes win.
 
It is not obvious what the Y, R, and S in these subtags stand for, one plausible theory is that S stands for Seeltersk, the Frisian language spoken in Saterland; see the S marker on the map.
 
Interestingly ISO 639-3 uses stq instead of frs for this language, this is also the code used for the stq.wikipedia. Two alpha-3 ISO 639 codes for one language are rather strange, and there is another theory to explain this situation: frs is the code of the Lower Saxon nds dialect spoken in Eastern Frisia, the territory including Aurich at the A marker on the map. In that case the S might stand for Saxon.

The ISO 639-2 rules make it fairly difficult to get codes for nonsense, there must be some evidence what they had in mind when frs was registered. OTOH with codes such as eur and tlh Occam's razor might miss the point.

rxwhois 2.1.1

The modifications in version 2.1.1 of rxwhois.cmd include the addition of whois.nic.asia, whois.nic.bi, whois.adsib.gob.bo, whois.registry.gy, whois.nic.ht, whois.nic.im, whois.kcce.kp, whois.nic.mq, whois.nic.org.mt, whois.nic.pr, whois.co.ug, and vunic.vu from the usual sources: IANA, whois-servers.net, guesswork.

Lost in space: whois.nic.ki, whois.nic.tel, and whois.cctld.uz. Some domain grabbers in the TLDs CM, FM, GD, KN, and PN were ignored. Eleven other whois.whatever.tld hosts were added, but these are (yet) no whois servers. The rxwhois manual page contains the version history up to 2.1 over the last six years.

HTML5: asinine + selfish

HTML5 "reuses the well-known URL moniker in the most asinine way, and blames the other standards (which he thankfully has no control over) for not supporting all of the possible crappy raw data that could be input in an HTML attribute."

"That's why this whole discussion about creating new identifiers and new protocols in HTML is a total waste of time — the rest of the world does not want it and will not allow it to be published as HTML5. Pound the sand all you like; the network standards will not change because they are designed to support everyone's needs, not just the selfish desires of a very small set of browser developers."

So far from a co-author of RFC 3986 (the Internet Standard STD 66 for URLs) and of RFC 2616 (the currently revised HTTP specification) in one of the various HTML5 flame wars.¹

Fast track IDN ccTLDs

There will be hundreds, thousands, or even millions of new top-level domains, from the variety known as gTLDs. "ICANN is working towards accepting the first applications in the second quarter of 2009", as noted in their process FAQ.

This also affects the "fast track" introduction of internationalized top-level domain names for territories with a country code, also known as IDN ccTLDs. "The Board intends that the timing of the process for the introduction of IDN ccTLDs should be aligned with the process for the introduction of new gTLDs", stated in an ICANN Board resolution.

Enough time to fix the toplabel bug in RFC 1123, document the IDN test TLDs as reported here ten months ago, and get ready with IDNAbis.

Lost + found: 268,435,455 free IPs

Three Internet Standards, one of them historic, RFC 3330, an RFC 3330 erratum, and three Internet Drafts entered the battle over 6.25% of all IPv4 addresses:

RFC 3330 lists special IPv4 addresses, among others 240.0.0.0/4 also known as class E. Allegedly "reserved for future use" on page 4 of the historic RFC 1700, formerly known as STD 2. The notation 240.0.0.0/4 stands for all IPv4 addresses starting with the four bits 1111, hex. F0 is decimal 240.

Page 4 of RFC 1700 actually belongs to an introduction with basic terms copied from RFC 1122, a part of STD 3. In fact RFC 1122 specifies 0.0.0.0/8 and 127.0.0.0/8 as listed in RFC 3330, but not 240.0.0.0/4.

RFC 1122 and the RFC 1700 intro only mention class E, but it is specified in RFC 1112, a part of STD 5. Apparently RFC 3330 got this wrong, RFC 1700 by itself did not register anything at all, it was a snapshot of various IANA registries with references to registrations of all "assigned numbers".

As the future of IPv4 is now before IPv4 is replaced by IPv6 the question is what to do with these 6.25% of all IPv4 addresses "reserved for future use" minus one 255.255.255.255 specified in RFC 1122. Three Internet-Drafts fight over it:

• IANA proposes to keep class E as is, because RFC 1700 said so.
• CISCO proposes to unreserve these 268,435,455 IPs reserved in RFC 3330.
• A third draft suggested to reserve these IPs for private use updating RFC 3330.

Ignoring the expired third draft as bad idea it will be interesting how the IETF manages to free this huge pool of IPv4 addresses while the rest of the world is busy to upgrade their hard- and software to IPv6. Apparently RFC 1112 does not do anything with class E apart from reserving it, it is about class D 224.0.0.0/4 multicast addresses. Or as RFC 1812 puts it:

The Class D (IP Multicast) and Class E (Experimental) address spaces are preserved, although this is primarily an assignment policy.

Update 1, it's a bit more complex: RFC 988, a predecessor of RFC 1112, created the 224.0.0.0/4 multicast addresses as class D out of the in RFC 960 reserved 224.0.0.0/3 block, the remaining 240.0.0.0/4 block got the name class E in RFC 990 obsoleting RFC 960. After that RFC 997 updated RFC 990 and listed the "Internet numbers" including class E, while RFC 1010 obsoleted RFC 990 and listed the "assigned numbers". RFC 1010 was a predecessor of RFC 1700 over many steps, RFC 997 was the predecessor of RFC 1166. In other words, RFC 1112 specifies class D, and RFC 1166 explains the remaining class E. RFC 1166 is only "informational", that's good news from the procedural side.

Update 2, a fourth draft was published: T. Savolainen proposes to use class E for hosts indicating that they can handle this , e.g., for dial-up connections.

Blogger trackback form

Encouraged by an immediately working backlink for the last post I added an experimental trackback form to the template of this blog, it allows manual trackback pings:

<!-- trackback form --><b:if cond='data:blog.pageType == &quot;item&quot;'>
 <b:if cond='data:blog.title != &quot;&quot;'><!-- trackback blog_name -->
 <b:if cond='data:blog.pageName != &quot;&quot;'> <!-- trackback title -->
 <form action='#requires.javascript' id='track' method='get' name='track'
       onsubmit='document.track.action=document.track.back.value;
                 document.track.method=&quot;post&quot;' target='_blank'>
 <input expr:value='data:blog.url' name='url' type='hidden'/>
 <input expr:value='data:blog.title' name='blog_name' type='hidden'/>
 <input expr:value='data:blog.pageName' name='title' type='hidden'/>
 <input name='back' size='50' type='text' value='http://delorie.com:81/'/>
 <input type='submit' value='ping'/></form>
</b:if></b:if></b:if><!-- end of trackback form -->

Apparently you can add this form to any type='HTML' widget after going to Layout: Edit HTML and checking Expand Widget Templates. I used #track:target { display: block; } in the CSS to show the form only when it's the target. Text mode browsers will see it anyway, but maybe they have no JavaScript.

I ✅ Unicode

Some days ago Mark noted on the Official Google Blog that UTF-8 finally managed to be more popular than US-ASCII, I found it on the Q&A Weblog.

Actually it is not that impressive, it merely shows the Unicode conspiracy at work, UTF-8 is designed to replace US-ASCII in the next decades, one encoding to rule them all.

But it is fascinating to see the usual suspects working together on IDNAbis, another important step in the master plan, among others Vint as author of RFC 20, Mark as co-author of UTF-7 when UTF-8 was not yet ready for prime time, Harald as author of RFC 2277, and John who recently added two critical missing pieces to the puzzle:

• RFC 5137 - ASCII Escaping of Unicode Characters (BCP 137)
• RFC 5198 - Unicode Format for Network Interchange

Hamburg-Web

An attempt to add this blog to HH-web.de finally worked, while I was at it I created a HH-web search googlet and learned some new CSS tricks.

For years I used hreflang="de" in links to German sites on English pages or vice versa, without visible effect, and likely no effect at all. Now I found a way to do something with it:

:link[hreflang]:hover:after {
     content: " " attr(hreflang); font-weight: 100;  
     vertical-align: super; font-size: xx-small;   }

This construct matches links with a hreflang, and displays the value as small as possible at the end of the link while the mouse hovers over it. Test it with the HH-web link above.

Another nice CSS feature is :target, not displaying the ugly blogger dashboard is one thing, but now I can also get it back when I need it with an invisible link in the upper left corner of this blog.

Googlet gallery

After a year one of my googlets is apparently used by some folks, great, it encouraged me to work on the whole set, add some settings such as the help language on the PDA LEO googlets, and create a gallery.

New entries are googlets for the German and English Heise whois for older browsers without OpenSearch support. For a different preview see googlemodules. No, I've not given up on the command line rxwhois client, but allegedly some users don't like command lines... ;-)

Another new entry is a MetaWikiHelp googlet, the Wikipedia help often is not good enough when working on other MediaWikis with different features and rules.

Custom search googlet

Transforming Google CSEs into OpenSearch descriptions is simple, even when Firefox needs some proprietary <moz:SearchForm> magic to get it right.

For older browsers not supporting OpenSearch each CSE has its own default gadget for uses on iGoogle, blogger, and elsewhere. I created a smaller configurable tiny CSE variant, to use it edit the cx-number, e.g., 001904119753490578822%25:zvsejdqm-pw for the xyzzy-CSE.

CSEs hosted by Google have one issue, creators cannot easily publish the source for users wanting to know what the CSE really does. Here's a snapshot of the sites currently covered by the xyzzy-CSE:

alvestrand.no, arkko.com, ecma-international.org, gmane.org/gmane.ietf.* (ditto org.w3c.*), iab.org, iana.org, icann.org, icir.org, iesg.org, ietf.org (excl. lists), imc.org, irtf.org, isc.org, isi.edu, isoc.org, itscj.ipsj.or.jp/ISO-IR, jabber.org, langtag.net, omniplex.blogspot.com (this blog), openspf.org, postel.org, rfc-editor.org, rfc-ignorant.org, rsa.com/rsalabs, standardstrack.com, unicode.org, w3.org, xml.resource.org, xmpp.org, and my own xyzzy mirrors (plus googlets).

MD5 1.6: POP3 and UUID

Version 1.6 of the MD5 test suite covers RFC 5034 (Digest-MD5 for POP3), RFC 4122 (UUID version 3), and an old RFC 1910 example. The POP3 example belongs to the MD5-sess series.

The UUID example is apparently wrong, it swaps the byte order unnecessarily. Examples published by python.org and ossp.org agree with that theory, I'll submit it as erratum.

MD5-sess and RFC 5090

RFC 5090 was published, it fixes some problems with the MD5 examples in RFC 4590. Version 1.5 of the MD5 test suite now contains the new RFC 5090 RADIUS examples.

The updated test suite contains a new procedure AUTHTTP for the RFC 2617 idea of MD5-sess noted in the errata. The old DIGEST procedure uses the RFC 2831 MD5-sess algorithm. Six new test cases cover MD5-sess examples published in RFC 2831 and 4643 using the RFC 2617 algorithm. Hopefully this will be documented in an RFC moving RFC 2831 to HISTORIC.

Hamburg's vote on ooXML

Microsoft's quest to forge the one ring will soon reach a critical stage. In the BRM on OfficeOpen XML a so-called German delegation will have six votes, one of them the tax authorities of the city of Hamburg. In 2007 DIN supported ooXML in a controversial procedure, with Hamburg's fiscal authority under the yes votes.

Historical background, Hamburg was once the home of StarOffice, a name still used for Sun's OpenOffice version, closely related to what later became ODF, an ISO standard roughly covering what MS Office 2007 as so far only potential ooXML implementation offers. Of course MS Office isn't free like OpenOffice, and with about 6000 pages the ooXML draft is considerably more elaborated than ODF.

It is not obvious why Hamburg's fiscal authority supported a draft allegedly identifying 1900 as leap year, where dates before 1900 don't work. As Excel simplification that is funny or even acceptable, but Excel is a commercial product and no international standard. Just one of many ooXML issues, maybe addressed in the additional 2293 pages submitted for the BRM.

It fits that the citizens of Hamburg get a chance to elect a new parliament one day before the BRM. Related, Google doesn't like ooXML, their German HQ is in Hamburg, and they got no vote in the relevant DIN committee.

Patch that zeppelin

XML is ten years old, good to know, waiting for the monthly W2K patch orgy to finish I used the time for my education. The worst update this month are 36 MB for Adobe Reader 8.1.2.

Also ten years old is RFC 2277, the IETF Policy on Character Sets and Languages. This is a nice piece of RFC number magic, RFC 2278 used to be the IANA Charset Registration Procedures, now 2978, and RFC 2279 used to be UTF-8, now 3629 (STD 63). The magic also works backwards, the predecessor of 2279 was 2044, and RFC 2045...2049 is MIME. The MIME type registration procedures used to be 1590 next to RFC 1591, i.e. what is today ICANN. After ten years they are now getting serious with I18N for domain names and other missing pieces in this puzzle.

RealPlayer BadWare

RealPlayer 10.5 and 11 were identified as BadWare. The unofficial Real Alternative 1.75 claims to use 6.0.12.1662 components, apparently not affected by various 10.5 vulnerabilities.

STD 68: ABNF (RFC 5234)

The IETF created the sixth Internet Standard (STD) in about 50 months, STD 68 specifies the ABNF used in many RFCs:

• STD 68, RFC 5234, 2008-01: ABNF
• STD 67, RFC 4506, 2006-06: XDR
• STD 66, RFC 3986, 2005-01: URIs
• STD 65, RFC 3551, 2003-07: RTP/AVP
• STD 64, RFC 3550, 2003-07: RTP
• STD 63, RFC 3629, 2003-11: UTF-8

The jump in the publication dates (2003-11 vs. 2003-07) is an effect of promoting RFCs 3550 and 3551 to STD without modification. STD 62 about SNMP version 2 published 2002-12 is a set of eight related RFCs.

QuickTime security flaws

In a SANS Diary entry they forgot to mention that there is no secure version for W2K, affected users should uninstall QuickTime, well, quickly. Products depending on QuickTime and claiming to be W2K-compatible could be considered to be broken, IANAL.

Having said this it is already rather tricky to find the 2007-11-12 QT Lite 1.1.2 for W2K with the 7.2.0.245 components, the download for this link is a damaged file, and an apparently working file was removed from where I found it. QT Lite 1.1.1 and QuickTime Alternative 1.90 still use the 7.2.0.240 components, and all these unofficial variants likely inherited the security flaws of the corresponding official versions.

Hunting W2K tools can be a pain, I try to stay on Microsoft's sites for security reasons. Check out the Petri IT Knowledgebase if you're looking for say a W2K-version of NTrights.

ICANN Ombudsman

After stumbling over a DomainTools Blog (1) entry discussing a new low in NetSol's (2) business practises, I tried to send an inquiry to the ICANN Ombudsman. That's a Web form with six required fields, but it won't let me submit it for no obvious reason. Fine, I can post it here:

Incident date	2008-01-08
Registrar	Network Solutions, LLC
Description of act, omission or decision	Please take a look into (1) and (2)