Continuing the discussion from Accrescent isn't the future:
Would it be a good idea for us to maintain a list of AppVerifier verification strings on our website?
I think we’d be in a unique position to crowdsource them, since we have a large community here and (I’d hope) the things we publish are generally considered trustworthy by most people. Entries would probably require fairly little maintenance after adding them, since signing certificates don’t really change too frequently.
In general, I support the idea
How would we prevent bad actors from poisoning the database?
Relevant thread from GOS forum:
Same approval process as the rest of the site, so ideally some oversight from the team, and some process for other people to vouch for submissions too.
I’m also thinking about having GitHub Actions automatically pull the app from F-Droid, Google Play, Accrescent, or online releases as applicable.
I’d still want to manually check submissions, but we could use that to label them as “likely good” and “likely bad” which could help filter out spam or obviously bad submissions quickly.
Basically like that, except one combined database we publish to privacyguides.org with some defined process, instead of having to search through individual submissions and decide which user to trust.
I love this idea! Would this be linked directly in the AppVerifier app, or something people can manually search?
It would be useful if it stated which app version and download source since the key is sometimes different. Also, if it was searchable or sortable that would be helpful!
We’d have to list Google Play versions separately I’d imagine, yeah.
Yeah.
Absolutely would make it searchable and sortable though. Probably some “copy to clipboard” button on each listing and then you just open AppVerifier and hit the verify from clipboard button.
I think the key here is that the list is maintained in the proper format. From this current issue/enhancement the dev is open to a feature that
share the text which is just multiple entries separated by newlines. When you share multiple, it can open the app list with only the apps in the text which are present on the system.
which would make the PG list easy to integrate into a possible future feature.
Agree, I just read that. I want to basically do a big YAML file with the data, which we can easily transform into a nice table on the website, or easily build a big plaintext list like that if some sort of mass import feature does get added to the app.
if you look at the other users fork it looks like they had the feature where the users could use their own database that could be imported and exported as a json which also seems pretty conveneint - especially for shared lists which I think was what their comment was getting at.
but the SAF export/import serves a different purpose: backing up your own curated database across devices or after a wipe. I could also see this being used to create shared community databases.
I dont know enough to know if a yaml, text file, or json is better or just different…
I just like yaml since it is easier to read than json, but it directly converts to json. And a script to convert it to a txt file would be very simple, so anything that AppVerifier ends up supporting will be easy to do 
It’s been brought up that maybe we could simply release a fork with an expanded internal database too, but I am not sure because I would think people will want to obtain AppVerifier from Accrescent, and we couldn’t publish a fork there (at least not yet).
I don’t think its a bad idea, the dev has said they arent actively working on the app and it seems pretty clear that once accrescent is stable there may not be a database feature at all. I also like the idea that people could have these trusted maintained community databases, it remindes me of blocklists from pihole but, that might just be how my amateur mind thinks of it.
I mean if we did a fork we would still present both options, for people who want to use the original app too.
Yeah of course. Did not mean to imply that should not be the case. I just meant it makes sense to have a fork if having a database is a feature people want in the longterm.
Shouldn’t the source of the hash thingy be from the developer if it’s a github APK? Or would we be okay with just multiple people corroborating? I assume that it would be okay to just have multiple people corroborating for the GPlay version because Gplay verifies stuff in a way, even GOS approves of.
I might not be understanding completely.
It’s definitely nice seeing that checkmark next to Molly and for the other apps that they have in the Appverifier database.
The app has functionality to share hashes for this reason (to share with a friend)
You would still want a corroborating source in case you don’t trust GitHub (if the developer publishes a hash in their readme), or for the much more common situation where a developer doesn’t publish this information at all.
In the hopes of not sounding like a broken record (as I have mention this previously) but it does seem relevant.
correct me if I am wrong but one could also use Website to help get an apks certificate hash
Instead of this database I want to make or instead of using the AppVerifier app?
I just meant as a 2nd method with AppVerifier, if a user of AppVerifier has neither the developers hash or another persons hash to verify against in response to @Expert4870 question but maybe I misunderstood.
Only if you are committed to maintaining it.