So, you're already familiar that when we hit a HTTPS server (via browser/app), the server produces a "certificate". This cert is used for: 1. Initialising encryption parameters. 2. Identification that it's indeed the right server It's the 2nd one we're interested in.

e.g. here's the certificate produced by Twitter's servers. As we can see, this certificate was issued by "DigiCert TLS...", which in turn, was certified by "DigiCert Global Root CA".

How does the browser know which Root CAs to trust? Clearly, trusting a wrong CA can be disastrous, as someone can then impersonate that website, while your browser shows that website as legitimate & trusted. So, strong criteria should be used to decide which Root CAs to trust.

Originally, each browser vendor used to keep their own criteria, but in 2005 a bunch of them got together to create , to define a std set of criteria which CAs need to adhere to, in order to be accepted in the Root CA list published by the CAB Forum.

But this approach is still flawed, like what happens if a CA is hacked (), or if the CA does the right thing in front of the auditors, but does backroom dealing with state actors. Clearly a problem of centralisation of CAs.

It is at this point that someone would jump in and shout "web3 solves this". But hold your horses. There's an easier & more efficient alternative: Certificate Transparency (CT) Logs

CT provides for an append only log, to which anyone (typically CAs) can submit new certificates to. This forces all compliant issuers to be fully transparent, so that maliciously issued certificates can't stay undetected. e.g. we can see DigiCert logged Twitter's cert to 3 logs

Browsers can then check if the cert as seen by them, is visible in CT Logs. If not, it's proof that the CA issued a cert without logging it in CT. "A very bad thing"! Note that it doesn't prevent a CA from issuing a bad cert, but they can't do it without being caught!

The astute amongst you will ask: what if a bad actor deliberately submits a bad certificate to the logs to bring disrepute to the CA? Answer is simple: they can't. On a new submission, the log operator verifies if this cert is indeed issued by the claimed CA (PKI FTW).

The append only property is also crucial, as without it, it'd be possible to do backdated changes. It's achieved via Merkle trees (yeah, the same ones used in blockchains) A web3 enthu cutlet at this point might say: "Merkle trees means you're just using blockchain".

Well, no. Merkle trees were created much before blockchains, and have been used by different products for a very long time. Plus, here, because of public cryptography's inherent locally verifiable nature, you don't need "consensus". You just need transparency.

As you can see, while this doesn't prevent malicious issue, it will get caught very quickly & publicly, and the issuer loses business & trust. Using 1st principles, you can solve most distributed trust issues without getting into "web3 solves this". Technical debates welcome.

To be clear, I've been deliberately loose with some of the concepts, in favour of brevity. Will clarify as they come up.

@amodm 15 years ago we built p2p zkp secured data saving/sharing. This was the time when using OTR encryption in chat was niche and people didn’t care about privacy and security much. Our product failed. Nothing much has changed. Web3/crypto is hot now not because of technical reasons.

@vys The idea here wasn't to make a point about what factors lead to product success, but to disprove the claim of exclusivity of "web3" in solving for decentralisation. Products will continue to win/lose based on a variety of factors.

@amodm What a beautiful thread. Thank you! So many ideas captured so well. Threads like these across various topics is what leads to serious FOMO.

@SaarthakAgarwal Thx, but how does this lead to FOMO?

@amodm Yup, the OS projects of old,Gnu, and OSF/Apache are all great examples of a decentralized stores which were immutable, secure peer reviewed, protocol based and verified to provide value for the collective. However built in BC stores and sprotocols obviously help, just my view 🙏

@SundarSrik This 🧵 is more to disprove claims of exclusivity of web3 in solving decentralisation, than to prove lack of usefulness of blockchain. Also, to bring focus back to fundamentals than brouhaha.

@amodm @amodm , thank you for your kind words. This was very helpful in understanding encryption and determining the proper server parameters. Do you honestly believe that certificate transparency logs will become a viable alternative to web3, or that web3 will simply become a buzzword?

@TapanshuTanay This deals only with solving "authority" problems in TLS certificate issuance. It's clearly not a problem for all authority problems. Idea here was to give a template of how one can solve for the same goals differently than "web3", so that most efficient answers can emerge.