It does this check when you connect to a new network and it repeats every so often to make sure the connection still works. It's how Android notifies you if there's a network connection but no internet access.
It's not a browser making the request so there's not much information in these requests. It's just a GET request with an unused result. It only checks to see if it succeeds. Every Android device does this, so it barely leaks any information. If it was changed to a CopperheadOS-specific URL, it would actually be leaking more information to networks.
I don't think there are other connections to Google in the base system but that doesn't extend to the user-facing apps like Chromium. I know for a fact that it doesn't make any other connections in normal usage, but there are a lot of edge cases.
We could make the internet access checks optional, but what about update checks? Those are leaking strictly more information (a phone connecting to builds.copperhead.co runs CopperheadOS and that can be seen without access to the HTTPS data) and it tells us which device is being used since it has to ask for the available updates. We don't really know how many people use CopperheadOS, but it would be possible to make a solid estimate from the update checks. Most people won't change the default of 1 check per day, so the number of checks per day in total is the approximate number of users, and the server has the IPs they connected from. It doesn't log anything itself but CloudFlare could.
F-Droid also does updates checks itself, so any F-Droid repositories that are enabled end up with similar information.
I am not really sure how this could be improved. You can use Tor... but in some ways that makes the situation worse.
An option to disable the internet access checks is possible, but I don't know what it would really accomplish. I don't want to make changes without a clear threat model in mind. So I'm not inclined to touch stuff like the internet connectivity check unless there are clear benefits rather than it just feeling right to people.
Those are all excellent points. Where there are tradeoffs, perhaps you could put some settings in your security slider UI.
An optional software firewall that requires outgoing connections to be whitelisted would be great for my purposes, but everyone knows how painful those can be.
Regarding connections, I've come across the following potential issues; I haven't looked into them but they give me the impression that locking down Android's network activity is too complex even for technical users, and that only a carefully secured OS will solve the problem (a big reason I've looked forward to Copperhead):
* Some connections are made during bootup so an effective firewall somehow has to load early, or at least first in the network stack.
* The address of the DNS server, Google's, is hard-coded in an in-kernel DNS resolver. Among other issues, it makes it hard to choose a different DNS server or to identify the application doing the lookup.
* Some other kernel connection activity is hard to stop even with a firewall [1][2]
> I don't want to make changes without a clear threat model in mind.
Confidentiality is part of security, and exploits of confidentiality by businesses are almost certainly the most common security exploits.
People tend to overlook them because usually they are technically legal and currently they are a sort of technological norm -- though remember that lead and asbestos were once norms. Certainly users should have the option; they should control their data.
It's not a browser making the request so there's not much information in these requests. It's just a GET request with an unused result. It only checks to see if it succeeds. Every Android device does this, so it barely leaks any information. If it was changed to a CopperheadOS-specific URL, it would actually be leaking more information to networks.
I don't think there are other connections to Google in the base system but that doesn't extend to the user-facing apps like Chromium. I know for a fact that it doesn't make any other connections in normal usage, but there are a lot of edge cases.
We could make the internet access checks optional, but what about update checks? Those are leaking strictly more information (a phone connecting to builds.copperhead.co runs CopperheadOS and that can be seen without access to the HTTPS data) and it tells us which device is being used since it has to ask for the available updates. We don't really know how many people use CopperheadOS, but it would be possible to make a solid estimate from the update checks. Most people won't change the default of 1 check per day, so the number of checks per day in total is the approximate number of users, and the server has the IPs they connected from. It doesn't log anything itself but CloudFlare could.
F-Droid also does updates checks itself, so any F-Droid repositories that are enabled end up with similar information.
I am not really sure how this could be improved. You can use Tor... but in some ways that makes the situation worse.
An option to disable the internet access checks is possible, but I don't know what it would really accomplish. I don't want to make changes without a clear threat model in mind. So I'm not inclined to touch stuff like the internet connectivity check unless there are clear benefits rather than it just feeling right to people.