@NebulaTide @GrapheneOS Um, Play Store is exactly the same. They lie that they're vetting packages and that's their justification for the walled garden approach. But all they're doing is setting policies which encourage malware-playing-by-Google's-rules and randomly ban software that's actually not shit (concrete example: not understanding that there's such a thing as an app that's a pure client not tied to a particular service provider, where by connecting to someone unsavory server you might see unsavory things).
@dalias @NebulaTide Our current general recommendation is obtaining apps directly from open source developers. Obtainium and App Verifier are useful tools for that, but Obtainium doesn't do things in a way that we can wholeheartedly recommend it or package it in our app repository. We could make our own tool for downloading app builds with pinned keys from where developers publish them without involving third parties. Could support a reproducible build verification system via third parties too.
@dalias @NebulaTide Play Store used to be a way to obtain developer builds of apps signed by the developers but has moved away from it and the code transparency system they provide isn't a complete solution to verifying what they generate and sign from the app bundles uploaded by developers.
For our own app repository, we don't want to build thousands of open source apps largely not aligned with our approach, especially without doing a pass updating dependencies and adding basic hardening.
@dalias @NebulaTide Accrescent is a project we recommend as an open source replacement for what the Play Store used to be but it's still in an early phase without a lot of apps. Makes sense to use it for the apps in it though.
It's a secure way to distribute developer builds where developers upload their releases. It's therefore not going to be a similar single point of failure, but it's also only going to exerting a small amount of influence on the app developers.
@dalias @NebulaTide F-Droid repeatedly not giving users Firefox updates for months because they have to slowly update their patches removing things they dislike is an example of how much of a disaster it ends up being. Users getting browser security updates is critical.
They've also had a long history of doing weird things like rolling back security critical dependencies compared to what apps use themselves. They do similar things for their own apps too to support ancient Android versions.
@dalias @NebulaTide It doesn't really matter that Firefox includes tiny proprietary Java libraries barely harder to review than open source code because of how Java works. If they're going to take that purity approach they need the resources to deal with updates. It's unclear how the purity approach is meant to work for the few percent of the apps where they use developer signed releases. What happens when they disagree about something the app includes? No more updates? It can be very political.
@GrapheneOS @dalias @NebulaTide >removing things they dislike
Maybe Mozilla could make a browser that is not riddled with telemetry and bad defaults, so the F-Droid team doesn't have to fix it.
@tibs @dalias @NebulaTide According to F-Droid themselves, their Firefox fork uses services which track users. The telemetry they're disabling is not mandatory and it's as if they're trying to make the changes more invasive rather than doing the least invasive change possible. Some of their changes include adding bookmarks/links to the F-Droid site.
The only thing they truly consider a blocker to updates is removing the client side Google Play libraries which blocks their updates for months.