Question on permissions
Type
Other
Bug description
We've just received a scanner warning at IzzyOnDroid:
! repo/io.chaldeaprjkt.boorusphere_1042.apk declares sensitive permission(s):
android.permission.READ_EXTERNAL_STORAGE
android.permission.REQUEST_INSTALL_PACKAGES
! repo/io.chaldeaprjkt.boorusphere_1042.apk contains signature block blobs: 0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)
Could you please clarify what those permissions are needed for?
Concerning DEPENDENCY_INFO_BLOCK, that can easily be avoided via a tiny adjustment to your build.gradle:
android {
dependenciesInfo {
// Disables dependency metadata when building APKs.
includeInApk = false
// Disables dependency metadata when building Android App Bundles.
includeInBundle = false
}
}
For some background: that BLOB is supposed to be just a binary representation of your app's dependency tree. But as it's encrypted with a public key belonging to Google, only Google can read it – and nobody else can even verify what it really contains. More details can be found e.g. here: Ramping up security: additional APK checks are in place with the IzzyOnDroid repo.
Thanks in advance!
Steps to reproduce
n/a
Android version
n/a
App version
versionCode 1042
Screenshots or videos
No response
Solution
No response
Additional context
No response
Acknowledgements
- [X] I have searched the existing issues and this is a new and no duplicate or related to another open issue.
- [X] I have written a short but informative title.
- [X] I filled out all of the requested information in this issue properly.
Today's release reports the same. As this is no App manager, I must assume REQUEST_INSTALL_PACKAGES is about a self-updater – which would violate the IzzyOnDroid App Inclusion Policy. So could you please clarify, @nullxception? What does that updater do? Is it opt-in? Does it outline the implications (like bypassing the checks performed at IzzyOnDroid)?
If we cannot resolve that, I must assume it is a violation, and would have to take the app off IzzyOnDroid.
yes it's in-app-update : c35c78b26b4419ae270c90ef0f0c786ac95cede8
but user has to manually press the download button, so it's not an auto-update
Gray borderline then, and requiring the NonFreeNet anti-feature as the check itself is not opt-in. And quite dark gray as well as it doesn't explain the implications of using the update this check offers (bypassing all scans in the repo).
Would you consider making the check opt-in as well (to avoid the NonFreeNet; you could ask in the OnBoarding activity whether to enable it or not and have an option in the settings to change it later)? When doing so, also list the implications (like "these updates will not be run through additional checks implemented by e.g. the IzzyOnDroid repo") along, and we'd be fine.
What do you think?