The E2E Argument in End-User Application Design: 50 Years or so Later

Historically, the E2E argument in system design has been applied to network design and distributed systems. While certainly important at the network and infrastructure level, the last decade has seen a lot of development at the application layer due to easy to deployment in business and advances in OS and cloud infrastructure. It is very hard to compete these days as a new infra company with established cloud (AWS, Azure, Google) and Overlay (Akamai, Cloudflare) providers.

The enterprise is being increasingly software-ized and automated (see SW is Eating the World by Marc Andreesseen), and more and more of it is happing at end-points and through new applications (think Slack, Zoom, MS Teams … etc). Maybe with the exception of Okta and similar companies that touch the enterprise’s IAM infrastructure.

We argue that future security (confidentiality, authenticity, integrity, and availability) and privacy and analytics solutions should be designed with the E2E argument in mind. Ideally push all these features and functions to the end-point application and embed them into the content/data as much as possible. This has three benefits:

1) Distributes the compute and processing and storage load 2) Provides redundancy, and increased availability 3) Has the potential to still be enforced outside the enterprise (e.g., for distributed enterprise and Web-3 like movements therein)

On the face of it, this contradicts the move to the Cloud. But upon closer and deeper inspection and investigation these two can be reconciled as follows:

1) Encryption/decryption can happen at end-points and be stored centrally unencrypted as a backup

2) Document-centric logs and analytics can be stored in the document (and encrypted)