accrescent / meta

Umbrella Accrescent issue tracker

Accrescent

A novel Android app store focused on security, privacy, and usability.

Currently in early alpha.

Screenshots

Home Page	App Details

Settings Menu	Material You

About

Accrescent is a private and secure Android app store built with modern features in mind. It aims to provide a developer-friendly platform and pleasant user experience while enforcing modern security and privacy practices and offering robust validity guarantees for installed apps. It does this through the following features:

• App signing key pinning
• Signed repository metadata
• Automatic, unprivileged, unattended updates (Android 12+)
• First-class support for split APKs
• No remote APK signing
• Meaningful quality control for submitted apps
• No account requirement for installing apps

...and more. See the features page on the website for details.

Accrescent currently runs on Android 10 and up.

Contributions are welcome! If you're interested in helping out, be sure to check out the contributing guidelines for tips on getting started.

Signing certificate hash

Accrescent's SHA-256 signing certificate hash is as follows:

067a40c4193aad51ac87f9ddfdebb15e24a1850babfa4821c28c5c25c3fdc071

Be sure to check it against the hashes on our website and Twitter to verify its legitimacy.

Translations

Accrescent has a project on Hosted Weblate if you would like to help translate.

Trademark

The name "Accrescent" and the Accrescent logo are common law trademarks owned by the Accrescent project. All other parties are forbidden from using Accrescent's name and branding, as are derivatives of Accrescent. Derivatives include, but are not limited to forks and unofficial builds.

meta's Issues

Support "open source" tag

Developers should be able to request an "open source" label for their app after it has been published (we can add label requests to the draft creation process later on). This request should then be reviewed by an Accrescent reviewer. If the app is licensed under an OSI-approved license, the request will be approved.

Implementation steps:

• #4 (prerequisite)
• Add "open source" label request submission workflow
• Add "open source" label request review workflow

Support delta updates

Although split APKs and compression greatly reduce download sizes, we can reduce them further by caching previous app downloads on the client and generating deltas to patch what's already downloaded. It doesn't really matter what format the deltas take as long as it can be feasibility implemented in both the client and server codebases. Ideally we should use a popular existing format with well-supported libraries for delta generation in Go (for the developer portal) and delta application in Kotlin/Java (for the client). However, since this is a pretty niche need I'm not opposed to writing/translating/maintaining a new delta generator/patcher for an existing format if need be or maybe using C bindings. Chromium's fork of bsdiff looks like an interesting candidate.

Considering how frequently Accrescent checks for updates and that it performs them without user interaction, we probably only want to generate deltas between the last release and the current release.

Create library for APK parsing

The Accrescent developer portal needs to parse uploaded apps for version codes, version names, requested permissions, target SDKs, etc. to display to reviewers and populate repository metadata. No well-maintained Go library exists to parse compiled app manifests and resource files, so we need to write our own library for this purpose.

This library should also be able to parse (not verify) v3(.1)/v4 app signatures and whatever string resources deemed necessary.

We may want to integrate Google's apksig test suite similar to how Avast does to ensure the signature parser is robust.

App channels (alpha, beta, stable?)

It would be awesome if there were app channels in Accrescent so developers could publish less tested builds in alpha or beta to get feedback from users, and then finally being able to release a stable version. Though I have no idea how it would actually work. Also there are higher priority features Accrescent should probably get first.

Provide multiple language translations

The scope of this issue is determining how we can provide accurate and timely translations for the Accrescent client, developer portal, web pages, etc.. There are many different approaches to this so we need to carefully consider which languages to support, who does the translations, how much translations will cost, and how maintainable they will be.

This is a long-term goal. I don't expect to be able to fairly evaluate all options until Accrescent is stable and has a sizeable user base.

Explicitly label closed source apps as such

Add "Closed Source" labels to every closed source app tile in all the app sections. This could inform the users better about the apps they use. The label should have full "Closed Source" text in them for extra clarity and awareness

Support app descriptions

• Add support for parsing and rendering descriptions from repository metadata in client
• Add required description field(s) to console data model for published apps
• Require description field(s) for new drafts
• Add support for submitting description update requests

Add comparison to F-Droid and Obtainium to the FAQ

This will help the users to know the differences between the stores, their advantages and disadvantage for specific use cases

Support app changelogs

Developers should be able to add a changelog entry to app updates and Accrescent should be able to display it in the app details screen. Initially we don't need to keep a record of previous changelogs, but doing so may be desirable in the future.

Add searchable app index to website

Users who don't have Accrescent installed may decide whether to install it based on what apps it contains, so it's important to make that information easily available to users who don't already have Accrescent installed.

The index could be generated periodically via a cron job or similar in the initial implementation, but it would be possible to have the developer portal trigger a reindex every time the repository is updated.

Add privacy policy to both the official site and to the app

• What data is collected, when and how?
• Is there optional telemetry or analytics in the client? Can you opt out and how?
• Does the client specifically track its users for some reason?
• What about GDPR or CCPA?
  Etc.

Support developer/organization pages

For each developer/organization, there should be a page within Accrescent which lists some developer information along with a list of the apps they're responsible for.

Rewrite developer console

Add per-app toggle for viewing changelog on app update

One way this could work is by adding an off-by-default toggle to each app description page. When an app is updated and said toggle is enabled, a Accrescent generates a notification that links to the app's changelog section in the description page.

The feature doesn't have to work like this exactly, but the general idea is to have an option to notify users on specific app updates so they can view the changelog. Should probably evaluate user interest before implementing.

Support Brotli (and gzip) HTTP compression

As more apps are hosted, this becomes more and more desirable.

The app's code will obviously need to support and implement it as well as the server-side.

You will also need to host pre-compressed files on the web server if you want to support HTTP download pause/resume in the app client in case of interrupted downloads.

Create "Get it on Accrescent" button

Ideally when clicked, the button link should redirect to the corresponding app page in the Accrescent client. If Accrescent is not installed, then the user should be redirected to a page instructing them to install Accrescent first. We don't have a web UI like Google Play and F-Droid (and I have no immediate plans for one), so we can't direct the user to a web page for the app.

To-do:

• accrescent/accrescent#5
• Create button graphic
• Publish to website
• accrescent/accrescent#19
• Add website redirect to installation page for when Accrescent is not installed
• Add badge generator to developer console
• Document usage

Determine whether we should pin app signing certificates

Accrescent currently pins the SHA256 hash of the public key(s) of a given app's signing certificate(s). Android identifies an app's signer by its entire signing certificate in various places, not just by the public key. Is there any benefit to pinning hashes of whole certificates instead of only their public keys?

App screenshots

It would be nice for the user & dev to have some screenshots in the app so that you can see what you install.

App Monetization Disclaimer

This is stemming from discussion in the Matrix room, but I'm making this issue to help collect thoughts.

It is generally agreed, for transparency's sake, that a disclaimer should be displayed to allow users to be aware of how an app is monetized, if at all. I would like to propose a few labels. This issue does not serve to describe the UI design for these features, only the labels themselves and their purpose.

Overall, I see these five categories:

• Free (no monetary transactions)
• Ad Supported
• Accepts Donations (Badges, themes, skins, etc. are allowed. No functional changes) (Example: Aegis)
• Freemium (Free tier, paying for app changes functionality) (Example: Bitwarden)
• Paid (Requires a paid license to use the app) (Example: Threema)

If an app would like to extrapolate on why it exists in a particular category, for instance a Freemium app that is free for individuals but requires a license for groups or enterprise users, can do so in their description or direct people to their information or pricing page.

Concerns:

Enforcement
Especially early on, I feel the best path here may be simply to allow developers to self-report, perhaps by making a dropdown or a set of radio buttons from which they can select their monetization category. Platform moderators should also have the ability to force a selection and prevent it from being changed by the developer.

Level of Detail
There is some discussion to be had about how much detail is needed. I feel displaying one of these five tags strikes a good balance between practicality and need-to-know information, especially since a lot of this information is not available with a cursory look at the app's info page. While I agree that a person should go to the app's website or github/gitlab repo and seek out more information, things like whether an app displays ads or if it requires a subscription to even use may not be that apparent at first glance. Threema, for instance, is not at all up front about their service being paid, how much it costs, or even how to buy just by looking at their home page.

Additional Information
Additional information should be available when selecting an app monetization category as well as to the end user seeking to download the app. This should help disambiguate what each of the tiers entail, help developers choose the right category for apps, and assist end users in making an educated decision. That said, as pointed out by others, it's not Accrescent's job to do the thinking for the end user, but providing information to guide them in their decision is something that is within our scope.

Edge Cases
Discussion should be had on how to handle these and other edge cases:

• Timed free trial (apps which are free to use for X days then require payment) - Paid tier?
• Limited free trial (apps which are free to use forever, but whose feature sets are limited) - Freemium tier?
  • Maliciously limited free trials, where the app is severely limited or appears to almost punish users for not paying, should probably be reported by end users and subsequently removed from the platform or marked as paid and restrict the ability of the app owner to change it.
• Free app, paid service (e.g. Threema). Freemium/Paid tier as appropriate?

Implement app tagging system

Allow developers to add tags to their app like "requires GMS," or "open-source" for filtering and categorization. Arbitrary tag names should not be allowed; tag names should come from a predefined list of allowed values to ensure they're actually useful for filtering.

To-do:

• Define app tag representation in repodata
• Properly update tags when fetching repodata in client
• Allow developers to specify tags when submitting their app
• Implement tag filters in search function

This is an enhancement to accrescent/accrescent#21

Add comparison table

Comparison table should at least include the following app stores

• Google Play Store
• Accrescent
• Aurora Store
• F-Droid
• Obtainium
• Sandboxed Google Play Store from GrapheneOS?

The table should be an simple overview to compare security/privacy related components and maybe some features. If the platform supports it use checkmark. If it doesn't support it use red cross.

Table should not include extensive explanation about why it does/doesnt support something. If documentation is available for it then u should link to it.

Add Cryptocurrency address Donate

Sponsored cryptocurrency for developers, Add Cryptocurrency address

instances
Bitcoin 17Pk1RurnkJxLV9V7mc6Y7dLyHFb9rvQDq
Monero 17Pk1RurnkJxLV9V7mc6Y7dLyHFb9rvQDq

---

Monero
Zcash
Bitcoin
Ethereum Classic
Ethereum
Oxen
mysterium.network
nymtech
sentinel.co

MetaMask
uphold

Support download counter(s)

We should keep track of download counts for all apps. This could be done with a simple microservice on each repository server which increments a counter for each download made and can return the total number of downloads for a given app. This number will eventually be retrievable to be displayed by the developer console and included in the per-app repository metadata.

Initially we only need to support total download counts. However, per-month download counts are a must to eventually have a more dynamic value.

Somewhat stabilize repository metadata format

The Problem

Accrescent needs repository metadata to find and download apps in the store. The current repodata format (as described by the data classes found here and the JSON files here and here) comes with strong cryptographic guarantees of app validity. However, it has a few significant limitations, namely:

• It expects developers to maintain a signify key for signing subrepodata and use it when updating their apps. This both raises the barrier to entry for app developers unfamiliar with signify (presumably most of them) and complicates the app upload process.
• It pins developer usernames, meaning developers would need to request the root repodata signer (myself) to change their username every time they changed their GitHub username since we use GitHub as our authentication provider. This is unnecessary and unsustainable.

New Format Goals

A new format is in order for the stable release. It should (ideally) accomplish the following:

• Protect new and existing users from malicious downloads in the event the repository is compromised
  • Validate first-time app installations, improving on Android's TOFU model for app signatures
  • Be resistant to downgrades
• Be usable for developers
  • Allow developers to upload updates to existing apps without waiting for external review/signatures (provided the update meets our eligibility requirements for unreviewed uploads, documentation for which is in-progress at accrescent/devconsole#1
  • Only require developers to use their existing tools (i.e. not require them to use signify)
• Provide a way to fetch split APKs generated by bundletool

Non-goals

This repodata format overhaul will not define an absolutely final format, so a few things are out-of-scope for this overhaul. To name a few:

• App descriptions
• App categorization or tagging system
• App developer information
• Different release channels
• Install-time feature modules

New design (so far)

An informal proposal of the new format is being put together at https://hackmd.io/@lberrymage/accrescent-repodata. It will eventually be moved elsewhere.

Related: accrescent/accrescent#9