Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make Debuggable #12

Open
mentalisttraceur opened this issue Sep 15, 2020 · 2 comments
Open

Make Debuggable #12

mentalisttraceur opened this issue Sep 15, 2020 · 2 comments

Comments

@mentalisttraceur
Copy link

Please add android:debuggable="true" to the manifest, in the `<application ...> element.

This would allow users to use the run-as command in adb shell. This opens up a lot of flexibility, so much that I can't exhaustively list everything that a technical user might be able to do with it.

But among other things, it would give technical users another option for backup and restore of the app data (without the Google Cloud backups downside of allowing direct native Android backups like in issue #11 ), including private keys (avoiding the "your safety number has changed" thing), in a way that someone familiar with command line tools would find more convenient or easier to automate.

The only downside I can think of is that on a non-rooted device, a malicious party with physical access to your phone (including ability to unlock it) could access your Signal data with adb.

But I think with the features of this fork, anyone with that level of access could get the data in other ways too, so this is just adding the convenience of another way of doing it without any obvious additional security risk.

@johanw666
Copy link
Owner

adb backups would be useless for devices with Android 6 or higher, as I explained in #11 . I am considering a method to restore custom encrypted backups before registration to prevent the safety number warnings.

@mentalisttraceur
Copy link
Author

mentalisttraceur commented Oct 5, 2020

Use-case debuggability independent of backups: manually getting into the Signal sqlite database to modify settings which cannot be modified through the app itself.

Personally, I had to do that a couple years ago when I accidentally modified a contact color and I wanted to set it back to the default unset darker gray (rather than the manually settable lighter gray) and at the time I could only do this my modifying the database.

From what I hear, the default Signal backups are like this too - the actual scheduled time for the next backup is not exposed in the settings.

Point being: there's almost always the possibility of a user justifiably wanting to change a setting currently not exposed by the app's interface.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants