Side Effects of Permit Next Button?

[whitedavidp]

Hi. While I haven't used this much, I am finding I have to do so more and more with the increase in 2-factor authentication for almost everything...

I am not 100% sure, but it seems to me that a call coming through due to Permit Next being enabled, ends up putting the next call's number onto the permitted list. Is this correct? I say this because the call shows as permitted in the call log (which seems as expected) and when I click on that number in the call log and press Change, I am shown the ability to Remove it from the Permitted List.

If this is indeed being added to the Permitted List, is this really necessary? I just assumed that this caused CA to allow the call to bypass screening and I am not sure that logically requires it be added to the Permitted List - where I then have to remove it later (perhaps).

Thanks. And thanks for suggesting any code changes that might permit this to NOT happen.

[rfbarraza]

Hi,

You are correct. The concept of "Permit Next" means that the next call will be automatically added to the Permit list. I suspect this exists for people (such as myself) who are overly cautious of what calls they let past screening. It's a quick and easy way to just let the next call through henceforth.

But this assumes that you know:

• for certain, the next call is one that needs to be permitted
• the caller will have a static number
• the caller will need to be permitted again in the future

E.g.) I called a new doctor's office and was somehow disconnected. The office clerk asked for my information in the event of a disconnect, so I have some certainty that the next call will not need to be screened now and henceforth.

The 2FA example is an understandably frustrating workflow. 🫤

---

FWIW, I had a similar issue with spoofed numbers. At the peak of my filtering, I had a line that was receiving 20+ calls a day from locally spoofed numbers. Whereas you have many numbers added to your permitted list, I had many numbers added to my block list.

Eventually, I would have to clean up the blocked list. I would add a small note to each of these numbers I blocked, "spoofed", and every few weeks, look through this list of blocked numbers with the "spoofed" note. If I sorted this list of numbers, I would see patterns emerge, which I could then translate to regular expressions.

It's a frustrating workaround, but it could be effective in the interim, especially since many companies use similar 2FA providers and presumably you're using 2FA with the same sites/utilities repeatedly.

[whitedavidp]

Your ideas make me wonder about running a Sqlite query now and then to simply remove entries from the permitted list where the comment is "Next Caller Flag".

You are correct that adding to the permitted list makes sense IF the 3 factors you mention are true. But sadly, at least in my case, they are most often NOT. And on the rare occasions when they ARE, I could easily add them manually through the UI.

Best

[rfbarraza]

Admittedly, I tend to rely on manual sqlite queries for very rudimentary data analysis and cleanup. It's obnoxious but some of the CA boxes I've deployed for older relatives have hefty demands. 😅

[thess]

A bit OT -- Regarding 2FA. Of all the choices one has for the handling of 2FA today (YubiKey/NitroKey, SMS text, email or a desktop/phone App), receiving a voice phone call is at the bottom of the list and I've never had to revert to it.

@whitedavidp - I agree that the logging and handling of "Permit Next Call" could be tweaked a bit. One of these days, I will get around to re-visiting call logging and screening, etc. as has been discussed here.

[whitedavidp]

As always, thanks!

I agree that voice call for 2FA is lame, lame, lame. But I actually have situations where I have no choice. Grrr. But I also have had non-2FA situations which require I use the permit next.

Right now, after a brief look at the code in app.py and inside of the screening package, I am not seeing where permit next is actually causing a write to the database's whitelist table. I might be missing it. Certainly, it DOES go to the Callog table and has an action = Permitted and all that seems logical to me. Maybe it is NOT really added to the whitelist table at all and clicking on the number, seeing a prompt to remove from Permitted List is just a red herring?

I need at least one other set of eyes on this. It might be related to my bug files #65

[rfbarraza]

If you look inside messaging/voicemail.py:145, you'll see a call to whitelist.add_caller.

This is how the functionality works on the backend. IIRC, there are two mechanisms for recording the state of Permit Next Call.

• a touched Permit file + the NextCall object (found in screening)
• the whitelist record in the DB

Together, the app can logic through logging and adjusting the UI to allow the user to permit the next call OR to allow a caller to permit their subsequent calls.

[roycewilliams]

Chiming in on call-based MFA -- I don't have to use it much these days, but for some of the folks I use Call Attendant to protect, it's the option that they can understand and use the best.

[whitedavidp]

Thanks for the code reference. I think it makes sense for a zero-touch during messaging to add a caller to permitted - it creates a mechanism by which the follow-up call specifically from that number will be allowed and there really isn't any other current place to persist that decision. One MIGHT say (as I think I once did) that pressing 0 should flip the Permit Next Call semaphore. But I know think that is not correct as it could allow another call, from another number, to slip in.

But I am still wondering only about the Permit Next Call mechanism causing my confusion. It could be that the number is NOT actually being added to the database's whitelist table. But the UI, because it "knows" the call was "Permitted" THINKS it IS in the whitelist and then shows a remove option when there really is nothing persisted yet to be removed. It could be that all of this is a red herring. I have to do a specific test of this and check the database's whitelist table before/after the Permit Next Call to be sure.

Best...

[whitedavidp]

Ok, all of this is a red herring. I just performed a test and, even though the Change UI for the number suggests that the number from a Permit Next Call is indeed in the database's whitelist table, it is NOT! This is consistent with what I see/do not see in the code as well. So this is just another manifestation of the bug I reported in #65 caused by the Change UI being driven from the call log Action column rather than the actual presence/absence of a row in the whitelist or blacklist tables. I should have suspected this given that I filed #65 but I just spaced-out, I guess.