Chrome 154 already asks before it opens your HTTP site — here's the 30-minute audit we ran on mintec.co

Chrome 154 has been in the stable channel since September 22, 2026, and it turns on Always Use Secure Connections by default for public sites: when someone clicks an http:// link or types one, and the site does not answer over HTTPS, Chrome asks for permission before it continues over HTTP. The part almost nobody explains is that the prompt is not a penalty on every old link. Chrome attempts HTTPS first, so most plain-text links upgrade silently and nobody sees anything. The prompt shows up only where HTTPS fails: forgotten domains, expired certificates, subdomains nobody reviews. That makes this a link-hygiene problem, not a security project.

The date you were promised is no longer the real date

Google announced it in October 2025 with a specific sentence: "with the release of Chrome 154 in October 2026, we will change the default settings of Chrome." Then, in March 2026, Chrome moved to a stable release every two weeks instead of every four, and milestones shifted without anyone updating that blog post. The result is what we verified today: the milestone Google named has been stable since September 22, confirmed by the Chrome Releases announcement for that date — the same date we published ourselves on August 26 in our two-week release cycle calendar. The current build is 154.0.8037.98, built on October 2 according to Chromium Dash.

Chromium's adoption guide, read on October 5, still says it without ambiguity: "Chrome will start asking for users' permission before navigating to HTTP pages by default in Chrome 154." So the calendar date and the milestone name no longer agree, and the practical lesson is simple: do not wait for "October" to review your site. If you want certainty about your exact build, turn the setting on and test it, which is exactly what Google recommends in that same guide.

This milestone also carries other interface changes we already covered in our Chrome 154 breakdown; what is new here is the navigation prompt, not the CSS features.

What triggers the prompt and what does not

The distinction matters because it decides in two minutes whether you have work pending. Per Chromium's adoption guide, the warning appears when Chrome could not connect over HTTPS but believes HTTP may still work:

One operational detail that gets overlooked: Chrome remembers the user's decision for 15 days and renews it whenever the person revisits the site. You are not paying an interstitial on every visit — one per domain every two weeks. The real cost is not the bounce; it is the prompt landing on first contact: the click from a printed QR code, the link in a 2019 newsletter, the catalog PDF still in circulation.

The audit we ran on mintec.co

We sell web architecture and maintenance decisions, so our own site had to be the first client of this audit. Five checks, run on October 5, 2026:

1. Root headers. https://mintec.co/ answers HTTP/2 200. It sends no Strict-Transport-Security header. No HSTS, no forced fallback.
2. Certificate. Valid from September 19 to December 19, 2026: automated 91-day rotation, no manual intervention.
3. Plain-text reference census. Across src/content/ we counted 13 distinct hostnames referenced as http://, across 81 occurrences:

4. Real coverage. Of the 13 hostnames, 11 answer over HTTPS today — silent upgrade, zero prompts. The two that do not are exactly the ones that need a manual test with the setting enabled.
5. Own domain and the www subdomain. Both answer 200 over HTTPS; the header finding is the same: no HSTS.

The conclusion of our own census: most of our archive is already covered by the silent upgrade, and the risk concentrates in a single legacy host with 45 references. That is the pattern we see on almost every project: the homepage is perfect and the danger lives in the old archive.

What we are changing

• Normalize the 81 plain-text references. The 45 point to a legacy domain that needs a decision about whether we still control it: if it answers over HTTPS, update the link; if it is no longer ours, unlink it. Leaving them as they are means accepting that part of the archive depends on decisions someone made in another era.
• Ramp HSTS on. Start with a short max-age (1 day), then 30, then a year with includeSubDomains, and only then consider preload. Order matters: HSTS removes the HTTP fallback, so an expired certificate stops being a redirect and becomes a hard error. Do not enable it before automated renewal covers every subdomain. The site detail that forces that order is what we just saw: the root does not send the header.
• Certificate inventory with an owner. The root certificate is fine; the question is the subdomains that exist only in someone's memory. An expired certificate does not trigger the new prompt — it triggers the old one — but for the user it is the same lost conversion.
• A fixed monthly check. Two commands in the maintenance routine: HSTS header present and certificate days remaining. For the reasoning behind our hosting decision, see Cloudflare Pages to Workers with Astro.

The 30-minute audit

1. Turn the new behavior on at chrome://settings/security → Always Use Secure Connections → Warn on insecure public sites. That way you test the future yourself instead of trusting a blog date.
2. Walk your twenty real entry points: campaign landing pages, archived newsletters, printed QR codes, PDFs, documentation, support links. That is where the domains normal traffic never touches will show up.
3. Census your repository: grep -rhoE 'http://[a-zA-Z0-9.-]+' src/ | sort | uniq -c. It returned 13 hostnames and 81 occurrences for us; in repos with more history the number climbs fast.
4. Check each hostname over HTTPS: curl -sI https://yourdomain/. If it answers, silent upgrade and you are done. If it does not, that is your pending work.
5. Read your header: curl -sI https://yourdomain/ | grep -i strict-transport. If nothing comes back, the fallback is still open.
6. Confirm the http → https jump at the edge and that certificate renewal covers every subdomain with its own traffic.

Chrome 154's prompt does not change how the web is built: it changes what it costs to leave rubble lying around. Your homepage is ready; the work is in the links nobody has looked at in years, and a half-hour audit puts them in front of you before a user ever sees the permission screen.

If you would rather have someone run this review against your site before touching anything, we do it as part of web design and development maintenance, not as a separate project.