Conversation

Replying to

and

If they used the modern approach for storage access on Android instead of the deprecated approach, users could also choose to store the backups on the sync service of their choice. That's what this thread is about:

Quote Tweet

Daniel Micay

@DanielMicay

Jun 30, 2020

Replying to @moxie @RichFelker and 2 others

Backing up locally via SAF works fine. No need for the deprecated Storage permission. The app can request persistent access to a directory for backups and the user just chooses the backup directory via SAF and the app. Can't something similar be done on iOS via their equivalent?

Replying to

and

The tweet from

that I'm replying to there is strange. He's a very experienced Android developer. I'm also sure he knows Signal on Android has full local encrypted backup support via a strong app generated key. He must know Signal could ask the user for a backup directory.

Replying to

and

SAF will open up the system file manager and have the user choose a directory for backups. They can choose to use an app-based storage provider like a sync service. That is absolutely not going away. What's deprecated is the Storage permission for requesting bulk home dir access.

This Tweet was deleted by the Tweet author. Learn more

Replying to

and

Problem is I feel I was engaging in a polite and constructive way and got blocked by

@moxie

for this tweet: twitter.com/DanielMicay/st. I don't consider a weak PIN + SGX secure. UX encourages weak PIN. We all users don't choose good passphrases.

Quote Tweet

Daniel Micay

@DanielMicay

Jul 9, 2020

Replying to @chrisrohlf @signalapp and @moxie

Hopefully as a toggle so that it's still possible to have a registration lock PIN without contact syncing, as it was before this was introduced. Most people are going to use the defaults so that's what really matters, and a user-generated PIN + SGX is not a secure approach.

This Tweet was deleted by the Tweet author. Learn more

Replying to

and

Well, I'm confused, because he was actively responding to people who seemed to just want to dunk on Signal with weak criticisms but he doesn't acknowledge my questions / concerns. I use it, consider it the best (least bad?) option available and have promoted it to our community.

Replying to

and

Didn't seem to want to acknowledge my questions / concerns though and ended up just blocking me. I wasn't even trying to message him in that thread, he was just tagged in it like this one unintentionally because the person I responded to did a mention. Don't really get it.

This Tweet was deleted by the Tweet author. Learn more

Replying to

and

I might. Our community already has the feeling of our input and contributions not being welcome upstream. There are some rough experiences already. I wasn't very involved in most of it myself but the feeling I get is that even informed input / discussion is not really wanted.

Replying to

and

So for example, Signal encrypts the database on Android using the hardware-backed keystore. It could set that key to require the device to be unlocked, and purge secrets from memory when the device is locked. Lots of people want it. Signal won't even explicitly reject it though.

3:47 PM · Jul 10, 2020Twitter Web App

Replying to

and

They just won't really engage in a real discussion. github.com/mollyim/mollyi is a fork implementing keeping the database at rest with a passphrase by someone in our community. Signal already uses HW keystore and could set key as requiring unlocked device + keep at rest like this.

github.com

GitHub - mollyim/mollyim-android: A fork of Signal for Android with passphrase lock

A fork of Signal for Android with passphrase lock. Contribute to mollyim/mollyim-android development by creating an account on GitHub.

Replying to

and

Similar experience with using Signal without Play Services. Originally, SMS-based TextSecure worked without it. It became dependent on it for push notifications. Community forks added support for running without it. Upstream seemed to have disdain for supporting it.

Show replies