Most active commenters
  • unsignedint(8)
  • kube-system(4)
  • mulmen(3)

←back to thread

379 points impish9208 | 12 comments | | HN request time: 0s | source | bottom
Show context
unsignedint ◴[] No.45016437[source]
The PSTN is simply not sustainable. It’s a relic of a time when there was no practical way to authenticate or validate calls. Today, with malicious actors able to dial in from anywhere in the world at negligible cost, the system is fundamentally unequipped to handle the abuse it faces.

Efforts like STIR/SHAKEN exist, but they’re little more than a band-aid—and not a particularly effective one—because the underlying network was never designed with resilience or trust in mind.

I know some people push back on this view, often pointing to edge cases where PSTN’s ubiquity still provides value. But as trust in the system erodes, so does its relevance. And if the majority of people already avoid answering calls from numbers they don’t recognize, its practical utility is clearly diminished.

replies(2): >>45019239 #>>45019275 #
mulmen ◴[] No.45019275[source]
This is a corollary to Chesterton’s fence. unsignedint’s public good.

If you can’t explain the benefit then you can’t tear it down. The PSTN guarantees that all telco operators interoperate. Without it you get what happened with instant messaging. AKA walled gardens. You take for granted the ability to call an iPhone with an Android.

The FCC is responsible for maintaining trust, which they have done here. They can incentivize telco providers to curb the spam activity. You don’t need to throw the baby out with the bath water.

replies(1): >>45020275 #
unsignedint ◴[] No.45020275[source]
I think Chesterton’s fence is a fair analogy—but it only works if the “fence” still serves a protective function. With the PSTN, the fence is riddled with holes, and the people meant to maintain it can’t keep up with the erosion. Interoperability was indeed its greatest strength, but today that same universality is what lets malicious actors reach everyone at trivial cost.

Comparing PSTN to instant messaging walled gardens is interesting, but I’d argue the real parallel is email: a federated, open standard that also suffers from spam and abuse, yet still manages to limp along thanks to heavy filtering and layered trust systems. The PSTN never evolved those trust layers; instead, it relied on scarcity (call cost, geographic constraints) to keep abuse in check. Once those costs collapsed, the trust model collapsed with them.

As for the FCC, sure, they can try to incentivize carriers. But the fact that we need constant regulatory intervention just to keep basic trust afloat suggests the system is no longer structurally sound. Band-aids like STIR/SHAKEN prove the point: we’re bolting authentication onto a protocol that never envisioned it. That might extend its life a little, but it doesn’t make the foundation any less fragile.

So the question isn’t whether the PSTN once had value (it did, massively), but whether preserving it now delivers more value than the cost of propping it up. If a good chunk of people already treat unknown calls as spam until proven otherwise, then the social contract around the PSTN has already been broken.

replies(3): >>45020513 #>>45020562 #>>45022167 #
1. kube-system ◴[] No.45020513[source]
> Comparing PSTN to instant messaging walled gardens is interesting, but I’d argue the real parallel is email: a federated, open standard that also suffers from spam and abuse, yet still manages to limp along thanks to heavy filtering and layered trust systems.

I think you're absolutely right to draw that parallel. But, today's email landscape isn't much of a federated open standard. It's a web of trust and distrust, filters, and deliverability issues. It's real work to maintain an email server and attain high deliverability with other email services. So much so that most don't even do it anymore. Most email is just delivered by a few large providers.

Really, email is suffering from a lot of the same issues that PSTN also suffers from. But email providers just decided to "solve" the problem themselves, mostly by taking a heavy hand at blocking things and deciding they don't really care if you're not a big provider.

replies(1): >>45020608 #
2. unsignedint ◴[] No.45020608[source]
Yes, absolutely — I’m not suggesting email is anywhere near perfect or free of abuse. But at least collectively, the layers of filtering, reputation systems, and standards make it usable for most people most of the time.

The key difference for me is that the PSTN moves at a snail’s pace, maybe because of regulatory entanglements, maybe because of interoperability constraints. The result is that problems which have been rampant for decades — spoofing, spam, robocalls — remain trivial to exploit. Email has plenty of its own problems here, but at least you get more signals to work with (headers, DKIM/SPF/DMARC, filtering, etc.) than just a string of 10–12 digits with no real context.

That’s why I’m less inclined to “cherish” a system whose shortcomings shift so much burden onto the end user’s well-being, all in the name of interoperability. If interoperability means putting up with abuse at this scale, then that interoperability isn’t worth much — and that’s where my frustration comes from.

replies(2): >>45020799 #>>45021135 #
3. kube-system ◴[] No.45020799[source]
> at least you get more signals to work with (headers, DKIM/SPF/DMARC, filtering, etc.) than just a string of 10–12 digits with no real context.

For most people it is a distinction without a difference because they know about as much what to do with a DMARC policy as they do an SS7 frame.

DKIM/SPF/DMARC as bandaids just as much as STIR/SHAKEN are, they just need to get a kick in the ass to implement them -- on both fronts. I get tons of official and sensitive email still from domains that fail DMARC.

replies(1): >>45020857 #
4. unsignedint ◴[] No.45020857{3}[source]
Sure, but my point still stands — you have more tools to work with in email. For what it’s worth, I can usually contextualize a message from the subject line and the sender’s address without needing to dive deep into headers. (Phishing is definitely a real problem, but it’s not unique to email in this discussion.)

Now compare that to the PSTN: what does 555-123-4567 really tell you? Not much. It’s just a string of digits with no inherent context. And unlike email, I can’t even choose to outright refuse delivery of a call at the network level.

replies(2): >>45021148 #>>45034756 #
5. mulmen ◴[] No.45021135[source]
Why are you so eager to give up interoperability when it’s not the problem? Spam exists within walled gardens too. Interoperability and spam are orthogonal.
replies(1): >>45021257 #
6. mulmen ◴[] No.45021148{4}[source]
You have more tools because the market created them because it’s a federated protocol. The PSTN is a different case where market forces don’t align incentives with spam reduction. This is why regulators like the FCC exist.
replies(1): >>45021281 #
7. unsignedint ◴[] No.45021257{3}[source]
I’m not “eager to give up” interoperability — I’m saying interoperability without trust isn’t worth much. Calling it orthogonal doesn’t change the lived reality that the abuse rides on that interoperability at scale.

If the only way to preserve interoperability is to accept decades of unresolved abuse and perpetual patchwork fixes, then that’s not a trade-off I find compelling. At that point we’re not debating facts, we’re debating tolerance levels — and mine is lower. I think that’s a good place to leave it.

8. unsignedint ◴[] No.45021281{5}[source]
I get the distinction you’re drawing, but that just brings us back to the same fork: if decades of FCC involvement haven’t produced a trustworthy caller identity system, then the reliance on regulation isn’t solving the structural weakness, it’s just propping it up.

At that point, we’re repeating the same values clash — you see regulation as a workable fix, I see it as evidence of fragility. I don’t think continuing this line is going to get us any further.

9. kube-system ◴[] No.45034756{4}[source]
> Now compare that to the PSTN: what does 555-123-4567 really tell you?

It tells you exactly as much as the "from" field does in your email.

> you have more tools to work with in email.

Only if you're an engineer implementing a mail server configuration. But if you're implementing a telco you also have more tools to work with than a caller ID.

End users use DMARC/SPF the same way end users use STIR/SHAKEN... they don't. None of them are user-servicable values. And service providers use DMARC/SPF the same way end users use STIR/SHAKEN... they implement those controls for their users in the form of a managed service.

replies(1): >>45035765 #
10. unsignedint ◴[] No.45035765{5}[source]
Even if I don't run my own mail server, I can still open an email header and see context. Last time I checked, I can't walk into a telco and ask for the telephone equivalent of that. On PSTN, there's nothing beyond a bare caller ID string, and that lack of context is exactly why I see it as a problem.

Email gives end users multiple signals and filters to work with. PSTN doesn't, and that's why I disagree with your equivalence.

replies(1): >>45048607 #
11. kube-system ◴[] No.45048607{6}[source]
DMARC/SPF/DKIM are not something that users can take advantage of by reading their email headers, because it is nonsensical to end users.

You can take advantage of it because you're an expert. Just because email vomits out more information that are useful for experts doesn't mean it is better as a real world system for normal people who use it.

replies(1): >>45049216 #
12. unsignedint ◴[] No.45049216{7}[source]
I've been consistent in framing this as a structural critique. The question isn't whether most users inspect metadata. It's whether the system makes that inspection possible. That's the architectural affordance I've emphasized throughout. Email exposes trust signals. PSTN does not. Its opacity isn't a side effect of user behavior. It is a design feature. That's the distinction I've been drawing, and it remains central to the evaluative lens I've laid out.