I choose to serve my blog over HTTP, because we need no intermediaries to publish content on the Internet.

Just your ISP, their ISP, your hosting provider (if applicable) and the browser vendor.

Adding in an optional HTTPS there would not greatly increase the amount of intermediaries, though I by no means argue that it matters.

It brings in one central intermediary used by most of the internet, converting a decentralised system to centralised.

For end users of websites ("users") one problem with so-called "WebPKI", as this "WebPKI" is currently implemented, is

(a) it forcefully "delegates" trust to third parties, i.e., commercial CAs

(b) these CAs, for a fee, are happy to trust sites that the user would not trust if given the choice of which sites to trust, e.g., ad servers, tracking servers, etc.

(c) popular browsers pre-install (trust) third party commercial CA certificates^1

(d) popular browsers distrust the user's freely-generated CA certificates

The efforts of the user who wants to sign a small number of certificates from sites that he trusts are deliberately hindered by (d). For example, browser warnings, interstitials, TLS failures. The user is effectively discouraged perhaps even prevented from trusting himself, i.e., his own CA, while being forced to trust pre-installed third party commercial CAs

One might reason this problem could be avoided by not using popular browsers. However, website owners, and today, "Content Delivery Networks" (CDNs), attempt to coerce or force users accessing websites to use popular browsers. The CDNs terminate TLS connections and substitute their own server certificates . These certificates are signed by CAs approved by the browser vendor. This produces no browser warnings, interstitials, or TLS failures

However if the user terminates TLS connections and substitutes her own free certificate signed by her own free CA,^2 then this will trigger browser warnings, insterstitials and/or TLS failures. The practice of the user trusting herself more than third parties is deliberately hindered

From this state of affairs, one might conclude that TLS termination is acceptable under this "WebPKI" so long as the CA is approved by the browser vendor and the user is not the one doing the termination

1.

These pre-installed certificates in (c) are also distributed by a popular browser vendor as a "bundle" for installation in operating systems, non-browser software, etc.

In other words, users get these CA certificates not from the CA but from another third party, i.e., a browser vendor

But it's also possible to get the CA certificates directly from the CAs

This can be done over HTTP (cf. HTTPS)

2.

I do this using a loopback bound TLS forward proxy. I use TLS failures as an additional way to block undesired connections, e.g., to Google servers (another form of so-called "de-Googling")

The proxy performs _many_ different functions for me, allowing far more control and versatility than a popular browser. Plus I can modify and compile the proxy myself even on underpowered computers; it's only several MB. Whereas compilation of a popular browser is impractical by comparison. Compiling a so-called "modern" browser consumes too much time, CPU, RAM and storage space

One function is sending all HTTP requests over TLS, so, e.g., an http:// URL as in this story about HSBC would be sent as HTTPS^3

This applies to all software sending HTTP requests on the computer, not only browsers

I have a file that lists sites for which I do not want to go over HTTPS. This file is loaded into the proxy's memory and these sites will be forwarded by the proxy without using HTTPS. This is a short list but an important one

I use rinetd and DNS to send TCP and HTTP traffic to the proxy as opposed using the firewall. As such it's still possible to reach non-HTTPS sites via IP address, even in popular browsers

3.

If HSBC used IP addresses rather than a domain name, then this could bypass the proxy