All about trust

At the moment, at A&A, we provide Firebricks to customers in various circumstances, including as part of our high availability multiple line Office::1 product.

Usually, and with the customer's knowledge and consent, we will include a login (suitably locked down and secure) for us to access the FireBrick. This means that we can address tech support issues, and make config changes if requested and so on.

This works because our customers can, and do, trust us.

 Of course, even where such access is via IPSec tunnels, it still involves trusting us!

The problem is not that we are untrustworthy, but the law, if the Draft Investigatory Powers Bill passes as it is now, would legally compel us to be untrustworthy as it forces us to co-operate with "equipment interference" and "removal of protection on communication" in some circumstances.

If it passes it is simply the case that our customers cannot trust us any more, as that trust will have been officially removed by the law of the land.

So, we are considering what we should do, before any such law comes in to force.

One obvious measure is to not have a login in to the FireBrick. However, the FireBrick does have a trick up its sleeve here - in that we can put our login on a profile and have that controlled by another login that the customer knows. That way they can decide to turn on or off our access as and when they need.

But we may have to go further and ensure that the signing of FireBrick code for automatic updates is managed outside A&A. The issue is that whilst A&A do most of the FireBrick R&D, A&A is also a communications provider. FireBrick is not, and hopefully is outside the scope of this legislation. So A&A might be compelled to add a back door to FireBrick code. If we make the signing authority for code updates exist outside A&A, in FireBrick Ltd only, then we cannot be compelled to issue code with holes in it just to allow equipment interference or removal of protection. What I don't know yet is whether that can be done simply by use of separate hats - i.e. can I be director of A&A and director of FireBrick, but only have authority to sign code in that second role and not the first. May have to take legal advice on that. If not, we will have to have a FireBrick member of staff and one that is not part of any telco that signs the code after reviewing changes - which is a nuisance.

Why do we care - surely this is all about targeted surveillance? Well maybe it is, but the wording of the bill allows bulk equipment interference, and a general intercept capability, neither of which is targeted.

But there is also the principle here - can our customers trust us? I would like them to be able to trust us. Should trusting your ISP be like trusting your lawyer or your MP? I really hate the idea that any law can officially undermine trust customers have in us - so yes, of course - we'll take steps to ensure that trust is valid and continues.

This is massively about perception. Even if we have no such orders - which we really doubt we would ever have - if people believe we may have, and lose trust, they may disable code updates. That would be bad for the product and ultimately their security as we would not be able to fix any weaknesses in their FireBrick that we discover. Ultimately, this really is all about trust!