The only way to do client side encryption is PGP on a native client distributed by a third party.
can be self hosted.
Of course this is sort of an odd game where you need to cut their access off before they backdoor it, so you have to somehow predict that Google is going to become malicious and beat them to the punch. If you a reacting to something that they are doing it likely isn't helping much.
Another possible advantage is that you could potentially have logging on key access which could give some idea of data usage. So if Google starts requesting keys for all of your stored data then you can be suspicious that they are siphoning up your data. (Or doing some background maintenance? Who knows?)
In practice this is probably mostly checkbox theater where it is a feature that Google and their users can list.
Yes, they could target specific people, deliver different javascript and break their encryption, but in general it's still a huge security gain. It makes it impossible for Google to handover E-Mails retrospectively to police or spy agencies.
There's no way to tell if they are intercepting your messages clientside, and you'd have to monitor all the network traffic (which would be encrypted with their keys) to detect exfiltration.
Or the ability to execute arbitrary external code?
You can also run your own self-built client (alternative implementations are available) and forward the messages securely any way you wish.
Such subterfuge would not remain undetected.
Signal is e2ee in ways that iMessage and WhatsApp are not.
It isn't supposed to protect you from government agencies. Really what this feature is, is 1) e2e of email, and 2) integration with an external enterprise key management service.
#2 means that at very least, your org will have access to your keys and therefore all encrypted mail, and if they have access to that, then they are open to things like subpoenas from law enforcement.