Question on permissions

[IzzySoft]

On the latest release, my scanner just reported:

! repo/free.rm.skytube.extra_48.apk declares sensitive permission(s):
  android.permission.REQUEST_INSTALL_PACKAGES android.permission.READ_EXTERNAL_STORAGE*
! repo/free.rm.skytube.extra_48.apk contains signature block blobs: 0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

READ_EXTERNAL_STORAGE was implicitly granted because of WRITE_EXTERNAL_STORAGE. But what is REQUEST_INSTALL_PACKAGES used for here? The DEPENDENCY_INFO_BLOCK can easily be dealt with:

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.

Thanks in advance!

[drogga]

@IzzySoft
Regarding the REQUEST_INSTALL_PACKAGES: SkyTube has a check for updates, but only Extra can DL and install them, the Oss only shows that an update is available in the form of only a white changelog pop-up dialog (with an unclickable link at the bottom), hence the permission.

[IzzySoft]

@drogga thanks, I was afraid that would be the case. Is that updater (including the checks) opt-in or enabled by default? Does it clearly state where the updates are taken from, and that they'd bypass the additional scanning at the IoD repo?

[drogga]

Unfortunately it's enabled by default and you can't stop it from checking (you can also trigger the check from the About menu screen), but you can always choose to not DL (2 buttons are available in the prompt: Later & Update, but if you choose "Later", it will nag/ask the same on every launch), I'm pretty sure they are directly DLed from the release assets here, on GH.

[IzzySoft]

That still violates the IzzyOnDroid App Inclusion Criteria. Here's the relevant part:

[the app] must not download additional executable binary files (e.g. addons, auto-updates, etc.) without explicit user consent. Consent means it needs to be opt-in (it must not be harder to decline than to accept or presented in a way users are likely to press accept without reading) and structured in a way that clearly explains to users that they’re choosing to bypass the checks performed in this repo if they activate it.

Can that be adjusted? For an example, please see here (RiMusic implemented that exemplary).

[drogga]

It probably can, as long there's someone that can code... I'm not one of those and @gzsombor is hard to contact to and rarely responds to my mentions here, let's hope he sees this and handle it if he can and want's.

[IzzySoft]

Thanks! I've to raise the red flag here and set a reminder on my end to check up here. I'd have to remove it now as it violates the criteria, but will make the compromise to delay that for a while given the update itself has to be confirmed, but that's deep gray area in this context already as the implications are not made clear. People installing apps from a repo expect updates to come from the very same, with the very same extra precautionary scans and all.

[drogga]

F-Droid lists the Oss variants of the 2 repos (this and the Legacy), IDK if you intend to do the same and if they are problematic for your repo as well, or only the Extra(s).

[IzzySoft]

I just left Extra in as it adds some more features. And I usually do not add apps at IoD if they're already available (and updated) at F-Droid. Exceptions are possible of course; but all those using Extra will be extra disappointed.

So let's see what @gzsombor says. Or maybe one of the other contributors can help out, there are several which are quite active (maybe @comradekingu?)

[gzsombor]

@drogga thanks, I was afraid that would be the case. Is that updater (including the checks) opt-in or enabled by default? Does it clearly state where the updates are taken from, and that they'd bypass the additional scanning at the IoD repo?

It depends on how did you compile your app, if FLAVOR=="oss" or BUILD_TYPE=="snapshot" then it won't contact github (configured in SKYTUBE_UPDATES_URL) to check for the latest release - in other build configuration, it does it. If github returns a different version number as the latest release, the app will show a dialog about the upgrade, and the user can click on it to download it - and Android can install it.

[IzzySoft]

Thanks @gzsombor – but I don't compile (I don't even have an environment set up for that). The updater of the IzzyOnDroid repo fetches the APKs you provide, signed by you, from the releases here. Would it be possible providing a build of extra with one of the matching flavors?

[gzsombor]

Technically it is possible to create a new flavor, and release that one too everytime, but the current release process is very manual, so we need to improve that, before we could add another task to do it.

[IzzySoft]

Thanks for considering! Is there an (approximate) ETA when that could happen?