More cooking with cookies

Sorry, this blog isn't intended to be all about cookies. I'm not even very interested in them but this whole EU regulation thing just keeps growing and this is as good a place to keep notes about it as anywhere.

The Department for Culture, Media and Sport has published an open letter on the subject:

• http://www.dcms.gov.uk/images/publications/cookies_open_letter.pdf

This seems to be trying to make some interesting assertions, including the idea that consent doesn't always need to be obtained in advance (based on the subtle difference of some instances being preceded by "prior" and some not). It does seem to say that whatever you do they don't think that relying on current browser cookie controls is enough.

The other interesting development is the addition of a banner to the ICO's web site that tells you about its cookie use and allows you to opt into more cookies (and incidentally get rid of the banner):

• http://www.ico.gov.uk/

(Hint: if you want to go back to the default state after you've accepted their cookies then delete the cookie called ICOCookiesAccepted, or all cookies from www.ico.gov.uk).

I think they are implementing this in their CMS and so serving different versions of their pages to different people, so an identical approach won't work on a purely static site. Note BTW that this means they have to disable caching which may have performance and load implications. I have an idea that a pure JavaScript approach might be possible for a static site, but my JavaScript isn't up to it! I'm rather hoping that Google might provide a canned solution along these lines for Analytics.

Further thoughts on cookies (or lack thereof)

The amendments to The Privacy and Electronic Communications (EC Directive) Regulations 2003 as they affect the use of cookies have now been published in The Privacy and Electronic Communications (EC Directive) (Amendment) Regulations 2011. What's surprising (to me) is how little has actually changed, though obviously a small change to legislation can clearly have a wide effect. What also fooled me is that if you don't read the ICO's guidance carefully (as I didn't) you might (as I did) think the change was bigger than it was. For example I thought paragraph (4) was new, and it isn't. In fact it hasn't changed at all.

One interpretation of all this is that many/most sites may already fail to comply with the 'old' regulations. Were you really giving subscribers "the opportunity to refuse the storage of or access to that information"? ... because if you were it should surely be trivial to turn the tests around and get consent instead. You could argue that all that's happened now is that, by requiring consent, the new regulations have made contraventions more obvious.

For your delight, here is paragraph 6 from the original  regulations with (if I've got it right) the new amendments applied to it (removals struck through, new text underlined):

Confidentiality of communications 

6.—(1) Subject to paragraph (4), a person shall not use an electronic communications network to store information, or to store or gain access to information stored, in the terminal equipment of a subscriber or user unless the requirements of paragraph (2) are met. 

(2) The requirements are that the subscriber or user of that terminal equipment— 

(a) is provided with clear and comprehensive information about the purposes of the storage of, or access to, that information; and 

(b) is given the opportunity to refuse the storage of or access to that information 

(b) has given his or her consent 

(3) Where an electronic communications network is used by the same person to store or access information in the terminal equipment of a subscriber or user on more than one occasion, it is sufficient for the purposes of this regulation that the requirements of paragraph (2) are met in respect of the initial use. 

(3A) For the purposes of paragraph (2), consent may be signified by a subscriber who amends or sets controls on the internet browser which the subscriber uses or by using another application or programme to signify consent. 

(4) Paragraph (1) shall not apply to the technical storage of, or access to, information— 

(a) for the sole purpose of carrying out or facilitating the transmission of a communication over an electronic communications network; or 

(b) where such storage or access is strictly necessary for the provision of an information society service requested by the subscriber or user.

Not all that different, is it?

IPv6 Gotchas, and 8th June 2011

IPv6 has been 'imminent' for a very long time. However it's shortly going to have a bit of a boost. 8th June, 2011 is 'World IPv6 day' when various big players (Google, Facebook, Yahoo!, Akamai, ...) will enable IPv6 access to their services alongside the existing v4 access as a world-wide test flight for a wider deployment. In Cambridge, some of the services run by the University Computing Service will be participating.

For almost everyone this will make no difference at all - if, like most people, you only have have access to IPv4 then you will just go on using that as you always have. Likewise if you have working IPv6 you should see no difference even though you'll be using it rather more than normal. But if you have broken IPv6 support you are likely to have problems on the day. If you want to check, the test pages at http://test-ipv6.com/ and http://omgipv6day.com/ seem to be useful, and the University's My IP page will at least tell you if have IPv6 connectivity with the University.

It's possible to think of IPv6 as just IPv4 with longer addresses, but there are enough differences and gotchas to make life difficult for both clients and servers. Here are some that we've identified:

• Auto-configuration. IPv6 natively supports auto-configuration, so if you connect most (recent) computers to an Ethernet that includes an IPv6 router the computer will acquire an IPv6 interface complete with address and default route without you having to do anything. A computer with an active IPv6 interface will normally try to use IPv6 when talking to a service that advertises a IPv6 address, so you may find ourself using IPv6 without knowing it. This has a couple of exciting consequences:
• If the IPv6 router you contacted isn't actually connected to the v6 Internet then your traffic isn't going to go anywhere useful. Your computer will probably fall back to using IPv4, but probably after a long (multiple tens of seconds) delay. This is going to look to users as if the internet is going very s l o w l y. It's rumoured that some versions of Windows will under some circumstances spontaneously advertise themselves as IPv6 routers.
• Even if you are successfully using v6 (knowingly or otherwise), unless you do something your address won't be in the DNS. So looking it up won't result in a .cam.ac.uk (or whatever) host name, and services that make access control decisions based on client host name aren't going to recognise you. [Even if the service makes decisions based on address rather than host name it will get things wrong if its access control lists haven't been extended to include the necessary IPv6 range(s)].
• If a service advertises a v6 address but doesn't actually respond to requests on that address then again there could be a longish delay before your computer falls back to trying IPv4.
• It's entirely possible (though probably not a good idea!) for a service to behave completely differently when accessed over IPv6 from how it does over IPv4. For a start, the process of resolving host names to addresses is entirely separate for IPv4 and IPv6 so there's no particular reason for the two addresses to end up on the same server. Further, web servers providing virtual hosts need a mapping between IP addresses and the corresponding virtual hosts and it's all to easy (as the operators of www.ja.net found some time ago) to forget to extend this mapping to include v6 addresses, with the result that v4 and v6 users end up seeing the content for different virtual hosts when requesting the same URL. 
• The IPv4 address 127.0.0.1 always corresponds to the local computer and conventionally has the name localhost. It's quite common for components of a server to communicate using this address (e.g. a web application and its database), and equally common to actively restrict communication to this address or name. The coresponding v6 address is '::1' - if this doesn't correspond to the name 'localhost' or if access lists only recognise 127.0.0.1 then, if IPv6 is enabled on a server, it may find that it can't tall to itself!
• There are a lot of programs out there, in particular log analysis programs, that implicitly expect IP addresses to look like 131.111.8.46. Such programs may be 'surprised' to come across addresses like 2001:630:200:8080::80:0. How they behave will depend on how well they have been written, but in some cases this may not be pretty. Further, note that library calls that lookup v4 addresses to find the coresponding host name may not work with v6 addresses.
• Firewalls and packet filters will need IPv6 configurations to match their IPv4 ones, and they are unlikely to be able to automatically derive one from the other. So, by default, they are likely to either block all IPv6 traffic or allow it - neither is likely to be what's wanted.
• A lot of networks (especially home ones) use RFC 1918 'private' addresses and network address translation (NAT) when talking to the wider Internet. While not intended as a security measure, this does somewhat shelter machines on such network from active attack from the Internet. Use of private addresses and NAT are a response to the shortage of IPv4 addresses which isn't a problem in the IPv6 world, and so they are not widely supported (if at all). So enabling v6 on a previously 'private' network may expose previously hidden security vulnerabilities to the world, which may be unfortunate.

IPv6 is probably finally coming. Some of us may get an early brush with it on 8th June. It really is time to start thing about the consequences.