Knowledge base Data Retention Directive
The The Data Retention (EC Directive) Regulations 2009 specifies a duty that we, as an ISP, must log and retain certain communications data. We must then provide that data to a wide variety of people under the RIP Act.
Section 10(1) means that we do not have to start logging data until we given a notice in writing. We have not been given such a notice.
However, even if we are required to comply with the directive, it seems to us to be full of holes. Serious ones. The following is a summary of the holes we think exist. We're not lawyers, so we may have some of these wrong, but we intend to ask the questions if and when we get a notice.
Section 2(h): User ID
The directive defines this: “user ID” means a unique identifier allocated to persons when they subscribe to or register with an internet access service or internet communications service.
This is quite a specific definition, but it has some holes. For a start, in what context is the user ID unique? For our services it is relevant that we have user IDs - i.e. we have an identifier for a user for broadband and email. It is the login on the control pages (clueless). It is relevant that an email address is not a user ID. This is clear because it (a) is not necessarily unique to a user;(b) it may not be a valid one (think of all the spam); (c) We don't allocate it, it is picked by our customers; (d) it is not allocated or picked when subscribing to the service but later when the user picks a mailbox or creates forwarding rules.
Given requirements to log user ID in some cases we are wondering if those drafting the act thought an email address was a user ID?
Section 3: Only logging data processed/generated
Section 3 states These Regulations apply to communications data if, or to the extent that, the data are generated or processed in the United Kingdom by public communications providers in the process of supplying the communications services concerned
This is quite specific, and means that we don't have to look up or obtain anything that we are not already processing or generating. This is good news, and it could add a lot to the complexity of some services if we did so. However, it is not 100% clear. If, for example, or email servers do not process or generate the name and address of sender or recipient of the email, then does that mean we do not have to log that - I would say yes. However, one may argue that as a company we do process or generate the name and address as part of providing the service when we do the billing. It is not 100% clear. It could easily be solved by subcontracting the email services to a separate company that do not see any name or address details, which clears up any confusion on this point.
It is also clear this only applies where the data are generated or processed in the UK. It is a simple matter to provide some of these services in another country if we wanted to.
Section 4(5): No revealing content
Section 4(5) states No data revealing the content of a communication is to be retained in pursuance of these Regulations.
This leads to an interesting point about the definition of content. This is not defined. If I send an email, I would consider the whole of the email I send to be content with perhaps the SMTP data being communications data. However, the sender and recipient and even date/time are reproduced in that content. That means that any logging of the communications data (sender, recipient) are revealing content. Logically we would have to exclude from logging anything that also appears in the content of the communications to comply with this clause. This means one simple work around to legal logging would be for people to include name and address in the signature of their emails. That means that it would be a breach of section 4(5) if their name and address were logged as doing so reveals (some of) the content of the communications.
Section 10(1) states These Regulations do not apply to a public communications provider unless the provider is given a notice in writing by the Secretary of State in accordance with this regulation. We have not had such a notice.
However, if we received such a notice, which has to state by when we must comply, we could simply subcontract relevant services to a third party. That third party would not have had such a notice. When they get a notice we could wind that company up and subcontract to another. Even if we did comply with notices, there nothing to stop one dissolving a company that does the logging every month, thereby eliminating the need to store data any longer than that. The directive imposes no actual offences, just makes duties - duties that apply to a limited company in that case with no offences attached to the directors or shareholders.
These regulations state that the only way to enforce them is by a civil action by the Secretary of State against the communications provider. This is a pretty poor means of enforcement. Basically, if ISPs don't comply the Secretary of State can take action to get the court to insist the ISP complies. This means even more time taken. It would be a simple matter to wind up a company rather than comply. It makes a mockery of the whole concept.
The directive allows for reimbursement of expenses. So if we, as an ISP, contract with a company to do the logging, and agree a price with them, we can then claim expenses to cover that. That sounds like an excellent money spinner, and well worth setting up a logging company.
Logging outgoing email
The regulations require very little to be logged for our outgoing email services.
- Only customers actually using our email services are affected anyway - anyone sending email directly do not use the service we provide for email and so nothing is logged in relation to email they send
- 11(1): Sender details: We have to log the user ID - but we don't generate or process that while sending email, so nothing to log
- 11(2): Sender details: We have to log the user ID and telephone number where the communication enters the telephone network - again, not something we process while sending email so nothing to log.
- 11(3): Sender details: The name and address of the subscriber or registered user to which the IP, user ID or telephone number was allocated at the time of the communication. Well, we don't have user ID, or telephone number so it is down to IP. We process the IP, but not the associated name and address, so nothing to log. Note that we are not required to log the IP address itself!
- 12(2): Recipient details: The name and address of the subscriber or registered user to which the IP, user ID or telephone number was allocated at the time of the communication. We don't have any of that for outgoing email. Nothing to log. Note that this also relates to intended recipient - how would we know someones intention, we only know what they actually did and cannot read their mind.
- 13(2): The date and time of the log-in to and log-off from the internet e-mail. Our outgoing mail server does not require a log-in or log-off. So nothing to log.
In summary, our outgoing email services log NOTHING under this directive.
Logging outgoing email (authenticated)
We do have an authenticated outgoing email service which has a login using a mailbox ID. The mailbox ID is in fact an email address, and is picked by the user (not allocated) at a time when they like (after they subscribed, not at the time). As such there is nothing to log that relates to a user ID. Note that as there is a log-in and log-off for this, the date and time under section 13(2) need to be logged, but not who logged in our out, or what IP they came from, etc.
In summary, for authenticated outgoing email we log date and time that someone logged in and out, but not who or any other data - just a log file of date/times. Really useful.
Logging inbound email (smtp)
SMTP email delivery to end users means they get email directly and do not use our email servers - so we do not process or generate any communications data for this and nothing is logged.
Logging inbound email (pop3/imap)
- 11: We have sender email and sending server IP, but do not have any sender user ID or name/address associated with IP. So nothing to log
- 12(2): Again, we don't have a user ID, only target email address and derived from that a target mailbox ID. Neither are user ID. We don't process or generate any name and address information in providing the incoming mail service. So, again, nothing to log.
- 13(2): We have to log the date and time of log-in and log-out, but not who or what login or mailbox ID.
In summary, our incoming mail services have to log data and time of log-in and log-off but not anything else - just a file of dates and times.
This refers to fixed network telephony. Our services use a login and work from anywhere in the world (both for making and receiving calls). As such they are nomadic and not fixed. So does any of this apply?
- 1(1): Source of call: The calling telephony number. We can log that. Though we allow presentation numbers.
- 1(2): Source of call: The name and address of the subscriber or registered user. We don't generate or process this as part of providing the telephone service, so nothing to log.
- 2(1): Destination of call: The telephone number dialled. We can't see this, all we can see is the called number as it comes to us - it may have been translated or redirected already and we have no way to tell. We can log the called number we get for the inbound call though.
- 2(2): Destination of call: The name and address of the subscriber or registered user. We don't generate or process this as part of providing the telephone service, so nothing to log. Of course the call could be a wrong number so have no subscriber anyway.
- 3(1): Date and time of start and end of call. Easy to log.
- 4(1): The telephone service used. Not sure what this even means.
In summary, we would log date/time of start/end of call and calling/called number. We log this for peoples itemised bills anyway. We would have to keep it for 12 months under the directive. However, see note below on correlation of data.
This is very much like logging for calls though the wording refers to dialling which is not something you do when sending a text. Also, sending number could not only be a presentation number, but could be an alpha tag.
Internet access (broadband)
- 11(1): There is a user ID which we allocate to each internet access, but see below.
- 11(2): We do not process the telephone number when providing the broadband service.
- 11(3); We do not process the name and address of the user ID, IP or telephone number as part of providing the broadband service.
- 13(1)(a): The data and time of log-in and log-off.
- 13(1)(b): The IP address, whether dynamic or static, allocated by the internet access service provider to the communication. Says The IP address? Which one? Also, which communication is this reference to. A log-on does not itself cause a communication. What if other IP addresses are allocated at times other than log-on? What about tunnelled IPs? What about where we have IPs routed to more than one internet access? What of fall-back routes?
- 13(1)(c): The user ID.
- 14: The internet service used. Not sure what that means?
- 15(2): The digital subscriber line. We have to log "the digital subscriber line"? Not "the telephone number of...", not "the circuit ID of...", but we have to log the line itself?. What does that even mean?
This basically means our basic RADIUS logs. Looks like the WAN IP address will be sufficient to log as an IP as we only have to log the IP.
However, we are considering changing our system to authenticate broadband logins solely on the line ID from BT. This means we would not process the user ID that we allocated. We also do not process the telephone number. If we do this, then we will only actually log date and time for broadband access.
Correlation of data
Nothing in the act seems to required that the data logged is in any way correlated together. So we could log user ID for internet access, in a file of user IDs, and rotate the log every few days. No date and time in that log. Separately we can log date and time of log-in in a file. Only dates and times in that log. As long as we can transmit the data without due delay then we are complying.
We appreciate that law enforcement requires access to some information. However, we are also well aware of the basic human right to privacy. We are very concerned that these new laws are the thin end of the wedge. At present these logs are only accessible under other laws and specifically when required. They are not centrally stored to allow data mining.
The logging is very simple to bypass and anyone who really does have anything to hide can take these simple steps
- Operating your own mail server means you bypass our services and so we log nothing about your emails
- Using email services in another country. Many free free email services exist. Note, for example, if you have a hotmail account we would not log anything about your emails (though hotmail may!). Setting up your own email server is pretty simple, and we'll be happy to help you. Many can be accessed via https to be extra secure.
- Leaving your router on-line all of the time means that there are fewer logs of when you use the internet.
- Using tunnelled IP to somewhere, then we would not log the IP you are using.
We have received a few comments on this, including some from a lawyer. It seems that some of what we have said is right and some just highlights the confusion in the drafting. It may be that to avoid invading peoples privacy too much we may have to take extra steps (separate companies for email maybe). We'll see. At the end of the day people with something to hide can do so easily, but everyone else - normal people with nothing to hide will find that their personal data is logged and available to all sorts of people unless we do take steps.