Recent searches
Search options
GrapheneOS and our community care about real privacy rather than a performative approach. The implication that GrapheneOS and our community care about security rather than privacy is nonsense. It's misinformation that's propagated by people who are pushing products far less private and secure than if people simply used iOS. Privacy is the main focus of GrapheneOS and our community. Our work and focus on security is entirely to defend privacy. It makes no sense to separate it.
I'm very new to grapheneos and I was surprised to find accrescent and not fdroid as an installable option.
I performed some web searches (not very extensive) and found no reason for this choice (yet).
Especially with #qlango containing so many trackers (see OP) - could you elaborate your point a bit more? Why is #Accrescent favored by #GrapheneOS by offering it as an installable app and how is this privacy focused?
@klopf @rufposten
@manu @klopf @rufposten F-Droid isn't a secure or trustworthy way to obtain open source apps. We're all for having a high quality app store which only packages apps meeting a high standard, but F-Droid is definitely not that app store and almost certainly never will be. It is not in our App Store because it's not safe and the developers have clearly demonstrated they cannot be trusted. Use it at your own risk, we don't recommend it and expect it to end very badly for people who use it.
@manu @klopf @rufposten Accrescent is an alternative to the Play Store where developers can distribute their apps to users securely with objective standards put in place for privacy and security. It is not supposed to be only privacy focused apps or only open source apps. We include it as being the best way for people to get specific apps available in it. It is not included as a way for people to get a list of recommended apps. We have the Play Store in our App Store too, so what's the issue?
@manu @klopf @rufposten If you're using F-Droid to obtain open source apps, you're making a mistake and putting your privacy and security at risk. You are far better off using the builds from the open source app developers which are signed by the developers. That way, you don't have unpredictable massive delays for updates which can go on for months. You avoid the apps being built on known to be poorly maintained infrastructure with outdated tools with sketchy downstream changes to them.
@manu @klopf @rufposten Either way, you're trusting the actual developers of the apps. By getting them from F-Droid, you're getting builds made on F-Droid's sketchy infrastructure with outdated tooling where you still trust the app developers just as much (it's not as if they review the code or changes to it) but are also trusting a whole additional set of infrastructure and people who we think have quite clearly demonstrated themselves to be highly untrustworthy for multiple reasons.
@GrapheneOS @manu @klopf @rufposten Are your arguments only targeting the Official F-Droid Repository, or the Repository architecture of F-Droid in general?
E.g. when I install Molly or Newpipe via the F-Droid repositories of their developers.
@linos @manu @klopf @rufposten Molly is available in Accrescent already. If all the apps you wanted were available there, what would be the reason to use another way to obtain them? That includes whatever closed source apps people want to use. If they were in Accrescent, why get them from the Play Store? It would of course not replace the apps depending on Google Play services and the Play Store for the services it provides but it would be a start.
@GrapheneOS
Hi, thanks four your summary and the pointer to the wireguard dev comment. I'll certainly follow up on this to better gauge the extent to which I'll trust F-Droid from here on out.
I've re-read my question and I've put the emphasis too much on the absence of F-Droid. I actually wouldn't have expected it to be part of GrapheneOS in the first place because it's easy to install for anyone who's capable of installing Graphene.
However, I was stumped to see Accrescent offered prominently because it does offer apps with privacy-invasive tracking and doesn't (and has no ability to) warn users about this. Considering the low number of apps in Accrescent, this is even more surprising because they probably know details about every single app in there. The Accrescent publication requirements do not regulate online-tracking at all. While I do understand your issues with F-Droid, I still don't understand how Accrescent deserves this favored place on GrapheneOS. I don't mean to challenge your decision but I'd like to understand how it came to be.
And yes, the Play Store is also offered but that has technical reasons beyond privacy. Anyone who cares the least bit will know that it's to be used cautiously. And it doesn't explain the reasons for why Accrescent is being favored beyond promising that privacy is important to them. Google would say the same, so do the F-Droid devs.
P.S.: I've found this closed issue on the Accrescent github and it's very verbose on how Accrescent decides about user tracking.
I don't know if this reasoning extends to GrapheneOS but I'll share for completenes' sake:
https://github.com/accrescent/accrescent/issues/637
@linos @klopf @rufposten
@manu @GrapheneOS @klopf @rufposten Hmm, I would enjoy seeing a contributions welcome or a label that indicates that possible better solutions need to be sketched out first, rather than having a not planned label on that issue
@linos @manu @klopf @rufposten See https://github.com/accrescent/meta/issues/25. The criteria for labels have to be objective and enforceable. An open source label, reproducible build label, etc. has to be well defined. They do have it as a planned feature, but it's meant to be an alternative to the Play Store and that includes packaging apps you don't like. It wouldn't be an alternative to the Play Store if it only permitted open source apps. If people want that they'll be able to get it from it.
@linos @manu @klopf @rufposten Accrescent is also not a GrapheneOS project. It meets our standards for an app repository distributing developer builds of apps securely and was therefore included in our App Store. Other app stores meeting our standards can be included there too. F-Droid does not and will not meet our standards. It will never be included in our App Store. A secure and trustworthy implementation of a repository of only open source apps would be happily included there.
@GrapheneOS
It would simply be nice to know what these standards are and how Accrescent is currently the only candidate that meets them (and what would need to be done to meet them).
This should fit well into the 'bundled-apps' section in the FAQ, I think. If it's already somewhere else, I couldn't find it.
@linos
See my other post, there is an open issue in Accrescent/Meta that goes more into depth and might be the right place to discuss this. I'll keep my eye on it anyway :)
Om why not add the link another time:
https://github.com/accrescent/meta/issues/40
@GrapheneOS
Ok, from what I collect, the reasoning is that tracking is "subjective", which means here that connecting to Google, Facebook etc. doesn't necessarily qualify as (harmful?) tracking. Furthermore it says that blocklisting individual libraries or URLs is not in the development scope. I can respect that but I also understand it's controversial.
There is a policy issue in the Meta repo for Accrescent here that takes this into account and tries to find some middle-ground (I think): https://github.com/accrescent/meta/issues/40
The line of reasoning works for me even if I tend to disagree. Seems that GrapheneOS is more or less aligned with this. I think it's a justified position (agree with it or not) but I think it would be beneficial to have some easy to find explanation (e.g. in the FAQ) that goes beyond saying 'Accrescent is privacy and security oriented' or 'better than F-Droid'.
There are some social media posts, one also mentions that Accrescent comes from within GrapheneOS. This way the choice makes more sense to me. But it's not very obvious on first use of GrapheneOS and the posts aren't too easy to find.
Posting this before checking if there are any new replies since my last post.
@manu @linos @klopf @rufposten
> Ok, from what I collect, the reasoning is that tracking is "subjective"
If you want subjective warning and filtering, don't be surprised if you don't agree with the way that's managed. F-Droid is a highly untrustworthy source of apps and highly insecure. It's unsafe to use and could be branded as such with a warning notice. It could also be included on DNS filtering lists. You probably wouldn't agree, but yet you're proposing blocking Firebase services.
@manu @linos @klopf @rufposten F-Droid developers have been heavily involved in extensive harassment towards members of our team and multiple of our community members. The overall harassment has escalated to stalking, swatting and real world violence including severe swatting attacks aimed at having someone killed by law enforcement. F-Droid is an untrustworthy and unsafe source of apps particularly for GrapheneOS users who they've been repeatedly targeting with underhanded attacks.
@manu @linos @klopf @rufposten Can you explain what Google has done which is remotely as bad as what F-Droid has been doing towards the GrapheneOS project, team and community members? In what sense are they more trustworthy or should have connections to their services allowed while filtering out connections to Firebase services? Put aside all the marketing about their claimed values not aligned with their actions and what they actually do. Why should Firebase be blocked but not F-Droid?
@manu @linos @klopf @rufposten If you open the can of worms that is subjectively adding blocking for DNS queries, warning labels for apps, etc. then don't be surprised if the way that ends up being done goes against what you want. F-Droid would be one of the first apps we'd label as a danger to our users if we were doing that since it's likely going to result in a large number of GrapheneOS users getting malware on their devices in the future. It is a serious threat to the safety of our users.
@GrapheneOS
You didn't read my post entirely, I think. I'm really trying to understand and not take sides before I understand.
I had to add the quotation marks because it's a quote and it was the central point of argument here.
I continue to agree that the argument made by the Accrescent dev is sound even if I still disagree with it.
The privacy standards that Accrescent applies to apps are unfortunately not published or published in a clear way (e.g. when would tracking be problematic?). But that is not a GrapheneOS issue itself.
GrapheneOS on the other hand doesn't publicly define standards for bundled apps at all, for what I found. And I wonder if you (person who runs the account) could point me somewhere useful. It is a pity that it's like this but doesn't mean the choice of adding Accrescent is inherently wrong. However, pointing out how much worse F-Droid or others is no basis for a reason. Why include an App Store at all?
@manu @linos @klopf @rufposten
> You didn't read my post entirely, I think.
No.
> The privacy standards that Accrescent applies to apps are unfortunately not published or published in a clear way
You realize it is in Alpha, right? Quite premature for people to be spreading attacks on it because not all the basic features and documentation is in place yet.
> GrapheneOS on the other hand doesn't publicly define standards for bundled apps at all
Not true, and Accrescent is also not bundled.
@manu @linos @klopf @rufposten
> Why include an App Store at all?
GrapheneOS needs our own App Store in order to ship updates to OS components and bundled apps without needing to update the whole OS. We clearly need to be able to ship out-of-band updates to Vanadium and GmsCompatConfig at a bare minimum. We also clearly need a way for people who want to use sandboxed Google Play to obtain it easily and securely. That bootstraps getting apps from the sandboxed Play Store securely too.
@manu @linos @klopf @rufposten
We don't particularly need to provide another way to get apps available on the Play Store which include the Google Play SDK. That's why we don't mirror things like Pixel Camera and Google Play Gamers, because people who want them can just get them from the sandboxed Play Store. Android auto and Pixel Thermometer is mirrored so we can control updates for people who use it due to needing compatibility code. Markup is mirrored because it's not in the Play Store.
@manu @linos @klopf @rufposten
You're portraying it as if apps we make available in our app store are bundled in the OS which is not the case. Accrescent is not a GrapheneOS project and is not included in GrapheneOS. Google Play is also not included in GrapheneOS. Putting apps into our App Store doesn't make them bundled apps. Having Accrescent and Play Store there allows securely obtaining them and then securely obtaining apps through them. F-Droid is not a secure source of apps regardless.
@manu @linos @klopf @rufposten GrapheneOS supports what Accrescent is building. We're going to support them and we're going to fight back against people and projects harming these efforts. We published https://grapheneos.social/@GrapheneOS/113900949999725460 across platforms (not only Mastodon) as a response to this thread, and we intend to publish several more threads about F-Droid. That one was to cover what WireGuard said about it. There's a lot more. We can also cover their team's harassment in much more depth than before.
@manu @linos @klopf @rufposten F-Droid is not a safe or trustworthy source of apps. It also has very lacking security, which contributes to it not being safe or trustworthy. A massive overhaul and rewrite fixing the major security design and implementation issues is possible, but that won't make it safe or trustworthy. The people behind it have very clearly demonstrated they can't be trusted at least to us and our community. Why have them as middlemen between users and app developers?
@GrapheneOS
Accrescent is not bundled, correct. It's only offered for installation in the GrapheneOS App Store as one of ten available apps.
Saying that it's "not true" that the bundled app standards aren't published omits my "for what I found". I've really looked but couldn't find something definite. As you say, it's not bundled, so I'll correct myself: Are there published privacy and security standards for Apps that are published in the GrapheneOS app store?
Could you please point me in the right direction for this? If you know that these standards are defined, why not point me to them? I'd actually be willing to argue your case but you don't seem to realize that.
I'll give up after asking this one last time.
@manu @linos @klopf @rufposten You need to press All packages in the menu to see the full list of apps. As an example, we only show Play services rather than Play services + Play Store since they depend on each other so showing both is redundant. There are currently a total of 16 packages in it. We could add 100 things we could update out-of-band but it would be a lot of work and we don't need regular updates to most OS components separate from overall OS updates the changes are tied to.
@manu @linos @klopf @rufposten Accrescent is not a bundled app so the criteria for including it in our App Store is not the same thing as criteria for including an app in the base OS. For example, we don't allow connections to non-GrapheneOS services in the base OS as a default behavior so Accrescent can't be bundled there.
https://grapheneos.org/faq#default-connections
https://grapheneos.org/faq#other-connections
We're also mirroring official releases of Accrescent and letting it take over updating itself, not acceptable for bundling.
@manu @linos @klopf @rufposten Bundling an app would involve forking it, changing the app id, rebranding and hosting any services it needs ourselves, potentially with the option to switch to other providers depending on how it works. We intend to replace several of the AOSP apps that way instead of overhauling them. Putting stuff in our app repository is far different than putting it in GrapheneOS. If F-Droid had trustworthy developers and was well designed/written it could be in the App Store.
@manu @linos @klopf @rufposten Similarly, Aurora Store can't be included because it doesn't verify Play Store app signatures, the default account sharing it does is highly questionable and it was recently taken over by a group of people overlapping with the F-Droid developers who we consider highly untrustworthy and want to limit our exposure to their code going forward. It's also a factor in why we're going to completely fork Seedvault, not just the fact that it doesn't work well.
@hannelore
Das ist der Thread den ich eben meinte
@manu ah püh. Der wieselt aber arg. Und die Frage nach Standards hat er noch immer nicht beantwortet jenseits von was bundled apps dürfen im Netzwerk.