What do you think “private mode” is, exactly?
I’ll tell you what it is: It’s a mode where your local web browser doesn’t save its history, which only means that people who has physical access to your device cannot see this saved history. Your ISP can still see everything of consequence, and your DoH provider can see most of it.
Maybe I'm ahead of the adoption curve here, but I see no overall reason they wouldn't be.
[0] https://arstechnica.com/tech-policy/2014/12/newly-published-...
What makes you say that?
It's useless for real "privacy"
It's also really useful for testing. For example building my WebAuthn implementation I hit "Cancel" a lot. In your ordinary session the browser soon remembers this site tried a WebAuthn registration, the user hit "Cancel" so let's suppress that because it'd be annoying if sites harass you with such requests over and over. Subsequent attempts soon just silently fail - that makes it really annoying to debug the backend. Maybe a refresh will fix it? Maybe I should wait five minutes? Who knows.
But the browser intentionally doesn't remember what happens in a Private window. I can hit Cancel to check that works as expected, then open a fresh Private window and registration still works fine there instead of silently failing.
Likewise I had a Cookie bug, where a typo meant enduring session cookies that were supposed to be cleared sometimes weren't. Private windows don't preserve cookies, so I could walk through all the steps to reproduce from a "fresh start", try something, then just throw that Private window away and make a new one for the next experiment.
None of this is impossible without Private windows of course, but it was more inconvenient when we didn't have them.
i.e. "works until someone actually cares enough to take active measures to track you."
I used to work directly with these big ISPs, and I can assure you they aren't very sophisticated. Even if they log every IP you send a packet to, and they know every domain that points to each of those IPs, they can't know exactly what you requested or which particular website you visited provided these websites use HTTPS.
You can still do DNS over VPN. That is, I could set up an unbound cache on a VPS and secure my traffic to that server using wireguard or openvpn. This just pushes the eyeballs out of my home and into someone else's datacenter, though.
Their DNS severs, however, and definitely doing this, and they sell that data to 3rd parties.
TLS SNI also leaks the domain name, but again that would require deep packet inspection to extract and correlate with the clients. Definitely possible, but probably not deployed.
With DNS blocking if you try to look up a "forbidden" FQDN you get back either a bogus NXDOMAIN or A records chosen by the blocker.
DoH bypasses DNS blocking pretty cheaply. DNSSEC would detect it and stop but doesn't bypass it. Tor bypasses it but at considerable cost.
The (eventually indefinitely delayed) UK government plans to institute mandatory censorship of the Internet relied on DNS blocking as their backstop. The idea was if anybody anywhere in the world didn't voluntarily agree to obey censorship rules, they'd be blocked in the UK. The government would just accept that some proportion of users would install Tor to bypass that restriction. DoH means "some proportion of users" potentially becomes "everybody with a modern browser" and that was not palatable.
The scheme (https) is implied but isn't transmitted anywhere. An adversary can infer you used HTTPS because it was port 443 and looks like TLS traffic.
The hostname (www.duckduckgo.com) is somewhat implied by the destination IP address on the connection, and is also transmitted in the clear as part of TLS Server Name Indication so that the receiving server knows which service you wanted. In TLS 1.2 and earlier the site's certificate is also transmitted in the clear (but this is fixed in TLS 1.3). Encrypting SNI is a work-in-progress.
The path and query string are encrypted. An adversary can't discover what they are, nor can they tamper with them successfully. The total overall amount of data sent is not hidden, but clients can (though most do not) add padding to hide exactly how much of this was "real".
The fragment identifier (#foo) is not transmitted anywhere it remains only on the client (web browser).
Headers, body and so on of both request and response are encrypted, and the same caveat about an adversary knowing how much data was transmitted and when applies.
I remember when I answered a Stack Overflow question about how Domain Validation for certificates in the Web PKI work thinking that just a year or two earlier the answer would be hazy and probably get marked unsatisfactory even though it was true - because it was so vague and few people would be in a position to confirm it. As it happened they'd asked after the Ten Blessed Methods were formally required and so those are the answer, written down in black and white in a document I could offer as a reference for anyone to look at.
† The hostname part is less obvious than the rest it's fair to say because HTTP's Host header is just a header and thus encrypted, and you need extra insight to realise SNI needs to exist.
If a CA is compromised (which was very rare, even under historically more lax oversight than today) the bad guys would need to issue themselves a cert from this compromised CA, get it logged, and then from an on-path position use the certificate to MITM you and capture your URL which presumably they wanted very badly as this seems like a really expensive approach.
The CA does not have the ability to decrypt eavesdropped HTTPS traffic for example.
With their transition from selling widgets to services I wonder how much longer that will be true. And considering their attempt at iAds the privacy incentive is more historical accident than an unchangeable, core culture.