The API /num doesn't require authorization.

[aj3423]

Hi,
I'm trying to integrate the PhoneBlock API to my app SpamBlocker, I found that the API for querying number /num/{num} doesn't seem to require any authorization. It can be queried like:

curl "https://phoneblock.net/phoneblock/api/num/0016465535819"

Is this by intention? Maybe the FRITZ!Box doesn't support authorization parameters? Or, is this a bug?

If I integrate this API to my app, I will inform users that it's for Gemany only, but I can't prevent users from other countries trying this API, which would be a waste of resources(CPU and bandwidth). If it requires an Authorization, I guess users from other countries won't spend time trying.

How do you think? Thanks.

[aj3423]

And I have some questions about reporting numbers:

1. Unlike other apps that people report numbers manually, that they would've answered the call first and they know whether it's G_FRAUD, F_GAMBLE, etc. But the SpamBlocker app rejects calls automatically, it wouldn't know the category. The API requires an attribute "rating": "...", will it be a problem if it's filled with empty strings or any other values than G_FRAUD, F_GAMBLE, etc?
2. The api /rate requires the authorization, can I use a fixed authorization for all users? Otherwise they will have to fill their API keys. I think it's more likely for users to report numbers without such extra work.
   (The fixed authorization will be only used in reporting numbers, they will still need to fill their API keys for querying numbers)
3. Should it only report domestic numbers start with 0 or 00?
   For users live in Germany, if a number is 12345, should I report it as 012345 or 0012345 or just 12345?

Thanks.

[haumacher]

Many questions let me try to answer...

Authorization for the Lookup-API

From today's perspective, its a bug that the API does not require authorization and I want to change this in the future. Initially, the API did require authorization and users started to use the regular web page search instead (which provides almost the same information but requires much more resources to deliver). Instead of making it harder to use the web page search from automated tools, I decided to remove authorization from the API (which was the far simpler solution).

However, If you integrate the lookup into the SpamBlocker app, I would recommend to make users provide PhoneBlock login credentials and transmit them to the "num" API in the way the other APIs require authorization. This makes the app independent from future changes to the API.

International numbers

I have many requests to make internationalize PhoneBlock. Currently, the blocklist is tailored towards devices connected to the German telefony network, because German numbers are added with only the local prefix 0.... However the API fully understands international numbers (either with the plus prefix +49..., or the double-zero prefix 0049... Therefore, I would suggest to always use the plus format +49... for reporting numbers.

Therefore, it is fine to lookup numbers of any country and also report spam numbers for arbitrary countries. To make PhoneBlock aware of the "target market" of a number, it would be useful to extend the voting API with information from which country the SPAM report originated. Let's make a separate issue for this.

The rating for a number (PING, ADVERTISING,...)

If you want to just vote a number to be SPAM, you can use the rating "B_MISSED" - this does not further categorize the number but just votes for SPAM. However, I do not fully understand the point. If SpamBlocker already knows that a number is SPAM, it blocks the call. This is OK and in that case, I really appreciate, if the app then sends a vote with rating "B_MISSED" to count such call and to keep the number alive in the database.

But the worst case is that the number is new (and there are many new numbers that occur every day) - then SpamBlocker cannot block the call. If the user then answers the call, it woud be very helpful, if the user then could easily report this new number as SPAM. And in that case it would be cool, if the user could select a rating from the list, or even give a comment for that number.

Authorization to the rate API

If the user installs his PhoneBlock-Account to the app once then there is overhead for the user for reporting numbers. I want to prevent spaming the database with fake ratings. Therefore, a single account for all users is not acceptable. A number can only safely identified as SPAM, if multiple users report the number independently. Therefore, PhoneBlock needs a chance to check the origin of the spam report. Maybe you could integrate the setup process of a PhoneBlock account right within the SpamBlocker app - this would create the best user experience.

[aj3423]

Thank you for the detailed reply.

If you integrate the lookup into the SpamBlocker app, I would recommend to make users provide PhoneBlock login credentials and transmit them to the "num" API in the way the other APIs require authorization.

Understand, the api template will contain the authorization information.

I would suggest to always use the plus format +49... for reporting numbers.

I'll report it with +49 prefix.

I do not fully understand the point. If SpamBlocker already knows that a number is SPAM

Please let me clarify how SB works and how the reporting logic will be implemented.
SB is desined for rejecting calls automatically, the call won't even start ringing and the user won't notice it. It blocks calls with offline filters, such as regex expression. For example, user can block numbers start with "+49123...", or local numbers that shorter than 6 digits, such as "12345", or block all non-contact numbers. Because it happens all automatically without user interference, there is no way for SB to know the spam category.
Those blocked calls will be logged in the local database, and will be scheduled to report to the API later, the reporting will happen automatically
The reason why there is a schedule buffer and it's not reported immediately is that, there can be repeated calls, those calls can be important rather than spams, they won't be reported if they repeat within that buffer. It also applies to the numbers that have been dialed back within the buffer.
Only the numbers blocked by these local rules will be reported, those numbers identified by your API will not be reported to other APIs. It won't leak numbers to the competitors.

But the worst case is that the number is new (and there are many new numbers that occur every day) - then SpamBlocker cannot block the call.

Because of the local rules, SB can actually block new numbers, this is what it's desined for, and these new numbers will be reported.

I want to prevent spaming the database with fake ratings. Therefore, a single account for all users is not acceptable.

I see your point, that's really important. I'll let user fill their authorization, and I'll try to make that process as simple as possible.

[haumacher]

Because of the local rules, SB can actually block new numbers...

For those reports, a rating of type B_MISSED would be the way to go.

Please let me clarify how SB works...

I understand this. But is the following use-case not also a valid one: On my business phone, I cannot have any rules that block unknown numbers. Nor can I afford to report callers that have not been answered for some time to some SPAM database. Instead, I've no choice of accepting all calls that are not explicitly marked as SPAM by some service - such as PhoneBlock. If I now accept such call from say +44xxx and find out that this is actually a new and yet unknown SPAM number, shouldn't I be able to explicitly report this number and add a classification that the caller tried to advertise (E_ADVERTISING) some questionable insurance?

[aj3423]

a rating of type B_MISSED would be the way to go.

I'll report all numbers with B_MISSED.

shouldn't I be able to explicitly report this number

Manually report, that's a good idea.
The tricky part is how to categorize it, because the number will be reported to multiple API endpoints, different endpoints may categorize it differently.
I'll need some time to think about it.

[haumacher]

I'm absolutely willing to add whatever API you like and/or adjust the available ratings to make such kind of reporting work.

Optionally entering a comment for a number would be also great. The reason behind this is the following: One great measurement for the number activity is the website traffic that the page for a number attracts. But to make search engines forward users to a page, the page must provide some unique content to get a good ranking. And the only way of producing such content for SPAM pages is making users to add comments for those numbers. cleverdialer.de has such app that produces such ratings and comments. PhoneBlock has not - that's why I desperately search for such an app you are creating.

[aj3423]

Optionally entering a comment for a number would be also great.

Unfortunately, I'll have to reject this feature. The main reason is that, everything in this app is designed for users only, from their perspective, the categorizing is enough.

[haumacher]

OK - however there are users out there that like telling about their frustration with SPAM callers - at least, if it is easy enough to do. And an optional text field is not in contrast to users wants - in my opinion. But anyway, it's OK for me.