Question on permissions

[IzzySoft]

My scanner reported for the latest APK:

! repo/com.octo4a_1002006.apk declares flag(s): usesCleartextTraffic
! repo/com.octo4a_1002006.apk declares sensitive permission(s): android.permission.CAMERA
  android.permission.READ_EXTERNAL_STORAGE android.permission.SYSTEM_ALERT_WINDOW

May I ask for clarifications on those? CAMERA is clear as it's mentioned in the Readme. usesCleartextTraffic I assume is only for the connections to the printer (didn't check if there's a network security policy set up). The other two I couldn't figure (and wouldn't mind a short explanation for the rest 😉)

Thanks in advance!

[hhocker]

{READ | WRITE}_EXTERNAL_STORAGE makes sense to me. There is an opportunity to store files or the application on the external drive. To access those files it will need READ permissions. It may also allow external thumb drives or similar for loading large gcode files.

The SYSTEM_ALERT_WINDOW permission appears to be for hijacking the screen with critical alerts (https://stackoverflow.com/questions/38045472/android-system-alert-window-permission). Having looked through the code and experienced this there are some pop up windows that demand action be taken ("Battery optimization still enabled, disable? ignore?") but it could be used if the permission is correctly granted (which might not be automatic since it is a sideloaded app) to pop up alerts over the top of other apps. I have heard of folks using an OctoPrint GUI app on their phone with Octo4A hosting OctoPrint server in the background. If a disconnect event was detected an alert could be put up on the screen alerting the lost connection. Otherwise I think it is simply to get access to the popup dialog builder from what I have found in the code.
FeelFreeLinux has clarified below and I can find nothing in the code supporting this supposition.

@feelfreelinux would have to explain better but I can take a crack at what I can see from the code:

• ACCESS_NETWORK_STATE, ACCESS_WIFI_STATE, CHANGE_NETWORK_STATE: These 3 are likely used together in NetworkStatusViewModel.kt to monitor the device's IP address and display it accordingly if it changes. These permissions are needed to read the current IP and to get a notification from the system if the network should change (say a wifi router reboots and suddenly network is down then back up under a new IP.
• CAMERA: Create the virtual webcam and create the MJPEG stream Octoprint uses
• FOREGROUND_SERVICE: From what I can see in OctoPrintService.kt this is used to put the OctoPrint container into a priority service running alongside but independent of the main UI. This is how OctoPrint is able to keep running and not get paused by being in the background
• INTERNET: Somewhat obvious, this allows the app to go and request updates / new plugins
• READ_EXTERNAL MEMORY/WRITE_EXTERNAL_MEMORY: Likely as easy as allowing the app to browse SD cards or other USB connected devices for files
• RECEIVE_BOOT_COMPLETED: This is likely needed to ensure that the OctoPrint server is not started prematurely before network and USB stacks are initialized allowing the "Start Octo4A on boot, start OctoPrint on launch" option to be more reliable.
• REQUEST_IGNORE_BATTERY_OPTIMIZATIONS, VIBRATE, WAKE_LOCK: Allows the app to request full operating power at all times. Ignores special power states and overrides the system lock timer setting itself to 10 minutes from what I can see in Octo4aWakeLock.kt. Vibrate permission will disable vibration on alerts as the hosting device is likely mounted to the printer.

I would need to do a much deeper dive into the system but most of everything seems good and I think the SYSTEM ALERT DIALOG is merely to create modal dialogs inside the app and not interfere with any other software. Overall a pretty clean app.

[IzzySoft]

Thanks @hhocker – I know what the permissions mean, my question was rather how they are utilized here. I've adopted some of your list – but e.g. CHANGE_NETWORK_STATE is no read-access AFAIK but used to toggle the connection on/off.

INTERNET: Somewhat obvious, this allows the app to go and request updates / new plugins

So one downloads plugins from inside the app? And updates are not shipped as updates to the app itself? Would make sense for drivers and Octoprint software probably indeed, if the app mostly provides the GUI. But what's more obvious is the need to access the device for monitoring.

Likely as easy as allowing the app to browse SD cards or other USB connected devices for files

What files? I guess WRITE might be needed to install the Octoprint drivers/software (and if READ were not requested explicitly it'd be granted implicitly then anyhow due to the presence of WRITE (btw, it's READ_EXTERNAL_STORAGE, not _MEMORY 😉).

The "chocolate" ones are the ones mostly needing an explanation, as they are considered sensitive there. So I hope for one of the devs to chime in for clarification.

Meanwhile, thanks for providing your details!

[hhocker]

So one downloads plugins from inside the app? And updates are not shipped as updates to the app itself? Would make sense for drivers and Octoprint software probably indeed, if the app mostly provides the GUI. But what's more obvious is the need to access the device for monitoring.

There would be two reasons for the internet usage. First the application will download the latest version of OctoPrint on first install. Then once the OctoPrint system is nested inside the container it will want to access the internet and check for updates and download plugins. Octo4A essentially creates what I would describe as a Docker container inside the app and runs the OctoPrint python system inside that. I dont know if the proot container can directly access the internet or if it proxies through the app.

What files? I guess WRITE might be needed to install the Octoprint drivers/software (and if READ were not requested explicitly it'd be granted implicitly then anyhow due to the presence of WRITE (btw, it's READ_EXTERNAL_STORAGE, not _MEMORY 😉).

Most likely any GCODE files stored externally so it can be loaded. Though I can see where there might be used for the proot container stored. Filip will need to confirm usage.

The "chocolate" ones are the ones mostly needing an explanation, as they are considered sensitive there. So I hope for one of the devs to chime in for clarification.

What are your concerns with them? I am not super familiar with all of the Android security as I have just started working with it. I presume unfettered READ_EXTERNAL_STORAGE would allow the app to view anything on the card, potentially collecting data?

I am also confused what the SYSTEM_ALERT_WINDOW would allow the application to do? Hijack a form on another application?

Meanwhile, thanks for providing your details!

[hhocker]

Digging a bit more into the SYSTEM_ALERT_WINDOW permission it might be a kludge to be able to force the Octoprint container foreground service. Take a look at this: https://developer.android.com/develop/background-work/services/foreground-services#background-start-restriction-exemptions

It appears that background services, provided they have the SAW permisson can start a foreground service. I wonder if this is how the system does the on boot launch. Filip will have to explain the code flow better as I am not fully following the code flow yet.

[IzzySoft]

There would be two reasons for the internet usage

Thanks for the insights! I've updated the description a bit (could not put everything into it as it has to be short).

Most likely any GCODE files stored externally so it can be loaded.

I'm not familiar with Octoprint (or 3D printing in general), so please forgive me if my question sounds a bit stupid: Those files one would manually place on external storage (like files from Thingyverse) for printing? Then it's pretty clear to my why those do not simply go to the app's "private storage" indeed. Didn't think of that, d'ooh…

would allow the app to view anything on the card, potentially collecting data?

And together with the INTERNET permission (or via intent of some other app having it, like system webview) send them off-device. Yeah, that would be one example. So listing what they are intended for is to create some transparency and build up trust.

I am also confused what the SYSTEM_ALERT_WINDOW would allow the application to do?

That was e.g. used in the past by malicious apps, creating overlays over other apps to grab sensitive information (input then went to the overlay while one thought to put it into the underlying app). For this there are protective measures in place meanwhile, but there are other "use cases". I'm not saying Octo4a (or any other app with this permission listed in the IzzyOnDroid repo) would do such shady things – but again this is for transparency and building up trust to show what it's needed for.

Thanks for your digging in; indeed I've been given comparable reasoning for this in connection with background/foreground services on other apps. Waiting for Filip to confirm then before I put in something we're not sure about.

[feelfreelinux]

Hi! Sorry for the lack of reply - got a bit lost in the notifications. Thanks a lot @hhocker for digging into the code :) Internally, octo4a works on quite a lot of odd hacks and workarounds, that are not exactly self explanatory. I'll try to give a quick rundown of the more suspicious permissions.

Digging a bit more into the SYSTEM_ALERT_WINDOW permission it might be a kludge to be able to force the Octoprint container foreground service. Take a look at this: https://developer.android.com/develop/background-work/services/foreground-services#background-start-restriction-exemptions

As far as I remember, this is correct. To be exact, this is used to make the "launch app on boot" feature work. While, just registering the boot receiver allows the app's service to run on boot, it does not allow the boot receiver to explicitly start the app's activity on start. However, Android does make an exception for apps with SYSTEM_ALERT_WINDOW permission. Octo4a is supposed to work on devices headlessly, with minimal interaction needed from the user - hence I did not want to rely on user clicking a notification.

I've adopted some of your list – but e.g. CHANGE_NETWORK_STATE is no read-access AFAIK but used to toggle the connection on/off.

To build a complete list of network interfaces + their assigned addresses, octo4a needs to use the NetworkRequest.Builder() / ConnectivityManager.requestNetwork API, which requires the CHANGE_NETWORK_STATE permission, to properly iterate the network interfaces.
https://github.com/feelfreelinux/octo4a/blob/master/app/app/src/main/java/com/octo4a/viewmodel/NetworkStatusViewModel.kt#L64

READ_EXTERNAL MEMORY/WRITE_EXTERNAL_MEMORY: Likely as easy as allowing the app to browse SD cards or other USB connected devices for files

While octo4a's linux bootstrap works inside of /data/data/com.octo4a/files, the .octoprint folder is mounted to user's external storage directory. OctoPrint then both reads and writes into that folder - eg, for configuration, storing gcodes, whatever else. I decided to mount it inside of the external storage directory, to make it possible for the user to easily back-up, or modify the octoprint's config directory. People often use it to access timelapses made with octo4a :)

So one downloads plugins from inside the app? And updates are not shipped as updates to the app itself? Would make sense for drivers and Octoprint software probably indeed, if the app mostly provides the GUI. But what's more obvious is the need to access the device for monitoring.

Octo4a tries to mimic the experience of someone running OctoPrint on some Linux SBC. The underlying Alpine Linux bootstrap has a full access to network, mostly used for performing updates, and for installation of plugins. The app can also optionally run an SSH server, allowing the users to customize the Alpine Linux environment manually. The plugins are downloaded from OctoPrints plugin repository - so this does technically allow for an execution of arbitary binaries, and is a security risk to some degree.

To be completely honest, by design octo4a is not something you would like to run on your daily driver phone. People usually use the app on old unused phones, tablets and tv boxes - those devices don't exactly have sensitive data on them to begin with.

[feelfreelinux]

Ah, also regarding the anti-features listed in IzzySoft repo - the bugsnag reporting is opt-in with a dialog asking for permission on first boot, and users can always change their mind through the app's settings. Does it still count as the Tracking anti-feature?

[IzzySoft]

got a bit lost in the notifications

Ha! Welcome to the party. I know exactly what you're talking about there 🙈

SYSTEM_ALERT_WINDOW

Talk about Android permissions being transparent to us "mere mortals". This is now the second time I get this explanation, so I totally believe it – especially with your elaborations on it, which I got for the first time now. Before I just facepalmed about the logic (well, there are worse things: permissions which are no permissions at all, like DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION). Thanks a lot for explaining! Will update that in my permission explanations ASAP so I cannot forget.

CHANGE_NETWORK_STATE

Tack. Next one. It's not changing anything but you need a permission named CHANGE_something. And then one wonders about those becoming suspicious (or giving up to even try understanding). Well, for octo4a we'll help that by making it transparent. Adding that now as well, thanks again!

READ_EXTERNAL_STORAGE / WRITE_EXTERNAL_STORAGE

Thanks, updated accordingly!

so this does technically allow for an execution of arbitary binaries, and is a security risk to some degree.

Yeah – and comes close to violate the IzzyOnDroid App Inclusion Policy:

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.

But only almost. It won't download things by itself (but only on explicit request), and hopefully also makes clear where it's downloaded from. As the app works fine without any of those, I guess the NonFreeNet anti-feature can be skipped, too – or should we rather add that for transparency, with a proper explanation, as the Alpine bootstrap will be downloaded from "somewhere", too?

NonFreeNet: The app downloads the Alpine Linux bootstrap and Octoprint binaries from XXX (and also lets you download Plugins from YYY)

(XXX and YYY would need to be replaced properly of course)

octo4a is not something you would like to run on your daily driver phone

Nope, certainly not. But as you write yourself: it's a very good use-case for your otherwise abandoned "older device". Unless of course you take along your OctoPrinter on your "daily drives" as well, then the term "daily driver" would need to be clarified 🤪

bugsnag reporting is opt-in with a dialog asking for permission on first boot

Ah, thanks for pointing out! Yes, then of course that anti-featue can be removed (just done that, effective with the next sync around 6 pm UTC).