Scam protection using a Raspberry Pi to perform caller ID and risk-assess incoming calls

Dave Cranwell — Thu, 29 Apr 2021 11:06:33 +0000

My dad is getting on and isn't super tech-savvy. In fact some nice Indian gentlemen liberated a few hundred pounds from him in exchange for unlocking his own computer for him. Twice.

I'm doing all the reeducation I can, but as a mostly-offline person he has a lot to cover. For example, the idea that staff from a reputable megacorp would benevolently, and for no explained reason, phone you up out of the goodness of their hearts, because your computer - your computer amongst billions - had a virus...this is not at all suspicious to a huge percentage of the population.

Since these events I've become obsessed with ways of helping Dad. I've spent months of my life watching Jim Browning's scam exposure videos. I wrote plain-english notes to be kept next to his phone on how to identify scam calls. Still he got sucked in on futher occasions and only managed to avoid serious loss because he doesn't have an Amazon account. I've even resorted to blacklisting all his calls. This means the only calls allowed through must be manually white-listed. But you've guessed it, that whitelist must be managed online, using a badly architected React webapp, with no thought to information architecture or simplicity, that Dad doesn't want to use.

The number of malicious calls he receives is clearly well beyond what British Telecom's pathetic Call Protect systems can keep up with. Scammers can change their numbers at will thanks to unscrupulous telecoms companies selling new ones, so BT and any other spam prevention system will always be playing catch-up.

Landline users are lagging behind

What BT can't do themselves, however, crowds can. Websites have cropped up like who-called.co.uk in which anyone can search for a number to find what others have said about it. And, having tirelessly compared my dad's phone records against services like this, they are mostly very accurate. But of course, my dad isn't going to check these sites - his computer is turned off at the wall.

Caller blocking devices do exist, but these are post-hoc. If you receive a call you don't like only then you block it. Most aren't even web-capable.

Mobile phones often ship with caller identification packages, but landlines are still hugely popular in the older generations. What consumers are missing is a centralised, democratised, orchestrated effort, to cut off dangerous callers at a handset level.

This is essentially what I've attempted, as a little passion project:

Badcaller

With a Raspberry Pi, a tiny USB Modem, some code and a few tedious hours trying to understand the Hayes AT Commands set, I've got a reasonable first draft of a box that can be placed beside the phone and can both identify and danger-check every phone call received. The big omission right this moment, is a screen. The "Badcaller" system is for now a browser-based display of your incomming calls and their danger. But this requires you to have a PC, or a phone - this isn't going to help Dad just yet. My next step would be to add a small screen, then perhaps a housing. Raspberry Pi's can be reasonably easily put into a "Kiosk mode" and when that's viable, I hope to test it with him.

The interface is dead simple and hopefully completely unquestionable:

Development (ongoing)

I originally stumbled across what looks like a silver bullet device for caller ID, the Artech AD102. This is a HID device though, not serial like a USB modem and requires DLLs to use. The node-hid package looked a plausible candidate here, but it became rapidly clear that the AD102 must be switched into a kind of "open for questions" mode to get responses out of it, mandating use of the DLLs. Those DLLs are only avaialble for Windows, have no source and can't seem to be recompiled into Linux Shared Objects (or if they can it was well beyond this web developer's capabilities). I considered Windows IoT too, which might have helped with the DLL, however Raspberry Pis use ARM processors and, from what I could gather, this would also require the DLL be recompiled. I eventually gave up with the AD102 entirely.

Discovering that USB modems do Caller ID was a breakthrough. I even found comments on a modem on Amazon, from someone happily confirming that it worked really well for using AT commands to get the caller ID! I'm clearly not alone.

Modems are FSMs, so I required no cajoling to give XState a try as I've had my eye on it for a while and I'm only slightly familiar with Machina. Check out the amazing, interactive visualisations you can do with XState.

Watchtower was also a very convenient discovery and is more suited to non-prod orchestration for which K8s would be overkill.

This is, of course, a doomed project in a way. The best outcome I could possibly achieve - making all scam calling untenable at a global level - would make this project/product useless. But it would be nice if someone else wanted to help and give it a shot. Let me know if you do!

Read more about the project on the Github page

Originally posted at https://davecranwell.com/2021/04/28/raspberry-pi-telephone-caller-id.html

Template Literal expressions within the Template tag seem like a missed opportunity

Dave Cranwell — Fri, 11 Jan 2019 12:41:46 +0000

Template Literals are amazing, but I've lately found they make everything look like a proverbial nail, particularly when it comes to updating large blocks of HTML dynamically.

I'm still working in an environment which is mostly backend, where Perl generates HTML from templates, on top of which we add progressively enhanced javascript components.

When both your back and front end need to be able to generate common UI patterns based on a pattern library, it becomes frustrating to have to define the HTML source for each UI pattern in multiple places (once in Perl, once in JS).

The <template> tag could be useful. The backend can generate the HTML required for the component (e.g each Todo item in the Todo list) and the JS can use that HTML template to generate each new todo item.

But the only way of dynamically inserting values into that template, that I'm aware of, is with the extraordinarily clumsy use of CSS selectors in the template content. (see: https://blog.teamtreehouse.com/creating-reusable-markup-with-the-html-template-element)

Wouldn't it make so much more sense, now Template Literals are in every major browser, to add support within the <template> API for expressions? e.g

<template id="test-template">
    hello ${where}
</template>

const tmpl = document.getElementById('test-template');

// where "MAGIC" is some means of supplying data as json 
document.body.appendChild(tmpl.content.cloneNode(true, MAGIC));

Web Components have the <slot> system, but that requires the adoption of a much larger tech. And, yes, there's always Mustache/Handlebars et al, but again that's adding to the JS payload. Yes we also use React, but upgrading everything to React isn't always possible.

Am I alone in trying to make this work? Anyone found a framework-free or framework-lite solution for this?

DEV Community: Dave Cranwell

Scam protection using a Raspberry Pi to perform caller ID and risk-assess incoming calls

Landline users are lagging behind

Badcaller

Development (ongoing)

Template Literal expressions within the Template tag seem like a missed opportunity