You are here
- Home
- Regulatory Developments
- Blogs
- Draft Investigatory Powers Bill (first look)
Group administrators:
Recent members:
Draft Investigatory Powers Bill (first look)
The Government has today published its draft Investigatory Powers Bill. There are 299 pages in the legislation alone, so for now I've been looking at the parts most likely to affect Janet and its customers. So far I’ve looked at a bit less than half of the Bill: further implications, if any, will be the subject of future posts.
For normal operations, there doesn’t appear to be much change. The rules that make it lawful for us to intercept our own networks (for example to debug problems) have been clarified/extended in a couple of areas:
- Clause 33(3) covers "identifying, combating or preventing anything which could affect the telecommunication system" or anything attached to it. So things like intrusion detection, incident response and virus scanning are now clearly OK, even where the target of an attack isn’t the network itself;
- Clause 33(2)(c) mentions "services or facilities aimed at preventing or restricting the viewing or publication of the content of communications transmitted", so content or malware filtering doesn’t constitute an illegal interception.
Under the wording of the Regulation of Investigatory Powers Act 2000 (RIPA), the conditions applying to these depended on which types of filtering were for the benefit of the network and which for connected devices and people. If the Bill becomes law these will all be covered by the same provisions.
As with current law the Home Secretary (or the equivalent Scottish Minister) can issue warrants (clause 12) ordering the interception of particular communications on any telecommunications system.
The orders most familiar to network operators are those requiring the disclosure of communications data, under section 22 of RIPA. These will still exist, under clause 46 of the draft Bill. Clause 60 brings into law the existing practice (currently just Home Office guidance) whereby authorities must check their proposed orders with a trained Single Point of Contact, who can advise on practicality, proportionality, etc. In emergencies (for example where there is a threat to life) orders can be issued without this prior check.
Unfortunately the problem of definitions, which has plagued this area of law for more than a decade, hasn’t been resolved. Clause 47(6) defines an "Internet Connection Record", which appears from the context to be a particular type of communications data whose disclosure can only be made in certain limited circumstances. My impression was that the wording was trying to say "full URL", but others have read it as referring to DHCP/NAT logs! I very much hope this can be clarified. The other telecommunications-related definitions are in clause 193: my immediate impression is that the definition of "Communications Data" is just as opaque as the current RIPA definition, but does seem to have fixed the "anything else" problem that extends the existing definitions far beyond anything relating to the use of computers or networks.
Potentially the most significant change is an extension of the Home Secretary's powers to order network operators to retain communications data. Under the current Data Retention and Investigatory Powers Act (and the earlier European Data Retention Regulations that were declared invalid by the European Court last year) those orders can only be made against *public* electronic communications services. The draft Bill replaces that by "telecommunications operators", defined in a way that is likely to include any organisational or inter-organisational network, even those not available to the public. Although the types of data that can be covered by an order are reasonably clear (see clause 71(9)), it isn't clear from anything I’ve spotted so far whether orders are limited to information that the operator already holds. The use of "retain", as opposed to "collect" might suggest that it is, but previous laws have been more explicit. Whether this has practical significance for universities or for Janet clearly depends on whether a Home Secretary ever choses to issue a retention notice against us (Janet, in particular, has almost none of the communications data mentioned in clause 71). And it's not something that needs action until such a notice is issued: keeping additional data in case you one day you receive a notice would be a breach of the Data Protection Act. But I'll be keeping an eye on this provision in particular as the draft Bill is discussed.
Comments
Thanks for posting your initial thoughts on this.
My interpretation of what is meant by a ICR is that it is not the URL, but the IP/Name. I am assuming this allows for an equal collection of SSL and non SSL data as part of a ICR. As the trend towards HTTPS everywhere is something they are no doubt aware of.
Then the other parts of the bill, allowing equipment interference etc will provision for the further details of communications if they require it.
Thanks. I'm now up to for (radically) different interpretations of that sub-clause :)
The Comms Data Code of Practice has now "clarified" that what an ICR is will "depend on the service and service provider" (2.64). The examples in 2.63 seem to include netflow, hostname, and "customer account record". Though the "core data" in 2.64 is a classic IP+port+time to user lookup.
However since the term ICR no longer appears in the Bill's list of things that an operator can be ordered to retain (that, in clause 78(9), is even vaguer/wider) the question may be moot. Where ICR does appear is as a datatype that is supposed to have special safeguards on access. If the nature of an ICR varies from one provider to another, I've no idea how the requesting and approving authorities are going to make that work.