Hacker News Reader

Comment by ipython | Hacker News Reader

The problem with the logical conclusion of this argument is that it’s networks all the way down. Remember verisign site finder? https://en.m.wikipedia.org/wiki/Site_Finder

That’s the sort of crap you end up with when every network operator asserts their “right” to modify traffic.

Don’t get me wrong I do dns filtering on my home network and block public dns over http endpoints, but there is some balance to be had here imo.

Also I would not attribute https uptake to google only. A slightly less than trillion dollar organization - let’s encrypt - is really imo responsible for making https as ubiquitous as it is.

View on HN

Let's Encrypt is just the carrot (and to be clear, Google is not just a top sponsor, but two of Let's Encrypt's other top sponsors are organizations themselves sponsored by Google). Let's Encrypt is not Google but absolutely is downstream from that money flow.

Meanwhile Google itself is the stick. Google has used it's policy control over Chrome to effectively mandate using Let's Encrypt, by making using certificates without it a nightmare, and making browser features arbitrarily require HTTPS for no reason other than it pushes more people to do it.

I am not wholly against HTTPS, mind you, I think there's reasonable benefit gains for privacy on balance, but we should definitely be clear that Google and it's subsidiaries and sponsored orgs are responsible for the spread, and the reasons for doing so are not goodwill.

DoH, QUIC, and ECH are where it really begins to go "too far", where we're obliterating norms to ensure nobody can tamper with ad delivery. Things like buying gTLDs and putting them in the HSTS preload list, to roll back to why them selling their registrar business is so unusual.

> by making using certificates without it a nightmare

You can still have "classic" certificates - if exchanging certificates is enough of a nightmare that you can't even do it once a year, it's a clear indicator your tech stack is brittle beyond belief and should be updated anyway. Meanwhile if you're using a modern cloud-based stack the provider (e.g. AWS ACM) does the work for you, and acme.sh makes it a breeze on on-prem/bare-metal stacks as well.

> DoH, QUIC, and ECH are where it really begins to go "too far", where we're obliterating norms to ensure nobody can tamper with ad delivery.

What? Browser extensions still exist and DoH doesn't impact whatever you're putting in /etc/hosts, that one works just fine.

Exchanging certificates once a year is... kinda ridiculous in almost every scenario except the one Google envisions when it dictates the Internet, yes. ACME support is making it into enterprise technology, but it'll probably be another five to seven years until it's common. Literally all businesses just have to suffer bull---- processes to cave to "Google felt like doing this, and Google is a monopoly".

And of course, don't worry, Google is ruining ad blocking browser extensions too, for the 70% of users who use their web browser. (This is one of the reasons defenses for Google's behavior so rarely holds... they are attacking users through so many different avenues at once, the justification only holds if you ignore everything else they're currently doing.)

> Exchanging certificates once a year is... kinda ridiculous in almost every scenario except the one Google envisions when it dictates the Internet, yes.

The thing is, if you're doing it right it should not take longer than 5 minutes. It forces people to actually invest in good infrastructure practices rather than build brittle shit that collapses at the first blow. And most of the "enterprise" stuff you're talking squarely fits into that category.

As said I'm happy for anything that aims to prevent ossification, simply because how often I have heard the lines "why invest into something proper when a thrown-together hack lasts us just the same" or "why replace that old Cisco firewall box if it ain't broken yet".

Reply on news.ycombinator.com