▲ | 1vuio0pswjnm7 18 hours ago | |||||||
"Great to have Google kicked off the phone" Except the default browser is Chromium with some changes This reminds me of a recent HN comment I saw that suggested using Firefox was "kicking Google where it hurts" or something like that Like Firefox, this project depends on Google. For the hardware, the web browser and who knows what else It even offers a sandboxed Google Play Store It tries to copy Google paternalism It swaps a Google mothership for a Graphene mothership What if the computer owner does not want a mothership Can connections to Graphene servers be blocked, i.e., are these connections optional or mandatory Even Netguard which works on any hardware and does not require root makes unnecessary connections to ipinfo.io servers effectively giving them a list of almost every domain the user's phone trying to access If the concern is apps that only require internet connection for ads, Netguard solves that problem without root Most apps but not all will try to connect to the internet at some point, even if you never use them The user-hostile design of Android is that apps keep running in the background after they are "closed" (There are crude apps one can use to automate manually killing each process with "Force stop" but no one uses them. This doesn't prevent apps from trying to access the internet on some preset schedule) Netguard will show when apps try to connect and block the connections. It provides DNS logs and PCAPs. One does not even need Netguard to see this subversive activity Try this at home Enable IP forwarding on a computer you can control, i.e., one that is running an OS you can compile yourself such as Linux or BSD Put the phone on the same network as this computer Set the phone's gateway address to the address of the computer Run tcpdump on the computer and filter for the phone's IP address | ||||||||
▲ | reincoder 9 hours ago | parent | next [-] | |||||||
I work for IPinfo. What is the context mentioning us here? I'm unsure if graphene uses our data. We process trillions of requests at the moment. I have no clue which services or software even use our data, let alone identifying individual IP addresses. Is making a connection to our API a cause for concern? If that is the case, we welcome OSS projects to user our local IP databases, which includes our free IPinfo Lite database that we primarily designed for firewall and privacy applications. | ||||||||
| ||||||||
▲ | 1vuio0pswjnm7 3 hours ago | parent | prev [-] | |||||||
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." https://news.ycombinator.com/item?id=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. |