I have been trying to focus on the bits that could impact us (A&A and FireBrick) mainly, and I am very happy to have had help from a friendly lawyer on this matter. I am the first to accept that I am not an expert on reading legislation, but getting better as the years go on.
So, some observations, in no particular order...
Can a retention order be placed on BT Wholesale to monitor A&A traffic?
We think no - surprisingly. This is because of 87(4): "A retention notice must not require an operator who controls or provides a telecommunication system (“the system operator”) to retain data which relates to the use of a telecommunications service provided by another telecommunications operator in relation to that system".
So that should mean, we think, that BT Wholesale or Openreach or BT plc as "the system operator" cannot be ordered to retain data which relates to the use of the telecommunications service provided by A&A in relation to that system. We see that as meaning BT provide PPP and we provide IP, and so BT cannot be ordered to log IP (or above), only PPP which is basically their RADIUS logs, because IP is related to what we provide via that system.
Good and bad - good is it means, in theory, if we say we have no monitoring (we don't) and we can assume BT do not, then there is no monitoring (same logic to LINX and transit providers). Bad news is that they may be more inclined to ask us to do retention as a niche ISP.
But it gets more fun - given that this now covers private as well as public telecommunications services, it is easy to say that every single one of our customers is a telecommunications operator even if only running one router to provide service to one person. So we can argue that we cannot be expected to retain data relating to our customer's use of the IP - you have to ask each and every one of them to retain data and not us.
We'll see how that plays out if ever we are asked to do retention (which we, A&A, have not been).
Can FireBrick be forced to add a back door?
We think no, thankfully. The definition of a telecommunications operator, which we thought could cover FireBrick would require that FireBrick is providing a "service", which we are not, we are providing a product, and that the FireBrick itself is a "system", which it is not, it is apparatus.
Even so, we still have standing order that if asked to back-door FireBricks then the UK company FireBrick Ltd would be dissolved.
In short, you can trust FireBrick!
Is FaceBook a telecommunications operator?
Well, this is tricky. Home office think so, apparently. An operator offers "services", and services means a service consisting of access to or facilitating making use of, a "system". A system is something allowing transmission of communications by electrical or electromagnetic energy.
So a system is wires and fibres and radio; A services provides access to that or making use of that; An operator offers a service to do that.
I think the wires, and fibres, and radio, facilitate the use of FaceBook, not the other way around. The "make use of" may be the sticking point.
I think it is badly drafted! FaceBook may want to argue on that definition.
What are Internet Connection Records?
Something much hyped in the process of this becoming law, but relegated to a small part of the Act.
It is a narrow and specific definition, "In this Act “internet connection record” means communications data which may be used to identify, or assist in identifying, a telecommunications service to which a communication is transmitted by means of a telecommunication system for the purpose of obtaining access to, or running, a computer file or computer program, and comprises data generated or processed by a telecommunications operator in the process of supplying the telecommunications service to the sender of the communication (whether or not a person)."
So it is just stuff to identify the service used by the sender, nothing more. But why does this narrow definition matter?
Well, retention can cover all sorts of data, anything that is not "content", which is "meaning of the communication". And that can be way more than ICRs. It is clear that ICRs are a subset of that data.
However, requests for this data to be acquired (e.g. from retained data) can cover anything.
There are restrictions on "local authorities" getting ICRs, but as that is a subset of the data ISPs may be forced to collect. So that is a less than useful constraint. Local authorities could ask for all sorts of non ICR data an ISP was required to "retain"!
How serious is "serious crime"?
Some aspects of the acquisition of data have restrictions for "serious crime", and that covers stuff with long prison sentences. Good. But, oddly the section also covers "relevant crime" which is rather fun as it covers offences that are "by a person who is not an individual, or which involves, as an integral part of it, the sending of a communication or a breach of a person’s privacy." This means things like failing to put your company number on your letterhead (a crime by a company) is lumped in with "serious crime"!
And the irony that you can get all this data which is a huge invasion of privacy to investigate a breach of a person's privacy is not lost on me.
Can the food standards agency get browsing history?
Well there are caveats, but yes, they are in the list and not even covered by the "local authority" exception to getting ICRs.
Does this mean back-doors can be mandated?
Well, yes, to any "service" which can be ordered to maintain a capability to decrypt stuff and even notify if new services are planned to ensure they have the back-door.
But not if you do the encryption yourself, using PGP or your own apps or pen and paper! Criminals can do this and do so legally with no interference by this Act. Well done!
Interesting stuff, so if you ever were asked to keep records the "all my customers are ISPs so I cant" argument might just work?
ReplyDeleteWho knows, but sounds like a good reason to appeal if that happened.
DeleteCouldn't you argue that the internet connection record is the ppp connection rather like a phone call. Which you keep records of any way.
ReplyDeleteYou know there is a certain level of trust required to just trust the firebrick given the source is not open, we have to "hope" there is no backdoor and that it is sound.
ReplyDeleteWe have discussed this, even if open you have to trust that is the code that is running in your brick and trust no bootloader backdoor and so on.
DeleteWouldn't having an open source base make it significantly harder for them to compel you to undetectably add a backdoor, though?
DeleteWell, again, no, as they can say issue code with back-door but don't update open source code. We'd have to allow people to build from source and install, which removes a key security that the code is all signed by us!
DeleteThat seems a harder thing to compel you to do, though - it's certainly a larger burden to ask you to maintain a 'public' source repository and a separate 'real' one.
DeleteAs I've pointed out before, too, you could provide verified builds while still not allowing arbitrary code to be loaded; for instance, by providing your builds as docker images, anyone could satisfy themselves that the source is reproducibly built into the same binary that you signed.
For the Firebrick devices if you wanted to make sure it was verifiable then you would open both the source and the build system so people could verify the signatures of the software that has been deployed to their own device.
DeleteBut you still don't know back doors are not installed by the bootloader. Even if we also released that, and people could JTAG that in, you don't know there is not a back door in the ethernet hardware or the pre-boot code in the processor. Ultimately you have to trust us, and if you trust us, then we don't need to make it open source.
DeleteBut there are more threat vectors than just trusting you, as we just discussed. If we assume, for instance, that you haven't already backdoored the bootloader, then if the source were available and the builds verifiable, it would be impossible for you to be coerced into including a hidden backdoor without us all sending our routers in for 'upgrades'.
DeleteThe approach that "transparency can't be perfect so we may as well have none at all" seems rather shortsighted to me, even leaving aside other compelling reasons to make source available. Wasn't the reason you created the firebrick in the first place because you were unhappy with the transparency of other vendors?
At this stage I am not keen on making the code open source, sorry. I appreciate the concern, but as I say, even if we did that you still have to trust us, and if you don't trust us, don't use the product. The back door concerns are, I hope, addressed by the fact the Act should not apply to us, and by the fact that we have said we would wind up FireBrick Ltd if ever asked to (again, trusting us to do that). I hope you can, in fact, trust us.
DeleteMy point has always been that it's not just about trusting you. Assuming we trust you 100%, we also have to trust that nobody's compromised your systems, that there are no crucial bugs in your code, and that nobody's coerced you into doing something. If this seems familiar, it's because it's the exact situation that you were in which you decided to solve by creating Firebrick in the first place.
DeleteOn an unrelated note: The new bill appears to contain gag provisions. Will there be any way for us users to know if A&A has been subject to a retention order?
For retentions, the gag provisions as well as compliance are only enforced by civil proceedings, and the gag provisions only by people employed/working for the company. If I resign for a short period and then get re-employed I would not even be breaking the gag provisions by saying something whilst not working for the company.
DeleteGood to know. And a good test of how much your employees like you to see if you get hired back. ;)
DeleteGood analysis of the IPA. My concern is that government lawyers will deliberately misinterpret the woolly wording of the Act to introduce whatever levels of intrusion they require. Changes will, as usual, be "in the interest of public safety" on the back of whatever wave of hysteria is sweeping the nation.
ReplyDeleteIn terms of "Can a retention order be placed on BT Wholesale to monitor A&A traffic?", under the *acquisition* framework, and subject to the restrictions in the Act, a telecommunication operator can be required to obtain or disclose communications relating to the use of a telecommunications service provided by another telecommunications operator: s61(5)(c).
ReplyDeleteSo, on a per-authorisation basis (and this could be broad), BT (or TalkTalk, or any other telecommunication system provider) could be required to hand over data relating to use of services provided by wholesale customers.
One would, of course, hope that would be narrowly targeted, but still, good point.
DeleteWould it be possible to use BT/TT backhaul and then L2TP with the LNS and ISP network outside the UK (and thus out of the jurisdiction of the IPA) ?
ReplyDeleteWell, maybe against retention if my reading of 87(4) is correct, but as Neil says targeted may still get you - but that should, in theory, mean you have been a bad boy :-)
Delete