More conversions + added TODO notes

docs/Protocol/commit_strategy.md

@@ -25,4 +25,4 @@ The commitment strategies differ mainly in the number of committed ranges (`K`).
 | `Attestation` | Artifact signed by the `Notary` attesting to the authenticity of the plaintext from a TLS session | Constant     | `Attestation` only contains data that remains constant-sized regardless of `K`, e.g., the Merkle root of the commitments |
 | `Secret`      | Artifact containing secret data that correspond to commitments in `Attestation`                   | Linear       | `Secret` contains some data whose sizes scale linearly with `K`, e.g., a Merkle tree whose number of leaves equals `K`   |
 
-Using the default hash algorithm (i.e., BLAKE3), every additional range committed costs around 250 bytes of increment in the size of `Secret`. For more details, please visit this [Jupyter notebook](https://github.com/tlsnotary/docs-mdbook/blob/main/src/protocol/commit_strategy.ipynb).
+Using the default hash algorithm (i.e., BLAKE3), every additional range committed costs around 250 bytes of increment in the size of `Secret`. For more details, please visit this [Jupyter notebook](https://github.com/tlsnotary/landing-page/blob/docusaurus/docs/Protocol/commit_strategy.ipynb).

docs/faq.md

@@ -8,6 +8,59 @@ import TOCInline from '@theme/TOCInline';
 
 <TOCInline toc={toc} />
 
+## Generic Questions
+
+### Why is TLS not sufficient for data portability?
+
+TLS indeed signs a checksum (a Message Authentication Code, MAC) to check data integrity. However, in TLS, both the Server and the User use symmetric keys for data exchange, meaning the same key is employed for both encryption and decryption. This symmetric key usage allows a User to modify the data and retroactively compute a new checksum. As a result, this checksum alone is insufficient to guarantee data authenticity to a third party.
+
+### How can I verify the data origin in a TLSNotary proof?
+
+The proof contains the domain name and ephemeral public key of the server. A standard certificate verifier can verify whether the key is valid for the provided server name and that it chains to at least one trusted root certificate.
+
+### What does “privacy-centric” exactly mean for TLSNotary?
+
+TLSNotary does not compromise on privacy for performance reasons. It prioritizes user privacy in all its operations. The verifier only sees the data the prover decides to share.  
+
+If a generic notary is used to verify the TLS session, this notary only sees encrypted data and does not know what Server the Prover communicates with. The only information the Notary can see is: the time of the TLS-session, the length of the requests and responses, the number or round trips, and which cipher suite is used.
+
+### What is the overhead of using TLSNotary?
+
+The Multi-Party Computation (MPC) between the Prover and the Verifier requires significant bandwidth, orders of magnitude more than the Server's data size.
+
+### Can the server detect that a TLS session is being notarized?
+
+To the server, the TLS connection appears the same as any other connection. Only the User communicates with the Server, not the Notary or the Verifier. However, the timing patterns of TLS communication might have a different fingerprint, so through statistical analysis, specific identifying patterns might be uncovered.
+
+### Can TLSNotary be used for public data?
+
+Yes, but for public data, a less-resource-intensive man-in-the-middle approach is more economical since the privacy features of TLSNotary are superfluous in this scenario.
+
+### How can I inspect and verify a TLSNotary proof?
+
+The easiest way is to use the proof-of-concept [TLSNotary Explorer](https://explorer.tlsnotary.org).
+
+### Which TLS versions are supported?
+
+TLSNotary currently supports TLS 1.2. Support for TLS 1.3 is on the roadmap.
+
+### How can I use TLSNotary to verify data on-chain?
+
+At the moment the most practical way to verify data on-chain is to prove the data directly to an off-chain application-specific verifier. There are planned upgrades to make TLSNotary proofs directly verifiable on-chain.
+
+### Why can a verifier trust a TLSNotary proof?
+
+A TLSNotary proof is trustworthy because of its cryptographic integrity and its inclusion of an ephemeral key, allowing verifiers to confirm the data's origin from the claimed domain. This trust also hinges on the verifier's confidence in the data source (the server) and the validity of any redactions. Additionally, if the verifier did not conduct the TLS-MPC process themselves, they must trust in the notary's neutrality, ensuring it has not been influenced or compromised by the Prover.
+
+### How does TLSNotary differ from other TLS portability approaches?
+
+TLSNotary distinguishes itself with its dedication to open-source development and a strong emphasis on trustlessness. Developed as a public good without a business model, it fosters transparency and allows for community-driven improvements.  
+
+Unlike other solutions, TLSNotary is designed to prioritize trustlessness, thereby guaranteeing superior levels of privacy and security. It achieves this without depending on particular network assumptions or compromising on privacy or security to enhance performance. This strategy positions TLSNotary as the go-to choice for projects that place a high value on security and privacy in their TLS portability needs.
+
+
+## Protocol Questions
+
 ### Doesn't TLS allow a third party to verify data authenticity?
 
 No, it does not. TLS is designed to guarantee the authenticity of data **only to the participants** of the TLS connection. TLS does not have a mechanism to enable the server to "sign" the data.