search

undergroundwires / privacy.sexy

Open-source tool to enforce privacy & security best-practices on Windows, macOS and Linux, because privacy is sexy
https://privacy.sexy
GNU Affero General Public License v3.0
3.59k stars 152 forks source link

Android support? #324

Open Rudxain opened 2 months ago

Rudxain commented 2 months ago

Problem description

3 OSes is nice, but including Android would be better. Especially considering each OEM has its own "distro", and some of them can be very privacy-invasive (looking at Xiaomi and Samsung)

Proposed solution

A checklist of settings to change manually

Alternatives considered

Automated scripts would usually require root access (which is out-of-the-question for users who have fully-locked bootloaders). This is why I propose a manual checklist, as GUI Settings and ADB config cmds are more accessible.

Additional information

Some scripts (such as shell history clear) can be executed on Termux without elevated privileges, and those are already included in the "Linux" section

femdiya commented 2 months ago

While this... can be a great idea but this service is never ment to run on mobile devices. Although yes, using root we can do much more but ADB is very limited in the terms of customization.

account183892 commented 2 months ago

Maybe a version that uses ADB and a root version also?

undergroundwires commented 1 month ago

Hi, so we have two ways to go:

  1. Provide scripts for Termux.
  2. Provide scripts to run through ADB.

So I wonder which option should be more suitable, and what we can do on non-rooted devices with each option. Seems like we can do more with ADB.

femdiya commented 1 month ago

Hi, so we have two ways to go:

1. Provide scripts for Termux.

2. Provide scripts to run through ADB.

* Correct me if I'm wrong here but Termux is very limited on non-rooted devices right? It cannot even delete apps.

* With ADB, we can easily build a "remove bloatware" section for different brands. But is there more we can do there for non-rooted devices?

So I wonder which option should be more suitable, and what we can do on non-rooted devices with each option. Seems like we can do more with ADB.

Android user here, Yes, Termux supports root but it's very limited on unrooted devices. ADB is the best option here, but I suppose that user needs to execute the commands manually (?)

undergroundwires commented 1 month ago

On desktop version, we can provide a GUI/Wizard to go through ADB process. It may install ADB automatically or guide on how to install, select device, instruct what to do on mobile phone step by step through a GUI. We can run it when the user clicks on "Run" button. How does it sound?

On some scripts we can do root check using adb, if the device is rooted then execute otherwise show a warning, on scripts supporting non-root they can run directly.

Is there anything more that we can do through adb rather than "Remove bloatware" (remove packages) and "Privacy cleanup" (cleanup some folders)?

account183892 commented 1 month ago

femdiya commented

Termux can execute shell scripts as root with su.

Rudxain commented 1 month ago

Provide scripts to run through ADB.

ADB can run on Termux. The setup process is clunkier because a ADB/TCP/IP/WiFi connection must be established. This must be done via USB (on older versions), but newer Android versions don't require USB for setup.

Termux is very limited on non-rooted devices right?

Yes, but there's a plugin to access the Android API, although it's much more limited than other apps such as Tasker, Macrodroid, or Llamalab's Automate.

"remove bloatware" section for different brands.

UAD aims to solve this. It doesn't have scripts, but users can select all packages from some category, then disable them all via ADB-over-USB.

is there more we can do there for non-rooted devices?

Settings. I bet Xiaomi has tons of privacy-invasive settings. Samsung and Google both request usage stats, and have similar tracking settings. Since those settings are tied to the OS instead of an app, debloating alone can't help here.

Google Play Services has settings such as "Advertising ID", and that pack can't be disabled safely on some devices. Even when G.P.S. can be uninstalled/disabled, it provides APIs that most Play Store apps depend on. Discord doesn't even work at all when G.P.S. is disabled (which is funny, because WhatsApp works ok, except for background messages), but I would argue that's the devs' fault for purposefully depending on it (the web app works fine without G.P.S.), and Discord+uBO is recommended anyways, so users shouldn't be using the native app

account183892 commented 1 month ago

Provide scripts to run through ADB.

ADB can run on Termux. The setup process is clunkier because a ADB/TCP/IP/WiFi connection must be established. This must be done via USB (on older versions), but newer Android versions don't require USB for setup.

Termux is very limited on non-rooted devices right?

Yes, but there's a plugin to access the Android API, although it's much more limited than other apps such as Tasker, Macrodroid, or Llamalab's Automate.

"remove bloatware" section for different brands.

UAD aims to solve this. It doesn't have scripts, but users can select all packages from some category, then disable them all via ADB-over-USB.

is there more we can do there for non-rooted devices?

Settings. I bet Xiaomi has tons of privacy-invasive settings. Samsung and Google both request usage stats, and have similar tracking settings. Since those settings are tied to the OS instead of an app, debloating alone can't help here.

Google Play Services has settings such as "Advertising ID", and that pack can't be disabled safely on some devices. Even when G.P.S. can be uninstalled/disabled, it provides APIs that most Play Store apps depend on. Discord doesn't even work at all when GPS is disabled (which is funny, because WhatsApp works ok, except for background messages), but I would argue that's the devs' fault for purposefully depending on it (the web app works fine without G.P.S.), and Discord+uBO is recommended anyways, so users shouldn't be using the native app

Shizuku can be ran in termux, but it does the same as executing commands from ADB, just with a computer connected once

Rudxain commented 1 month ago

Shizuku can be ran in termux

True. There's a button to "use in terminal apps" that provides a script that can be executed by Termux.

just with a computer connected once

Shizuku setup is almost the same as ADB on Termux. There's no need for USB on newer Androids.

However, Shizuku makes pairing+connection less annoying:

IIRC, Shizuku has a "keep-alive" feature that keeps Wireless-Debug enabled until the user disconnects (or wifi is turned off). Termux, OTOH, lets the OS disable WD after a period of inactivity.

[!note] WD is the "developer setting", not adb, nor shell user

account183892 commented 2 weeks ago

Shizuku can be ran in termux

True. There's a button to "use in terminal apps" that provides a script that can be executed by Termux.

just with a computer connected once

Shizuku setup is almost the same as ADB on Termux. There's no need for USB on newer Androids.

However, Shizuku makes pairing+connection less annoying:

  • It shows an input notification that asks for the pairing PIN, which is better than multi-window.
  • It auto-detects pairing and connection ports. I have no idea how it does it so fast, it cannot be port-scanning.

IIRC, Shizuku has a "keep-alive" feature that keeps Wireless-Debug enabled until the user disconnects (or wifi is turned off). Termux, OTOH, lets the OS disable WD after a period of inactivity.

Note

WD is the "developer setting", not adb, nor shell user

You can add a button to quick settings to toggle Wireless Debugging.

undergroundwires commented 2 weeks ago

I'm noob to Android and modding it. So I appreciate all discussions about it.

To be able to run su in Termux you need to root the phone right? Without rooting, it cannot configure the system,or delete files/apps, basically a sandboxed emulation of a unix shell, which is useless.

Looking at AndroidManifest.xml we can see that a lot more permissions are granted to ADB.

Using ADB we can actually:

ADB on Termux (which I did not know about as @Rudxain mentions) seems to remove the need for USB cable and PC connection and allow us to run adb CLI directly on Termux if I understand this correctly.

In that case we can have some explanation on UI about how to get ADB running and then provide scripts utilizing ADB commands like (examples):

I'm not sure how to utilize Shizuku and if allows adb CLI usage as above.

I'm very interested in what other settings we can configure as you mentioned @Rudxain.

Does it make sense to create "Android" collection and adding these commands. To start with, we can add a dialog explaining how to get going with ADB using Termux or PC on the UI.

Rudxain commented 2 weeks ago

you need to root the phone right?

Yes, but there's tools like Magisk, which allow rooting without sacrificing too much of its benefits.

Without rooting, it cannot configure the system

Well, the settings cmd (typically used via ADB) can be run on Termux, with some caveats.

delete files/apps

If Termux (or any app) has "Access to all files" permission, its commands have it too. Of course, "All files" refers to user files. It cannot delete the data within other apps (such as cache).

Apps can request a "Request delete package" permission. But, as the name suggests, it requires manual user confirmation. Termux doesn't request this permission, but LL-AM does. Termux can communicate with LL-AM in many ways (Tasker plugin, user file-system, etc...), and we just need a "flow" for that.

basically a sandboxed emulation of a unix shell

Sandboxed: yes. Emulated: no.

Apps can execute arbitrary programs (execve I guess?), as if they were Linux users (they are). They just need the proper permissions. Some programs may be executable, but have partial functionality.

Apps targeting A10 cannot execute writable storage. Basically W^X applies to file-system as well as memory.

Android's shell is MKSH, but Termux uses Bash by default.

I'm not sure how to utilize Shizuku and if allows adb CLI usage as above.

The script I mentioned should support that. I don't remember how to use it. The Shizuku app documents it. IDK why the docs aren't available online.

Here's the developer docs, just-in-case I missed something.

I'm very interested in what other settings we can configure

AppOps unlocks many possibilities! Such as disabling clipboard access, background location, etc...

Shizuku dev made an app to manage them.

Does it make sense to create "Android" collection

Anything Android-specific should be there. Cross-distro stuff is already handled by the Linux collection

Rudxain commented 2 weeks ago

other settings

There are OEM-specific settings. Samsung has had a lot (~200) in the history of Galaxy devices.

Apps like LL-AM expose hidden features such as secure (there's also global and system) settings, unreachable app activities, services and broadcasts, etc... I recommend that sort of apps (such as Tasker and Macrodroid) to get a glimpse of the hidden stuff.

WRITE_SECURE_SETTINGS can be requested in the AndroidManifest.xml (IIRC, Termux does it), but needs a one-time adb shell pm grant, and (for some reason) apps cannot configure arbitrary secure settings (such as display resolution, unless calling the WindowManager API or executing adb shell wm size)

undergroundwires commented 2 weeks ago

ADB commands

🔍🧐 Please provide any docs/projects about what we can configure regarding privacy using adb on Android.

I think we decided that we'll provide a script collection based on adb commands and we have the consensus on this as way forward.

@Rudxain, I checked @ionuttbara's melody_android and it looks nice and provides some nice tweaks.

Mobile app - Packaging

@plantindesk suggests in https://github.com/undergroundwires/privacy.sexy/issues/353#issuecomment-2088813411 that:

We can use Native Script (Free) and Expo (Free-Limited in deployment) for android support As all is dependent upon vue Nativescript is best

This is more about providing the Android package rather than the scripts. I checked Nativescript after your suggestion and it will require re-building the app, which would be too much.

I think publishing privacy.sexy as PWA (progressive web app) would be the easiest option. vite-plugin-pwa seems to simplify this. It can then be pushed to Play Store etc. Google provides a CLI (bubblewarp) to turn PWA to Android APK that can be published.

A PWA cannot run the scripts as I understand, but it can give more offline experience to copy paste the scripts into Termux. This is sad as desktop version adds desktop-native functionality but mobile version will not be able to do that, but rebuilding a complete new app using Nativescript is too much time consuming and is not on my radar.

I read your posts @Rudxain and try to follow. Almost all of this stuff is new to me, so I may be missing some points or misunderstanding stuff. Feel free to guide us through this implementation.

Rudxain commented 1 week ago

PWA cannot run the scripts

I'm confident in that being true. AFAIK, PWAs (bubblewraped or not) cannot access the Android API (unless indirect, such as Web File API), let alone the Linux ABI (execve).

BTW, converting the existing website into a PWA should be pretty straight-forward. So the offline experience can be achieved easily

Rudxain commented 1 week ago

I just remembered that ADB can work via WebUSB, so I would expect wireless-debug to also work via WebRTC. Since ADB is just an application-layer-protocol, it works over:

And indeed, it does seem like it should work via WebRTC!

BTW, last time I checked, Firefox refuses to support WebUSB because Mozilla deems it unsafe/insecure. Chromium browsers support it, though