Features
The following is a list of notable features Accrescent currently has. It is not exhaustive and not all features listed are exclusive to Accrescent, but they are some of the more distinguishing features and are intended to give the reader an idea of the benefits of Accrescent and how it works.
Signed repository metadata
Accrescent's repository contains metadata files used by the client to retrieve apps and display info about them to the user. One of these pieces of metadata is signed by a key hardcoded into Accrescent to protect against tampering of sensitive information in the event the server is compromised. This signed metadata supports key rotation, is downgrade-protected, and a minimum revision hardcoded into Accrescent is regularly updated to protect new installations and sideloaded Accrescent updates from being served old metadata.
Below is a list of what the signed metadata protects and the corresponding security implications for the user.
App signing key pinning
When a developer submits a new app to Accrescent, a hash of their app's public signing key is added to the signed repository metadata. This signing key hash is checked by the client every time it downloads the respective app. If it doesn't match, the installation is rejected.
This check is unnecessary for updates since Android already enforces key pinning for app updates. However, the OS takes a trust-on-first-use approach and doesn't provide a mechanism to verify that the initial installation was signed by the proper certificate, so pinning the certificate in signed metadata ensures that even the first installation is legitimate.
Minimum version pinning
Each app in the signed metadata has a minimum expected version which is updated regularly. Accrescent will refuse to install a version of a given app less than its minimum version.
This check mitigates the threat of an attacker serving obsolete versions of apps. If a minimum version was not set, an attacker in control of the server could specify the latest version of a given app as an old version with known security vulnerabilities. Android already enforces downgrade protection for existing apps, so this threat is only applicable to users installing a given app for the first time.
Name verification
Accrescent stores app names in signed metadata. These are used to verify the app names displayed to the user in the client UI.
Signing the app name makes it more difficult for an attacker to trick a user into installing a malicious copycat app. If names weren't verified, a malicious actor in control of the server could modify it and trick a user into installing a different app than they intend.
Unattended updates
Accrescent supports unattended updates with or without privileged integration into the OS. By default, it will prompt for confirmation the first time an app is installed and perform updates in the background without prompting thereafter.
Accrescent also supports the privileged package management permissions on OSs which integrate it. When privileged, it will not prompt the user when installing or uninstalling apps.
Split APK support
Accrescent serves all apps as split APKs. This means that native code for different architectures, images for different screen densities, and strings for different languages aren't downloaded for a given device, saving bandwidth.
No remote APK signing
Accrescent doesn't sign apps itself. Developers sign (split) APKs with their own keys and upload them to Accrescent themselves.
This measure allows developers to maintain exclusive control over their app signing keys. Developers' signing keys cannot be compromised if Accrescent's servers are and Accrescent cannot deliver modified updates to developers' apps.
No accounts
Accrescent doesn't have user accounts. Users can simply install the store and use it. This design makes Accrescent more accessible and more private since user accounts can often be used to track user behavior.
Note that developers still need to create accounts on the developer console to publish apps.