Can

One more structural option worth considering before the mitigations: change what you expose.

Right now your proxy is essentially a free version of the paid service. Anyone who finds it gets exactly what you pay for. That is the strongest possible incentive to abuse it.

If you can narrow the proxy — restrict which queries it will forward, transform the response so it is only useful in your context, limit parameters to a fixed set — then the endpoint stops being a general-purpose free tier for someone else's product. An attacker copying it gets something much less valuable, and the incentive largely evaporates.

That is usually more effective than any amount of request signing, because it attacks the motive rather than the mechanism.

If you are handling something where you do not want secrets sitting in memory longer than necessary at all, the relevant controls are inside your process rather than at the container boundary: locking pages so they are never written to swap, and overwriting buffers before freeing them.

Most cryptographic libraries already do this for key material. It is worth knowing which of your own buffers hold plaintext secrets, because the kernel guarantees nobody else sees them after you free them — it does not stop them sitting in your own address space for hours.

If for some reason a managed tool is not available, the intermediate step that is genuinely better than a spreadsheet is a purpose-built encrypted database file — the kind that stores one credential per entry, locks after inactivity, handles clipboard clearing, and can be kept in version control or synced without the plaintext ever existing on disk.

It does not solve access granularity or auditing, but it removes the whole-file exposure and the accidental copy problem. It is also free, which removes the usual objection to changing anything.

Knowingly accepting it, and the reasoning is more defensible than it first looks — though the conclusion has shifted over the past decade.

Worth correcting one detail first: over the air, mobile traffic is encrypted between the handset and the network on modern generations. It is not broadcast in the clear. What is true is that the operator sees the plaintext, and that the signalling protocols between operators were designed for a small club of trusted national carriers and have not aged well.

So the realistic attack is not somebody with an antenna near you. It is an attacker with access to interconnect infrastructure, or far more commonly, a phone number transferred away from you by social engineering the carrier's support desk. That last one requires no technical capability at all and is how the overwhelming majority of real cases happen.

That is the honest risk profile: not broken cryptography, but a recovery channel whose control depends on a customer service process.

What survives, even assuming the endpoint is untrustworthy:

• Protection against everyone else. The network operator, the service provider, anyone on the wifi, anyone who obtains the server's storage. That is a large set of adversaries and they are eliminated.
• Protection for the other participants' other conversations. A compromise of your device does not expose their messages with anybody else.
• A limit on retroactive exposure. Modern protocols rotate keys as the conversation proceeds, so obtaining a key at one moment does not open the whole history.

So the correct framing is not "encryption is useless if the device is compromised". It is "encryption changes your problem from many adversaries to one". That is a genuine improvement, and it is also a warning that the one remaining adversary is now the whole game.

The practical mistake people make is assuming the app is where the security lives, and therefore that the device does not matter.

One more wrinkle: the boundary itself is not free. Virtualisation escapes are rare but they exist, and every hypervisor has had some.

So a virtual machine is a good boundary, not a perfect one, and stacking your entire security posture on it means a single class of vulnerability collapses everything. Which is a general argument for defence in depth rather than against virtualisation — but it is worth stating whenever somebody proposes one mechanism as the answer.