28 ms·
HTTPS by default
- cube00 11mo agoWhat's worse, many plaintext HTTP connections today are entirely invisible to users, as HTTP sites may immediately redirect to HTTPS sites. That gives users no opportunity to see Chrome's "Not Secure" URL bar warnings after the risk has occurred, and no opportunity to keep themselves safe in the first place. Two hosting providers I use only offer HTTP redirects (one being so bad it serves up a self signed cert on the redirect if you attempt HTTPS) so hopefully this kicks them into gear to offer proper secure redirects.
- nakamoto_damacy 11mo agoSecurity theatre is all it is. Protect us from petty thieves but let our employers and the gov MITM our comms.
- minitech 11mo ago> Security theatre is all it is. Protect us from petty thieves Even picking the most dismissive wording you can, you contradict yourself.
- deleted 11mo ago[deleted]
- tracker1 11mo agoAs good an idea as this is... I do hope that localhost/127.0.0.1 will be excluded for devs/testers.
- ottah 11mo agoMmmm, great that and mandatory key rotation every 90 days, plus needing to get a cert from an approved CA, means just that more busy work to have an independent web presence. I don't like people externalizing their security policy preferences. Yes this might be more secure for a class of use-cases, but I as a user should be allowed to decide my threat model. It's not like these initiatives really solve the risks posed by bad actors. We have so much compliance theater around email, and we still have exactly the same threats and issues as existed twenty years ago.
- antisol 11mo agoImpressive. I don't need to post my opinion on this anymore - you did it so much better than I ever could.
- techbrovanguard 11mo agoYou understand that key rotation can and should be automated, right?
- ottah 11mo agoIt adds complexity, more points of failure, and ensures that more legacy services will go offline needlessly. While almost certainly not actually improving the actual security issues the average user experience. Lack of a valid tls certificate is usually not the reason people are victims of crime online.
- danpalmer 11mo agoHTTPS doesn't have mandatory key rotation every 90 days. LetsEncrypt does for reasons that they document, but you can go elsewhere if you'd prefer. > I as a user should be allowed to decide my threat model Asking you if you want to proceed is allowing you to decide your threat model. > We have so much compliance theater around email, and we still have exactly the same threats and issues as existed twenty years ago. ...and yet we have largely eliminated entire classes of issue on the web with the shift to HTTPS, to the point where asking users to opt-in to HTTP traffic is actually a practical option, raising the default security posture with minimal downside.
- yardstick 11mo ago> HTTPS doesn't have mandatory key rotation every 90 days. LetsEncrypt does for reasons that they document, but you can go elsewhere if you'd prefer. A lot of this discussion is about how the browsers define their security requirements on top of HTTPS/TLS/etc. Such as what CAs they trust by default, and what’s the maximum lifetime of a certificate before they won’t trust it. I believe it is now 2 years? Going even lower soon.
- rr808 11mo agoHttps really sucks for our intranet. Every little web app and service needs certificates and you can't use letsencrypt.
- itintheory 11mo agoYou may not want to, but you can use public certs and URLs on your intranet. You can't necessarily do http-01 challenges, but DNS based challenges are feasible. There are also other ACME providers which will let you skip challenges for DCVd domains.
- kassner 11mo ago> There are also other ACME providers which will let you skip challenges for DCVd domains Do you have examples? I’m not sure how to search for this feature.
- keyle 11mo agoI'm sure there will be a setting flag to stop blocking http sites, or maybe even a domain exclusion which will let you set up your intranet to work on http. Maybe everything .local will already be allowed.
- lateforwork 11mo ago> One year from now, with the release of Chrome 154 in October 2026... Wait a minute, how do they know what version Chrome will be at a year from now?
- cbowal 11mo agoChrome has a set release schedule, shipping a new major release every four weeks. https://chromium.googlesource.com/chromium/src/+/HEAD/docs/process/release_cycle.md#:~:text=Milestone%20Branch%20Support-,Overview,stable%20channel%20every%20four%20weeks. https://chromium.googlesource.com/chromium/src/+/HEAD/docs/p...
- elcritch 11mo agoChrome moved to a time based release cadence.
- nhumrich 11mo agoGoogle has a time machine
- dopa42365 11mo agohttps://chromestatus.com/roadmap https://chromestatus.com/roadmap >Chrome 154 Stable next year (Oct 7, 2026)
- bo1024 11mo ago> What's worse, many plaintext HTTP connections today are entirely invisible to users, as HTTP sites may immediately redirect to HTTPS sites. That gives users no opportunity to see Chrome's "Not Secure" URL bar warnings after the risk has occurred, and no opportunity to keep themselves safe in the first place. What is the risk exactly? A man-in-the-middle redirect to a malicious https site?
- dadrian 11mo agoA MITM could replace the redirect with malicious content, as described in the blog.
- minitech 11mo agoYes, that. Could be to a lookalike domain name, for example.
- 1313ed01 11mo agoHTTPS sadly offers no protection from that at all these days. At least in the past when something was HTTPS you knew that someone had to jump through some hoops and pay some real money to earn that padlock, but now any script kiddie can automate certificates for free for as many lookalike domains they want to. It would be nice to see some way for browsers to indicate when a site has some extra validation so you could immediately see that your bank has a real certificate as is appropriate for a bank and not just Let's Encrypt. Yes, I can click the padlock icon to get that information, but it would be nice if there was some light warning for free certificates to make it more immediately obvious.
- deleted 11mo ago[deleted]
- protocolture 11mo agoPrediction: Wifi captive portal vendors will not react to this until after 90% of their customerbase has their funding dry up. It is incredibly common for public wifi captive portals to be built on a stack of hacks, some of which require the inspection of HTTP and DNS requests to function. *Yes better tools exist, but they dont arent commonly used, and require Portal, WAP and Client support. Most vendors just tell people to turn new fancy shit off, disable HTTPS and proceed with HTTP.
- GaryBluto 11mo agoTo be fair, most people connecting to captive portal networks are more likely to be doing so on their phones, and I don't think IOS even allows non-Safari browsers for captive Wi-Fi login. I'm unsure how they'll fix this for Android though.
- protocolture 11mo agoApple does however you have to go out of your way to do it. Every time.
- EGreg 11mo agoWhat are you talking about? You can easily build the captive portals by setting up a custom DNS server, and HTTPS has nothing to do with it! In fact, local networks have been doing this very thing for years now. Apple even supports Detecting this interception so the operating system can show a captive portal to the user. The OS maker gives network admins an official a way to enforce captive portals, and it’s not going away with https.
- Maxious 11mo agoYou can but many vendors have not yet adopted that
- protocolture 11mo ago> Apple even supports Detecting this interception so the operating system Whats it intercepting? Apples detection sends a HTTP/HTTPS request to captive.apple.com. If it fails, it assumes a captive portal. Theres also a DHCP option apple supports. But even after detection, theres redirection. Have a look at WAP Vendor options. Heres Powerlynx explicitly requests disabling HTTPS before auth on Cambium in their user setup guide. https://docs.powerlynx.app/networking/cambium.html https://docs.powerlynx.app/networking/cambium.html "Redirect HTTP-only - On" This guarantees that, upon redirection, you are presented with a HTTP login page for the captive portal. And then any subsequent redirections, also have to be HTTP. Heres Start Hotspot https://go.starthotspot.com/help/cambium/ https://go.starthotspot.com/help/cambium/ "Redirect: Tick HTTP-only" Cambium supports more modern methods, but captive portal vendors are not going to shift before letting their customers fall on their face. (Also, cambiums guest access whitelist is based on DNS and breaks with DNS over HTTPS/TLS)
- jongjong 11mo agoWe need to replace the DNS system with a blockchain-based alternative where people can own domains on-chain without renewal fees. The public key used to encrypt data would be shown alongside the IP addresses registered for that domain name (same record). The owner of the domain (an NFT) would be able to change their public encryption key at will on-chain. They would only pay a fee when they want to perform some write action; holding the domain and lookups would be free forever. No need to separate DNS from the certification and encryption layer. You know the private key, you own the domain. So much cleaner than the mess we have now. If someone doesn't like it, they can stay behind on the old DNS system or they can launch a new blockchain with their own version of reality... It's retarded that we need to have one version of reality for the entire planet. If someone in China wants to own facebook.com, they should be allowed. Heck, it could be a separate silo per city. The age of copyright and trademark is over. I don't see AI companies distributing royalties to people who wrote its training set...
- not4uffin 11mo agoI see this as pretty much only a positive thing.
- EGreg 11mo agoThis is what things should be like chatting programs and end-to-end encryption. But in every case by the way, we kinda trust the makers of this software. They can easily ship backdoors to specific users. Same with crypto wallets etc.
- superkuh 11mo agoHTTPS is great. HTTPS without HTTP is terrible for many human person use cases. Pretending those use cases don't exist is anti-human. But for corporate person use cases HTTPS-only is more than fine, it's required. So they'll force it on us all in all contexts. But in our own personal setups we can chose to be the change we want to see in the world and run HTTP+HTTPS. Even if most of the web becomes an HTTPS-only ID-centric corporate wasteland it doesn't take that many people to make a real web. It existed before them and still does. There's more human's websites out there now then ever. It's just getting harder and harder to find and see using their search and browser defaults. It's not okay, but maybe this is finally a solution to eternal september and we can all just live peacefully on TCP/IP HTTP/1.1 HTTP+HTTPS with HTML while corporate persons diverge off into UDP-land with HTTP/3 HTTPS-only CA TLS only QUIC for delivering javascript applications.
- philippta 11mo agoWhile this is great for end users, this just shows again what kind of monopoly Google has over the web by owning Chrome. I work at a company that also happens to run a CDN and the sheer amount of layers Google forces everyone to put onto their stack, which was a very simple text based protocol, is mind boggling. First there was simple TCP+HTTP. Then HTTPS came around, adding a lot of CPU load onto servers. Then they invented SPDY which became HTTP2, because websites exploded in asset use (mostly JS). Then they reinvented the layer 4 with QUIC (in-house first), which resulted in HTTP3. Now this. Each of them adding more complexity and data framing onto, what used to be a simple message/file exchange protocol. And you can not opt out, because customers put their websites into a website checker and want to see all green traffic lights.
- zoeysmithe 11mo ago>First there was simple TCP+HTTP. Then HTTPS came around, adding a lot of CPU load onto servers. You can't do e-commerce without encryption. You live under capitalism. Its weird to me to see capitalists not wanting to accept payments for goods. As far as the complexity argument, goes, wait until you see what goes on in your CPU! Or the codebase of your average website. There is no real simplicity and simplicity just ties people's hands. These weird worship of simplicity just don't make sense. By this argument we should have never left the mainframe green-screen terminal world. Or the PDP era. Or the abacus era for that matter. An arbitrary line drawn in the sense is a near purely emotional appeal and the libertarian housecat meme when applied to technology. Instead, this is a train with no final destination and those who think overwise are just engaging in nostalgia.
- saurik 11mo ago> Its weird to me to see capitalists not wanting to accept payments for goods. Even the most hardcore capitalists refuse to take our money for their services, insisting on giving away free websites--some which don't even have any authentication at all--that have frustrating business models on the backend :(. The reason we encrypt the vast majority (by volume, not weight) of our web content is for integrity (so random other people can't hijack and modify what we render), and somewhat (but not sufficiently, as TLS is broken) for privacy, not because of some attempt to partake in capitalism.
- Traubenfuchs 11mo agoI for one hate https. Some html5 apis like location do not work without it and you get big fat warnings if you don‘t use it. From having to pay for it in the past to now having to set up lets-encrypt, certbot, https-ingresses! God, half my hobbyist and raw non-helm kubernetes config is https related. https-ingress.yaml is gigantic! Is this really the best devex we could come up with?
- cowl 11mo agoThis is to be honest a little unfortunate. While Https is very important, do we really need to verify that Blog X that I may read once a year is really who they say they are? For many sites it doesn't make a lot of sense but we are here due to human nature
- throw_a_grenade 11mo agoThe problem is not the site, but the network in the middle. On-path attackers typically don't care about which site they MITM in order to inject javascript e.g. to show ads, insert tracking tokens or hijack the browser for other purposes. The site is the vector, not the target.
- bell-cot 11mo agoSounds like a great argument for keeping js disabled in my browser. Because "httpS://" does nothing whatever to sanitize the js that it delivers. And one perfectly legit site may pull in js from two dozen or more different servers. Zero of which are magically guaranteed to only deliver benevolent code. Vs. `traceroute` suggests that would-be on-path attackers are up against a vastly smaller attack surface.
- eadmund 11mo agoIronically, this Google page itself fails to work without Javascript enabled!
- bell-cot 11mo agoIronically? For maximum monetization, Google needs js, to turn "your" web browser into their web browser. https://news.ycombinator.com/item?id=42747092 https://news.ycombinator.com/item?id=42747092
- DaSHacka 11mo ago> Sounds like a great argument for keeping js disabled in my browser. Because "httpS://" does nothing whatever to sanitize the js that it delivers. And one perfectly legit site may pull in js from two dozen or more different servers. Zero of which are magically guaranteed to only deliver benevolent code. See: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
- austin-cheney 11mo agoThe only challenge to https, as compared to http, is certificates. If not for certificates I could roll out a server with https absolutely anywhere in seconds including localhost and internal intranets. On another note I would much prefer to skip https, as the default, and go straight to WSS (TLS WebSockets). WebSockets are superior to HTTP in absolutely every regard except that HTTP is session-less.
- popcornricecake 11mo agoIt's not even certificates that's the problem, but trust. And here Google is making exceptions to allow unencrypted connections to private addresses, because trust is hard. If encryption was not tied to trust, then we would have 0 unencrypted connections by now and we would be that much better off. Making an exception to allow plain HTTP connections instead of making an exception to allow self-signed certificates, seems like the worse choice to me.
- austin-cheney 11mo agoYeah, that is an excellent point. I really wish there were a unique icon for self-signed certificates opposed to other untrusted certificates. Self-signed certificates are not deceptive or malicious but they are not trusted. In a localhost environment self-signed certificates from the host machine are perfectly fine. Even better would be if browsers did not require certificates at all to make use of HTTPS from localhost, 127.0.0.1, or ::1
- bagol 11mo agoHow dangerous is plain http?
- tepmoc 11mo agoI love https, but I also hate that its basically killed on-site caching and give CDNs more power as its only way to distribute content closer to user
- matthewaveryusa 11mo agoIf I set a DNS entry that points to a private ip (e.g, A internal.domain.com 192.168.0.5), will the allow private site setting succeed or fail for http://internal.domain.com http://internal.domain.com? Either way I agreee with this update. It's better to put the burden of knowledge on those hosting things locally and tinkering with DNS than those that have no idea that a domain does not infer ownership of said domain.
- p1mrx 11mo agohttp://http.rip/ http://http.rip/ is useful for testing this sort of thing. I used to test with http://neverssl.com/ http://neverssl.com/ until they added HTTPS for some reason.
- shakna 11mo agoIANA's http://example.com http://example.com still has a plain http version.
- dorianmariecom 11mo agoi use http://perdu.com http://perdu.com
- yjftsjthsd-h 11mo ago> I used to test with http://neverssl.com/ http://neverssl.com/ until they added HTTPS for some reason. My first reaction was along the lines of "What? That can't possibly be right..." After testing a bit, it looks like you can load https://neverssl.com https://neverssl.com but it'll just redirect you to a non-https subdomain. OTOH, if the initial load before redirecting is HTTPS then it shouldn't work on hotel wifi or whatever, so still seems like it defeats the purpose. Huh.
- jeroenhd 11mo agoneverssl added an HTTPS version for browsers that automatically connect to HTTPS when entering a domain name (like Chrome probably will after this change, eventually). The HTTPS version of the site uses Javascript to load a random http:// subdomain of neverssl.com so automatic HTTPS redirects are still defeated. http.rip will probably show a "website unavailable" error at some point unless you manually type in the http:// prefix.
- drusepth 11mo agoDoesn't it already do this? I keep a domain or two on HTTP to force network-level auth flows (which don't always fire correctly when hitting HTTPS) and I've gotten warnings from Chrome about those sites every time for years... Only if I've been to the site recently does the warning not show up.
- deathanatos 11mo agoRight now it only shows a little bubble in the URL bar saying "Not Secure", I think. (So, that is a "warning", in a sense.) TFA is saying there will now be an interstitial if you attempt an HTTP connection. HSTS might also interact with this, but I'd expect an HSTS site to just cause Chrome to go for HTTPS (and then that connection would either succeed or fail). > to force network-level auth flows (which don't always fire correctly when hitting HTTPS) The whole point of HTTPS is basically that these shouldn't work, essentially. Vendors need to stop implementing weird network-level auths by MitM'ing the connection, and DHCP has an option to signal to someone joining a network that they need to go to a URL to do authentication. These MitM-ers are a scourge, and often cause a litany of poor behavior in applications…
- yardstick 11mo agoI don’t believe Android IPv6 stack supports dhcp, so won’t be much use there.
- deathanatos 11mo agoIPv6 RAs also support prompting the client about captive portals similarly, too, I think. (But also at some point that seems like a bug in Android.)
- sam_lowry_ 11mo agoHTTPS url?
- dadrian 11mo agoChrome has shown the HTTP warning in Incognito mode for about a year, and has shown the warning if you're in Advanced Protection mode for about 2-3 years.
- mistrial9 11mo ago"cannot connect" is next ?
- dist-epoch 11mo ago> HTTPS adoption expressed as a percentage of main frame page loads Why is Linux adoption at 80% when MacOS/Android/Windows are at 95%? Quite unexpected.
- jeffbee 11mo agoTendency of Linux users to have local resources that lack TLS? phpmyadmin, netdata, duckdb ui, git-webui, whatever.
- shadowgovt 11mo agoSilly question and one I should probably already know the answer to but never really got around to thinking through: are there practical concerns for not doing TLS in your home intranet? It means that if someone has patched into your local network they can access anything in there, but they have to get in first, right? So how concerned should one be in these scenarios (a) one has wifi with WPA2 enabled (b) there's a Verizon-style router to the outside world but everything is wired on the house side?
- dist-epoch 11mo agoEverything that matters in your home intranet should already be password protected and firewalled.
- jabroni_salad 11mo agoPerhaps you might worry about hostile IOT doodads snooping on things that arent their business or making insecure public webpages with UPNP. If it is just devices you truly control and you never expose an unhardened device, then a walled garden can be fine. Also, if WPA2 ever becomes extremely broken. There was a period of 3-5 yrs where WEP was taking forever to die at the same time that https was taking forever to become commonplace and you could easily join networks and steal facebook credentials out of the air. If you lived in an apartment building and had an account get hacked between maybe 2008-2011, you were probably affected by this.
- 11mo ago
- tialaramex 11mo agoI have had HTTPS-by-default for years and I can say that we're past the point where there's noticeable year-to-year change for which sites aren't HTTPS. It's almost always old stuff that pre-dates Let's Encrypt (and presumably just nobody ever added HTTPS). The news site which stopped updating in 2007, the blog somebody last posted to in 2011, that sort of thing. I think it's important to emphasise that although Tim's toy hypermedia system (the "World Wide Web") didn't come with baked in security, ordinary users have never really understood that. It seems to them as though http://foo.example/ http://foo.example/ must be guaranteed to be foo.example, just making that true by upgrading to HTTPS is way easier than somehow teaching billions of people that it wasn't true and then what they ought to do about that. I am reminded of the UK's APP scams. "Authorized Push Payment" was a situation where ordinary people think they're paying say, "Big Law Firm" but actually a scammer persuaded them to give money to an account they control because historically the UK's payment systems didn't care about names, so to it a payment to "Big Law Firm" acct #123456789 is the same as a payment to "Jane Smith" acct #123456789 even though you'd never get a bank to open you an account in the name of "Big Law Firm" without documents the scammer doesn't have. To fix this, today's UK payment systems treat the name as a required match not merely for your records, so when you say "Big Law Firm" and try to pay Jane's account because you've been scammed, the software says "Wrong, are you being defrauded?" and so you're safe 'cos you have no reason to fill out "Jane Smith" as that's not who you're intending to give money to. We could have tried to teach all the tens of millions of UK residents that the name was ignored and so they need other safeguards, but that's not practical. Upgrading payment systems to check the name was difficult but possible.
- isodev 11mo agoWhile Google and friends are happy to push for https, it’s dramatically easier to scam people via ads or AI generated content. Claiming plain HTTP is scary seems like a straw man tbh
- Arainach 11mo agoThe threat model of HTTP isn't site owners, it's that anyone else can change the content and you can't tell that it didn't come from the original site. It's not a strawman, it's a real attack that we've seen for decades. The entire guidance of "don't connect to an open wireless AP"? That's because a malicious actor who controlled the AP could read and modify your HTTP traffic - inject ads, read your passwords, update the account number you requested your money be transferred to. The vast majority of that threat is gone if you're using HTTPS instead of HTTP.
- shadowgovt 11mo agoGood stuff. Anyone have a good recipe for setting up an HTTPS for one-off experiments in localhost? I generally don't because there isn't much of a compromise story there, but it's always been a security weakness in how I do tests and if Chrome is going to start reminding me stridently I should probably bother to fix it.
- deleted 11mo ago[deleted]
- marginalia_nu 11mo agoHow exactly are unencrypted localhost connections a security weakness? To intercept the data on a loopback connection you'd need a level of access where encryption wouldn't really add much privacy.
- zamadatix 11mo agoChrome treats localhost as a secure origin (regardless of HTTPS) by default - don't overthink it.
- shadowgovt 11mo agoOh, groovy; if they keep doing that I'm all good, since I usually do one-off remote stuff by SSH tunnels anyway.
- jmholla 11mo agoI haven't used it, but I think `mkcert` is the go to solution for this. [0] [0]: https://github.com/FiloSottile/mkcert https://github.com/FiloSottile/mkcert
- marginalia_nu 11mo agohttp://www.slackware.com/ http://www.slackware.com/ is probably the biggest website I'm aware of that does not serve encrypted traffic[1]. but there are a few other legitimately useful resources that don't encrypt. [1] (Except on the arm subdomain for some reason)
- giancarlostoro 11mo agoMy first distro was Slackware. Good memories. The ARM subdomain looks drastically more maintained, posts from 2025. Don't ever view source on slackware.com
- tptacek 11mo agoDon't ever view source on slackware.com Awwww, that's the stuff right there.
- hulitu 11mo ago> Don't ever view source on slackware.com why ?
- marginalia_nu 11mo ago> Don't ever view source on slackware.com That's very 90s looking HTML. Large swathes of blank spaces may also indicate they're rendered somehow. PHP? CGI? Confusingly it also sets an akamai cookie, `ak_bmsc`. Seems a bit out of place.
- keyle 11mo agoIt's a much nicer source to read than those javascript generated doms with 1,200 classes per tag.
- fooofw 11mo agoWhat defines private sites, I wonder – beyond "such as local IP addresses like 192.168.0.1, single-label hostnames, and shortlinks like intranet/"?
- dadrian 11mo agoNon-unique hostnames, which are RFC 1918 space, single-label hostnames, and addresses assigned to mDNS (.local).
- deleted 11mo ago[deleted]
- srcreigh 11mo agoSingle label hostnames had an issue where it’s hard to type them into a browser. How to fix this?
- jeroenhd 11mo agoUsually, completing the domain name by adding the final period will do the job. Instead of entering myprinter into the address bar, try myprinter. so your DNS server doesn't try to resolve myprinter, myprinter.domain, myprinter.domain.tld, and whatever other search domains have been configured. A real, fully-qualified domain ends in a period, though most tools will happily let you avoid that final period. Alternatively, .local domains will work for mDNS-capable devices (and non-mDNS-capable devices if you like to risk things breaking randomly), and the .internal TLD has been reserved so .internal domains should also work for local addresses.
- dadrian 11mo agoAdd a /, e.g. `shortname/`
- IgorPartola 11mo agoI distinctly remember trying to sign up for Pandora’s premium plan back in 2012 and their credit card form being served and processed over HTTP. I emailed them telling them that I wanted to give them my money if they would just fix the form. They never got back to me or fix it for several more years while I gave my money to Spotify. Back then HTTPS was NOT the norm and it was a battle to switch people to it. Yes it is annoying for internal networks and a few other things but it is necessary.
- deleted 11mo ago[deleted]
- fuzzzerd 11mo agoI remember even back in the early 2000s https for credit card forms was pretty common. Surprised a company like Pandora wasn't with it by thr 2010s.
- giobox 11mo agoThere is likely zero chance the OP's recollection is remotely correct. Pandora went public in 2011 with 80 million users, the chances of a publicly listed company of this size taking payments over HTTP in 2012 are about as close to zero as can be. If nothing else, their payment processor would drop them as a customer.
- wingman-jr 11mo agoI found this: https://textslashplain.com/2016/03/06/using-https-properly/ https://textslashplain.com/2016/03/06/using-https-properly/ Seems like it at least partially corroborates OP's recollection!
- MBCook 11mo agoDoes this apply to requests made by JS or just page loads?
- deleted 11mo ago[deleted]
- pKropotkin 11mo agoThanks God, i am not using google