From Newsgroup: comp.mobile.android


This is an article in Spanish, translated. I do not know if it applies worldwide.


<https://bandaancha.eu/articulos/android-detectara-llamadas-numero-falso-11792>

Android will detect calls with spoofed numbers by sending a real-time
RCS message to the legitimate owner

By Joshua Llorach
Published 3 June 2026 10:50

Until last summer, it was very easy for malicious actors to spoof the
number that appears on a mobile phone screen as the caller ID when a
call rings. The lack of a system to validate numbers and their origin
allowed spammers and other malicious actors to inject traffic into the
network with a spoofed caller ID, a practice known as CLI spoofing.

Since June 2025, mobile operators have been filtering calls originating
from abroad that use Spanish numbers without permission, as well as
applying other validation checks to make this practice more difficult.
Added to these measures is the system from Orange and Telefónica that displays a warning on the screen for suspicious calls.

Falsifying a number known to the victim makes the attack much more
effective, especially in the age of AI, where it is very easy to imitate
a person’s voice, so Google is joining this fight with its own measures against CLI spoofing.


The Android Phone app has started to verify the caller ID of incoming
calls by connecting in real time to the supposed originating mobile
phone to check that it is indeed the one making the call.

For this to work, both parties must be Android users with the Phone app.
When the call rings on the recipient’s device, the phone sends an
encrypted RCS message to the legitimate owner of the number to ask if
they are actually making the call at that moment. In this way, the recipient’s phone can tell when the call is fake.

The idea is interesting, as it does not use OTT data traffic, but rather
core network services, making the exchange of information faster and
more reliable.

This feature is being rolled out first on Pixel devices running Android
12 and above, but Google has released it as an open standard so that
other phone apps and operating systems can use it, meaning that in the
future it would be possible to verify numbers between Android and iOS if
the parties involved wish to do so.

Translated with DeepL.com (free version)
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 10.06.26 11:44, Carlos E.R. wrote:

This is an article in Spanish, translated. I do not know if it applies worldwide.

<https://bandaancha.eu/articulos/android-detectara-llamadas-numero-falso-11792>

Android will detect calls with spoofed numbers by sending a real-time
RCS message to the legitimate owner

By Joshua Llorach
Published 3 June 2026 10:50

Very old news. And it shows how helpless Google is.
--
"Roma locuta, causa finita" (Augustinus)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

"Carlos E.R." <robin_listas@es.invalid> wrote:

This is an article in Spanish, translated. I do not know if it applies worldwide.

<https://bandaancha.eu/articulos/android-detectara-llamadas-numero-falso-11792>

Android will detect calls with spoofed numbers by sending a real-time
RCS message to the legitimate owner

By Joshua Llorach
Published 3 June 2026 10:50

Until last summer, it was very easy for malicious actors to spoof the
number that appears on a mobile phone screen as the caller ID when a
call rings. The lack of a system to validate numbers and their origin allowed spammers and other malicious actors to inject traffic into the network with a spoofed caller ID, a practice known as CLI spoofing.

Since June 2025, mobile operators have been filtering calls originating
from abroad that use Spanish numbers without permission, as well as
applying other validation checks to make this practice more difficult.
Added to these measures is the system from Orange and Telefónica that displays a warning on the screen for suspicious calls.

Falsifying a number known to the victim makes the attack much more effective, especially in the age of AI, where it is very easy to imitate
a person’s voice, so Google is joining this fight with its own measures against CLI spoofing.

The Android Phone app has started to verify the caller ID of incoming
calls by connecting in real time to the supposed originating mobile
phone to check that it is indeed the one making the call.

For this to work, both parties must be Android users with the Phone app. When the call rings on the recipient’s device, the phone sends an encrypted RCS message to the legitimate owner of the number to ask if
they are actually making the call at that moment. In this way, the recipient’s phone can tell when the call is fake.

The idea is interesting, as it does not use OTT data traffic, but rather core network services, making the exchange of information faster and
more reliable.

This feature is being rolled out first on Pixel devices running Android
12 and above, but Google has released it as an open standard so that
other phone apps and operating systems can use it, meaning that in the future it would be possible to verify numbers between Android and iOS if
the parties involved wish to do so.

Translated with DeepL.com (free version)

So the non-spoofed caller makes their call, and then has to respond to a
text message? Oh joy, 2FA comes to voice calls, too.

"When the call rings on the recipient’s device, the phone sends an
encrypted RCS message to the legitimate owner of the number to ask if
they are actually making the call at that moment."

One, only works when caller and callee are both Android users, and both
use a phone app with the integrated verification check. Two, to
eliminate 2FA interference, the caller's phone app must automatically
respond to the RCS request by the callee's phone app, and the callee's
phone app must automatically handle the RCS response.

Texting is not a guaranteed communication venue. What happens when a
call is received, but texting fails in either direction between caller
and callee? And how does this scheme eliminate the delay in getting the specially encoded text? Texting is not always immediate. Who is going
to wait 2 minutes for the texting to complete in both directions when
there is an incoming call? After how many rings should the callee wait
before picking up the call? Will the callee's phone app silence all
ringing until its validation text gets received by the caller, and the
caller's phone app sends back the response text, to when the callee's
phone app finally gets that response text?

I'm sure there are some glitches that will have to get ironed out.
Since texts are an insecure communication venue (no encryption), there
wouldn't be some means to spoof the response text the spammer sends to
the callee? There are entire companies dedicated to providing spoofing services, so I'm sure they'll figure out a workaround.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-06-10 21:29, VanguardLH wrote:

"Carlos E.R." <robin_listas@es.invalid> wrote:

This is an article in Spanish, translated. I do not know if it applies
worldwide.

<https://bandaancha.eu/articulos/android-detectara-llamadas-numero-falso-11792>

Android will detect calls with spoofed numbers by sending a real-time
RCS message to the legitimate owner

By Joshua Llorach
Published 3 June 2026 10:50

Until last summer, it was very easy for malicious actors to spoof the
number that appears on a mobile phone screen as the caller ID when a
call rings. The lack of a system to validate numbers and their origin
allowed spammers and other malicious actors to inject traffic into the
network with a spoofed caller ID, a practice known as CLI spoofing.

Since June 2025, mobile operators have been filtering calls originating
from abroad that use Spanish numbers without permission, as well as
applying other validation checks to make this practice more difficult.
Added to these measures is the system from Orange and Telefónica that
displays a warning on the screen for suspicious calls.

Falsifying a number known to the victim makes the attack much more
effective, especially in the age of AI, where it is very easy to imitate
a person’s voice, so Google is joining this fight with its own measures
against CLI spoofing.

The Android Phone app has started to verify the caller ID of incoming
calls by connecting in real time to the supposed originating mobile
phone to check that it is indeed the one making the call.

For this to work, both parties must be Android users with the Phone app.
When the call rings on the recipient’s device, the phone sends an
encrypted RCS message to the legitimate owner of the number to ask if
they are actually making the call at that moment. In this way, the
recipient’s phone can tell when the call is fake.

The idea is interesting, as it does not use OTT data traffic, but rather
core network services, making the exchange of information faster and
more reliable.

This feature is being rolled out first on Pixel devices running Android
12 and above, but Google has released it as an open standard so that
other phone apps and operating systems can use it, meaning that in the
future it would be possible to verify numbers between Android and iOS if
the parties involved wish to do so.

Translated with DeepL.com (free version)

So the non-spoofed caller makes their call, and then has to respond to a
text message? Oh joy, 2FA comes to voice calls, too.

Yes, I wonder.

"When the call rings on the recipient’s device, the phone sends an encrypted RCS message to the legitimate owner of the number to ask if
they are actually making the call at that moment."

One, only works when caller and callee are both Android users, and both
use a phone app with the integrated verification check.

The Google telephone app, which is the default.

Two, to
eliminate 2FA interference, the caller's phone app must automatically
respond to the RCS request by the callee's phone app, and the callee's
phone app must automatically handle the RCS response.

Texting is not a guaranteed communication venue. What happens when a
call is received, but texting fails in either direction between caller
and callee? And how does this scheme eliminate the delay in getting the specially encoded text? Texting is not always immediate. Who is going
to wait 2 minutes for the texting to complete in both directions when
there is an incoming call? After how many rings should the callee wait before picking up the call? Will the callee's phone app silence all
ringing until its validation text gets received by the caller, and the caller's phone app sends back the response text, to when the callee's
phone app finally gets that response text?

I'm sure there are some glitches that will have to get ironed out.
Since texts are an insecure communication venue (no encryption),

It is RCS, there is encryption.

there
wouldn't be some means to spoof the response text the spammer sends to
the callee? There are entire companies dedicated to providing spoofing services, so I'm sure they'll figure out a workaround.

--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

VanguardLH <V@nguard.lh> wrote:

"Carlos E.R." <robin_listas@es.invalid> wrote:

Translated with DeepL.com (free version)

So the non-spoofed caller makes their call, and then has to respond to a
text message? Oh joy, 2FA comes to voice calls, too.

I was assuming that it's making an automatic handshake with the calling
phone via RCS, not asking the caller to do it.

ie:
1. Recipient phone app receives a call from +34567890123

2. Recipient phone app sends an RCS to +34567890123 saying 'hello RCS client, I'm +34xxxxxxxxx, are you calling me?'

3. Sending phone RCS app sends an RCS back saying 'yes, I'm currently calling you now' or 'no, I'm not calling you right now'

4. If recipient gets the 'yes' RCS they display a green tick, if they get a 'no' they display a 'suspicious incoming call' message and maybe block it.
If they don't get an answer they don't display anything.

That could be done automatically without the sender having to do anything.

If someone is spoofing numbers they aren't receiving messages on them, so
the RCS will go to the genuine number owner, rather than the one doing the spoofing.

The trouble is that calls from iPhones or from businesses won't operate
this system, so it doesn't actually help very much. And even if iPhones do adopt it, it seems unlikely that businesses will, since business telecoms is mostly SIP based and has nothing to do with RCS.

Theo
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Theo <theom+news@chiark.greenend.org.uk> wrote:

VanguardLH <V@nguard.lh> wrote:

"Carlos E.R." <robin_listas@es.invalid> wrote:

Translated with DeepL.com (free version)

So the non-spoofed caller makes their call, and then has to respond to a
text message? Oh joy, 2FA comes to voice calls, too.

I was assuming that it's making an automatic handshake with the calling
phone via RCS, not asking the caller to do it.

ie:
1. Recipient phone app receives a call from +34567890123

2. Recipient phone app sends an RCS to +34567890123 saying 'hello RCS client, I'm +34xxxxxxxxx, are you calling me?'

3. Sending phone RCS app sends an RCS back saying 'yes, I'm currently calling you now' or 'no, I'm not calling you right now'

4. If recipient gets the 'yes' RCS they display a green tick, if they get a 'no' they display a 'suspicious incoming call' message and maybe block it. If they don't get an answer they don't display anything.

That could be done automatically without the sender having to do anything.

If someone is spoofing numbers they aren't receiving messages on them, so
the RCS will go to the genuine number owner, rather than the one doing the spoofing.

The trouble is that calls from iPhones or from businesses won't operate
this system, so it doesn't actually help very much. And even if iPhones do adopt it, it seems unlikely that businesses will, since business telecoms is mostly SIP based and has nothing to do with RCS.

Theo

SMS texts can be delayed, sometimes for minutes, or longer.

Is RCS *guaranteed* to be immediate, like before any ringing, or during
the first ring on the callee's phone? It would have to be as
instantaneous as is Caller ID to be usable to verify the authenticity of
the Caller ID. This RCS scheme is to validate Caller ID to thwart
spoofing. CID occurs between the 1st and 2nd ring. This RCS scheme
would have to prelude that lookup. Anytime later means the callee sees
the proposed CID before it was validated.

I've read where RCS messages can take 20 minutes or hours to arrive
versus SMS that takes seconds or minutes? In either case, any setup
using RCS would have to terminate that mode of authentication if it did
not complete just before or during the 1st ring at the callee.
For the proposed setup to work, the callee's RCS message to the caller
would need to get an immediate RCS response from the caller.

The article says "When the call rings on the recipient, the mobile sends
an encrypted RCS message to the mobile phone of the legitimate owner of
the number to ask if they are really calling at that moment." But is
RCS actually a real-time (instantaneous) messaging system? Not from
what I've read, so far.

"The idea is interesting, since it does not use OTT data traffic, but
the services of the core of the network, which makes the exchange of information faster and more reliable."

That is the hope. Not a guarantee the scheme accomplishes the
validation BEFORE the Caller ID is presented to the callee. Faster and
more reliable is still not a guarantee.

It isn't just the caller and callee that must both use the RCS scheme to validate Caller ID. The caller must be in a searchable database by
their provider to do the lookup by the callee's service provider. Both
callee and caller must be using a phone app that incorporates the RCS
scheme for CID validation. The caller, if spoofed, must have their
phone powered on to send the RCS response. If the spoofed caller's
phone is off, it obviously cannot respond, but also as obvious is they
couldn't be making the call.

The telcos for both caller and callee must support RCS. Is RCS actually
so prevalent that all telcos support RCS? That is, does every VOIP,
landline, and cellular provider for both major carriers and also all
MVNOs (Mobile Virtual Network Operators) now support RCS?

Will the callee's phone only ring after the RCS validation has
succeeded, and ensure the succeeding Caller ID is validated? If RCS is employed before the phone rings, could be the caller has to wait for RCS
to work at the callee, for the request for response via RCS reaches the
caller, and for the caller to send back a RCS response. While all this
might happen in half a second under ideal conditions, again, is RCS
*always* guaranteed, and guaranteed instantaneous?

The criteria states both caller and callee be using phone apps that
incorporate the RCS validation scheme. First limitation. Both parties
must be using an Android phone. Second limitation. Excludes all the
iPhone users, and makes an easy circumvent by spammers.

There are many phone numbers you cannot dial. While you may have a
direct phone number to your doctor, or his office, or your health plan,
those also have internal phones that you can never reach. You cannot
call them on those numbers. How about all those robocallers that aren't
for spam, but legitimate use, like your doctor's office making a
robocall as a reminder for an upcoming appointment. Very unlikely RCS,
or any type of chatting, will be setup at those servers.

This is a stab in the right direction to help callees reduce spam and
phish calls, but it seems geared to a small subset of all callers. The
premise is something is better than nothing, but not if its benefits are outweighed by its interference. It also puts the onus upon users
instead of placing it where it belongs: at the telcos. In the long
past, users had to employ client-side anti-spam filtering to get rid of
all the crap showing up in their Inboxes. Then e-mail providers started
adding their own server-side anti-spam filters. Took a while before
they were more effective than local solutions. Now I no longer need a client-side anti-spam filter. This RCS scheme seems to follow the same pattern: make the users handle the problem, and maybe the telcos will do
the job they've promised for a long time.

The RCS validation of Caller ID may provide some benefit, but I see it
can also cause a lot of false positives. Just because someone calls you whether a human or robocaller doesn't mean they will issue an RCS
response, that they even could, that your and their telco supports RCS,
and all this is before when Caller ID is presented at your phone.

Road spikes can impede a fleeing felon in a car, but is not guaranteed
to stop the car. The escapee could be driving a semi or bus. X-Net is
better and safer as it wraps around and siezes the front wheels. Both
are still useful, but not effective a rising road-embedded pillars yet
those don't work on motorcycles or bicycles.

Any POCs (Proof Of Concept) testing on this RCS scheme yet?

We can attempt reduction using client-side solutions, but are still
allowing the spoofing services to continue operating. Once those are
made illegal, and globally, CID spoofing will severely wane.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 11.06.26 23:32, Theo wrote:

The trouble is that calls from iPhones or from businesses won't operate
this system, so it doesn't actually help very much. And even if iPhones do adopt it, it seems unlikely that businesses will, since business telecoms is mostly SIP based and has nothing to do with RCS.

+1
--
"Roma locuta, causa finita" (Augustinus)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-06-12 03:18, VanguardLH wrote:

Theo <theom+news@chiark.greenend.org.uk> wrote:

VanguardLH <V@nguard.lh> wrote:

"Carlos E.R." <robin_listas@es.invalid> wrote:

...

"The idea is interesting, since it does not use OTT data traffic, but
the services of the core of the network, which makes the exchange of information faster and more reliable."

That is the hope. Not a guarantee the scheme accomplishes the
validation BEFORE the Caller ID is presented to the callee. Faster and
more reliable is still not a guarantee.

It isn't just the caller and callee that must both use the RCS scheme to validate Caller ID. The caller must be in a searchable database by
their provider to do the lookup by the callee's service provider.

I don't see why?

Both
callee and caller must be using a phone app that incorporates the RCS
scheme for CID validation.

The Google default app.

The caller, if spoofed, must have their
phone powered on to send the RCS response. If the spoofed caller's
phone is off, it obviously cannot respond, but also as obvious is they couldn't be making the call.

The telcos for both caller and callee must support RCS. Is RCS actually
so prevalent that all telcos support RCS? That is, does every VOIP, landline, and cellular provider for both major carriers and also all
MVNOs (Mobile Virtual Network Operators) now support RCS?

Mobile phones only, AFAIK.

...

Any POCs (Proof Of Concept) testing on this RCS scheme yet?

This is the field testing now :-)

We can attempt reduction using client-side solutions, but are still
allowing the spoofing services to continue operating. Once those are
made illegal, and globally, CID spoofing will severely wane.

--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-06-11 23:32, Theo wrote:

VanguardLH <V@nguard.lh> wrote:

"Carlos E.R." <robin_listas@es.invalid> wrote:

Translated with DeepL.com (free version)

So the non-spoofed caller makes their call, and then has to respond to a
text message? Oh joy, 2FA comes to voice calls, too.

I was assuming that it's making an automatic handshake with the calling
phone via RCS, not asking the caller to do it.

ie:
1. Recipient phone app receives a call from +34567890123

2. Recipient phone app sends an RCS to +34567890123 saying 'hello RCS client, I'm +34xxxxxxxxx, are you calling me?'

3. Sending phone RCS app sends an RCS back saying 'yes, I'm currently calling you now' or 'no, I'm not calling you right now'

Ah, automated. I thought it was the user typing. Now it makes sense. So
they are doing a handshake without having a protocol designed for this.
Mmm. Next step would be upgrading the entire network to do a handshake
on all calls.

4. If recipient gets the 'yes' RCS they display a green tick, if they get a 'no' they display a 'suspicious incoming call' message and maybe block it.
If they don't get an answer they don't display anything.

That could be done automatically without the sender having to do anything.

If someone is spoofing numbers they aren't receiving messages on them, so
the RCS will go to the genuine number owner, rather than the one doing the spoofing.

The trouble is that calls from iPhones or from businesses won't operate
this system, so it doesn't actually help very much. And even if iPhones do adopt it, it seems unlikely that businesses will, since business telecoms is mostly SIP based and has nothing to do with RCS.

Theo

--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

"Carlos E.R." <robin_listas@es.invalid> wrote:

VanguardLH wrote:

It isn't just the caller and callee that must both use the RCS scheme to
validate Caller ID. The caller must be in a searchable database by
their provider to do the lookup by the callee's service provider.

I don't see why?

Isn't this whole RCS scheme to validate the Caller ID which is what is
getting spoofed? The caller isn't being spoofed. It's the CID they
send that could be spoofed.

Not everyone that calls has a CID. They may elect to be anonymous, but
then the callee can choose to reject anonymous calls.

I use Google Voice: a VOIP service with PBX features. Outgoing calls
made through Google Voice will have no CID to the callee. That is,
Google Voice does not support the use of outgoing CNAM (Caller ID Name),
so the callee only sees my GV phone number. Those that know my
long-time phone number will recognize it, or have already added me to
their contacts, so CID is superfluous. GV sends state, city, unknown
caller, or possible spam as the CNAM to the callee, but the callee also
gets my phone number. When someone calls my GV number, they call GV,
not my phone through its carrier. They connect to GV which calls all my
phones (work, home, cell phones), like a PBX, by using simultaneous
ring. Whichever of my phones I pick up gets the call. I can switch
between phones by having GV ring a different phone to transfer the call.
I doubt any of this RCS scheme is going to work through GV since I doubt
GV will step out of the way to get the RCS request from my phone to the
caller, and the caller's RCS response back to my phone.

Possibly it could work since GV passes the call to whichever phone I
pickup the call across all my phones getting the synchronous ring;
however, since there can be multiple phones getting rung by GV, just
which phone is going to send the RCS request to validate the caller?
Luckily with GV's anti-spam filtering, and call screening enabled, I
rarely get bogus calls, or spam calls, or wrong-dial calls.

I have had to make outbound calls using my cellular carrier since some destinations refuse to accept calls from GV, or from any service other
than a major carrier or telco. I cannot call someplace using GV, but
using my cellular carrier works. That happens so rarely that it's like
I got caught with my snake in the pants zipper, and have to figure out
how to extricate myself from the situation: a painful occurrence that
hopefully happens VERY rarely.

Both callee and caller must be using a phone app that incorporates
the RCS scheme for CID validation.

The Google default app.

For everyone other than Pixel users, that means having to install
Google's Phone app. Most all other phones come bundled with whatever
Phone app the phone makers wanted to bundle on their phones in their
constant customizing to brand-mark their phones.

The telcos for both caller and callee must support RCS. Is RCS actually
so prevalent that all telcos support RCS? That is, does every VOIP,
landline, and cellular provider for both major carriers and also all
MVNOs (Mobile Virtual Network Operators) now support RCS?

Mobile phones only, AFAIK.

Android. Google's Phone app (when updated). Cellular carrier must
support RCS. Nothing like GV in the route between caller and callee;
i.e., direct connect between endpoint mobile phones.

Any POCs (Proof Of Concept) testing on this RCS scheme yet?

This is the field testing now :-)

"This feature is first rolling out to Pixel devices running Android 12
and above, but Google has released it as an open standard so that other
phone apps and operating systems can use it, so that in the future it
would be possible to validate numbers between Android and iOS if those
involved want."

Android 12 came out October 2021. RCS got supported back in Android 6,
and later, but maybe now there are more RCS functions, like extensions
to RCS, that upped the minimum Android version.

No explanation why it must be a Pixel phone. Google is delivering this
as an open standard hence there'll be some specs on it for use with
other phone apps. Seems ANY non-Pixel phone running Android 12+ could
install the updated Google Phone app when it shows up.

The Google Phone app was released back in 2015. I have a Samsung phone,
not a Pixel, so the Phone app on my phone is the one Samsung bundles on
their phones. Was contemplating investigating Google's Phone app as a replacement, but I'm not impressed with its reviews. I've had none of
the difficulties with the Samsung Phone app that are noted by the 1-star
Play Store reviews on Google's Phone app with way too many within the
last year than I'm going to bother to count, and it's been out for over
10 years now. Guess I'll pass on whatever extras Google's Phone app
might've given me to opt for stability.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

"Carlos E.R." <robin_listas@es.invalid> wrote:

Ah, automated. I thought it was the user typing. Now it makes sense.
So they are doing a handshake without having a protocol designed for
this. Mmm. Next step would be upgrading the entire network to do a
handshake on all calls.

The core RCS scheme to validate the caller would have to be faster than delivery of the CNAM (Caller ID Name) data sent to the callee's phone
since the RCS scheme is to validate CNAM. What good would be validating
the caller's CNAM that has already been presented to the callee?

CNAM can be spoofed. How about the caller's phone number?

"Google has released it as an open standard so that other phone apps and operating systems can use it."

Google will publish the protocol, but this is a client-side solution,
not up at the mobile carrier. Upstream at the carrier would be prefered
to eliminate any minimum requirements at the callee's end: minimum
Android version, Pixel but don't know why that hardware is required, and Google's Phone app. The only requirement for the mobile carrier is they support RCS.

Is RCS now ubiquitous across *all* mobile carriers? RCS is carrier
dependent. Google has no control over whether or not carriers have RCS.

https://www.braze.com/resources/articles/future-of-rcs-vs-sms#h-758d433902f8 "As with MMS, if a message cannot be delivered via RCS (because either
the carrier or device does not support it), it will be delivered via SMS
by default."

Uffdah. If the fallback is to SMS, forget about transparency in this RCS-validate-CNAM scheme. SMS texts would never arrive before CNAM was presented to the callee. Ever have to wait for a 2FA code sent by SMS
to complete a login? Sure you have. I've even had to resend the 2FA
code via SMS, because their SMS server didn't send me the code, or it
never arrived. Would you tolerate that unreliable (nonguaranteed
delivery) scheme with exhorbitant delays after your phone starts
ringing?

Long ago, I had to employ client-side anti-spam filtering. More
overhead and maintenance for me. Been a long time since anti-spam
filtering has been more than satisfactory for me up on the server. I
even prefer to define my e-mail filters on the server instead of in my
local e-mail client, but it took even longer for e-mail providers to
have a decent set of server-side rules to eliminate doing it at the
client end.

If this RCS scheme to validate CNAM works well, with high reliability,
and with almost zero latency to ensure the CNAM validate completes
before the callee ever sees it, and Google's protocol gets adopted by
other phone apps, especially those bundled by phone makers, then maybe
the mobile carriers will implement this as a standard upstream feature
in their service. After all, they'll probably save on reduced support
calls from their customers. They could even advertise it as "Come to us
with our free anti-spoof feature" for a marketing edge. I suspect it
will be many years before CNAM-validate-by-RCS will become a standard
service feature, or carriers may get greedy by charging their customers
for the extra anti-spoof feature, or include it in a paid business-tier
service plan. Money money money.

Another cripple point: SMS doesn't require [cellular] data service. No
data or wifi needed for SMS. RCS does require data or wifi. So this
scheme attempts to meld phone calls with messaging. I know folks that
have unlimited calling, but with limited data, or they have mobile
service for calls but no data included. Although RCS was designed for
rich content, this anti-spoofing scheme should have tiny messages, but
LOTS of calls means a lot more data usage. Then there are folks that
don't have any mobile service. They use their smartphone with a wifi
hotspot, like their wifi cable modem at home, or at cafes, libraries,
etc. Even with data over wifi, someone driving in a car will make (if
auto is enabled) and break wifi connections too fast as they're zooming
down the street past Starbucks*. Versus mobile data that is designed to
switch between towers the same as for mobile calls.

* Of course, they shouldn't be doing calls while driving, but we all
know that happens. While driving, they could stop to park right in
front on Starbucks hoping to be close enough to get enough signal
strength from the hotspot for wifi data.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Theo <theom+news@chiark.greenend.org.uk> wrote:

VanguardLH <V@nguard.lh> wrote:

"Carlos E.R." <robin_listas@es.invalid> wrote:

Translated with DeepL.com (free version)

So the non-spoofed caller makes their call, and then has to respond to a text message? Oh joy, 2FA comes to voice calls, too.

I was assuming that it's making an automatic handshake with the calling
phone via RCS, not asking the caller to do it.

I was almost there, but got it wrong that the verifying RCS message is sent along
with the call - it's only initiated by the recipient if it didn't get the initial RCS verification:

https://blog.google/security/android-fake-call-detection/

They're selling it as preventing deepfakes where the attacker can both spoof
a number and spoof that person's voice, making it hard to tell from the real person. In that case I can see why something to assert it wasn't the real phone comes in useful.

It's quite a narrow use case (just spoofed calls from people you know,
rather then spoofed calls from your bank/etc, and not Facetime/Whatsapp/... voice calls) but I suppose phone calls are where the scammers are striking,
so it makes sense to start there.

Theo
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

VanguardLH wrote:

Isn't this whole RCS scheme to validate the Caller ID which is what is getting spoofed? The caller isn't being spoofed. It's the CID they
send that could be spoofed.

Apparently the scammers *are* faking the voice as well as the caller ID.

So you get a call from an AI version of your relative, saying they've
been robbed while on holiday, asking if could you send them some money
so they can get home again ... enough people fall for this when it's
just faked email/text.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Andy Burns <usenet@andyburns.uk> wrote:

VanguardLH wrote:

Isn't this whole RCS scheme to validate the Caller ID which is what is
getting spoofed? The caller isn't being spoofed. It's the CID they
send that could be spoofed.

Apparently the scammers *are* faking the voice as well as the caller ID.

So you get a call from an AI version of your relative, saying they've
been robbed while on holiday, asking if could you send them some money
so they can get home again ... enough people fall for this when it's
just faked email/text.

https://signalwire.com/blogs/industry/caller-id-vs-cnam

I thought just CNAM (Caller ID Name) was getting spoofed. Apparently
the phone number, part of Caller ID, can be spoofed, too. More
pernicious than I knew.

https://en.wikipedia.org/wiki/Caller_ID_spoofing
"Starting in mid-2017, the FCC pushed forward Caller ID certification
implemented using a framework known as STIR/SHAKEN.[45][46]
SHAKEN/STIR are acronyms for Signature-based Handling of Asserted
Information Using toKENs (SHAKEN) and the Secure Telephone Identity
Revisited (STIR) standards. The FCC has mandated that telecom
providers implement STIR/SHAKEN-based caller ID attestation in the IP
portions of their networks beginning no later than June 30, 2021."

"Congress passed the TRACED Act in 2019 which makes Caller ID
authentication mandatory."

https://en.wikipedia.org/wiki/STIR/SHAKEN

That was over 5 year ago (2021) for large providers with over 100K
subscribers, and 3 years ago (2023) for providers with under 100K
subscribers (e.g., C Spire). These are service-side measures. Nothing
needed on your end.

https://techoutreach.extension.msstate.edu/news/2022/04/take-steps-avoid-caller-id-spoofing-scams
"The SHAKEN/STIR caller ID authentication system is also stopping many
unwanted calls from being completed. These acronyms stand for
Signature-based Handling of Asserted Information using toKENs and the
Secure Telephone Identity Revisited standards. The system allows a
phone number to be verified by both the carrier from which the call is
placed and the carrier receiving the call."

If these service-side measures worked, why would Google be trying to
come up with an alternative client-side validation scheme using RCS to
attest the caller of a call?

All of this is to eliminate spoofed calls, not specifically to eliminate
spam calls initiated by humans or robocallers. However, if *no* spoofed
calls could complete a connection to a callee, then block lists of bad
phone numbers would be feasible, and not end up blocking innocents that
were spoofed.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 13.06.26 22:52, VanguardLH wrote:

Apparently
the phone number, part of Caller ID, can be spoofed, too.

This is the real issue and nothing else.
--
"Roma locuta, causa finita" (Augustinus)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-06-13 00:11, Theo wrote:

Theo <theom+news@chiark.greenend.org.uk> wrote:

VanguardLH <V@nguard.lh> wrote:

"Carlos E.R." <robin_listas@es.invalid> wrote:

Translated with DeepL.com (free version)

So the non-spoofed caller makes their call, and then has to respond to a >>> text message? Oh joy, 2FA comes to voice calls, too.

I was assuming that it's making an automatic handshake with the calling
phone via RCS, not asking the caller to do it.

I was almost there, but got it wrong that the verifying RCS message is sent along
with the call - it's only initiated by the recipient if it didn't get the initial RCS verification:

https://blog.google/security/android-fake-call-detection/

Can we ensure that the bad caller can not also send a fake RCS message?

They're selling it as preventing deepfakes where the attacker can both spoof a number and spoof that person's voice, making it hard to tell from the real person. In that case I can see why something to assert it wasn't the real phone comes in useful.

It's quite a narrow use case (just spoofed calls from people you know,
rather then spoofed calls from your bank/etc, and not Facetime/Whatsapp/... voice calls) but I suppose phone calls are where the scammers are striking, so it makes sense to start there.

Theo

--
Cheers,
Carlos E.R.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

"Carlos E. R." <robin_listas@es.invalid> wrote:

Can we ensure that the bad caller can not also send a fake RCS message?

If the scammer is making the call, and it's not some robocaller frontend
that cannot be called back nor responds to RCS messages, and the scammer
spoofs their phone number, the callee's RCS message goes to the spoofed
number, not back to the scammer.

spammer @ 123-456-7890 --> spoof 567-890-1234 --> callee sends RCS --.
\__________/ |
^______________________________|

Since the scammer doesn't get the "are you there" RCS message, the
scammer cannot send an RCS response to the callee. They cannot send a
fake RCS ACK to the callee, because they never got the RCS REQ from the
callee.

There are situations in which a spoofed number is legal, and actually mandatory. Say a doctor wants to call a patient regarding a test
result. He calls the patient on his phone, but doesn't take direct
calls from patients. His personal phone couldn't handle the load of all
his patients calling him. Instead he wants them to call his office to
handle, process, and forward incoming calls to him.

If the spoofed number is controlled by the caller, that number could
send an RCS response to make the callee happy that the spoofed number
was the caller. This is the situation where spoofing is legal. The
caller uses a phone that does not take outside calls, or any calls. It
is an outbound-only number. The spoofed number points the callee at an
office for the caller, a call center, support center, customer service,
the front desk at a pharmacy, etc.

I use Google Voice, and it spoofs my phone number. When I make calls
through GV, the callee sees my GV number, not the one for my landline at
home or work, or one of my mobile phones all of which have different
real phone numbers (i.e., the one with the telco or mobile carrier).

real mobile # my GV number
me @ 123-456-7890 --> spoof 789-012-3456 --> callee sends RCS --.
\__________/ break |
^________~ ~__________________|

Although Google is promoting their RCS-caller-validation scheme, I doubt
their Google Voice service will respond to RCS requests by the callee.
To the callee, it tries to send an RCS message to my GV number, but GV
doesn't send back an RCS response.

GV will forward SMS texts to my real phones, and even e-mail me a
transcript of them, but I don't how the RCS messages will be handled.
GV does forward regular RCS messages to my real phone, but the RCS
validation scheme proposes to use "special" messages that the Phone app automatically handles for an automated response. If the special RCS
messages get through my GV account just as do SMS texts, it would
something like:

real mobile # my GV number
me @ 123-456-7890 --> spoof 789-012-3456 --> callee sends RCS --.
\__________/<----------\__________/<-----------------------'
'------------ RCS ACK -----------> callee

However, the RCS ACK from my real phone will be for my real phone
number, not the spoofed number from my GV account. The caller will see
a mismatch between the GV spoofed number and my real phone number on my
actual phone. If GV sends the RCS ACK, the caller sees and verifies the spoofed number called them. If GV merely passes the RCS REQ through GV
to my real phone, the callee sees a mismatch. They know my GV number is spoofed, but that is exactly how PBX systems worked: many internal publicly-inaccessible numbers piped in and out through one externally publicly-accessible number. For me, and for the RCS validation scheme
to work, Google would also have to deploy their RCS validation protocol
at the Google Service itself, so it can send the RCS ACK to the callee,
and the callee sees the ACK came from the same GV spoofed number
originally given the callee. That's why I say there will many scenarios
that are legit that Google will have to amend their RCS scheme, like
providing registrations for PBX, VOIP, and other service providers where
the caller isn't trying to hide, or where spoofed number are completely
legal.

Just like GV would have to add handling of incoming RCS REQs coming from callees receiving GV outbound calls, seems easy enough for spoofing
providers (those that don't care about intent regarding use) to also incorporate the RCS ACK in Google's RCS validation scheme. The callee
sends an RCS REQ to the spoofed number, the spoofing service sends back
an RCS ACK, and the callee is happy that the Caller ID number shown to
them is the caller's phone number. Again, there are legit uses of
spoofing. It's the scammy (illegal) uses of spoofing that are a
problem.

The way the law is written is not to totally bar the use of spoofing,
but to make illegal the use of spoofing to collect info or falsely
respresent the caller to cause [financial] harm to the callee, or
attempt to phish, or otherwise collect sensitive information that could
harm the callee. The laws don't make spoofing illegal. They make
illegal some uses of spoofing.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-06-15 03:18, VanguardLH wrote:

"Carlos E. R." <robin_listas@es.invalid> wrote:

Can we ensure that the bad caller can not also send a fake RCS message?

If the scammer is making the call, and it's not some robocaller frontend
that cannot be called back nor responds to RCS messages, and the scammer spoofs their phone number, the callee's RCS message goes to the spoofed number, not back to the scammer.

You missed the part where the calling party also sends an RCS saying I'm calling you, before being asked.

If this initial message is missing, then the called party sends an rcs
back. Thus not always.

spammer @ 123-456-7890 --> spoof 567-890-1234 --> callee sends RCS --.
\__________/ |
^______________________________|

Since the scammer doesn't get the "are you there" RCS message, the
scammer cannot send an RCS response to the callee. They cannot send a
fake RCS ACK to the callee, because they never got the RCS REQ from the callee.

There are situations in which a spoofed number is legal, and actually mandatory. Say a doctor wants to call a patient regarding a test
result. He calls the patient on his phone, but doesn't take direct
calls from patients. His personal phone couldn't handle the load of all
his patients calling him. Instead he wants them to call his office to handle, process, and forward incoming calls to him.

Just call using the exchange at the clinic. He can have a mobile phone
with a number handled by the exchange, but I have seen this only on big places.

...
--
Cheers,
Carlos E.R.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

"Carlos E. R." <robin_listas@es.invalid> wrote:

You missed the part where the calling party also sends an RCS saying I'm calling you, before being asked.

If this initial message is missing, then the called party sends an rcs
back. Thus not always.

My understanding is the RCS validation is callee initialized, not caller initialized. I would think the scheme would not have the callee
accepting an RCS ACK before it even sent its own RCS REQ.

The article mentioned Google's open standard, but did not provide a URL
to it. Looks like the scheme uses encrypted RCS messaging. The
callee's Phone by Google app would have to initiate the encrypted RCS messaging. It's not going to listen for an RCS ACK message until the
callee initiates with an RCS REQ.

https://blog.google/security/android-fake-call-detection/

But still no link to the definition of their open protocol.

https://www.techtimes.com/articles/318000/20260608/android-fake-call-detection-targets-ai-deepfakes-rcs-handshake-verifies-caller-devices.htm
"When a saved contact calls, their Phone by Google app sends a silent, real-time cryptographic confirmation token over the RCS signaling layer
to the recipient's device. That token confirms the call is genuinely originating from the contact's registered hardware — not routed through
VoIP software with a spoofed caller ID."

Hmm, so the caller initiates with sending an encrypted RCS token to the
callee. But all of this RCS attestation is only for saved contacts.
Your phone sees a number you saved as a contact for Mom, and uses the
RCS token to verify it's Mom. However, if you don't have a contact for
Mom, the caller ID says "Mom", and RCS attestation isn't involved.
Doesn't seem a reliably or trustworthy scheme if the caller initiates
the RCS attestation.

"There is one meaningful constraint: both the caller and the recipient
must be using Phone by Google with RCS active [and the mobile carriers
by both parties must support RCS], alongside Google Contacts and Google Messages. Users whose carriers installed a different default dialer can
install Phone by Google from the Google Play Store and set it as the
default to enable protection."
(I added the bracketed content.)

How many spammers, scammers, or phishers are going to use the Phone by
Google app to make calls? None. The prime assailants won't be using
the Phone by Google app, so none of the RCS scheme gets employed.
Google hopes their open standard (wherever it may be defined) gets
adopted by other phone app authors, but that's wishful thinking, and
would take a while, anyway.

Seems this RCS attestation scheme is limited to a select few users. If
the caller doesn't have RCS (or you don't) with your mobile carrier, the
scheme is dead. If the caller doesn't use the Phone by Google app, the
scheme is dead until if and when the dev for whatever phone app you use incorporates this scheme. The scheme doesn't look to cover non-contact
callers; i.e., it validates the Caller ID matches a contact, but if the
caller isn't a contact then there is no validation. I was hoping the
scheme would address any spoofed caller, not just spoofed callers trying
to imitate an entry in your Contacts.

https://www.makeuseof.com/android-fake-call-detection-how-it-works/

From the image, the assumption is the scammer doesn't send the
confirmation signal via encrypted RCS. Maybe that is how it not works
at the spoofing services used by scammers, but obviously the spoofing
services could also implement the RCS scheme by pretending, for now,
they are using the Phone by Google app.

Imposter makes a call pretending to be Mom, and includes the RCS
confirmation signal. You get the spoofed call, and your phone app
checks with Mom's device using RCS. Might work if Mom's phone was
powered up to respond. Maybe it isn't. If the imposter pretends to be
not just your pharmacy, but the distro warehouse for your pharmacy, you
won't have them as a contact (you won't even know their phone number).
Caller isn't a contact, so this RCS scheme is dead. A caller that is
not a saved contact isn't challenged to prove they are who they say. I
wasn't aware that spoofing primarily targeted saved contacts on the
callee's phone. How are they going to get my contacts?

This seems a stab at an iffy scenario for limited subset of users, and
likely to fade away if STIR/SHAKEN gets adopted by all mobile carriers,
and actually works. However, its just for mobile calls. Apparently
Google isn't keen on STIR/SHAKEN, and came up with a client-end scheme
that bypasses any spoof checking at the carrier.

Gotta have this, gotta have that, and something else, too, and only for
some callers, which means the typical user won't know what it isn't
working. I don't see this as some Earth shaking improvement in
thwarting spoofed calls with untoward intent. Seems more likely it will interfere with legitimately spoofed callers.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

VanguardLH <V@nguard.lh> wrote:

initialized. I would think the scheme would not have the callee
accepting an RCS ACK before it even sent its own RCS REQ.

The article mentioned Google's open standard, but did not provide a URL
to it. Looks like the scheme uses encrypted RCS messaging. The
callee's Phone by Google app would have to initiate the encrypted RCS messaging. It's not going to listen for an RCS ACK message until the
callee initiates with an RCS REQ.

https://blog.google/security/android-fake-call-detection/

But still no link to the definition of their open protocol.

https://www.techtimes.com/articles/318000/20260608/android-fake-call-detection-targets-ai-deepfakes-rcs-handshake-verifies-caller-devices.htm
"When a saved contact calls, their Phone by Google app sends a silent, real-time cryptographic confirmation token over the RCS signaling layer
to the recipient's device. That token confirms the call is genuinely originating from the contact's registered hardware — not routed through VoIP software with a spoofed caller ID."

Hmm, so the caller initiates with sending an encrypted RCS token to the callee. But all of this RCS attestation is only for saved contacts.
Your phone sees a number you saved as a contact for Mom, and uses the
RCS token to verify it's Mom. However, if you don't have a contact for
Mom, the caller ID says "Mom", and RCS attestation isn't involved.
Doesn't seem a reliably or trustworthy scheme if the caller initiates
the RCS attestation.

It seems this is a byproduct of end to end encryption over RCS. As part of starting an RCS conversation a set of key pairs are established. Then you
can use those to securely communicate with your correspondent.

In this case the 'I'm calling you' RCS message is presumably using the
existing key pairs, meaning that secure communication is already established. In that way you can know that a call you receive from your correspondent without the accompanying RCS message is more likely to be spoofed, and the warning message displayed.

For a contact who you haven't previously established RCS communication with, the system hasn't yet established a secure channel. I'm not sure if you can send an unsolicited RCS message anyway; presumably businesses must be able
to send out RCS messages without having the user enroll them as contacts
first? But presumably if you don't have a key pair established then you
can't put up a message saying the call is suspicious?

The place I can see this falling down is where you have never contacted them via RCS, only phone calls or other means. For example if you always chat
with grandma via iMessage or WhatsApp then you may not have established an
RCS session with her to set up keys. Then the phone can't know whether she
is on RCS or not (without some potentially slow discovery process) and can't pop up a message saying not to trust the call.

Imposter makes a call pretending to be Mom, and includes the RCS
confirmation signal. You get the spoofed call, and your phone app
checks with Mom's device using RCS. Might work if Mom's phone was
powered up to respond. Maybe it isn't. If the imposter pretends to be
not just your pharmacy, but the distro warehouse for your pharmacy, you
won't have them as a contact (you won't even know their phone number).
Caller isn't a contact, so this RCS scheme is dead. A caller that is
not a saved contact isn't challenged to prove they are who they say. I wasn't aware that spoofing primarily targeted saved contacts on the
callee's phone. How are they going to get my contacts?

I don't think it's saved contacts that is relevant, it's people you have already contacted via RCS. That is mostly people with real mobile
phones, rather than landlines or businesses.

This seems a stab at an iffy scenario for limited subset of users, and
likely to fade away if STIR/SHAKEN gets adopted by all mobile carriers,
and actually works. However, its just for mobile calls. Apparently
Google isn't keen on STIR/SHAKEN, and came up with a client-end scheme
that bypasses any spoof checking at the carrier.

STIR/SHAKEN is a US thing, it doesn't apply in other countries. Google's solution does.

Theo
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-06-15 17:29, Theo wrote:

VanguardLH <V@nguard.lh> wrote:

initialized. I would think the scheme would not have the callee
accepting an RCS ACK before it even sent its own RCS REQ.

The article mentioned Google's open standard, but did not provide a URL
to it. Looks like the scheme uses encrypted RCS messaging. The
callee's Phone by Google app would have to initiate the encrypted RCS
messaging. It's not going to listen for an RCS ACK message until the
callee initiates with an RCS REQ.

https://blog.google/security/android-fake-call-detection/

But still no link to the definition of their open protocol.

https://www.techtimes.com/articles/318000/20260608/android-fake-call-detection-targets-ai-deepfakes-rcs-handshake-verifies-caller-devices.htm
"When a saved contact calls, their Phone by Google app sends a silent,
real-time cryptographic confirmation token over the RCS signaling layer
to the recipient's device. That token confirms the call is genuinely
originating from the contact's registered hardware — not routed through
VoIP software with a spoofed caller ID."

Hmm, so the caller initiates with sending an encrypted RCS token to the
callee. But all of this RCS attestation is only for saved contacts.
Your phone sees a number you saved as a contact for Mom, and uses the
RCS token to verify it's Mom. However, if you don't have a contact for
Mom, the caller ID says "Mom", and RCS attestation isn't involved.
Doesn't seem a reliably or trustworthy scheme if the caller initiates
the RCS attestation.

It seems this is a byproduct of end to end encryption over RCS. As part of starting an RCS conversation a set of key pairs are established. Then you can use those to securely communicate with your correspondent.

In this case the 'I'm calling you' RCS message is presumably using the existing key pairs, meaning that secure communication is already established. In that way you can know that a call you receive from your correspondent without the accompanying RCS message is more likely to be spoofed, and the warning message displayed.

Ah. So this is the answer to my question, thanks.

For a contact who you haven't previously established RCS communication with, the system hasn't yet established a secure channel. I'm not sure if you can send an unsolicited RCS message anyway; presumably businesses must be able
to send out RCS messages without having the user enroll them as contacts first? But presumably if you don't have a key pair established then you can't put up a message saying the call is suspicious?

In this case, and grandma below, side B messages side A.

The place I can see this falling down is where you have never contacted them via RCS, only phone calls or other means. For example if you always chat with grandma via iMessage or WhatsApp then you may not have established an RCS session with her to set up keys. Then the phone can't know whether she is on RCS or not (without some potentially slow discovery process) and can't pop up a message saying not to trust the call.

Imposter makes a call pretending to be Mom, and includes the RCS
confirmation signal. You get the spoofed call, and your phone app
checks with Mom's device using RCS. Might work if Mom's phone was
powered up to respond. Maybe it isn't. If the imposter pretends to be
not just your pharmacy, but the distro warehouse for your pharmacy, you
won't have them as a contact (you won't even know their phone number).
Caller isn't a contact, so this RCS scheme is dead. A caller that is
not a saved contact isn't challenged to prove they are who they say. I
wasn't aware that spoofing primarily targeted saved contacts on the
callee's phone. How are they going to get my contacts?

I don't think it's saved contacts that is relevant, it's people you have already contacted via RCS. That is mostly people with real mobile
phones, rather than landlines or businesses.

Right.

This seems a stab at an iffy scenario for limited subset of users, and
likely to fade away if STIR/SHAKEN gets adopted by all mobile carriers,
and actually works. However, its just for mobile calls. Apparently
Google isn't keen on STIR/SHAKEN, and came up with a client-end scheme
that bypasses any spoof checking at the carrier.

STIR/SHAKEN is a US thing, it doesn't apply in other countries. Google's solution does.

Theo

It is a start.
--
Cheers,
Carlos E.R.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.22a-Linux NewsLink 1.2