Skip to content

Commit 98233cd

Browse files
authored
Rewrote TLSNotary motivation (#40)
1 parent 68b3a3e commit 98233cd

File tree

1 file changed

+41
-16
lines changed

1 file changed

+41
-16
lines changed

docs/motivation.md

Lines changed: 41 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -4,48 +4,73 @@ sidebar_position: 2
44

55
# Motivation
66

7-
The decentralized internet demands privacy-respecting data provenance!
7+
:::tip TL;DR
8+
* **Prove your data** from any website without screenshots or sharing passwords
9+
* **Selective disclosure**: Show only what you want (balance but not transactions)
10+
* **No permission needed**: Works with existing sites—servers don't even know it's happening
11+
* **Built for Ethereum**: Import reputation, credentials, and private data into dApps on Day 1
12+
:::
813

9-
Data provenance ensures internet data is authentic. It allows verification of the data's origin and ensures the data hasn't been fabricated or tampered with.
14+
The internet is broken. Your data is locked in "walled gardens," and you can't prove what's yours without giving away the keys to everything.
1015

11-
Data provenance will make data truly portable, empowering users to share it with others as they see fit.
16+
**Data provenance** is the solution: it proves your data is real, shows where it came from, and guarantees it hasn't been tampered with. Think of it as a "digital receipt" that travels with your data.
1217

13-
## Non-repudiation: TLS is not enough
18+
With true data provenance, your data becomes **portable**. You control what you share and with whom. No intermediaries, no gatekeepers, no compromises.
19+
20+
## The Problem: TLS Keeps You Safe, But Can't Prove Your Data to Others
1421

1522
![](../diagrams/light/data_provenance_none.svg#gh-light-mode-only)
1623
![](../diagrams/dark/data_provenance_none.svg#gh-dark-mode-only)
1724

18-
Transport Layer Security (TLS) plays a crucial role in digital security. TLS protects communication against eavesdropping and tampering. It ensures that the data received by a user (_"Alice"_) indeed originated from the `Server` and was not changed. The `Server`'s identity is verified by Alice through trusted Certificate Authorities (CAs). Data integrity is maintained by transmitting a cryptographic hash (called Message Authentication Code or MAC in TLS) alongside the data, which safeguards against deliberate alterations.
25+
When you browse the web, **TLS** (the "lock" icon in your browser) protects your connection. It ensures that the data you receive from a server is authentic and hasn't been tampered with in transit. You can trust what you see on your screen came from the real server.
1926

20-
However, this hash does not provide **non-repudiation**, meaning it cannot serve as evidence for the **authenticity and integrity** of the data to Bob (e.g., a service or an app). Because it is a keyed hash and TLS requires that the key is known to Alice, she could potentially modify the data and compute a corresponding hash after the TLS session is finished.
27+
But here's the catch: **TLS only protects the conversation between you and the server**. It doesn't give you proof you can share with others.
2128

22-
Achieving non-repudiation requires digital signatures implemented with asymmetric, public-key cryptography.
29+
Say Alice wants to prove her bank balance to Bob (maybe to get approved for a loan). Even though TLS guarantees the bank sent her that balance, she can't simply show Bob a screenshot: anyone can fake those. And because TLS uses "symmetric keys" (both Alice and the bank know the secret), Alice could technically fake the data herself and Bob would have no way to verify it actually came from the bank.
2330

24-
While the concept seems straightforward, enabling servers to sign data is not a part of the TLS protocol. Even if all data were securely signed, naively sharing all data with others could expose too much information, compromising Alice's privacy. **Privacy** is a vital social good that must be protected.
31+
To solve this, you'd need **digital signatures** from the server, but servers don't do this. Even if they did, forcing Alice to share *all* her data would be a privacy nightmare. We need a way to prove data authenticity **while preserving privacy**.
2532

26-
## Status Quo: delegate access
33+
## Today's "Solution": Hand Over the Keys (OAuth)
2734

2835
![](../diagrams/light/data_provenance_oauth.svg#gh-light-mode-only)
2936
![](../diagrams/dark/data_provenance_oauth.svg#gh-dark-mode-only)
3037

31-
Currently, when Alice wants to share data from a `Server` with another party, OAuth can be used to facilitate this if the application supports it. In this way, the other party receives the data directly from the `Server`, ensuring authentic and unchanged data. However, applications often do not provide fine-grained control over which data to share, leading to the other party gaining access to more information than strictly necessary.
38+
Right now, if Alice wants to share data from one platform with another service, she typically uses **OAuth** (think "Sign in with Google" or "Connect to Facebook"). This lets Bob's app directly access Alice's data from the original server, so the data is guaranteed to be authentic.
39+
40+
But there are major problems:
3241

33-
Another drawback of this solution is that the `Server` is aware of the access delegation, enabling it to monitor and censor the other user’s requests.
42+
* **All-or-nothing access**: Most platforms don't let Alice pick and choose. She has to give Bob access to *way more* information than necessary. Want to prove you have a Twitter account? Here's your entire DM history too.
3443

35-
It's worth noting that in many instances, OAuth is not even presented as an option. This is because a lot of servers lack the incentive to provide third-party access to the data.
44+
* **The platform watches everything**: The original server knows exactly what Alice is sharing and with whom. They can monitor, analyze, or even block the connection at any time.
3645

37-
## TLSNotary: data provenance and privacy with secure multi-party computation
46+
* **Many platforms refuse to play ball**: Most services have zero incentive to let competitors access their users' data. No OAuth option means no data portability, you're stuck.
47+
48+
## TLSNotary: Prove Your Data Without Revealing Everything
3849

3950
![](../diagrams/light/data_provenance_tlsn.svg#gh-light-mode-only)
4051
![](../diagrams/dark/data_provenance_tlsn.svg#gh-dark-mode-only)
4152

42-
TLSNotary operates by executing the TLS communication using **multi-party computation** (MPC). MPC allows Alice and Bob to jointly manage the TLS connection.
43-
With TLSNotary, Alice can selectively prove the authenticity of arbitrary portions of the data to Bob. Since Bob participated in the MPC-TLS communication, he is guaranteed that the data is authentic.
53+
TLSNotary solves this using clever cryptography called **multi-party computation** (MPC). Here's how it works:
54+
55+
Instead of Alice connecting to the server alone, **Alice and Bob work together** to manage the TLS connection. Neither one has full control: they split the cryptographic "keys" between them. This means:
4456

45-
The TLSNotary protocol is **transparent** to the `Server`. From the `Server`'s perspective, the TLS connection appears just like any other connection, meaning **no modifications to the TLS protocol are necessary**.
57+
* **Alice can selectively prove specific parts of her data** to Bob. Want to prove your bank balance but hide your transaction history? No problem: just reveal the balance.
58+
* **Bob knows the data is authentic** because he participated in the TLS connection. Alice can't fake it because she never had complete control of the keys.
59+
* **The server has no idea this is happening**. From the server's perspective, it's just a normal TLS connection. No API required, no permission needed, no modifications necessary.
60+
61+
It's data provenance with built-in privacy: exactly what the internet needs.
4662

4763
<!-- TLSNotary can also separate the TLS-MPC verification from the data verification. When an independent **Notary** handles the TLS verification, the user receives signed, or notarized, data from the notary, which she can store or carry around. This equates to full data portability. It is worth noting that in this setup, Bob (the data verifier) needs to trust the notary. -->
4864

65+
## TLSNotary is a Growth Accelerator for the Ethereum ecosystem
66+
67+
* **Unlocking the "Private Data" Ocean**: Ethereum is the ultimate "Trust Machine," but it currently runs primarily on public data. TLSNotary provides "super-fuel" by unlocking the 99% of world data currently hidden in "walled gardens" (bank records, social graphs, and identity), enabling a massive new class of useful applications.
68+
* **Battling "Enshittification" via Portability**: It restores market pressure by enabling a Permissionless Exit. If users can leave a platform while taking their data and reputation with them to an Ethereum alternative, the "walled gardens" lose their monopoly power.
69+
* **Solving the Cold Start Problem**: New dApps no longer have to start from zero. They can build on the "data capital" of incumbents, allowing users to import a 10-year reputation or credit history onto Ethereum on Day 1.
70+
* **Scaling without Permission or Censorship**: It allows Ethereum to scale into real-world use cases without needing "API blessings" or permission from corporate gatekeepers.
71+
* **Selective Disclosure**: TLSNotary ensures this new "private fuel" doesn't leak. By using zero-knowledge proofs, users stay in total control over what specific facts are shared and what raw data remains private.
72+
73+
[Read more](/blog/2026/01/01/do-not-pass-go)
4974

5075
## Make your data portable with TLSNotary!
5176

0 commit comments

Comments
 (0)