as it means I need to actively work to get rid of it, by overlay or source code patch. This is why I say it leaves a taste, as this is an opt-out and leaves the work with me if I do not want this. It is not a drama nor a controversy, just opt-out strategy, which I dislike.
Conversation
No source code patch is needed. It is a fallback that's not used in practice so it's unclear why you consider it relevant enough to even have a discussion about it. Incredibly hard to understand why it leaves a bad taste. What do you think the AOSP fallback should be instead?
1
What should the default captive portal URLs be instead? GrapheneOS leaves those with the same values. This is explained in grapheneos.org/faq#default-co. Data is not sent there. It makes an empty HTTP(S) GET request to check if internet access works and trigger captive portals.
1
Neither of these is a proprietary service. DNS is an open standard. The connectivity check URLs are an open standard: empty HTTP and HTTPS GET requests with an empty 204 response from the server. Go ahead and use connectivitycheck.grapheneos.org/generate_204 instead. It won't give you more privacy.
1
Would you feel better if AOSP used an android.com URL for the default? What difference does it make? What do you think AOSP should use as the default? You say it leaves a bad taste, but you don't provide an alternative, and you are free to change it without building.
1
For me privacy is increased, if less information about me can be put together (in which google is quite skilled). Hence leaving my IP on each network change with them. I would prefer an option in the settings to change that URL. And I would prefer not to have the fallback...
2
... set in AOSP. (take some AOSP 9 code and grep the captive portal URL. It is not only in the options XMLs). The bad taste is about why it was designed this way. To make the lazy ones not use opt-out (creating an overlay)? I can't tell, but it does not feel correct.
1
> take some AOSP 9 code and grep the captive portal URL. It is not only in the options XMLs
It can be changed via either the resource or runtime setting. It does not need to be changed elsewhere. You don't seem to understand how this kind of thing works in software...
1
> The bad taste is about why it was designed this way. To make the lazy ones not use opt-out (creating an overlay)? I can't tell, but it does not feel correct.
There you go trying to spread misinformation and create drama/concern out of nothing again. Really not a good look.
1
There are runtime configuration options along with resources that can be changed directly or with static or runtime overlays. It is all clearly documented too. Not sure why you are trying to make up some nonsense conspiracy theory. Again, not sure how else you expect it to be.
1
If you're confused by the fact that tests need to reference it and also use sample URLs for various purposes... maybe you shouldn't be making bad assumptions from a shallow look at things you clearly don't understand. Confirmation bias + ignorance is a hell of a thing.
Thank you for lecturing me Daniel. I think I understand why you get into troubles with so many people.
On last thing from my side: I distance myself from any conspiracy myth and of course would be happy to understand it as deep as you do... but we are not getting there.
1
Don't make false and misleading claims repeatedly and they won't need to be repeatedly refuted. You chose to jump into a conversation between other people and derail it with misinformation. Did not need you to jump in and make false claims that are going to mislead other people.
1
Show replies
As you can see from android.googlesource.com/platform/packa, there are no default DNS servers set in the standard configuration. Android does not use Google DNS by default. It uses the network-provided DNS servers. I expect that you won't repeat that falsehood again, or the other ones.