The TLS client's view of Certificate Transparency and CT Logs
TLS Certificate Transparency is a system where browser vendors require TLS Certificate Authorities to publish information about all of their TLS certificates in cryptographically validated logs, which are generally run by third parties (see also Wikipedia). This raises the question of how clients (generally browsers) interact with Certificate Transparency. As far as I can tell, it depends on how thorough a client wants to be about verifying that a TLS certificate really is in a given CT log.
The current version of Certificate Transparency is described in RFC 9162. Following RFC 9162, when a client gets a TLS certificate issued by a participating CA (which is all of them that want to work with Chrome and Safari), it will also receive (in one way or another) some number of Signed Certificate Timestamps (SCTs). Each SCT is a promise by some CT log to include the certificate (broadly speaking) in the log within a time interval specified by the log, and is signed by the CT's private key. A garden variety client can verify the SCT signatures (for CT logs that it knows of and accepts) and stop there. Generating a valid SCT requires (some) control of that log's private key and its activities, and if the key or the log is compromised, there's potentially not lots of point in going further.
(A client may also receive additional CT related information from the TLS server, up to all of the information it needs to validate things more thoroughly, See TLS Client in the RFC.)
A client that wants to be more thorough can then request a proof of inclusion in the CT log from the log operator, provided that enough time has gone by since the SCT's timestamp. I believe that it may need to bootstrap a Signed Tree Head (STH) from the CT log, unless it got one (and an inclusion proof) from the TLS server. That the TLS server can provide the STH and inclusion proof from the CT log is good for privacy but potentially bad for your confidence in the SCT, because it means that your client has no outside check on all of them. If an attacker had access to the CT log's private keys, they could potentially manufacture a STH and inclusion proof along side their signed SCT and have their server give all of them to you.
(I don't know how common it is for TLS servers to provide the additional CT information to clients. In modern usage TLS certificates have embedded SCTs, so they take no extra configuration work to provide; the other information requires the server operator to set it up and do things, and possibly for the client to have special features.)
I believe this means that a thorough client must learn and save the STHs for CT logs, and then (periodically) get a Merkle consistency proof between two STHs, possibly along side getting the latest STH for the CT log. Assuming that STH's are relatively coarse grained and aren't issued for every new TLS certificate sent to the CT log, it presumably leaks less information to the log operator to ask for a consistency proof between some STH and the current STH than it does to ask for a proof of inclusion of some specific certificate (if the server gave you that).
(Since this thoroughness requires state and state management, it's probably mostly restricted to browsers.)
Periodically verifying that two STHs are properly related to each other means that if someone has lied to you about a proof of inclusion (which requires a false STH), they have to keep lying from then onward in order to remain undetected. Otherwise, you will someday get a current STH for the real CT log (without the TLS certificate) and then there will be no path between your latest false STH and the real one.
Continually lying to you this way will be very difficult (if not impossible) if a bunch of TLS servers provide you with proofs of inclusion and their view of the log's STH during your TLS conversations. These TLS servers are seeing the true log and so getting true STHs from it and then providing these true STHs to you. Really, you don't need a bunch of TLS servers to be doing this, you just need some really popular ones to be doing it for common CT logs.
PS: RFC 9162 is surprisingly readable, especially its general discussion sections on server and client stuff. Interested people may want to at least skim them.