The wikipedia app has the tracking antifeature since forever. It has a opt-in tracking functionality and an opt-out crash reporting. What I couldn’t figure out so far is if the crash reporting, even if enabled gives the user a chance to review and not upload the report? If that’s the case I’d argue that we don’t need the antifeature.
Anyone knows anythig about this? Someone wants to investigate?
It could be a false positive, because all TrackerControl does, I believe, is monitoring connections to sites known to be recipients of tracking data, but upload.wikimedia.org is probably home to a lot of completely innocuous stuff as well. Still, it’s not wikipedia.org, and it made those connections as soon as I opened the app, without doing anything special, so I’m not entirely sure why it’d need to contact upload.wikimedia.org. And then if I do use the app a bit, like by just going into the settings or scrolling the home page, the number of packets shown increases.
I’ll take that as a clue to definitely keep the tracking antifeature for now.
It would be nice to either dig into the traffic of what’s it sending exactly or talk to wikipedia devs about it. mitmproxy is your friend if anyone wants to try.
apps that just happen to update without bothering you about it
Do note that given the Android security features an app can’t just update itself from outside the F-Droid.org anyway (except apps that build reproducibly but those are rare now)