Quickly ID "non blocked requests" to "blacklisted recipients"?

How does one identify “non blocked requests” to “blacklisted recipients” quickly without having to manually scroll through the “stream” tab to find the tracker with a black “status” dot? I would like to see if my DNS filter caught these buggers that got through.

The more I use iodeOS the more impressed I become. Nice work @Antoine ! I think I understand why its not 100% open source but am looking forward to when that changes. It must change for the FOSS community to fully embrase.

For now the only ‘quick’ way to see the non blocked requests to blacklisted recipients is to go to the report tab, stack apps and check from there transmitted requests to blacklisted recipients

1 Like

Okay I have now found the requests that went through, thanks. Is there any reason why these requests got through when they are blacklisted?

Edit - also I see a total of 19 non blocked requests but only 2 (not 3) blacklisted recipients, any ideas?

If you disable the protection, requests to blacklisted recipients will be transmitted and counted as ‘non blocked requests to blacklisted recipients’.

About the 2 blacklisted recipients, are you sure you looked at the same timestep in the home page as well as the report?

Yes, both were set to “All Time”. I believe I found the third blacklisted recipient. The third recipient was an app in the Shelter Work Profile. I could only view it from the iode app in that profile but it appears to be counted in both iode apps, the regular and work profile iode apps.

Another item of interest is that it appears to have sent “3Ko” of data but shows “0” “Transmitted requests”. How did 3Ko of data get sent but “0” “Transmitted requests” show? Good news is my DNS caught this👍

Ahhh… This must have happened when I temporarily disabled the iode app when tinkering with it. Thank you, I am impressed!

An excellent feature would be to have a filter on the “Stream” tab to sort/filter by different “Status” colors (tiel, gray, black) as to find the entries below quickly.

1 Like

Regarding the data sent, this may be due to a DNS request made at least the day before and the IP address was kept in memory by the app. The app kept transmitting data to the IP address if the blocker was deactivated.

1 Like