This won't really work technically, because pins can only be installed after the client has formed a TLS connection to the server, so if you have a self-signed certificate, the client will refuse to connect. In principle you can override this refusal, but in practice browsers make it very hard. Moreover, this isn't what you want people to do, because unless you have some out of band way of distributing the certificate or its fingerprint (and users check it) then they are open to a MITM attack by anyone on the network on first use, not just by attackers who have a valid (but misissued) WebPKI certificate.
The article mentions that pinning is often used by mobile apps and IoT devices. In those contexts, you have an easy out-of-band mechanism to deliver the cert: baking it into the app/firmware binary. (The user generally receives this from the App Store, or in a cardboard box from a retailer, so no initial TLS connection to your server is required.)
If you're pinning the leaf certificate this way, really the only benefit I see of using a WebPKI cert is if you want to reuse the same API endpoint for a web app. Otherwise you're mostly getting a bunch of restrictions and downsides (information leaks from CT, revocation drama, etc) that don't make sense if the cert is hard coded in the client.
I was thinking about certificates distributed with the software itself, so extra bootstrapping connection is not needed. Although in some cases it could still be done, just using other, trusted and not pinned context, I guess.
But yes, for the specific narrow use case of web pages and web browsers, this means out of band installation into the browser trust store. And if we focus on this particular use case, what difference does it make if the cert is self signed or not?
I'm not following you. The way pinning (specifically HPKP) works is that you're supposed to use a valid WebPKI certificate, so the initial connection works, and then you send a header to pin that certificate (or more likely it's CA).
Pinning in mobile apps/IoT is usually done the way the grandparent comment suggests. The fingerprint of the key is hard coded into the app somewhere,[1] so there's no initial connection without it.
IMO, pinning only solves the corner case scenario where a public CA is compromised or issuing fake certs under the table. Everything else is make-the-blue-team-feel-good measures like trying to keep users from intercepting their own traffic, or actively owner-hostile effects like devices no longer working when the cert is rotated. I'm happy to see CloudFlare calling for it to be retired.
[1] sometimes it's more DIY than that, where the code will require that the issuing cert have a particular string in its name, etc.
WebPKI still has the "devices stop working if certs are rotated" problem, just on a longer timescale. If the user takes an old IoT device out of the box, and the auto-update server is using a newer root cert that wasn't trusted when the device first shipped, they'll have a bad time.
Any solution to this requires something that basically looks like certificate pinning. You've gotta rely on your server provider to use a dwindling set of "trusted by the original device firmware and also still trusted now" root certs forever (which gets fun when all of those certs are mandated to expire), or you've gotta create some other mechanism to establish trust on software updates (delivering them via unencrypted HTTP and then verifying an OpenPGP signature is a common choice).
Ah, yes, I was wondering if you have meant HPKP. But then I checked it's deprecated in FF, removed in Chrome and was never present in Edge or Safari. At least according to Wikipedia. MDN mentions it as "obsolete". So it doesn't look like something usable in practice these days, right?
