Your Browser Should Ask: “Does the Rest of the Internet See What I See?”

by

this post has been formatted by AI

We have spent decades making HTTPS better.

Today, when I connect to my bank, Google, Amazon, or almost any other major website, my browser performs a remarkably sophisticated series of cryptographic checks. It verifies the site’s TLS certificate, checks that the certificate chains back to a trusted Certificate Authority, makes sure the certificate matches the hostname I’m visiting, and checks that it hasn’t expired.

Chrome also requires publicly trusted certificates to comply with Certificate Transparency, a system of public, append-only logs that makes certificate issuance visible and auditable. That was a major improvement to the security of the Web.

But I think browsers are leaving an important security tool on the table.

They should ask a very simple additional question:

Does the rest of the Internet see the same certificate I do?

The Problem With Our Current Model

Imagine I’m sitting on an airplane, in a hotel, or at a coffee shop.

I connect to Wi-Fi and then visit https://example.com

My browser receives a certificate and validates it.

That’s good. But I’m accessing the Internet through a network I don’t control.

What if my browser could also ask independent computers elsewhere on the Internet:

“When you connect to example.com right now, what certificate do you see?”

Imagine the answer looks like this:

ObserverCertificate fingerprint
My laptop71:92:DE:88:11…
MicrosoftAA:BB:CC:12:34…
GoogleAA:BB:CC:12:34…
AmazonAA:BB:CC:12:34…
AppleAA:BB:CC:12:34…
NISTAA:BB:CC:12:34…

I don’t care how many traditional certificate checks my browser just passed.

Something is seriously wrong.

The entire Internet appears to be talking to one server, while my laptop is apparently talking to another.

My browser should stop me.

We Already Have Most of the Pieces

This isn’t an argument for throwing away the Certificate Authority system.

It’s an argument for adding another independent layer to it.

Certificate Transparency already recognizes an important principle: trust becomes stronger when certificate issuance is publicly observable rather than being a private transaction between a CA and a website.

Chrome has required publicly trusted TLS certificates issued after April 30, 2018 to support Certificate Transparency. CT allows website operators and the broader security community to see certificates that CAs have issued and detect unauthorized issuance.

That’s excellent.

But logging that a certificate was issued isn’t quite the same thing as independently observing:

“This is the certificate the rest of the Internet is actually receiving from this server right now.”

We should do both.

Create a Certificate Notary Network

Imagine a collection of independent certificate observers distributed around the world.

Microsoft could operate some. Google could operate some. Apple, Amazon and other major infrastructure providers could participate.

But I wouldn’t want this controlled exclusively by five enormous technology companies.

Universities could participate. So could nonprofit security organizations, ISPs and governments.

For Americans, NIST or CISA could operate public observers. European governments could operate others. Universities could run them. Independent organizations could participate.

The important feature would be diversity.

Your browser wouldn’t have to trust any one observer.

It would look for agreement.

For example:

google.com

Certificate I’ve previously seen: A
Certificate my browser sees now: B
Certificate Transparency: B is properly logged
Independent observers: 18 of 20 currently see B

That’s almost certainly a routine certificate rotation.

Proceed.

But consider:

google.com

Certificate I’ve previously seen: A
Certificate my browser sees now: Z
Certificate Transparency: questionable or unexpected
Independent observers: 20 of 20 see B

STOP.

Something is very wrong.

Certificate Rotation Doesn’t Break This Model

One obvious objection is that websites change certificates constantly.

That’s actually an argument for distributed observation rather than old-fashioned certificate pinning.

Suppose Google legitimately deploys a new certificate at noon.

Within seconds, independent observers around the Internet begin seeing it:

11:59:59   Old certificate

12:00:00   Google deploys new certificate

12:00:02   Google observer sees NEW
12:00:03   Microsoft observer sees NEW
12:00:04   Amazon observer sees NEW
12:00:06   NIST observer sees NEW
12:00:08   University observer sees NEW

Now my browser encounters that certificate for the first time.

It has never seen it before.

But that’s okay.

The certificate passes normal CA validation. It’s appropriately represented in Certificate Transparency. And independent observers all over the Internet are seeing the same thing.

That’s compelling evidence that I’m seeing a legitimate change rather than a localized attack.

We Have Tried Ideas Like This Before

This isn’t an entirely new concept.

Research projects such as Perspectives explored the idea of network notaries observing certificates from different locations. Later systems such as Convergence explored related approaches to distributed trust.

The concept never became part of mainstream browser security.

Perhaps it’s time to revisit it.

The Internet of 2026 is dramatically different from the Internet in which those projects were conceived.

We now have enormous globally distributed cloud networks. We have ubiquitous HTTPS. We have encrypted DNS. We have Certificate Transparency. We have browsers performing sophisticated real-time security and reputation checks.

Running geographically distributed certificate observers is no longer an exotic research project.

It’s infrastructure that some of the world’s largest organizations could operate almost trivially.

DNS Should Be Part of This Too

Certificates aren’t the only thing observers could compare.

My browser could ask:

What IP address does my trusted DNS resolver return for this hostname?

Then independent observers could answer:

What addresses do you see?

This has to be interpreted intelligently because CDNs, load balancers, geographic DNS and anycast mean different users legitimately receive different addresses.

But a radically different DNS result combined with a radically different certificate would be an extremely powerful signal.

Imagine:

MY CONNECTION

DNS:         203.0.113.72
Certificate: Z


INDEPENDENT OBSERVERS

Virginia:    142.x.x.x    Certificate B
California:  172.x.x.x    Certificate B
London:      216.x.x.x    Certificate B
Tokyo:       142.x.x.x    Certificate B
Sydney:      172.x.x.x    Certificate B

Different IP addresses? Not necessarily concerning.

Different IP addresses and a completely different cryptographic identity?

Now I want my browser paying very close attention.

The Browser Can Remember, Too

There’s another source of information we’re barely exploiting: history.

I’ve connected to Google thousands of times.

My browser has accumulated an enormous amount of evidence about what normal looks like.

Then one day I connect to airport Wi-Fi and suddenly:

  • DNS behaves differently.
  • A certificate changes.
  • Independent Internet observers disagree with what I’m seeing.
  • The network is presenting a captive portal.
  • And a page wants credentials.

Those signals shouldn’t exist independently.

The browser should put them together.

Modern browsers already combine enormous numbers of signals to determine whether a website might be malicious. Certificate history and independent network observations should be additional signals.

Don’t Replace PKI. Add Another Lock.

Security works best in layers.

We shouldn’t replace Certificate Authorities.

We shouldn’t replace Certificate Transparency.

We shouldn’t replace DNSSEC, encrypted DNS, HSTS, Safe Browsing, password managers or passkeys.

We should add another independent question:

“Does my view of this website agree with the view seen from the rest of the Internet?”

An attacker sitting next to me on an airplane might control my Wi-Fi.

They might control my local DNS.

They might manipulate routing.

They might even discover some unforeseen weakness in one component of the certificate ecosystem.

But they don’t control Microsoft, Google, Apple, Amazon, NIST, universities and independent security organizations distributed across dozens of networks around the world.

That’s precisely why their observations are valuable.

Make the Internet Gossip

There’s an old principle in distributed systems:

Don’t trust one observer when you can cheaply ask several.

We now have the infrastructure to apply that principle to Web security at enormous scale.

Certificate Transparency was an important step because it made certificate issuance publicly observable.

The next step should be making certificate use independently observable.

Your browser already asks:

“Is this certificate cryptographically valid?”

It should also ask:

“Is everyone else seeing the same Internet I am?”

If the answer is no, I’d like to know before I type my password.

Let me know if you’d like for me to write a browser extension for this.


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *