Every Evolving Edge request involves two strangers.
The first is a company with content to deliver. They hand it to us to serve from hardware they’ll never see, in a house they can’t name, owned by someone they’ll never meet.
The second is a person with a machine sitting mostly idle in that house. They give up compute, storage, and bandwidth to software they didn’t write, so it can serve files belonging to companies they’ve never heard of.
Neither one is being unreasonable. Both are being asked to trust the same thing - an environment neither of them controls.
Today we’re publishing Two Strangers, One Machine, a 46-page white paper on how our distribution layer handles that problem, and exactly where our answer stops.
The question we stopped asking
Most security architectures start by asking how the node can be made trustworthy. When the machine underneath the software belongs to someone else, that question has no good answer. Whoever owns the box can read its memory, attach a debugger, and capture its traffic. Control of the machine beats control of the process, every time.
So we asked a different question:
The question is not how much we can trust an Edge Node. It is how little we have to.
The answer is our .ee container format and three encryption levels. A customer picks a level when they package their content, and the level decides one thing above all: who holds the key.
| Level | Who can read the content | What the Edge Node holds |
|---|---|---|
| Level 0 | Anyone | Public content, integrity-checked |
| Level 1 | The end user’s browser only | Ciphertext. No key. It cannot decrypt. |
| Level 2 | The node, for one authorized request | A key issued per request, released when the response ends |
Level 1 is the strong claim, and it holds. The key travels in the URL fragment - the part after the # - which browsers never send to any server. The Edge Node, our control plane, and the storage origin all see only AES-256-GCM ciphertext. An operator who copies the file off their disk walks away with random-looking bytes. Even if our own control plane were compromised, Level 1 content would stay unreadable, because we never hold that key either.
Cannot vs. will not
This is the idea at the center of the paper.
An operator who promises not to look at your content has made a commitment. Commitments get broken, forgotten, or overridden by whoever acquires the company. An operator who holds no key hasn’t made a commitment at all. There’s nothing to break.
Our job is to move as much of the guarantee as possible from “will not” to “cannot” - and to be exact about where that stops being possible.
Why trust has to live in the architecture
eBay, Uber, and Airbnb make strangers trust each other with reputation: reviews, ratings, dispute resolution. That works because there’s a window between the transaction and the verdict. The ride ends, then you rate it.
Content delivery has no such window. By the time a customer could complain that their content was exposed, the exposure is over, and no rating changes it. For confidentiality, reputation isn’t a weak mechanism here. It’s an unavailable one. So the guarantee has to be a property of the system itself.
The part most white papers leave out
The paper opens with a section called What We Do Not Claim, and it ends with a chapter called Limits We State Plainly. Some of what’s in there:
- Level 2 plaintext exists in operator RAM for the length of a request. An operator with root and a debugger can extract it. No software-only system prevents that on hardware the adversary owns.If operator compromise is in your threat model, use Level 1. We say that even though Level 2 is the more capable mode.
- Compression leaks object size. Ciphertext length tracks plaintext content - we measured differences of 27.5x between same-length files in our own test suite. We list it as a limitation, not a footnote.
- We publish a defect we’re still fixing. Crypto-shredding isn’t yet immediate on running control plane instances. The paper says so, and it won’t describe that effect as immediate until the fix ships.
- No compliance certifications yet. SOC 2 Type II and HIPAA readiness work is underway. Nothing in the paper is an attestation.
- No customer code runs on Edge Nodes today. AI inference and general edge compute are on our roadmap, but they’ll need their own threat model and their own paper when there’s something running to test.
We also counted our security controls honestly. There are four, not ten.
Don’t take our word for it
Chapter 9 pairs every security claim with the test that checks it, and Section 9.6 (page 37) lists five things you can verify without our cooperation - starting with opening your browser’s DevTools and watching a Level 1 download arrive as opaque ciphertext, then decrypt in the page.
If you run an Edge Node
Chapter 8 (page 31) was written for you, too. It’s a complete inventory of what our software puts on your machine and what it does there - a cache of hash-named files you can’t read, an encrypted credential file sealed to your specific hardware, and a process that serves them. Nothing in it is hidden from you, and every claim is written so you can check it on your own box.
The threat model runs in both directions, because you didn’t sign up to be trusted either.
Read it, then tell us what we got wrong
-
Read the paper:Two Strangers, One Machine (PDF, 46 pages)
-
Security teams: start with Section 9.6. Every verification step there is available to you right now.
-
Researchers: report vulnerabilities tosecurity@evolvingedge.ai . We aim to acknowledge within one business day.
-
Home lab and self-hosting folks: the Edge CDN beta is open.Put your idle machine to work. This is version 1.0. When the limits in Chapter 11 change - and several of them are on our list - the paper changes with them, and we’ll say what changed.