[btown]

It may be easier for an insider or compromised server to add a silent exfiltration functionality to server code, than to additionally compromise the frontend build, add a side channel by which the client could transmit the secret to the server or to a third party, and exfiltrate the data itself, all without detection. Defense in depth!

Oh, and a deactivated account, where no client with secret access ever gets updated or executes code again, will never leak its secrets, regardless of level of (pre-quantum) compromise of the company. Useful for limited-time communications that need to be private from sophisticated adversaries in perpetuity.

Not to mention that it signals commitment of your company to data privacy, which may deliver value in and of itself.

[tptacek]

I don't understand the first point as a claimed security level with a specific threat model. The second point, about deactivated points, is equally true of serverside encryption --- again, assume keys stored clientside, but encryption code run serverside (in fact, it can be true in applications that don't encrypt at all).

[btown]

If I have a 0day for your backend stack, or you fail to upgrade a dependency, I might get RCE on your backend server and install an exfiltration system, but I would not necessarily be able to pivot to changing the frontend bundle on the static CDN without compromising the CI/CD and code review system, which (hopefully) uses isolated credentials and has strong audit logs. A threat model where even a persistent or long-running infection on backend servers allows user content (if not metadata) to remain opaque can be useful.