Probably9857 you know they are coming directly from the dev, and no third party has tampered with the APK.
This doesnt preclude the possibility that the dev deliberately published safe source code then compiled malicious code, unless the apk release is also published via a github workflow. I admit, this may be an unlikelyunlikely scenario, but a possible one.
Thanks for the informative links about F-Droid!
Probably9857 No, because with Accrescent, or downloading from GitHub, or from the developer's website, the APKs are signed by the developers. So you know they are coming directly from the dev, and no third party has tampered with the APK.
No third party, except for maybe Bruce Schneier (source).
hemlockiv This doesnt preclude the possibility that the dev deliberately published safe source code then compiled malicious code
True. Reproducible builds would address this, but its more work for devs, and few seem to think its worth the effort.
Even then, it's not that difficult to obfuscate malicious code, so...
In practice, its difficult to avoid trusting the devs of the software you use.
Probably9857 Yeah, and from what you're saying it sounds like the Accrescent maintainers are going to do a better job of vetting source code than F-Droid, which doesnt do it as much as I had previously believed
hemlockiv This doesnt preclude the possibility that the dev deliberately published safe source code then compiled malicious code, unless the apk release is also published via a github workflow. I admit, this may be an unlikelyunlikely scenario, but a possible one.
Maybe rethink the word "deliberately". Their infrastructure might be compromised and they will be unknowingly compiling malicious code. Which seems much more likely!
Hb1hf not sure I follow what sort of compromised infrastructure could lead to that result. You mean someone's personal git repo being hacked? If we are now considering a threat model that includes trusted devs unknowingly compiling malicious code not included in their open source code, then we're back to square one of "never install any apk you didn't audit and compile yourself"
I think if the app developer gets hacked we are lost anyway.
hemlockiv offtopic, but could you explain why Transcribro is less reliable than Futo Voice? I'm the lead developer of Transcribro, I'd just like to know what reliability bugs you found so I can fix them. If you can, please report it to Transcribro's GitHub issue tracker (https://github.com/soupslurpr/Transcribro/issues) but I understand if you don't have an account. Please let me know, thanks.
soupslurpr Hi ! are there any plans to add other languages such as French to the text-to-speech ? I remember the last time I used it, it only supported English, thanks !
Edit : I read the topic on Github, this seems like good news.
juicer please, don't make us scroll. We want to live, it's all we we've got.
DeletedUser69 Say what?
I installed qlango from accrescent.. my DNS log picked up the following trackers from the app. Most were already blocked (red colour - entries from mobile DNS blocklist, but one got through to the net (green colour).
Are accrescent apps supposed to have all these trackers allowed?
tomz Accrescent aims to have both closed-source and open-source apps available in the App Store. Qlango is the first closed source app published on Accrescent and that app has Google analytical libraries. This app does not violate any of Accrescent's app review policies and so it was allowed on the store. In the future, it is planned for Accrescent to have a tag to differentiate between closed-source and open-source apps.
I think most users still would have preferred if the functionality to distinguish between open and closed source apps had been added prior to accepting Qlango, even if it technically meets the requirements.
tomz To further add to my point, Accrescent does not have a policy against analytics libraries in apps. As time goes on, it is more likely that apps containing analytical libraries will be added to Accrescent.
