Question on permissions about songtube-app

[Artx-II]

That sounds reasonable, actually, I also think that's how it should be.

I made a new issue at #263 to start working on it.

[Artx-II]

Sure,

MANAGE_EXTERNAL_STORAGE is only and exclusively requested when editing a song's artwork or tags, since write permission is required to do this action.

READ_EXTERNAL_STORAGE is used to fetch all songs from the device.

REQUEST_INSTALL_PACKAGES is needed for the in-app updates.

If this clarifies everything feel free to close this issue, otherwise, just let me know.

[IzzySoft]

Thanks @Artx-II – added the first two to the allow list. As for the updater: is it opt-in or opt-out? Is explained where the APK is downloaded from? Are the implications clearly presented (e.g. they might bypass the extra screening in my repo¹)?

¹ no offense meant, but none of us is perfect – mistakes happen to the best of us. Wouldn't be the first time my scanner alerted of something that "slipped through" unintentionally.

[Artx-II]

When a new update is detected the app opens up a dialog with information like new version number, changes, etc... and a button to download and install the latest APK. Everything is extracted from this repository latest release and it's optional, you can simply choose to ignore and close it.

As for an explanation from where the update information and APK comes from, is not clarified in the app, I guess I should do that.

Here is the file from where the check happens and the information is extracted:
https://github.com/SongTube/SongTube-App/blob/development/lib/internal/models/update/update_manger.dart

And here is the dialog that pops up when a new update is detected:
https://github.com/SongTube/SongTube-App/blob/development/lib/ui/components/app_update_dialog.dart

That's all, let me know if I missed something!

[IzzySoft]

Hm, OK – that would not meet my repo's (or F-Droid's at that) inclusion criteria.

I guess I should do that.

If I might suggest for that:

• have an option in settings whether the app should update itself, initialized with NULL. With this option, add the details (where the APK would be fetched from, plus the implications I mentioned above) in its description
• on start of the app, if the option is NULL ask if it should be used or not (showing those details for an "informed consent"), then remember the choice
• now the other part can stay as-is, but update check is only performed when enabled

Those having installed from file (e.g. from releases here) can/will then choose to have the app perform the updates, those using e.g. my F-Droid repo can choose not to if they prefer the additional screening over "getting the update a few hours earlier".

That makes the updater checker opt-in, and thus meet the inclusion criteria. Functionality stays available, everyone happy (hopefully).

How does that sound to you? No "ultimatum" here, just trying to find the best way to deal with it.

[IzzySoft]

Thanks! I'll add REQUEST_INSTALL_PACKAGES to the allow-list when that's implemented then.