> I don't see if the private half of the key is shared with the web app to decrypt the cypher text, or if the cypher text is sent to the key service which responds with plain text.
I checked out the ref for that encryption API. Seems like the service stores the key, and the API exposes encrypt/decrypt calls:
So yeah, go trust that third-party provider, or if you have the technical skill, set up your own. Since most people would do the former, this is basically back to square one, and to call this "end-to-end" is misleading.
The idea of storing your keys on an Internet-facing server baffles me too. It will 100% get hacked sooner or later.
> most people would do the former, this is basically back to square one, and to call this "end-to-end" is misleading.
I'm not sure I agree that this is misleading. Google, who is storing the data, never holds the key. Likewise, the key provider never holds the data. To compromise the data you'd need to compromise both gmail and the key provider at the same time. The fact that organizations are delegating the key management is an implementation detail.
> The idea of storing your keys on an Internet-facing server baffles me too. It will 100% get hacked sooner or later.
I mean you can separate it out. You just need to implement the API on an internet-facing server.
> I don't see if the private half of the key is shared with the web app to decrypt the cypher text, or if the cypher text is sent to the key service which responds with plain text.
I checked out the ref for that encryption API. Seems like the service stores the key, and the API exposes encrypt/decrypt calls:
https://developers.google.com/workspace/cse/reference
So yeah, go trust that third-party provider, or if you have the technical skill, set up your own. Since most people would do the former, this is basically back to square one, and to call this "end-to-end" is misleading.
The idea of storing your keys on an Internet-facing server baffles me too. It will 100% get hacked sooner or later.