with apologies

Following up some remarks concerning Lawful Access

· 4 min read · March 09, 2026 · #tech #policy #academic

A few weeks ago I published some remarks I’d given on the risks of lawful access. I also tooted about them on Mastodon and Martin kindly referred to them on Bluesky (as I haven’t yet got around to signing up). I was pleased that this generated some interesting commentary and interaction. I think I replied to all those on Mastodon, but I thought I could collate the points here as a sort of follow-up for posterity, so here goes :)

Before I begin, I should repeat (perhaps more clearly) something I tried to note in the original:

Emphasis there on might—it might also turn out to be impossible to do anything useful at all. But at the moment it seemed to me that we’re not even really trying because the discussion always degenerates into this must/can’t/must/can’t argument and never moves forwards. I think it’s also necessary to repeat (again, perhaps more clearly) that no system, whatever its design and implementation, will be perfect. But that doesn’t mean that a system that works as intended most of the time might not still be useful—though it might mean that, for some, the risks of an inevitably imperfect system in this domain are simply too great.

So—my characterisation of the points that I think were made and I replied to is as follows:1

  1. Adding features adds complexity and that creates vulnerabilities.

    But adding features always adds complexity and creates vulnerabilities.

    It’s true that lawful access is a particularly powerful feature that operates without direct interaction with the user. But 0-click 0-days exist due to complexity that was added for other reasons—when the platform provider believes it worthwhile, they seem quite happy to take that risk. For example, as reported in January 2026 the addition of automatic audio transcription of SMS and RCS audio attachments gave rise to an exploit chain resulting in arbitrary kernel read/write.

  2. A lawful access mechanism necessarily places requirements on clients.

    This is possibly true—but in what form exactly? And what are the consequences of that?

    If, for example, the requirement was placed on the platform provider (there are approximately two in the mobile space I think) then that might be enforceable in that the platform provider would have to comply. Perhaps this could even be enforced in the major app stores in ways similar to how Apple try to foce use of WebKit browsers in iOS.

    Of course, this can be worked around by developers and users happy enough to do the work. But maybe it’s still helpful to force bad actors off the major messaging platforms and onto more esoteric—and thus perhaps easier to spot, and maybe even sometimes less well-engineered—applications. As I cite in the original remarks, the Encrochat is among those that might be considered instructive here.

  3. From a legal perspective it really matters which legal jurisdiction is the client currently in.

    I thought this was an interesting point that I really hadn’t thought of. And probably one for someone that knows something of the law rather than me! But off the top of my head and speaking through my hat, perhaps there are multiple points where this can be assessed? E.g., supposing some ledger-based system as per Martin’s proposal referenced in my original remarks, then maybe the platform could determine in which jurisdiction the device was at:

    • the point of installation and then, if it changed, at the point of use—perhaps informing the user in these cases; and
    • the point of a relevant warrant being accepted into the ledger or the moment when such a warrant was exercised—presumably not informing the user in these cases.2

I don’t know. I suspect this is a genuinely complicated problem to try and solve. But I still think it might be worth giving it some thought, at least until there’s a sufficiently articulated argument as to why it really is the case that absolutely nothing can or should be done here.

  1. This might be rather less well thought through than the original given I haven’t taken the chance to run it past anyone else, and particularly therefore anyone who actually knows about this domain!

  2. Yes, doing this naively might scale poorly with the number of active warrants. That’s why some engineering by actual experts might be required.