Conversation

Replying to

and

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

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.

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.

Replying to

and

I tried to help to get the support for it upstream. It didn't really go well. People just kept getting discouraged by their response to it and giving it. Eventually Moxie ended up rewriting it mostly to add a big scary warning even though it can be done properly without issues.

Replying to

and

Hard to recommend it anymore when I don't have confidence it's going to get better rather than worse and things that are important to our community like first class support for no Play Services, keeping database at rest, attack surface reduction options, etc. seem unwanted.

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