A Statement on Recent Events Between Signal and the Anti-Censorship Community

Post by h_anna_h » Tue, Feb 09, 2021, 3:50 PM UTC

FDSGSG wrote: post #14

nexthash wrote: post #8

It seems that a couple of security researchers from this community felt that Signal's implementation of a TLS-in-TLS proxy to allow its use in censored Iran didn't live up to their standards (it can be detected by censors and blocked). However, after Signal rejected this issue, they turned toxic and were prevented from posting anymore [1]. The above post is their reaction, which feels more like them lashing out rathe…

They even talk about their own inappropriate behaviour in this statement: >2021-02-06 12:00 @DuckSoft sended a pull request that adds the PoC to Signal TLS proxy's repository. It has since been deleted and both @DuckSoft and @studentmain were banned by the Signal organization on GitHub in the afternoon. A repost by @U-v-U was later closed and locked.

Post by dmix » Tue, Feb 09, 2021, 3:56 PM UTC

lovelearning wrote: post #120

hiq wrote: post #73

The answer from Moxie to these people: https://github.com/signalapp/Signal-TLS-Proxy/pull/15#issuec... I think that says it all. I'm also a bit concerned that "security researchers" don't seem to understand the threat model. Signal has never claimed to be able to hide that it was being used. The TLS proxy is only meant to help circumvent censorship, not obfuscate its protocol. And indeed, as a temporary solution, it'…

> Signal has never claimed to be able to hide that it was being used. From their blog post some days ago, I thought it did just that: > Unlike a standard HTTP proxy, connections to the Signal TLS Proxy look just like regular encrypted web traffic. There’s no CONNECT method in a plaintext request to reveal to censors that a proxy is being used. Valid TLS certificates are provisioned for every proxy server, making it m…

Post by olah_1 » Tue, Feb 09, 2021, 4:00 PM UTC

motohagiography wrote: post #128

olah_1 wrote: post #78

Earlier quoted context omitted.

> instead of forking and building solutions What would you fork? The signal server code that hasn’t been updated in almost a year[1]? If that is truly the same code that we use with signal today, would your fork work with this same network? Or would it be it’s own 1-server network all alone? [1]: https://github.com/signalapp/Signal-Server

Either fork the code, or fork a new effort that implements the things you want, and then share it with people who also want it. That these people think it is more viable to co-opt an existing product using organizing pressure for their ends than to build one someone actually wants and share it is indicative of their strategy and attitude. Project leaders need to recognize this tactic coming from afar and then exercis…

Post by zrm » Tue, Feb 09, 2021, 4:09 PM UTC

gclawes wrote: post #71

UncleMeat wrote: post #53

Earlier quoted context omitted.

Tone can often be more important than facts. At one point in my career I had a somewhat public facing role. I made a tough decision that aggravated a user, who decided to send me several death threats. Suddenly that tough decision wasn’t so tough anymore. Any possible resolution was gone. These situations involve people. We aren’t fact machines.

> Tone can often be more important than facts. Exactly: https://www.edge.org/response-detail/27181

Post by FDSGSG » Tue, Feb 09, 2021, 4:12 PM UTC

cmiles74 wrote: post #125

FDSGSG wrote: post #93

Earlier quoted context omitted.

>Bundle an Open source IME to be used when in incognito mode Is there a good open source IME? I thought Apple/Google/Microsoft haven't been able to ship a decent one and most people use Baidu's. > 2. Warn users when they switch to incognito that their IME may still be recording the words they type. Is a blanket "Your phone might be compromised, we can't help you if it is." warning actually useful? This doesn't really…

I don't think this framing of the issue is helpful in this case. The people who have installed a custom keyboard likely did so for a tangible benefit, they may not have understood the warning from the phone at installation time or they may have forgotten about the warning entirely. I think it is unreasonable to characterize these phones as "compromised" or these keyboard applications as "malicious". While some keyboa…