zlacker

When viewing the "Show log" screen in Netguard, under the top right, three dot menu there are checkbox options for "Show names" and "Show organization". Netguard sends requests to ipinfo.io to get information about IP addresses. These requests to ipinfo.io do not show up in the Netguard log.

There is no cause for concern necessarily. These are design choices, nothing more.

Users have no idea what happens to the data that leaves their computers. To quote from another story currently on the HN front page: "It's incredibly easy to give information away. But once that data is out there, it's nearly impossible to take back." >>44689059

Promises made by developers are reassuring to some, but rarely if ever legally enforceable in the event something goes wrong, and the harm already caused may be beyond redress. As a proactive measure users can, among other things, seek to minimise the amount of data they send. For example, some users might want the _option_ to stop their phones from constantly trying to ping or connect to remote servers _without any explicit user intent to do so_. Maybe they do not want their phone to act like a beacon to someone else's remote server.

The point of the comment is that sometimes there are remote connections being made to servers chosen by developers that are assumed to be OK with all users, e.g., connections to Graphene servers, IPinfo servers, or myriad other examples. Meanwhile there is no option for the user to disable this behaviour. There may be some users who prefer _zero_ remote connections except the ones they themselves choose to initiate or enable. The possibility of such users often seems to be overlooked or deliberately ignored.

Like Firefox constantly sending HTTP requests to remote servers to check for "connectivity". Even when the user is not trying to connect to any server. The requests are sent in the clear. This is not optional behaviour.

>>1vuio0+(OP)
Traditionally Windows allowed applications to be either minimized or closed. (AFAIK it still does.) These options might be displayed as buttons in the upper right corner of the window in which the application is running, for example, [-] and [x], respectively. When an application is minimized, it may continue to run in the background. When an application is closed, it does not run in the background.

https://www.zdnet.com/article/3-ways-to-stop-android-apps-ru...

https://www.androidpolice.com/how-to-close-android-apps/

https://www.androidauthority.com/how-to-close-apps-on-androi...

An exception would be Windows applications that can be "run as a service". This is generally not default behaviour for user-installed Windows applications. It generally requires administrative privileges and manual configuration for each application

https://en.wikipedia.org/wiki/Windows_service

https://stackoverflow.com/questions/3582108/create-windows-s...

https://www.windowscentral.com/how-start-and-stop-services-w...

Unlike Windows, Android does not present an option to close an application while the application is in view. Android applications can be "swiped off" the screen, but they are not closed. By default, _all_ Android applications continue to run in the background. Closing an application in Android requires using a separate app. For example, opening the "Settings" app, then finding the app to be closed in a list of apps, then "stopping" the app by selecting "Force stop" as describeed in the articles above. If the Android user wants to close a number of applications running in the background simultaneously, she is out of luck. They can only be closed serially, one after the other. She must find each of them via the Settings app and Force stop each one, individually. This is extremely tedious and slow and, as one would expect, results in almost all Android users allowing applications to run in the background. The tedium mandated by this design could be purely coincidental.