Alex Bligh's blog

Nominet‘s ill-thought out proposals for .uk (since apparently expunged from their web site) appear to have been scrapped. The highlights:

Following our Board meeting yesterday, we are not proceeding with our original proposal on ‘direct.uk’ … It was clear from the feedback that there was not a consensus of support for the direct.uk proposals as presented, with some concerns cutting across different stakeholder groups.

Many of the defects they list were ones that I pointed out here and here – no particular credit for that claimed, as everyone to whom I have spoken made much the same points.

A little ominously Nominet continue:

As a result, we are going to explore whether it is possible to present a revised proposal that meets the principles of increasing trust and security and maintaining the relevance of the .uk proposition in a changing landscape. The Board plans to review progress at their June meeting, where they would decide whether there is an alternative option that addresses the concerns raised in the consultation.  This would be subject to further consultation prior to any final decision being made.

Let’s hope that if a new proposal is presented, it is truly new rather than a warmed up version of the last proposal. In particular, let’s hope that increasing trust in .uk is dealt with separately from opening direct registrations under .uk as the two issues are entirely orthogonal. There were some small nuggets of goodness buried deep within the original proposal (support for DNSSEC for instance), so I’ve no objection to a well thought out replacement proposal (or better pair of proposals) being presented.

A couple of days ago I wrote about Nominet’s plans to allow registrations in .uk. Apparently it’s not just me that thinks the ideas are misguided. Every person I’ve spoken to who has any significant dealings with Nominet doesn’t think much of them. Even the UK chapter of the Internet Society (ISOC), hardly known for rocking the boat, agrees.

I was asked on a mailing list to make public some of the highlights of Nominet’s proposals, so here goes:

• Permit direct registrations in .uk, but with no priority for those with existing .co.uk domain names;
• Maintain (almost certainly wrongly) that registrations directly in .uk are more secure, more trustworthy and safer to deal with, so everyone with a .co.uk feels they need a .uk as their misguided customer base things they are somehow shifty;
• Send out a paper form with every .uk registration to verify the registration address – remember certificates & reply forms anyone?
• Give trademark holders (even non-UK trademark holders) priority over those without trademarks who legitimately use names;
• Auction domains for which there are competition;
• Auction domains names that expire;
• Only permit registrations through a subsection of registrars; and
• Virus scan ‘domains’ (I think they mean web sites) and award those that pass a ‘trustmark’ apparently proving the site is ok.

In my view this not just a very silly idea, but an attempt to adopt a ‘registrar knows best’ model, with Nominet as policeman of what should and should not be trusted, and gives a huge boost to the international trademark lobby. If implemented, it will forever change the nature of .uk and Nominet (mostly in the latter case by making them look stupid, I suspect).

I wrote a longer blog article on this, and submitted an even longer full consultation response. But if you’ve got this far, and agree this is a stupid proposal, please fill in Nominet’s survey here even if you just go to the end and click ‘disagree with everything’. You’ve got until Monday close of business on Monday, I think.

Nominet announced a little while ago a consultation on allowing domains to be registered directly within .uk rather than in .co.uk. So, for instance, you can register example.uk rather than example.co.uk. In itself this is an interesting proposal worthy of consideration; I think the arguments for and against are pretty balanced. But Nominet has mixed it up with so much other stuff in a rather misguided attempt to improve internet security that this probably counts as one of their sillier ideas. In their current form, my view is that the proposals are seriously flawed.

My full consultation response can be found here. You can reply to the consultation online here (hats off to Nominet for making it easy to do). But hurry hurry hurry! It closes on Monday.

I’ve put a version of the executive summary of my response and my counterproposals below.

Links:

• Nominet’s compendious PDF consultation document
• Nominet’s link to respond electronically
• Nominet’s main consultation page
• My full response
• My much shorter list of highlights / low-lights

Summary

This is consultation document is one of the least well thought-out proposals I have yet to read from Nominet. Whilst there are a number of problems with the detail of the proposal, there are two significant and overarching problems: conflation of purpose, and naivety as to the proposed mechanisms.

Conflation of purpose

The first problem is that it conflates two entirely separate issues:

• The question of whether direct registrations should be capable of being made at the .uk level; and
• The question of whether Nominet should encourage more ‘secure’ registrations (validated contact address details, virus checks, DNSSEC and so on), and if so under what circumstances and under what commercial terms.

Nowhere in the consultation document does Nominet adequately explain why registrants within the existing subdomains should not be able to avail them of the ‘high security’ registrations, and why it is thus in the interests of Nominet’s stakeholders to require such registrants to re-register another domain within .uk, at considerable cost to them. As such costs involve not payments to Nominet and/or the registrar concerned, but also the far larger costs of re-branding, it seems perverse not to provide such ‘high security’ registrations where possible in .uk. A cynic might suggest this was simply a revenue or empire building exercise.

Equally, nowhere in the consultation document does Nominet adequately explain why the first-come first-served light-weight registration model which has served Nominet well from inception should not be available within direct registrations in .uk (assuming opening up .uk for third party registrations is a good idea). Nominet proposes that .uk be a domain with enhanced checking of registration details (including the rather quaint idea of sending letters by post). Nominet has already tried this model with (e.g.) ltd.uk and plc.uk. Whilst I cannot find current information on Nominet’s web site, I believe these subdomains are less than 1% of the size of co.uk and considerably smaller than (say) org.uk.

The only purported link is the one set out at the head of the next section, which is in my opinion laughably naïve.

Naivety of mechanism

The only arguable link between the two issues set out in the section above is that consumers will somehow draw a link between the fact that the web site they visit or email they receive has the domain name ‘example.co.uk’ or ‘example.plc.uk’ and conclude that is insecure (being registered as third level domains within existing SLDs), but also know that ‘example.bt.uk’, ‘example.pcl.uk’ (sic) or ‘exampleplc.uk’ are secure (being registered as second level domains within the .uk subdomain). This seems fantastically unlikely unless Nominet embarks on a world wide education program of its own domain registration structure.

Nominet appears to be around 15 years out of date in this area. Consumers increasingly do not recognise domain names at all, but rather use search engines. The domain name is becoming increasingly less relevant (despite Nominet’s research) as consumers are educated to ‘look for the green bar’ or ‘padlock’. Whilst SSL certification has many weakness in proving security, it is by no means as poor a solution as the solution Nominet proposes to replace it.

Recommendations

I make the following recommendations:

1. Nominet should abandon its current proposals in their entirety.
2. Nominet should disaggregate the issue of registrations within .uk and the issue of how to help build trust in .uk in general. Nominet should run a separate consultation for opening up .uk, as a simple open domain with the same rules as co.uk. There are plenty of arguments for and against this, but the current consultation confuses them with issues around consumer trust. Whilst consumer trust and so forth are important, they are orthogonal to this issue.
3. Nominet should remember that a core constituency of its stakeholders are those who have registered domain names. If new registrations are introduced (permitting registration in .uk for instance), Nominet should be sensitive to the fact that these registrants will feel compelled to reregister if only to protect their intellectual property. Putting such pressure and expense on businesses to reregister is one thing (and a matter on which subject ICANN received much criticism in the new gTLD debate); pressurising them to reregister and rebrand by marketing their existing co.uk registration as somehow inferior is beyond the pale (for instance marketing as ‘less secure’ as proposed here). Any revised proposal for opening up .uk should avoid this.
4. Nominet should recognise that there is no silver bullet (save perhaps one used for shooting oneself in the foot) for the consumer trust problem, and hence it will have to be approached incrementally.
5. Nominet should be more imaginative and reacquaint itself with developments in technology and the domain market place. Nominet’s attempt to associate a particular aspect of consumer trust with a domain name is akin to attempting to reinvent the wheel, but this time with three sides. Rather, Nominet should be looking at how to work with existing technologies. For instance, if Nominet was really interested in providing enhanced security, it could issue wildcard domain validated SSL certificates for every registration to all registrants; given Nominet already has the technology to comprehensively validate who has a domain name, such certificates could be issued cheaply or for free (and automatically). This might make Nominet instantly the largest certificate issuer in the world. If Nominet wanted to further validate users, it could issue EV certificates. And it could work with emerging technologies such as DANE to free users from the grip of the current overpriced SSL market.

People wanting Apple Mail to support subscriptions might like to look at:

https://github.com/abligh/imapmboxfilter

(warning: beta quality).

In a future version, I hope to make the ‘omit’ list optionally and automatically contain to a list of folders not subscribed to (i.e. you can use it to automatically track subscriptions rather than do it manually).

I’ve put my current work on the Apache vnc/tcp proxy (explanation here) on github, as people were (quite rightly) complaining a tarball was not particularly helpful. I’ve also added initial support for the guacamole protocol, though this is in need of optimisation. What’s on github is actually a clone of self.disconnect’s repo of apache-websocket, with my stuff in the vncproxy directory. It’s rough at the edges at the moment (don’t expect makefiles, substantial documentation etc.)

There is an occasional SEGV with guacamole (after 30 minutes of watching YouTube over it) which is, I think, due to me doing something as yet unknown which is not thread safe.

Comments welcome.

This blog post tells you how to add an emacs style for programming apache httpd and its modules. This is one of those things that is difficult to google for, as you’ll end up finding emacs modes for editing httpd.conf, or various Java-based apache projects.

Nice and simple. Add this to your ~/.emacs file:

(c-add-style "apache"
             '((inclass . ++)
	       (indent-tabs-mode . nil)
               (defun-block-intro . ++)
               (statement-block-intro . ++)
               (substatement . ++)
               (brace-list-intro . ++)
               (statement-case-intro . ++)
               (inextern-lang . 0)
               ))

Then when you want to use it, in emacs do:

C-c . apache

 
Or if you like typing:

M-x c-set-style apache

 
I don’t claim to be an emacs expert, but I can confirm this works.

Here is a really interesting article from GigaOM.

I’m going to quote two paragraphs:

I was a loyal (and repeat) Dell customer. Like clockwork, I would buy a new Dell desktop or laptop, mostly to keep up with Microsoft’s Windows OS. And I never really had a problem with Dell machines — they were solid and lasted forever. Except when Apple launched the Titanium Powerbook, I switched and never looked back. I think it was frustration with Windows more than Dell.

They are tied at the hip with Microsoft and its operating systems and as a result they cannot look beyond Microsoft. The fact is that both Dell and HP have offered consumers pretty much nothing in terms of innovation when it comes to PCs. Compare that with Apple and Samsung and you start to see that these two PC giants have been essentially twiddling their thumbs.

The lesson here is that tying your company’s future to a megalith in a way that makes it impossible to produce a truly differentiated product is a recipe for allowing competitors that don’t adopt this strategy to overtake you. PC hardware is commoditised and undifferentiated. Is a Dell laptop significantly different from a Lenovo or an Acer? No. It’s the software on it that makes the difference. And if your strategy is to produce a laptop with slightly different moulding that runs the same software as everyone else, then you are not going to be able to differentiate (at least not on product). That’s not to say producing computers that run Windows or are compatible Windows software is dumb (after all, the Powerbook will run Windows too, under a VMware Fusion, under Bootcamp) – in fact compatibility is probably a sensible strategy if there is an ecosystem to exploit. But making your product do no more than that means in practical terms it does no more than any of your competitors.

Agree? If so, cloud folks, substitute ‘Windows’ with ‘EC-2′, and ‘Windows compatible’ with ‘EC-2 compatible’.

Providing trackable download servers seems to be a tricky business. I wanted to reliably log download over http and associate them with an authenticated user, where that authentication is carried out over https (from WordPress), but not pass basic auth parameters to http in the clear for obvious reasons. Further, I wanted to track the outcome of this download in an easily parseable manner.

As far as I can tell, there is no easy way to do this. So I wrote a WordPress module and a perl CGI script to do this. It is intended to be used where:

• A website (such as a WordPress website) wants to offer a downlaod facility and record the downloads made. Let’s call this the ‘source website’.
• The download should come from a different website (possibly because the source website is https and large downloads over http are resource consumptive). Let’s call this the ‘download web site’.
• It is imperative that the download must be tracked by authenticated username, and by time and success.

The strategy used is as follows:

1. The source website contains a link to a download page, which appears to be on the source website, but in fact is redirect page.
2. The redirect page redirects to a dynamically constructed URL on on the download site. That URL is a URL for a CGI script with the following parameters: the file to be downloaded (or the name of a symlink to such a file), the id of the user against whom the download is to be logged, the UNIX time (since epoch), and a hash of the above plus a shared secret
3. The download script checks the parameters, checks the time is within a few seconds, and checks the hash value. If these match, it serves the file, logging start, success and errors. The purpose of the time check is so that the URL can’t realistically be distributed to others. The hash prevents tampering with the parameters.

It seems to work. I’ve put it under the MIT licence. Basically you can do anything you want with it. It’s in git here. Comments welcome.

At Flexiant, we had a need for a general websocket to tcp proxy. A cute apache module to do extensible web-sockets programming has been developed by self.disconnect, and is available on github here. I’ve hacked around with this to produce a generic, apache licensed, websocket proxy. A websocket connection is made over HTTP or HTTPS to apache, this calls the websocket module, which in turn calls my module, which makes an outbound tcp connection.

Some features:

• It supports base64 and text format sockets. So it will thus process (for instance) VNC which works using base64 encoding.
• Configuration is supplied through normal apache directory based configuration (see details below).
• It’s extensible (currently by changing the code, rather than calling additional modules)

The configuration section looks like this, in this case set up to proxy VNC using a novnc client:

<IfModule mod_websocket.c>
      <Location /vncproxy>
        SetHandler websocket-handler
        WebSocketHandler  /usr/lib/apache2/modules/mod_websocket_tcp_proxy.so tcp_proxy_init
        WebSocketTcpProxyBase64 on
        WebSocketTcpProxyHost 192.168.199.199
        WebSocketTcpProxyPort 5900
        WebSocketTcpProxyProtocol base64
      </Location>
 </IfModule>

Note that the parameter you specify for Location must not be a file or directory that exists with your docroot, or you will just get 404 or similar. So, in the above example you must not have a file or directory at ${DOCROOT}/vncproxy.

I discovered that on a default apache install, you may also want to change the RequestReadTimeout, i.e.

<IfModule reqtimeout_module>
  RequestReadTimeout body=300,minrate=1
</IfModule>

I’m going to try and persuade self.disconnect to stick this in the examples directory for apache-websocket, but in the mean time the source is available here. Put it in the examples directory of apache-websocket, then compile, install and enable it with it with:

sudo apxs2 -c -i -a -I.. mod_websocket_tcp_proxy.c

[Update: see new blog post, git repo link here]

I blogged here about adding SQL support to dhcpd. I’ve fixed a couple of issues – mainly memory leaks. I have no idea how I missed these before (sigh). The good news is that the server ran for sufficiently long for the process to get to many gigabytes in size, and nothing crashed!

You can find a new patch, against dhcpd 4.2.0-P1 (but should work against dhcpd 4.2.1-RC1) here.

See the original post here for build instructions and documentation.