add public JSON API like for https://reports.exodus-privacy.eu.org/api/trackers

[eighthave]

@uniqx @jspricke and I are working on directly integrating ETIP into our scanning workflow. That includes downloading the JSON from Exodus. The fdroid scanner needs to use data that is only in ETIP, but ETIP currently requires an API key to read the data: https://etip.exodus-privacy.eu.org/api/trackers/

Would it be possible to have that API with the same access control setup as https://reports.exodus-privacy.eu.org/api/trackers ?
The exodus data can be downloaded without an API key. Then we can ship fdroid scanner so that it automatically downloads and uses the data from ETIP, no matter who installed it, without having to setup API Keys. That is directly useful for our issuebot setup, which runs in GitLab CI, but also for anyone who wants to scan APK collections, like https://mobilsicher.de/

You can follow our work on this in:

• Rewrite ETIP as a GitHub repository #133
• https://gitlab.com/fdroid/fdroidserver/-/issues/732
• https://gitlab.com/fdroid/fdroidserver/-/issues/1008

[pnu-s]

Setting the technical aspects aside, I just want to state that the data in ETIP is potentially unverified.

Before a tracker is sent to exodus, it has not been reviewed and therefore you have a high risk of false positives.
That does not mean we cannot open the API endpoint, but I think that's an important point to consider.

Out of curiosity, why cannot you use the exodus tracker endpoint? Is it because the process of moving trackers from ETIP to exodus is too slow? If that's the case, that's maybe where we need to focus our work instead of you using directly ETIP data.

My 2 cts :)

[eighthave]

Thanks, we're aware of that. We use this in a place where the goal is to provide information to human app reviewers, so they are already used to unverifed information. The core idea is to provide leads to human reviewers, so we would rather have false positives than false negatives. Then this would also help the ETIP review process, since fdroiddata maintainers could also adjust information in ETIP if it is generating results that are not helpful.

[eighthave]

Out of curiosity, why cannot you use the exodus tracker endpoint? Is it because the process of moving trackers from ETIP to exodus is too slow? If that's the case, that's maybe where we need to focus our work instead of you using directly ETIP data.

There are a number of fdroiddata contributors who maintain signature lists, so working out of ETIP makes sense here because an fdroiddata contributor can edit something in ETIP, then immediately see the results.

[pnu-s]

@eighthave Just deployed the changes, I'll let you confirm whether this is working as you expected :)

[eighthave]

Great, thanks! curl https://etip.exodus-privacy.eu.org/api/trackers/ works for me!

[eighthave]

It is working, thanks