DynDNS reports a DDoS attack against their Webhop services. This also affects xyzzy.webhop.info and xn--80akhbyknj4f.boldlygoingnowhere.org. The first address used to be a HTTP redirection to my mirror site, at the moment it is a redundant redirection to xyzzy.
The second address is used in some IDNAbis experiments with IRIs; the actual content are now subpages of xyzzy/home/googlets.
Instead of a thank you to the news.t-online.de team in RFC 5538 I added the historic videotex: URI scheme to the IANA registry.
When the WWW with http: and https: started to replace gopher: and various videotex: systems (BTX, minitel, Prestel) this URI scheme allowed links to videotex: resources for browsers supporting it. It was a nice system for limited clients including DOS boxes, but the software to create videotex: pages was very expensive.
Is it only me, or do we really invent the wheel again and again ? Now we have WAP and a .mobi TLD, but what was wrong with telnet: and gopher: ? At least ftp: is still alive and kicking. And maybe news: survives.
If you know a public specification for an unregistered URI scheme, please submit it to IANA following the rules in RFC 4395 — in a nutshell this is a public review on an expert mailing list.
The famous son-of-1036 Internet Draft about the Netnews article format was published as historic
Son-of-1036 (also known as 1036bis) was the first Internet Draft I've ever seen 15 years ago. Admittedly I didn't know the exact difference between draft and RFC at this time, let alone the various RFC series and status flags.
RFC 1849 was immediately obsoleted by the work of the IETF USEFOR WG:
Folks interested in Usenet & Netnews can be rather stubborn, one of the reasons why this WG needed more than a decade to finish its work (presumably a new IETF record). Thanks to Charles Lindsey, Russ Allberry, Ken Murchinson, Henry Spencer, Alexey Melnikov, Harald Alvestrand, Lisa Dusseault, and many other contributors on the USEFOR mailing list.
Thanks also to anybody helping to publish…
… while I was offline for more than two years. That this RFC took so long was clearly my fault. Anonymous credits I coludn't add in this RFC: The news.t-online.de team triggered my interest in an Internet Draft by A. Gilman about news:, nntp:, and snews: URLs. Later Paul Hoffman started the work to obsolete all old URL schemes in RFC 1738 by new RFCs based on the Internet Standard for URLs (STD 66, RFC 3986).
There are still some schemes in RFC 1738 not yet obsoleted by fresh RFCs, notably file:. Maybe Martin Dürst could finish his work on the awfully complex mailto: scheme, I have not yet checked this. If you find no old URL scheme to work on try dict:.
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 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.
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.
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 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.
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.
