celzero
Allow / block per-app logging
Somtimes the amount of data in the firewall can be a bit of a distraction. It would be great if there was some mechanism to limit the data seen in firewall logs.
I can think of three alternatives. I'm sure there are more. Any (or all) would be a welcome addition to RDNS.
One possibility is to add an app setting that tells the log viewer to optionally not display this app's log entries. The log viewer can then have its own correponding option to filter out these apps from the visible log entries.
A second way would be to have an app setting to turn off logging for an app.
If either of these app settings mentioned above are implemented, they should also be filterable in the app list.
A third alternative is to have an option in the log viewer and app list that allows for the deletion of an individual app's log entries.
I am partial to the first option. It keeps all log data available if needed while at the same time allows an app's log entries to be excluded from showing in the log viewer.
Thanks
The log viewer can then have its own correponding option to filter out these apps from the visible log entries.
The current network logs screen is meant to be a real-time log of connections. It has search by IP, app name, and domain name functionality already to filter things up. Related #98 / #53
A third alternative is to have an option in the log viewer and app list that allows for the deletion of an individual app's log entries.
This option has been already present since v053k (July 2022): A per-app log screen which groups entries by IPs and lets users delete logs specific to the app. Go to Apps, then tap on any app from the long list, and it should show you a screen with app specific logs.
A second way would be to have an app setting to turn off logging for an app.
This is something we could implement quite quickly. Let's see (:
This option has been already present since
v053k(July 2022): A per-app log screen which groups entries by IPs and lets users delete logs specific to the app. Go toApps, then tap on any app from the long list, and it should show you a screen with app specific logs.
I never noticed the trash can on that screen. Thanks for pointing it out. While I was in there looking at the per-app log, I also noticed that the per-app log screen has much less info displayed than the firewall log. The useful info missing include request status, date time and protocol. I guess this is because IPs are being grouped together. Is there a reason they being grouped? As it Is, the user can't determine what actually happened to the requests for those grouped IPs. Maybe the individual log entries similar to the firewall log would be more informative/helpfull to the user.
This is something we could implement quite quickly. Let's see (:
This would be great for those apps the user has finalized their firewall rules and no longer needs to do logging. Thanks.
I guess this is because IPs are being grouped together. Is there a reason they being grouped? Maybe the individual log entries similar to the firewall log would be more informative/helpfull to the user.
Ungrouped, chronological per-app logs are already viewable from the Network Log UI; type the app name in the search bar...
Connections are grouped by IP in the Apps UI because it is meant to present a "report card" of an app's network activity. We don't intend to show chronological logs there. In the next version, we will also show logs grouped by domain names (in addition to IP addresses), which might come in more handy as folks typically find it easier to reason about block/allow rules for domain names than IPs.
Ungrouped, chronological per-app logs are already viewable from the Network Log UI; type the app name in the search bar...
Yes, but it would be nice if the user can see them without the additional steps involved to get there. If its not too much work maybe a choice under the app display to go directly to the Network Log for that app could be considered.
Connections are grouped by IP in the Apps UI because it is meant to present a "report card" of an app's network activity.
Having such a report card is a great feature to see the network activity for an app. But listing all IPs or domains that ere attempted to be accessed does not show a full picture of an apps activity. It might be better to also show some information about how many of these were actually successful and not blocked for some reason. Maybe something as simple as changing the number of requests column to be "x/y", where x is the total number of successful requests and y is the total number of attempted requests. (Its just such a situation that a user seeing blocked IPs or domains, may want to determine why they were blocked and want to go directly to the apps network log as described above.)
Yes, but it would be nice if the user can see them without the additional steps involved to get there.
Not straight-forward but, tap on any app on the stats screen, and you should see chronological logs for that app only.
If its not too much work maybe a choice under the app display to go directly to the Network Log for that app could be considered.
Do-able, but aren't there too many buttons already ;) we'll see if we can fit this somewhere on that screen.
Maybe something as simple as changing the number of requests column to be "x/y", where x is the total number of successful requests and y is the total number of attempted requests.
This is planned (: Hopefully it makes it in one of the next few releases.
May I add a very similar request here? You guys keep talking about the same issues I would have like to raise except I am wondering why the Logs => DNS do not show / allow any connection to the app which triggered this connection. I'm very much interested to see the same connections we have between apps and their connection logs extended to the DNS logs.
Logs => DNS do not show / allow any connection to the app which triggered this connection
Because those are DNS logs?
For app <-> domain mapping, check Network logs. Rethink must be running in DNS + Firewall mode and Private DNS must have been disabled for the app <-> domain mappings to work.
For app <-> domain mapping, check Network logs. Rethink must be running in DNS + Firewall mode and Private DNS must have been disabled for the app <-> domain mappings to work.
This I already have working, thanks.
Logs => DNS do not show / allow any connection to the app which triggered this connection
Because those are DNS logs?
Maybe I am having a blonde moment but wouldn't it be helpful to see which app tries to access which IPs/domains and gets blocked by which ad blocker list? Do I not need to see the link between an app and its blocked requests to figure this out or am I missing some obvious pooint here?
Maybe I am having a blonde moment but wouldn't it be helpful to see which app tries to access which IPs/domains
Network Logs is the closest right now to what you want. This information isn't yet shown in DNS Logs. The reason is, when the app is in DNS-only mode, the DNS Logs UI is the only logs UI that's shown to the user (and there's no possibility of doing app <-> domain mapping in DNS-only mode as network flows don't go through Rethink for it to make the app <-> domain association).
and gets blocked by which ad blocker list?
All DNS requests coming from apps are forwarded to Rethink by Android (there's no way to change this behaviour). As far as Rethink is concerned, it knows nothing about which DNS request was sent by which app.
However, if setup in DNS + Firewall mode, Rethink does know which IP address an app connects to. The way Rethink maps apps to domains is actually via IPs, ie apps <-> IP addresses <-> domains. This heuristic breaks in cases where the same range of IP addresses (Google-owned IPs for example) are assigned to multiple domains (all Google-owned domains).
The mapping of apps <-> IP addresses <-> domains also means that without "IP addresses" (as happens when a domain is blocked, no IPs are assigned to it by the resolver, in this case Rethink) there's no way to associate an app with a domain name. So, this heuristic also cannot tell just which app sent the DNS query which was blocked by some blocklist.
Do I not need to see the link between an app and its blocked requests to figure this out or am I missing some obvious pooint here?
All that said, Rethink does have an internal "translation layer" that can map an app to a particular DNS query with precision, but as you might guess, it is a battery drainer, and hence not enabled by default. This setting is named Advanced DNS filtering in v054+. Once you enable it, Network Logs will point out connections blocked by a given blocklist... but there's no way to view all connections and apps blocked by grouped by particular blocklists, right now... other than taking a backup of the underlying datasase (see Configure -> Settings -> Backup & Restore) and querying it via sqlite3 clients.
I hope my explanation was clear rather than confuse matters further (:
Your explanations were very helpful, although I had to read them twice at least to wrap my head around it.
Just to add some more clarification on my part, when I said:
wouldn't it be helpful to see which app tries to access which IPs/domains and gets blocked by which ad blocker list?
I did not mean to stress "which ad blocker list" - what I am rather interested in is to see a general overview of apps to figure out which ones do extensive tracking and which ones do load extensive ads and try to find alternatives for them. I hope this clarifies my interest in these little details.
So maybe down the road there could be some stats shown per app? i.e. app 01 has had 95% of its DNS requests blocked with 90% ad blocking lists and 10% tracking lists? Although I understood this is difficult and not generally of interest to other users, I simply wanted to explain my interest in these stats.
Gotcha (though, as mentioned above, per-app DNS stats app 01 has had 95% of its DNS requests blocked with 90% ad blocking lists and 10% tracking lists are not possible unless Advanced DNS filtering is enabled)
More stats make sense, and we intend to show them in one of the upcoming releases:
- #98
- #42
A user writes,
I have a small request. Some apps like microsoft launcher and many others flood the connection log with thousands of entries which makes finding relevant ones hard. Can you maybe implement a way to hide certain entries / apps from logs? Like "dont show any of these 10000 entries called vortex.microsoft.com".
If i understood that correctly something like the Design of the Adguard App would be great. There you can see what app contacted which ip/url and to what company it belongs (akamai, google, some tracking comany, etc.)
Having a more Clearer user interface that is easier to navigate, understand and where you get more information would be a great benefit for this app. If you compare this app with Adguard's app (which I use alternately to Rethinkdns) then It's easier for me to make settings, see which app contacts which service, and also see directly which companies are contacted most frequently. With the current design, you can click on a app, but it wont show what requests got blocked and why
You also can directly go to company by clicking on it, see the logs and what app contacted it.
I hope that this can be added in the future
There you can see what app contacted which ip/url and to what company it belongs (akamai, google, some tracking comany, etc.)
Planned, see: #590
With the current design, you can click on a app, but it wont show what requests got blocked and why
Yeah, the UI can be better. Not sure when we get around to making such changes, though.
Hi, is there a way to see what App made what DNS request? Many blocked requests are only visible in the DNS tab. But there is no information on what App sent what request.
This would be very helpful to determine what app is sending which requests and how often, etc.
Thanks
Hi, is there a way to see what App made what DNS request? Many blocked requests are only visible in the DNS tab. But there is no information on what App sent what request.
Not possible as Android sends DNS requests on behalf of ALL apps. That is, the originator of a DNS request cannot be known unless there's a corresponding outgoing network (TCP/UDP) connection. But as you note, there are no such outgoing connections for when domains are blocked (as there are no IPs that the app can connect to).
How does Android keep track of the relationship between the App that asked for a dns resolution and the reply ? Somehow it needs to make sure the proper answer gets back to the original app that requested it.
DNS: [app] <---> [android] <--(tun)--> [rethink]
TCP/UDP: [app] <--(tun)--> [rethink]