Accrescent Store
xxx That' s always the case regardless from were you get the app.
Of course I agree it is possible in all cases. But is it equally probable? Are devs equally likely to give up on maintaining their apps on a store with 3 billion users, one with 200 thousand users or one with 1000 users?
duck1 If I understanding correctly, apps that go without updates for over a year or so will be deleted from the store. But how does that change the scenario I asked about? If the app is be removed from the store, the user will not be notified, they will just be stuck with an app that won't get updated. Right?
Hb1hf But how does that change the scenario I asked about? If the app is be removed from the store, the user will not be notified, they will just be stuck with an app that won't get updated. Right?
I guess yeah. Devs wouldn't have any reason to not maintain on a specific app store though. Don't know when that has ever happened.
- Edited
Hb1hf "Are devs equally likely to give up on maintaining their apps on a store with 3 billion users, one with 200 thousand users or one with 1000 users?"
To me, this question could be argued in all sorts of ways with absolutely no way of answering clearly. For example, I could argue that devs who publish their app on Accrescent, are more likely to keep up the maintenance needed for Accrescent, rather than for the Play Store. Because I would say, devs who wish to publish on Accrescent are more likely to be invested in this app store and the goals of the team behind it. Not just the security and privacy enhancements for users, but for the devs that publish there too. Even the fact that Accrescent is far less well known than the Play Store implies that the devs who publish there are invested in it as they were either searching for a store that would meet their needs, or probably heard of it because they are involved with, or following, projects with similar aims, such as increasing privacy and freedom for users etc, etc...
Since both mine, and your, points are pretty much based on assumptions about the motivations of the devs who publish on both app stores, I reckon... Well basically, it's pointless to speculate on.
As to your main question, I have personally had apps that were installed by the play store, decide to no longer allow installations on devices that don't pass Play Integrity, despite remaining compatible.
In these instances I do not recall being notified, but when I went to the app page in the Play Store, it did say, underneath the uninstall button, that "this app is no longer compatible" (I can't remember for sure, but I think it might have said it was no longer compatible with my device by choice of the developer, or something similar).
In one case, the app in question was Netflix, and I decided to install Aurora Store to check if they were actually enforcing the Play Integrity, and they weren't. Ridiculously, the app worked absolutely fine when installed by Aurora (by spoofing the device as a Pixel with the stock OS).
I don't know if it would be different if the app was abandoned by the dev. Perhaps Google would respond differently. I mean, isn't that what "Play Protect" is for?
I would also be interested to know if Accrescent would have some way of notifying the user if an app was abandoned/stopped being compatible etc...
- Edited
roamer4223 I should add for clarity, in the cases with apps, like Netflix, no longer allowing installations through the Play Store without the device passing Play Integrity - the app also stopped receiving updates.
Netflix ended up reversing that decision by the way, though as I don't use it anymore, I can't say for sure that they currently allow installations/updates on GrapheneOS via the Play Store. I hope they do, as not doing so is a stupid and pointless decision for so many reasons
Don't know when that has ever happened.
"Contact you" left accrescent after they stopped updating on it.
They'd also changed the app's signature, so updates wouldn't have worked.
There's no magic solution here.
It's up to developers to assume their responsibilities and not leave users without any information. The trust we give them is not limited to the app's code.
Manna "Contact you" left accrescent after they stopped updating on it.
Did they stop maintaining it in general or just publishing on Accrescent?
Manna There's no magic solution here.
It's up to developers to assume their responsibilities and not leave users without any information. The trust we give them is not limited to the app's code.
I agree
Did they stop maintaining it in general or just publishing on Accrescent?
On Accrescent, after 7.0 : https://github.com/you-apps/ConnectYou/releases/tag/v7.0
They're now on 9.0 : https://github.com/you-apps/ConnectYou/releases/tag/v9.0
treequell existing Play Store alternatives are fatally flawed.
How so?
I don't really understand the logic to implement Accrescent either - yes it's good to have a chain of trust from the OS to other apps, but helpful is it if there's only like ten of those other apps in total?
Why not have F-Droid in the Graphene App Store? It's massively well-established, mature in its own app development, and trusted by millions. (If the security issue is that users can add 3rd-party repos, well, that's a user decision just like using Play Store, isn't it? What is F-Droid's "fatal flaw"?)
lberrymage It's assumed that users will use system navigation (i.e. gesture or 3-button navigation) to navigate backward through the app, which is why there's no back button. We can reconsider this, but it is currently possible to navigate backward through the app.
I also vote to implement an in-app back button, for clearer navigation. If your repo has an issue open for this I'd be happy to comment there too. My experience, as a "digital native" and very tech savvy, is that lacking back buttons leads to confusion about where one currently is in relation to the rest of the app. I've used several apps that use your approach, like Neo Store and SystemUI Tuner, and in all of them I frequently exit the app accidentally because I thought the OS back gesture will take me to the previous screen in the app.
hemlockiv [how] helpful is it if there's only like ten of those other apps in total?
The Accrescent devs are deliberately limiting the number of apps while they build a scalable infrastructure, and add the features expected of an app store. They obviously expect to have far more apps in the future.
hemlockiv Why not have F-Droid in the Graphene App Store?
1) F-Droid signs most apps themselves, so you are trusting them in addition to the app developers
2) F-Droid has a history of sketchy behavior
I do not speak for the GrapheneOS team, but based on past comments, I think they would discourage people from using F-Droid for apps that can be obtained from elsewhere.
Probably9857 They obviously expect to have far more apps in the future.
Sure. It just seems weird that GOS, typically a very polished project, would push something in its alpha. And the apks that ARE included feel arbitrary. Why Clipious but not NewPipe, which is more mature and stable? Why Transcribro but not Futo Voice, which is more reliable? How many users need a chess clock?
Probably9857 1) F-Droid signs most apps themselves, so you are trusting them in addition to the app developers
Yes, they build and sign apps so there's one root of trust instead of dozens. The entire process is open-source. Beyond that, it's exactly the same trustworthiness of installing ANY precompiled apk. Unless you're building from source, you always have to trust that the apk's code hasn't been modified.
Probably9857 2) F-Droid has a history of sketchy behavior
Such as...?
hemlockiv It just seems weird that GOS, typically a very polished project, would push something in its alpha.
My sense is that Accrescent is doing a soft launch, but that the GrapheneOS developers believe that their app vetting and security processes are good enough that what is available should be trustworthy. I don't think the GrapheneOS project is "pushing" Accrescent, any more than they are "pushing" Android Auto or Markup.
hemlockiv And the apks that ARE included feel arbitrary. Why Clipious but not NewPipe, which is more mature and stable? Why Transcribro but not Futo Voice, which is more reliable?
From the outside it's hard to say. Are the NewPipe and FUTO Voice authors willing to have their apps vetted? Do those apps depend on features that Accrescent doesn't support yet? Asking the app authors and/or the Accrescent authors might be productive.
Probably9857 2) F-Droid has a history of sketchy behavior
hemlockiv Such as...?
These might be of interest:
hemlockiv Such as...?
In addition to the links from @de0u...
See https://privsec.dev/posts/android/f-droid-security-issues/ for a good compilation of the issues (some of which may have been addressed by now, but I suspect most have not).
Regarding sketchy behavior aside from poor security practices, see the Meta section at the end:
https://privsec.dev/posts/android/f-droid-security-issues/#meta
...the release of this article has unfortunately triggered a mostly negative response from the F-Droid team and some of their community, who seem to take a dismissive stance toward this article rather than bringing relevant counterpoints. Some of these individuals go as far as engaging in harassment campaigns against projects and security researchers that do not share their views;
hemlockiv Yes, they build and sign apps so there's one root of trust instead of dozens.
That is the wrong conclusion. You're still trusting the developers. F-Droid themselves acknowledges this.
The fact that they build and sign does 2 things:
It introduces an additional trusted party.
It makes it impossible to verify that the app you're installing wasn't modified from what the developer provided, or that it even came from the developer at all.
You're putting a lot of trust in F-Droid, but that does not substantially reduce the trust you're also putting in the app developers.
hemlockiv Beyond that, it's exactly the same trustworthiness of installing ANY precompiled apk
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.
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!