JRS developments: protecting privacy

One of the fun parts of my job is working with colleagues to understand the technical developments they are considering and work out whether there are any legal or policy implications that we need to be working on in parallel. One advantage of doing this at an early stage is to get views from those likely to be affected, so please feel free to comment. A couple of examples have recently come up in the context of JANET Roaming/eduroam involving the transfer of additional information between the user’s home site and the location they are currently visiting.

The first is a field called Operator Name (ON), which the visited site can use to tell the home site where the visitor is calling from. I was actually surprised to learn that the home site doesn’t already know this, but apparently any location information is lost when the authentication request passes through the National RADIUS Proxy. All the home site gets is a request to authenticate a roaming user. This can make it tricky for home sites to debug problems, especially if the authentication attempt fails at an early stage, before the user has identified themselves. The home site’s logs may indicate that an authentication attempt failed, but with nothing other than a time to link it to the particular user. For a busy site that can make it hard to find the relevant log entries. Operator Name can help with this identification, and also let home sites spot if there are any recurring problems with authentication attempts from a particular visited site.

So are there any legal or policy issues involved? The home site can associate the Operator Name (i.e. geographic location) with a particular user, which makes it personal data as defined by the UK Data Protection Act 1998. However the home site already processes a lot of personal data about their users, so the relationship between them is already subject to the Act.  In theory the additional piece of information should be notified to the user (it’s necessary for the effective delivery of the Roaming Service, so the user doesn’t need to give additional consent for it). But I feel it comes very close to “telling the user something they already expect”, which the Information Commissioner has recently identified as an unnecessary waste of time. Indeed for the majority of successful authentications I suspect that the user will very soon disclose their location anyway, by accessing a home site server using a visited site IP address. If we do decide to recommend Operator Name, therefore, I’ll be suggesting that we mention it in our JANET Roaming documentation, but that we don’t need to spend a lot of effort updating policies, agreements or guidance to home and visited organisation.

It seems to me there are significantly more challenges with the second field we discussed: Chargeable User Identity (CUI). This is a value that is transferred in the opposite direction, from home site to visited site; it is designed to allow the visited site to recognise (but not directly identify) different users. Its original purpose was to allow users to be charged for roaming on commercial networks, but it could also be used by a visited site to apply different rules to individual users, for example to ban access by a person who has caused problems in the past. That would make support more difficult (since the home site will have no idea why the user has not been able to connect), but might be considered worth that disadvantage. Unfortunately the CUI value would also let the visited site assemble a record of the activity of a single user: although the value itself does not give the user’s name it’s quite possible that a user might accidentally reveal that, for example by entering their name into a website that either didn’t use SSL encryption or placed the name into subsequent URLs. This sort of privacy problem has led most (though not all) European regulators and courts to conclude that opaque identifiers of this kind are personal data, while also conceding that doing so may make it impossible to comply with data protection law! It’s true that even without a CUI value a visited site can anyway do that sort of unwelcome tracking using either the MAC address of the visitor’s computer or the IP address that they allocate to it. The law requires such a visited site to inform the user what they are doing, but if the home site is providing the CUI value on which it is based then they are likely to be responsible for ensuring that that visited site does so and, at least in part, to be liable for any harm that results if it doesn’t.

So if we were to adopt CUI for JANET Roaming it seems likely that we would have to, at least, change the JRS Policy to specify how visited sites can use the value, how long they can retain it, and who is responsible for informing the user. This might let us comply with current data protection law but that law is likely to change in the next few years following a European revision that we hope will deal better with opaque identifiers. And things would get even more complicated if CUI values were exchanged with other eduroam partners, since there are varied interpretations of the law even within Europe and very significant differences in other countries. Especially given the uncertainty over the EC revision, this feels like a thoroughly messy area of law to get into if we don’t really need to.

In fact the uses of CUI that we have come up with so far can be addressed in other ways. For example the JRS Policy already requires home sites to deal with problem users, if necessary withdrawing their entitlement to roam; in emergency a visited site can disable authentications from a particular home site, though they must inform the JRS operator and work with them and the home site to resolve the problem. Detecting virus infected machines and placing them in a quarantine network may actually be better done using the MAC address of the equipment (since here it is the machine, rather than the user, that is the immediate threat). That would get us back to the support issue, so we may also need to look at how the user can be informed of the problem: fortunately there are already some good ideas on that bouncing around on mailing lists. So my fun continues!