[omgtehlion]

I could not find anything about google or other browser vendors in the article.

My take is that you should trust provider (developer, hoster) of said encryption app to send you actual implementation, not something that looks like the real deal, but does not encrypt anything. From a regular user's point of view: you can not inspect what you run (due to technical reasons, that on the web anything can be downloaded and executed at any moment, swapping implementation on the fly. And due to skills needed to actually read and understand executed scripts), so you can only believe and trust. At which point usual TLS is surely enough.

[utopiah]

Like I said I'm confused, genuinely trying to figure the article out.

"A cryptosystem is incoherent if its implementation is distributed by the same entity which it purports to secure against."

What is the cryptosystem then on the Web? Who is the entity? It's not the server or the Website so I don't see what's left except the browser and browser vendor.

[avaer]

There's also a long list of government (or subpeonable) entities on your certificate trust list.

Without which TLS is not gonna work.

The article is arguing that in practice you could just send your "encrypted" communications to the browser vendor, or one of the governments on the certificate root list, or someone else in the distribution chain, and have them be the middle man. The security properties of your communications would be the same. Hence "snake oil".

Things like stapling don't change this much, or reduce to TOFU.

[prmph]

But we are talking about protecting data at rest on the vendor's servers. Unless the vendor stores no user data at, how does TLS protect that data?

Your argument is a bit like saying TLS protects plain-text passwords in transit, so there is no need to store them in hashed form in the database.