misc fixes. (#27)

* misc fixes.

* revert wording

src/SUMMARY.md

@@ -31,7 +31,4 @@
 - [Committed Oblivious Transfer]() <!-- (./mpc/committed_ot.md) -->
 - [Oblivious Transfer]() <!-- (./mpc/oblivious_transfer.md) -->
 
-# Developer resources
-
-
 +[Glossary](./glossary.md)

src/intro.md

@@ -20,7 +20,7 @@ The TLSNotary protocol consists of 4 steps:
 
 ### ① Multi-party TLS Request
 
-TLSNotary works by adding a third party, the `Notary`, to the usual TLS connection between the `User` and a `Server`. This `Notary` is **not "[a man in the middle](https://en.wikipedia.org/wiki/Man-in-the-middle_attack)"**. Instead, the `Notary` participates in a **secure multi-party computation** (MPC) to jointly operate the TLS connection without ever seeing the data in plain text; the `Notary` only sees encrypted data. Given that the `Notary` only sees the temporary key of the `Server`, the `Notary` does not know which `Server` the `User` is communicating with. The TLSNotary protocol is transparent to the `Server`. From the `Server`'s perspective, the User's connection is a standard TLS connection.
+TLSNotary works by adding a third party, the `Notary`, to the usual TLS connection between the `User` and a `Server`. This `Notary` is **not "[a man in the middle](https://en.wikipedia.org/wiki/Man-in-the-middle_attack)"**. Instead, the `Notary` participates in a **secure multi-party computation** (MPC) to jointly operate the TLS connection without ever seeing the data in plain text; the `Notary` only sees encrypted data. Given that the `Notary` only sees the temporary key of the `Server`, the `Notary` does not know which `Server` the `User` is communicating with. The TLSNotary protocol is transparent to the `Server`. From the `Server`'s perspective, the `User`'s connection is a standard TLS connection.
 
 <!-- - Transport Layer Security (TLS)
     - Encryption: hides data from third parties
@@ -28,18 +28,18 @@ TLSNotary works by adding a third party, the `Notary`, to the usual TLS connecti
     - Integrity: verifies that data has not been forged or tampered with -->
 ### ② Notarization
 
-By participating in the **secure multi-party computation** (MPC) for TLS communication, the `Notary` can validate the authenticity and integrity of the communication with the `Server`. If the `User` has not cheated, the `Notary` **signs** the transcript of the entire TLS session. Since the `Notary` only checks encrypted data, this process is referred to as "blind signing".
+By participating in the **secure multi-party computation** (MPC) for TLS communication, the `Notary` can validate the authenticity and integrity of the `User`'s communication with the `Server`. If the `User` was honest, the `Notary` **signs** the transcript of the entire TLS session. Since the `Notary` only validates encrypted data, this process is referred to as "blind signing".
 
 ### ③ Selective Disclosure
 
 The TLSNotary protocol provides a means for the `User` to selectively prove the authenticity of arbitrary sections of the transcript to a `Verifier`. In this context, the `User` is often referred to as the `Prover`.
 
-Due to the manner in which the `Notary` signs the transcript, the `User` can **redact sections**, thereby removing sensitive data. This capability can be paired with Zero-Knowledge Proofs to prove properties of the redacted data without revealing the data itself.
+The `User` can **redact sections** of the transcript, thereby not disclosing sensitive data to the `Verifier`. This capability can be paired with Zero-Knowledge Proofs to prove properties of the redacted data without revealing the data itself.
 
 ### ④ Verification
 
 A `Verifier` validates the proof received from the `User`. By comparing the signature against the `Notary`'s public key, the `Verifier` ensures that the `User` did not tamper with the data.  
-The data's origin can be verified by inspecting the `Server` certificate through trusted certificate authorities (CAs).
+The data origin can be verified by inspecting the `Server` certificate through trusted certificate authorities (CAs).
 
 ### Trust Assumptions
 
@@ -62,7 +62,7 @@ While TLSNotary can notarize publicly available data, it does not solve the "[or
 
 ## Who is behind TLSNotary?
 
-TLSNotary is developed by the Privacy and Scaling Exploration (PSE) research lab of the Ethereum Foundation. The PSE team is committed to conceptualizing and testing use cases for cryptographic primitives.
+TLSNotary is developed by the [Privacy and Scaling Exploration (PSE)](https://pse.dev) research lab of the Ethereum Foundation. The PSE team is committed to conceptualizing and testing use cases for cryptographic primitives.
 
 TLSNotary is not a new project; in fact, it has been around for [more than a decade](https://bitcointalk.org/index.php?topic=173220.0).
 

src/motivation.md

@@ -10,21 +10,21 @@ Data provenance will make data truly portable, empowering users to share it with
 
 ![](png-diagrams/data_provenance_none.png)
 
-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 the `User` from the `Server` indeed originates from the `Server` and was not changed. The `Server`'s identity is verified by the `User` 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.
+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 the `User` indeed originated from the `Server` and was not changed. The `Server`'s identity is verified by the `User` 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.
 
-However, this hash does not provide **non-repudiation**, meaning it cannot serve as evidence for the **authenticity and integrity** of the data to third parties (e.g., a service or an app). Because it is a keyed hash and TLS requires that the key is known to the `User`, the `User` could modify the data and compute a corresponding hash after the TLS session is finished.
+However, this hash does not provide **non-repudiation**, meaning it cannot serve as evidence for the **authenticity and integrity** of the data to third parties (e.g., a service or an app). Because it is a keyed hash and TLS requires that the key is known to the `User`, the `User` could potentially modify the data and compute a corresponding hash after the TLS session is finished.
 
 Achieving non-repudiation requires digital signatures implemented with asymmetric, public-key cryptography.
 
-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 forwarding all data could expose too much information, compromising the `User`'s privacy. **Privacy** is a vital social good that must be protected.
+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 the `User`'s privacy. **Privacy** is a vital social good that must be protected.
 
 ## Status Quo: delegate access
 
 ![](png-diagrams/data_provenance_oauth.png)
 
-Currently, when a `User` 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.
+Currently, when a `User` 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.
 
-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.
+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.
 
 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.
 
@@ -36,10 +36,10 @@ TLSNotary operates by introducing a third party, the `Notary`, into the usual TL
 
 The TLSNotary protocol is **transparent** to the `Server`. From the `Server`'s perspective, the TLS connection is indistinguishable from all other connections. As such, **no modifications to the TLS protocol are necessary**.
 
-Due to the TLSNotary protocol's nature, it enables the `User` to selectively prove the authenticity of arbitrary portions of the data to a Verifier. Through the `Notary`'s signing of the data, the `User` can prove the data's authenticity to any third-party `Verifier`. The provided proof can be easily verified by the `Verifier`.
+The TLSNotary protocol enables the `User` to selectively prove the authenticity of arbitrary portions of the data to a `Verifier` as long as the `Verifier` trusts the `Notary` who signed the data.
 
 ## Make your data portable with TLSNotary!
 
-TLSNotary is a solution designed to prove the authenticity of data while preserving user privacy. It unlocks a variety of new use cases. So, if you're looking for a way to make your data portable without sacrificing its authenticity or compromising on privacy, TLSNotary is developed for you!
+TLSNotary is a solution designed to prove the authenticity of data while preserving user privacy. It unlocks a variety of new use cases. So, if you're looking for a way to make your data portable without compromising on privacy, TLSNotary is developed for you!
 
 Dive into the protocol and integrate it into your applications. We eagerly await your feedback on [Discord](https://discord.com/invite/9XwESXtcN7).

src/protocol/notarization/README.md

@@ -14,11 +14,11 @@ The `Requester` is the party which runs the TLS connection with the `Server`. Th
 
 ## Notary
 
-The `Notary` is the party of which the authenticity of the `Transcript` relies on. During the session the `Notary` withholds its' shares of the TLS keys and participates in a series of secure 2-party computation protocols with the `Requester` to operate the TLS connection.
+The `Notary` is the party of which the authenticity of the `Transcript` relies on. During the session the `Notary` withholds its' shares of the TLS keys and participates in a series of secure MPC protocols with the `Requester` to operate the TLS connection.
 
 ## Server
 
-The `Server` can be any server which supports TLS. The TLSNotary protocol is entirely transparent to the `Server`, thus it can not be censored nor does it have to support any additional functionality.
+The `Server` can be any server which supports TLS. The TLSNotary protocol is entirely transparent to the `Server`, thus it cannot be censored nor does it have to support any additional functionality.
 
 <img src="../../png-diagrams/tls12-multiround.png">
 

src/protocol/notarization/commitment.md

@@ -1,9 +1,9 @@
 # Commitment
 
-The TLSNotary protocol entirely conceals the plaintext transcript from the `Notary`. Simultaneously, the TLSNotary protocol offers a way to the `User` to selectively prove the authenticity of arbitrary portions of the plaintext to the `Verifier`.
+As part of the TLSNotary protocol, the `User` creates authenticated commitments to the plaintext and the `Notary` signs those commitments without ever seeing the plaintext. This offers a way for the `User` to selectively prove the authenticity of arbitrary portions of the plaintext to the `Verifier`. 
 
-A naive approach could extend the `Encryption and Decryption` steps to also compute a commitment (e.g. a blake3 hash) to the plaintext in MPC, with the `Notary` signing that commitment. The `User` could then open the commitment to the `Verifier`. Unfortunately, this approach would be resource-intensive, prompting us to provide a more lightweight commitment scheme.
+A naive approach of creating such authenticated commitments is to extend the `Encryption and Decryption` steps to also compute a commitment (e.g. a blake3 hash) to the plaintext using MPC and have the `Notary` sign that commitment. Unfortunately, such MPC approach is too resource-intensive, prompting us to provide a more lightweight commitment scheme.
 
-The high-level idea is that the `User` will reuse the encodings from the MPC protocol used for `Encryption and Decryption` to create commitments[^commitment_scheme]. Since those encodings are chosen by the `Notary` and are not known to the `User` at the time when she makes a commitment, they can be thought of as "authenticated plaintext".
+The high-level idea is that the `User` creates a commitment to the encodings from the MPC protocol used for `Encryption and Decryption`. Since those encodings are chosen by the `Notary` and are not known to the `User` at the time when she makes a commitment, they can be thought of as "authenticated plaintext".
 
-[^commitment_scheme] For technical details on the commitment scheme, see [Commitment scheme](/mpc/commitment_scheme.md)
+For technical details on the commitment scheme, see [Commitment scheme](/mpc/commitment_scheme.md)

src/protocol/notarization/encryption.md

@@ -10,20 +10,20 @@ Both parties see the resulting ciphertext and execute the [2PC MAC](../../mpc/ma
 
 The `User` then dispatches the ciphertext and the MAC to the server.
 
-As explained in the [Commitment section](commitment.md), the `User` creates a commitment to the plaintext (her private input to DEAP).
+As explained in the [Commitment section](commitment.md), the `User` creates a commitment to the plaintext (her private input to MPC).
 
 ## Decryption
 
-Once the `User` receives the ciphertext and its associated MAC from the server, the parties first authenticate the ciphertext by validating the MAC. They do this by running the [MPC] (/mpc/mac.md) protocol to compute the authentic MAC for the ciphertext. They then verify if the authentic MAC matches the MAC received from the server.
+Once the `User` receives the ciphertext and its associated MAC from the server, the parties first authenticate the ciphertext by validating the MAC. They do this by running the [MPC](/mpc/mac.md) protocol to compute the authentic MAC for the ciphertext. They then verify if the authentic MAC matches the MAC received from the server.
 
 Next, the parties decrypt the ciphertext by providing their key shares as private inputs to the [MPC](/mpc/deap.md) protocol, along with the ciphertext and some other public data.
 
 The resulting plaintext is revealed ONLY to the `User`.
 
-As discussed in the [Commitment section](/protocol/notarization/commitment.md), the `User` establishes a commitment to the plaintext.
+As discussed in the [Commitment section](/protocol/notarization/commitment.md), the `User` creates a commitment to the plaintext.
 
 Please note, the actual low-level implementation details of `Decryption` are more nuanced than what we have described here. For more information, please consult [Low-level Decryption details](/mpc/encryption.md).
 
 ## Summary
 
-This chapter illustrated how the `Notary` and `User` collaborate to encrypt and decrypt data. The `Notary` performs these tasks "blindly," without acquiring knowledge of the plaintext. In fact, the `Notary` even remains unaware of the `Server` with which the `User` is communicating. Additionally, the `User` creates commitments to the plaintext and can use these later to prove the authenticity of the plaintext to a third party `Verifier`.
+This chapter illustrated how the `Notary` and `User` collaborate to encrypt and decrypt data. The `Notary` performs these tasks "blindly", without acquiring knowledge of the plaintext. In fact, the `Notary` even remains unaware of which `Server` the `User` is communicating with. Additionally, the `User` creates commitments to the plaintext and can use them later to prove the authenticity of the plaintext to a third party `Verifier`.

src/protocol/notarization/handshake.md

@@ -2,12 +2,12 @@
 
 During the TLS handshake, the TLS Client and the TLS Server compute the session keys needed for the encryption and decryption of data.
 
-In TLSNotary protocol `User` and `Notary` jointly play the role of the TLS Client. The User is the one who physically communicates with the server but all cryptographic TLS operations are performed in MPC.
-The parties use MPC to compute the session keys in such a way that neither party ever learns the full keys but each has their share of the keys.
-They then use their shares of the keys to finish the TLS handshake.
+In TLSNotary protocol the `User` and `Notary` jointly play the role of the TLS Client. The `User` is the one who physically communicates with the server but all cryptographic TLS operations are performed using MPC.
+
+The parties use MPC to compute the session keys in such a way that each party only has their share of the keys and never learns the full keys. The parties proceed to complete the TLS handshake using their shares of the keys.
 
 To a third party observing the `User`'s connection to the server, the connection appears like a regular TLS connection. The `User` maintains all the security guarantees of a standard TLS connection against a third-party bad actor.
 
 However, the `User`'s TLS connection does not maintain the normal TLS security against the `Notary`. Instead, the `User` relies on the security which the underlying MPC protocols provide.
 
-With the shares of the session keys computed, the parties now proceed to the next MPC protocol where they use their session key shares to jointly encrypt requests to and decrypt responses from the server while keeping the plaintext of the request/response private from the Notary.
+With the shares of the session keys computed, the parties now proceed to the next MPC protocol where they use their session key shares to jointly encrypt requests to and decrypt responses from the server while keeping the plaintext of the request/response private from the `Notary`.

src/protocol/verification.md

@@ -1,6 +1,6 @@
 # Verification
 
-A `Verifier`` receives the following from the `User`:
+A `Verifier` receives the following from the `User`:
 
 <!-- TODO will explain each -->