Hacker News Reader

Comment by superkuh | Hacker News Reader

>For the past several years, more than 90% of Chrome users' navigations have been to HTTPS sites,

How do they know this? That's frightening. I guess that's part of why they're so okay with going to HTTPS only; it apparently doesn't stop them from snooping.

Adding scaremongering annoyance click-throughts for connections to HTTP is bad too. Much like how the megacorp browsers have made HTTPS self-signed sites unvisitable it looks like they're trying to make HTTP sites unvisitable too. This will not be a problem for for-profit and institutional sites but it'll make most of the old, non-commercial web unvisitable for chrome users.

I'm not against HTTPS or HTTPS by default. I think that's a good idea. But stopping people from visiting HTTP sites is something that only makes sense in some contexts. Doing it universally will make the web a much smaller, more profit oriented space (at least for chrome users).

View on HN

The snooping is literally just Chrome saying "I've visited 95 pages, 90 of which were encrypted." None of that violates HTTPS's security guarantees; the fact that you are using encryption is not a secret in HTTPS.

This isn't scaremongering. Go on any kind of public Wi-Fi and see what horrors the network does to your unencrypted traffic (and how those horrors can get cached and persist when you leave the network). It's actually kind of bonkers that we spent a decade treating unsigned HTTPS as less secure than unencrypted HTTP. As for non-commercial sites, we've had Lets Encrypt for almost a decade at this point. It's literally free, and it's really all you need. There is no excuse for any public facing website with a fully-qualified domain name to not have encryption anymore.

As far as I'm aware Chrome isn't trying to ban HTTP connections. All they're doing is giving you a warning. Hell, they're actually making things easier on the old web by doing automatic upgrades. So you don't even need to change your old HTML files, you just need to ensure that you have a cert setup in your server configuration.

No on is advocating for HTTP only. We're saying webservers should be HTTP+HTTPS.

> As for non-commercial sites, we've had Lets Encrypt for almost a decade at this point

Saying there's "no excuse" to not have HTTPS is presuming there's a benefit in 100% of cases to have it in the first place. I don't want my internal sites breaking because a cert couldn't be updated, on something that didn't need it in the first place. There are even external sites I run that I could argue don't need it.

Just imagine 10-year-old-us trying to build a website now, and some megacorp slapping us down and saying ‘No TLS no excuse!’

I'm having a hard time imagining a 10 year old capable of building a website from scratch but incapable of figuring out how to setup Let's Encrypt.

You realise building a website can be done in notepad, without a web server, or self hosted on loopback, or a variety of other things, right?

You do realise a HTML page in notepad isn't a website, right?

TFA is about moving all http:// navigations to https:// and requiring explicit permission to access content over http://.

A local file is not served over HTTP.

"There is no excuse for any public facing website with a fully-qualified domain name to not have encryption anymore."

This is a display of arrogance and lack of empathy matching the Chrome team's article.

There is a sizable "old web". Built by amateurs. Think people writing web pages in Microsoft Word and FTP-ing it. They're not web developers or sysadmins and have absolutely no idea what we're talking about when we insist they should just install certbot.

Many of the owners may not be reachable anymore or in the worst case, dead.

I object to breaking the old web. I object to the assumption that behind every website there is a competent tech team, perpetually upgrading whatever others decide to break from some ivory tower. And whilst I don't need convincing of the security benefits of HTTPs, I worry about the centralizing force that it is.

Take out Letsencrypt and Cloudflare and you destroy the internet. We're practically begging for it.

Linux distro repositories commonly use http and gpg verify on the host, as the repository hosting provider may be as grey party. I assume tls overhead on CDNs would be substantial, so if cryptographic verification can be offloaded elsewhere, maybe that is a reasonable solution in some cases.

> I object to breaking the old web.

Just click through the warning.

Sure, as geeks we're all going to click though. But 99% of people aren't going to. So that makes hosting a visitable website pretty hard.

I just think that's significantly different from "breaking" the old web. Nothing is broken.

Totally agree. Old forums and personal websites are some of the best resources on the web for many topics outside of current events. Google Search already downranks them in favor of more corporate results, and this Chromium change will hurt that part of the web even more.

It's maddening that so many people in tech seem oblivious to the fact that most people in the world interact with the web totally differently than them and have very different interests. Google in particular can be so hostile to people who couldn't care less about the latest tech trends and just want the stuff they care about to work with minimal fuss.

If you're writing HTML directly and SFTPing into a server, you probably are also using a shared hosting platform that offers Lets Encrypt. You don't even need to touch a config file or install certbot in that case, you literally just click a button. If your host does not offer Lets Encrypt there are hundreds that will host bare files and do offer encryption, and migration is as simple as copy-pasting files and transferring the domain.

If the owners are unreachable or dead you have bigger problems to worry about then having to click through to an unencrypted site. Dead people can't pay hosting bills.

I get what you're saying with centralization but LE is not the only central point of failure here. The old web would not survive, say, VeriSign deciding to make .com worse or ICANN deciding to kill DNS. At least we can switch CAs.

> There is no excuse for any public facing website with a fully-qualified domain name to not have encryption anymore.

One really good excuse is for sites like neverssl.com. Its sole purpose is to always be unencrypted so janky WiFi (and truly horrifying ethernet) setups can work.

That's an edge case made specifically to be MITM'd by the network you're on. It's also a pretty good example of what someone with control of the network can do to any non-encrypted connection.

> There is no excuse for any public facing website with a fully-qualified domain name to not have encryption anymore.

neverssl.com is a legitimate use case (though the fact that it's even needed is unfortunate).

`neverssl.com` will continue to work just fine. It's not like ISPs are blocking HTTP or something, your browser is just going to tell you that the site is HTTP and you'll have to click through.

The click-through is already cumbersome and hidden by default. I wouldn't be surprised if it was soon deprecated altogether.

>no excuse

Are you sure about that? Yeah if your site has possibly sensitive data or deals with login data, HTTPS matters a lot.

Thing is, there's still a sizable portion of the web that runs without HTTPS because for a static blog/site about boring stuff you really get no advantage on HTTPS besides "Chrome won't yell at you" (which to be clear, Chrome Being Annoying About It has been the larger push to HTTPS for this group of site operators).

> As far as I'm aware Chrome isn't trying to ban HTTP connections.

It's the long-term goal. The link says this specifically. Right now they'll do silent upgrades but the long-term goal is to show the current "insecure connection" interstitial for expired HTTPS certs.

Also, as has been stated in other places - intranet is a thing and deploying self-signed certs, especially on consumer intranets (who do need these things for setting up stuff like printers, home cameras and solar panels) is a complete crapshoot.

Windows has its own cert store, but so do Chrome and Firefox and you need it in the browser to work (plus adding it is really non-intuitive). Linux has no cert store if memory serves me right so you only need the browsers. Android requires digging in the system settings to add a cert and on iOS you need a provisioning profile to add any certs if I'm not mistaken. No clue about OSX.

To be clear there's mitigations - ie. Autotrust the reserved intranet/multicast TLDs (.intranet, .internal, .private, .corp, .home, .lan and .local - this list being taken from RFC6762, which is followed by the IETF even if they've never officially declared it to be in effect) or having a universally signed certificate for those domains that generates no records in the crt.sh log (this is why you can't always issue things for intranets with a public CA - all certificate requests to public SSL hosts like letsencrypt are logged).

Both would probably limit security but they're a big hurdle that needs clearing.

> How do they know this?

I believe the setting "Make searches and browsing better" (subtitle "Send URLs of pages you visit to google") under chrome://settings/syncSetup is on by default if you don't manually uncheck the send usage data checkbox when installing

Even without snooping on domains (let alone entire URLs), it would be feasible to only observe the protocol part of `window.location` and send it as anonymized telemetry.

But who am I kidding, given who we're talking about, I doubt that's what's happening.

Chrome is an extension of Googles ad empire, it spies in you.

It is publicly available data from Chrome's non-URL keyed metrics system. https://transparencyreport.google.com/https/overview?hl=en

> How do they know this?

I'd assume through ga.js (and urchin.js).

> How do they know this? That's frightening.

It's very frightening, and it's the end result of opt-out telemetry "to make the product better". There are certain pieces of software that should never have telemetry: your OS, your web browser, your terminal, your email client...

I choose software written by craftspeople with an opinion who don't "need" telemetry, not software that's just a conduit to hoover up my personal and sensitive data.

Is "percentage of sites visited that are HTTP vs HTTPS" "personal" or "sensitive" to you? And if so... how?

Yes, all of my data is sensitive to me. I don't want Google knowing anything about me, including when I use their software.

Reply on news.ycombinator.com