Slashdot Mirror
T-Mobile Begins Verifying Calls To Protect Against Spam (theverge.com)
T-Mobile is beginning to roll out support for call verification technology, which will confirm that a phone call is actually coming from the number listed on caller ID. From a report: Now, if one T-Mobile subscriber calls another T-Mobile subscriber, the person receiving the call will see a message saying "Caller Verified" if they have a supported phone. Unfortunately, there's only one supported phone -- Samsung Galaxy Note 9 -- for the time being. Call verification won't put a stop to spammy phone calls, but it will start to help people identify which calls are actually coming from real people. As anyone with a phone knows, spammers have relentlessly spoofed local phone numbers in recent years, making it appear that you're getting an incoming call from someone you may know. Call verification is meant to combat that.
so it will block spammers spoofing T-Mobile's numbers to call other T-Mobile's customers. But won't block all other spoofers. As much as I'd like this to be a good start, I can't see how it can be useful.
I think excessive spam is existential crisis for voice calling. I no longer answer any calls from unknown numbers as chances of spam are near-certain. This has been going on for couple years, to the point that I permanently silenced voice call notifications on my phone - no vibrations, no ringing. Consequently, now it is much harder for legitimate callers to get through.
It's disgusting that in this day and age we have to put up with spam calls that appear to be coming from the SAME bloody phone number as our phones!
I guess the telcos are more interested in money then respecting customer's time.
What can customers do to change the situation since the FCC appears to be doing fuck all about it ?
An app does not have access to carrier ANI data that's routed with the call. So if you're spoofing using real local numbers, they can't mark those as spam. Otherwise that actual customer being spoofed would show as spam when they make outgoing calls.
Caller ID spoofing is still required by a lot of business telephone systems - especially regarding outgoing calls on an MLTS. They can really only vet their own numbers right now. And that probably isn't even enough to stop local number spoofing because of the number of wireless and landline carriers in a given area.
"I'm fascinated that someone thinks there is such a thing as "authorized spam", as opposed to "unauthorized spam"."
Oh, are you one of those who thinks the authorized sort isn't spam? If I'm a business who pays t-mobile to let me blast their customers is that not still spam to their users? If I've signed up for texts about the latest sales from company x would you still classify that as spam?
By my account both are spam and are authorized or unauthorized from the perspectives of either t-mobile or the user though one doesn't necessarily agree with the other. Some guy in china selling Viagra is likely viewed as unauthorized by both.
Personally, I'm of the opinion that carriers should transit everything, with payment only coming from users, by default while expending effort to empower users to effectively block things. If implemented well they can block the carrier transiting the spam (to them) and/or block at their device at the users discretion with the carrier level block carrying the added benefit of alleviating load on their infrastructure. With a good API the user could employee third party smart tools to help with this task.
The last party who should have any discretion about what is blocked is the carrier let alone open support to build revenue streams based on abusing that sort of discretion.
This requires some infrastructure on the carrier side to determine whether the number should be allowed to be set by the PBX.
And numbers can come from more than one carrier. This infrastructure doesn't exist yet. I own a phone number through Google Voice, but I spoof that number when calling out from my home PBX so that return calls hit my cell phone too.
Google Voice, in turn, spoofs the numbers of the caller when forwarding incoming calls to my cell so that I know who the forwarded calls are coming from. Google does not own the numbers at all here, but it's still a legal use case for spoofing the numbers.
I really could use something similar on my landline. The technical prerequisites for detecting and preventing caller ID spoofing are there, but where I live (Germany) CLIRO is sadly only available for special called parties like police and emergency services. CLIRO stands for Calling Line Identification Restriction Override and means that the real caller ID is always transferred.
But perhaps something like CLIRO Light could be introduced, where spoofed calls are automatically rejected at the telephone exchange, without or without notifying the called party. I would happily activate something like that. It would kill 90% of all spam calls because the spammers would run a much larger risk of being identified and fined.
C - the footgun of programming languages
Really? Why bother, TMo?
That limitation is temporary. I wish the summary had bothered to mention anything about the technical side of what T-Mobile's doing, because it's news for nerds after all.
What T-Mobile is implementing is a technical standard known as STIR/SHAKEN which is explicitly designed to prevent spoofed calls, among other things. Even the FCC itself (PDF) back in 2015/2016 was big on this particular framework for combating robocalls. So much so that one of the very, very few things Ajit Pai managed to do right for consumers was have the FCC require (PDF) that U.S. telecoms implement STIR/SHAKEN, and do so "without delay". Oh yeah, and they're required to interoperate.
So right now the Note9 is the first phone to support it. Others will follow. I'm sure Apple devices will get it quickly, probably with iOS 13 this year. And to respond to your specific complaint, it's "only TMo to TMo" right now because they're the first to implement the framework. Once the other telcos get their STIR/SHAKEN setups going, calls between networks should also be able to be verified.
And just for funsies, here's a full hour-long (!) video on the framework and how it works, as well its status in various countries, not just the U.S.
If it requires any sort of technology on my own phone, then they are doing it WRONG. The telephone network is no different than the Internet network. If I am an ISP or Telecom provider, nothing enters my network without permission and nothing exits my network without permission. Source and destination, within my own network, is essentially guaranteed. I am not letting anything into my network without a known, by me, source and destination. There is ZERO room for "unknown" activity without cutting wires and sending random voltages down them... and the results of THAT will not leave my own network anyways.
No. If this requires technology on MY end as a consumer, then this is not about preventing spoofing, it is about tracking and gathering data, presumably to monetize it.
I gather you did not even glance at the linked whitepapers? I'll quote the relevant line. "Using STIR/SHAKEN, the call is authenticated by the calling party’s service provider that digitally signs the calling number. The called party’s service provider validates the digital signature to verify the calling party identity. The SHAKEN governance framework defines how service providers are authenticated and authorized by a certificate authority to digitally secure the calling number of telephone calls." Emphasis mine. STIR/SHAKEN in and of itself works between providers, and does not require technology on the consumer end device.
However, until (or rather, a big if..) STIR/SHAKEN becomes universal (or at least reaches a point where a critical mass/majority of providers have implemented it), a service provider can't feasibly block unverified calls wholesale. They could certainly offer the customer that as an option perhaps, with plenty of warnings about the caveats, but doing it by default would block tons of legitimate calls that are unverified through no fault of the calling party, but rather because their telecom provider simply hasn't implemented the tech yet. So, bearing that in mind, the end user needs some way to know which calls have been verified and which haven't so they can decide for themselves whether to answer or not. The small piece that does require the phone's participation is the part that makes the phone aware that this STIR/SHAKEN transaction is going on in the background between the service providers. i.e., the part where the phone literally displays "Call Verified" or "Call Unverified" on the screen. That's all. The actual verification process itself requires no participation on the phone's end. Basically, it's the same concept as Caller ID. CID signalling works whether your phone supports it or not. You only need tech in your phone if you want to actually see the CID data.
There is a reply from an AC on this thread too that linked to responses from telecom providers about their implementation status. They make plenty of mention that they will begin signing/verifying calls all calls originating from their networks, regardless of whether the customer can see it or not, though several mention working on "displays" for the customer to see the verification results.