Thought exercise: you'd like to become an email provider that promises to not look inside your customers' emails.
In our example you can replace AWS with Google or someone else, it's not important here.
You'd argue to public that this is your pipeline:
Email comes in via Amazon SES inbound SMTP
Lambda handler gets called which applies public key encryption using customer's public key
After step 2, emails are unreadable via your email service provider. It's just passing around encrypted data in databases where the provider doesn't have decryption keys for.
So the public has to only trust steps 1 and 2. If those steps can be audited so the plaintext does not go outside of those steps, and the step 2 can be validated to be trustworthy, the inbound email flow is totally trustworthy.
Step 1 is not controlled by the email service providers, so customers have to only trust AWS.
Step 2 is code controlled by the email service provider, how can you "prove" to your customers that the code is safe?
Open sourcing the code is not enough - how can the customer know the exact code is running and not something else, or only a derivative of it?
AWS (& others) are in unique position with their PaaS offerings to provide "infrastructure assertions". They could offer opting in their customers (in this case the email service provider) in to selectively certify certain parts of their infrastructure configuration to the public. How powerful it could be if AWS could use its credibility to say "AWS certifies that any example.com inbound emails to AWS account 1234 go through AWS SMTP and only terminate in Lambda handler XYZ whose current version image is sha256:abcdef0123456789...".
That would be enough to provide trust (if the customer trusts AWS's word), if any customers can trace that sha256 back to Git revision in a repo that they can build themselves and verify that it yields the same image. This of course requires reproducible builds.
This of course goes back to the question of roots of trust, and in this example AWS is that. A knee-jerk response is of course that nobody can trust AWS 100 %. Yes, this is not perfect, of course. But you have to trust some centralized authority anyway, unless the end customer handles all aspects of the email pipeline themselves. And nobody has the resources to do that, robustly. I'd trust AWS more than any of the consumer-oriented "private email" alternatives though.
Thought exercise: you'd like to become an email provider that promises to not look inside your customers' emails.
In our example you can replace AWS with Google or someone else, it's not important here.
You'd argue to public that this is your pipeline:
So the public has to only trust steps 1 and 2. If those steps can be audited so the plaintext does not go outside of those steps, and the step 2 can be validated to be trustworthy, the inbound email flow is totally trustworthy.
Step 1 is not controlled by the email service providers, so customers have to only trust AWS. Step 2 is code controlled by the email service provider, how can you "prove" to your customers that the code is safe?
Open sourcing the code is not enough - how can the customer know the exact code is running and not something else, or only a derivative of it?
AWS (& others) are in unique position with their PaaS offerings to provide "infrastructure assertions". They could offer opting in their customers (in this case the email service provider) in to selectively certify certain parts of their infrastructure configuration to the public. How powerful it could be if AWS could use its credibility to say "AWS certifies that any example.com inbound emails to AWS account 1234 go through AWS SMTP and only terminate in Lambda handler XYZ whose current version image is sha256:abcdef0123456789...".
That would be enough to provide trust (if the customer trusts AWS's word), if any customers can trace that sha256 back to Git revision in a repo that they can build themselves and verify that it yields the same image. This of course requires reproducible builds.
This of course goes back to the question of roots of trust, and in this example AWS is that. A knee-jerk response is of course that nobody can trust AWS 100 %. Yes, this is not perfect, of course. But you have to trust some centralized authority anyway, unless the end customer handles all aspects of the email pipeline themselves. And nobody has the resources to do that, robustly. I'd trust AWS more than any of the consumer-oriented "private email" alternatives though.