Android: "System-wide connection/tracker blocking" allows feature not to be an OS feature

alohapersona commented 2 months ago

In the feature table "System-wide connection/tracker blocking" has two realizations, "VPN app" and "DNS setting", that refer to features that may or may not be provided through or as part of the OS itself.

DNS setting for most OS requires the user to find and insert a third-party (or their own) DNS server that would block the trackers for them. In that case, the feature cannot be considered part of the OS. In contrast, the OS vendor could provide their own, tracker-blocking DNS server and make it an easy toggle to enable using that (without having to enter a server address manually), which I then would consider an OS feature. Also one could run a tracker-blocking DNS server on the phone itself, which, if part of the OS, would also be an OS feature.
VPN apps for blocking trackers can be shipped with the OS or easily provided by the OS vendor (in which case they are an OS feature) or installed from third-parties (in which case they are not).

The way the "System-wide connection/tracker blocking" row works right now, it's pretty useless, as it would be really hard to not be considered supporting this feature (would require removing features from AOSP). It's thus not very helpful for comparison. I would suggest to either entirely remove it, or restrict to functionality that's directly provided by the OS that would block trackers (i.e. not require configuring a server in the settings manually or installing a third-party app).

eylenburg commented 1 month ago

Yes, you've got a point, it might be better to just delete this row as it doesn't really tell you anything valuable.

matchboxbananasynergy commented 1 month ago

I don't think that it would be horrible for this line to go, but assuming that someone reading through the table doesn't realize that you can use something like a VPN app or particular DNS servers for this purpose, it's useful for them to be able to know that.

A few OSes on the list advertise this as a feature and it's not really explained to people how you can replicate it without needing that OS integration, so they might wrongly think that this cannot be done without that specific thing (such as what iode or DivestOS does).

alohapersona commented 1 month ago

@matchboxbananasynergy I understand your point, but to a person not knowing, "Private DNS setting, or via VPN app" barely explains how to do it either. And if one searches "How to block trackers on LineageOS" there's probably some reasonable results even without the table giving hints of how it could be done. I would say it's the responsibility of every OS to make sure there is enough and easily found documentation on how to do things like this with their OS.

matchboxbananasynergy commented 1 month ago

I would say it's the responsibility of every OS to make sure there is enough and easily found documentation on how to do things like this with their OS.

Sure, and I would say that is already the case for most of the OSes being showcased in the table. But if someone's starting point is the table, and assuming they have no prior knowledge of these systems, the row might be a good starting point.

I don't feel particularly strongly about this, but I think it's at least worth considering.

thestinger commented 1 month ago

It's currently accurately comparing a difference between the operating systems. It simply shouldn't portray not having legacy hosts-file-based blocking as being superior, and there are disadvantages to censoring the internet by default so it's not strictly beneficial. Blocking at a DNS level is also quite difficult for users to debug unless they get notifications about it from an app doing it locally. The row serves a useful purpose of showing which operating systems add more options for this, even if those options are questionable such as a hosts file. It's genuinely useful to show they can all do it including via a dual purpose VPN app with both local filtering and actual VPN support, of which there are now several options.

GrapheneOS update servers have been included on the blocklists used by Quad9 DNS before, because they consume sketchy info as the source for their data and blindly trust it. This puts people in a position to censor the internet stealthily and then claim it was an accident or simply quietly remove it if it goes wrong. Quad9 simply said they're not responsible for making the data, made an exception for GrapheneOS but didn't change any policies/processes due to it. They wouldn't say which source of data said to block it so we couldn't find the root cause and either get it resolved there or document that they had done it and wouldn't remove it. If we used Quad9 DNS by default, we would have been at their mercy to fix it or most users wouldn't be able to get updates without undoing that default. Shows how wrong this can go.

matchboxbananasynergy commented 1 month ago

I hadn't fully considered everything mentioned in @thestinger's post above. I think I'm leaning more towards leaving the row as is now.

alohapersona commented 1 month ago

@eylenburg, sorry for bringing the crusade to your page. I guess every comparison must be designed to be effectively a marketing piece for a specific OS or else their developers and community are immediately going to go after you. I'm closing and unsubscribing here and all the other feedback I had, it's entirely up to you what you do with it and please feel free to ignore it if you don't want to waste your time in discussions like these.

matchboxbananasynergy commented 1 month ago

I don't understand this reaction. An issue was raised for this to be discussed. How can changes be made if they're not discussed best? Unless it's something obvious and trivial that has no nuance, which none of the issues raised by the user above were...

thestinger commented 1 month ago

I'm unsure how a row showing that GrapheneOS has the standard functionality for this is biased towards GrapheneOS. The row is useful because it shows which operating systems like DivestOS provide something beyond the standard functionality. I simply don't think it makes sense to portray providing that as inherently better.

eylenburg commented 1 month ago

I think I'll just leave it in as that is the least amount of work and just because AOSP already supports it doesn't mean it can't still be in the table.

GrapheneOS update servers have been included on the blocklists used by Quad9 DNS before, because they consume sketchy info as the source for their data and blindly trust it. This puts people in a position to censor the internet stealthily and then claim it was an accident or simply quietly remove it if it goes wrong. (...) If we used Quad9 DNS by default, we would have been at their mercy to fix it or most users wouldn't be able to get updates without undoing that default. Shows how wrong this can go.

This is a very interesting argument against having blocking on by default which I wasn't aware of.

eylenburg / eylenburg.github.io

Android: "System-wide connection/tracker blocking" allows feature not to be an OS feature #69