I got an obviously-AI voice agent spam call yesterday. Had a bit of fun getting it to answer trivia questions (when was the treaty of westphalia ratified? answer in a rhyming couplet) as a precondition to handing over the keys to my bank accounts.
Downside is they most likely are using stolen tokens, not paying themselves so it cost them next to nothing.
Anti-fraud tools can't keep pace with robocall scammers
121–130 of 149 posts
Re: Anti-fraud tools can't keep pace with robocall scammers
#122Earlier quoted context omitted.
Which is why we turn originating / sourcing / routing calls into a risk. See: https://news.ycombinator.com/item?id=49130932 > There's a related issue apparently of small operators who can't afford (or haven't been bothered) to implement STIR/SHAKEN. Many of these are apparently small rural phone co-ops (its own interesting bit of telecoms history). There should be both support in providing them with such capabilities…
Well then phone companies will stop originating/routing/sourcing calls. Do you want that? Your idea has been implemented for banks already, and the result is that machine learning algorithms randomly block transactions and close people's accounts for no reason.
Where there's legitimate business, and the risks are low (including the overwhelming majority of personal / residential lines, as well as most business / institutional lines), there's absolutely no problem.
The key is getting incentives right. Indexing bonding and payouts to the spam level, and having a target, is one way to approach this.
The problem with cheap comms, or cheap anything, is that it makes low-return, high-volume activities viable, including especially those which externalise costs and internalise benefits. Such as, say, fraud or spam generally.
What my proposal does is internalise those costs to spammer and telcos which facilitate them, by raising effort (most bulk calls are blocked) and shifting the financial incentives. From participating in the fight against spam for the past 30 years I've a pretty good notion that this will work. And unlike email, the phone system already has a costing and payment system built in.
With single spam operations generating hundreds of millions to billions of calls monthly and barely achieving profitability, I'm pretty sure we can knock things back a lot without inconveniencing legitimate players.
Re: Anti-fraud tools can't keep pace with robocall scammers
#123Earlier quoted context omitted.
Why not? And why would you impose a highly-intrusive personal-tracking system across billions of subscribers?
Because I don't want some stupid AI system to randomly decide I'm a spam caller. And you know every other country has full KYC for phone connections, right?
What activities are you engaged in which make you think you'd likely be considered a spammer? What specific harms do you see occurring? Might these be related to your present line of business / profession / employment?
Re: Anti-fraud tools can't keep pace with robocall scammers
#124Earlier quoted context omitted.
That's a familiar complaint from the world of email, where it's usually applied to mailing lists. If I were to steelman the concern, I'd look at a few related scenarios, say, where a subscriber is running a poorly-secured VOIP system and spammers hijack that to make calls. I'll ... get to that. First: the scenario here is phone systems, not email, so the traffic would be voice calls, possibly texts. That said, I'll c…
So I just sign up for $60, collect a bunch of calls and then report them all a spam, earning me a guaranteed $1000 from the phone company?
If you're acting fraudulently and at scale, there will likely be consequences.
If this happens occasionally, it's a feature of the system, and your reports effectively become a super-opt-out.
And if perhaps the problem does become sufficiently widespread, I'd be interested in seeing how you'd address it given one constraint: operating within the bonding/surety system I've suggested. And that the State of California and others have already enacted in some form.
Re: Anti-fraud tools can't keep pace with robocall scammers
#125Re: Anti-fraud tools can't keep pace with robocall scammers
#126Earlier quoted context omitted.
Because I don't want some stupid AI system to randomly decide I'm a spam caller. And you know every other country has full KYC for phone connections, right?
What would be a sufficient appeals process or remedy action that might address your concern? What activities are you engaged in which make you think you'd likely be considered a spammer? What specific harms do you see occurring? Might these be related to your present line of business / profession / employment?
Re: Anti-fraud tools can't keep pace with robocall scammers
#127Earlier quoted context omitted.
Well then phone companies will stop originating/routing/sourcing calls. Do you want that? Your idea has been implemented for banks already, and the result is that machine learning algorithms randomly block transactions and close people's accounts for no reason.
Telcos will stop originating high-risk calls. Where there's legitimate business, and the risks are low (including the overwhelming majority of personal / residential lines, as well as most business / institutional lines), there's absolutely no problem. The key is getting incentives right . Indexing bonding and payouts to the spam level, and having a target, is one way to approach this. The problem with cheap comms, o…
Re: Anti-fraud tools can't keep pace with robocall scammers
#128The solution is accessible law, not better anti-fraud tooling. Introduce a spam / fraud button, using it requires your pin and costs $10, but obliges your telecom provider to record the call (preferably including a few minutes before you hit the button), email you a signed recording and if found to be spam deposit $100 onto your account. Your provider may then hand the fee +10% for himself to whatever network the cal…
Unscrupulous operators will just run up huge liabilities and close up shop by the time they can be identified and dragged into court, meanwhile having started another similar operation under a different name. That's basically already what's happening, and the speed differential between the technology and the law will be forever in their favor.
The bonding agent (the Surety) sets the bond rate based on the perceived risk of the venture.
Unbonded ventures are not permitted to operate. In a telco context, unbonded carriers would not be peered to other carriers.
Overview of how surety bonds work: https://www.suretybondsdirect.com/educate/what-is-surety-bon...>.
California's present regulation: https://oag.ca.gov/consumers/general/telreg>
Re: Anti-fraud tools can't keep pace with robocall scammers
#129The solution is accessible law, not better anti-fraud tooling. Introduce a spam / fraud button, using it requires your pin and costs $10, but obliges your telecom provider to record the call (preferably including a few minutes before you hit the button), email you a signed recording and if found to be spam deposit $100 onto your account. Your provider may then hand the fee +10% for himself to whatever network the cal…
I think we have to do something this extreme. We have to give the system a total makeover. Somehow we also have to keep it from being fully centralized and have the big brother problem on the other side. Unfortunately these two goals are difficult to get through at the same time, with the system that we have.
You can't make a system that can force bad actors off the system that can't also be used to force politically undesirable actors off the system.
Re: Anti-fraud tools can't keep pace with robocall scammers
#130I've been using the Android app SpamBlocker off F-Droid for several years to block unwanted calls and SMS. It blocks entire area codes, individual numbers, names and any pattern using regular expressions. It can silence, pickup and hangup or just send to VM. The developer has a github page and has provided many updates. https://f-droid.org/en/packages/spam.blocker/
Initially the approach was a long list of rules, usually a whitelist and blacklist of known good and bad contacts, and then a large set of specific patterns and assigned weights. Procmail was an early standard here, later Spamassassin.
The biggest revolution came with Bayesian classification. YCombinator's Paul Graham (@pg) developed one such system. The idea here was that a small set of mail was classified into two categories, spam (unwanted) and ham (wanted), and the classifier went looking for patterns within each corpus, automatically assigning weights. This took much of the guesswork and assumptions out of the process, but still relied on contextual clues within the mail itself, though both data (the message payload) and metadata (email headers) could be used.
Following that were reputation-based systems, generally looking at domains or IP address space, where a sufficiently large-scale survey of mail patterns, initially based on honeypots, later largely conducted by large email providers themselves such as AOL, Yahoo, Hotmail, (this was the aughts, they still existed), and eventually Gmail and a few others. Senderbase/Ironport (later bought by Cisco) were another major contender here. These approaches strongly leveraged power-law relations, in which a small number of origins (IPs, CIDR blocks, ASNs) account for the vast majority of email spam. Generally: poor network hygiene practices, whether intentional or otherwise, show, and are actionable by peers / others.
Google especially, through Gmail, had access to a phenomenal amount of activity, and could detect both datacenter-based bulk mailing activity and residential proxy campaigns. Effectively its Gmail service serves as a huge, distributed, collection observatory, and can respond to new spam campaigns incredibly quickly. I don't have specific insights, but suspect that response times are measured in minutes if not seconds.
Google of course also has insight to the contents of emails, but network- and header-level adjudication is much faster, cheaper, and surprisingly effective.
This is why I'm strongly advocating carrier-based, network-level phone-spam mitigations, and whatever regulatory changes are necessary to incentivise providers to adopt these. On-device apps are fine, so far as they go, but would best work in concert with network-level countermeasures.