Thoughts on AppVerifier alternatives

Overlay1404

With Privacy Guides starting their own database for verifying apps, two forks of AppVerifier have popped up.

One is Verified Apps for Android made by Privacy Guides, the other is AppVerifier BG.

I am wondering what people think about them and if anyone has switched from AppVerifier and started to use one of those options instead.

ClickClickDrone

Please note that these are just my few cents...

Firstly, I'd personally avoid any forks since they add another middleman that needs to be trusted. That is fine if the person behind it is known to be credible and transparent, like the original author, @soupslurpr. Though, IMHO, new forks like AppVerifierBG need to earn trust gradually over time, especially when it is from people with pseudonyms[1].

Secondly, the Privacy Guides fork seems to be for their own database only, so it may or may not fit all users.

[1] And that is not at all intended as an insult to folks who opt to do that, rather, it is more about it being a potential accountability & transparency smell, which warrants a small dose of carefulness.

DohnJoe

ClickClickDrone Firstly, I'd personally avoid any forks since they add another middleman that needs to be trusted.

Honestly, I fail to understand this statement in this context.
We are talking about open source software.
As you can read the code of AppVerifier (and you do not need to trust the dev team), you can read the code of Verified Apps for Android (and you do not need to trust the dev team).

SimpleApps is the perfect example why you should use the code as meter of trust for software, and not the dev team itself.

ClickClickDrone IMHO, new forks like AppVerifierBG need to earn trust gradually over time,

I would argue that if everyone switch trust on every single PR/commit (instead of trust in the dev submitting them), the codebase would be much more trustable and you would avoid more supply chain attacks.

ClickClickDrone

DohnJoe

Yes, that is right, assuming one actually thoroughly audits the app.

Which, unfortunately, is very uncommon, since it requires people who can actually read code, has time, and knows what to look for.
Not to mention that you have to do this on a continuous basis.

Thus it means that you still de-facto have to place trust in the developers, unless you really go out of your way.

DohnJoe

ClickClickDrone

I partly agree.
I guess we have overlapping areas in our reasonings :)
In a way, the trust built over time can come only if the code stay "clean".

I think that waiting for someone auditing the app, means just to switch trust to that someone, doesn't it?
If you are not going to read the code yourself you are simply trusting someone else to read it, which I think it's not very different than trusting the dev team.

The good thing about open source is that more than a single person can read and audit the code, so you might take the average opinion and trust that instead, which I agree would take time in the first place.

ClickClickDrone

DohnJoe If you are not going to read the code yourself you are simply trusting someone else to read it, which I think it's not very different than trusting the dev team.

That's the issue, few people reads it for the reasons I outlined above, which means, as you noted, that you de-facto just trust the developers.

DohnJoe The good thing about open source is that more than a single person can read and audit the code, so you might take the average opinion and trust that instead, which I agree would take time in the first place.

The problem with that is that there is no "average opinion" if the app is new, like for example, this AppVerifierBG app.

Also, sometimes, things still go unnoticed; remember the XZ backdoor?