Live data from Hacker News

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

github.com

121–130 of 290 posts

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

#121
post #13
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…

What could have been the more productive way? If their issues are closed (and Signal does not seem interested in discussing this) and they feel like this is actively putting peoples lives in danger I feel they should call this out.

Following the project guidance on interaction, especially when directed specifically. Remaining cordial when engaged on the technical aspects, rather than throwing one's toys out of the pram the moment one is challenged. Avoiding excessive exaggeration of the issues as a tool to amplify one's point of view. By not immediately stomping around the project's places and throwing insults, factually incorrect accusations and orating about how one must be correct, rather than engaging in reasoned debate. By not drumming up a playground of like-minded people to assail those who disagree with one.

Nowhere in technical communities is this behaviour tolerable, productive or successful. This affair is painfully cringey to watch; it reads like a sugar-induced temper tantrum by a class of kindergarteners screeching at an adult that their juice cartons should be a different shape because corners are dangerous.

It would have been more productive if the group had not embarrassed themselves with every single action they've made.

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

#122
post #41

Earlier quoted context omitted.

The owners and maintainers of the product get to decide on how to handle issues like this one. But I’m not convinced that an “internet catfight” is a good enough reason for shutting down the conversation completely as it was done. I am aware that it’s totally unfair that signal owners should have to deal with this kind of behavior and not take strong measure like they did... I don’t really know what a good resolution…

> You were blocked because you know that we don't use GH for discussion, but came here anyway and started opening fake PRs so that you could post and harass other people on GH. > …If you want to discuss anything about circumvention or any other aspects of Signal in a way that is respectful to the rest of the community, please join in on the forums. https://github.com/signalapp/Signal-TLS-Proxy/pull/15#issuec... That…

he was banned on the forums too

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

#123

Earlier quoted context omitted.

> rather than resolving the issue productively Unfortunately it's not possible to productively resolve issues with the Signal team, something you can find documented again and again. (My own experience: I had to justify the the user impact of 30+sec freezes on every sent message, confirmed by multiple people. Bug was closed wontfix.) This is a known thing with Moxie and the culture he's created at Signal and it's unf…

But even then, there's really no point in trolling the PR section of Github besides griefing. Just fork the thing and make a better Signal if you believe so harshly that there's no hope with Moxie at the helm.

Even if one thought that this would help the people that need help on this matter, you can't really fork signal as it is today, I think. Or at least whatever it is that signal is using on its servers because that is very unlikely to be the software in its public repo, which hasn't been updated in almost a year. And even for a while before then, most of the commits were version bumps with no visible changes on the code.

If anything, that's another problem with signal that's not getting enough attention (that I've seen): It claims to be open source, but as of now, it doesn't seem to be. At least not in the servers.

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

#124

Earlier quoted context omitted.

> rather than resolving the issue productively Unfortunately it's not possible to productively resolve issues with the Signal team, something you can find documented again and again. (My own experience: I had to justify the the user impact of 30+sec freezes on every sent message, confirmed by multiple people. Bug was closed wontfix.) This is a known thing with Moxie and the culture he's created at Signal and it's unf…

But even then, there's really no point in trolling the PR section of Github besides griefing. Just fork the thing and make a better Signal if you believe so harshly that there's no hope with Moxie at the helm.

Just fork it isn't useful if they believe this is putting people in danger right now.

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

#125
post #93
post #60

Earlier quoted context omitted.

There are two practical options. 1. Bundle an Open source IME to be used when in incognito mode. 2. Warn users when they switch to incognito that their IME may still be recording the words they type. This isn't just about compromised phones. A 3rd party keyboard doesn't have to respect the incognito flag.

>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 keyboard apps are truly out to get people, this isn't the case for all of these applications and they meet a real need (i.e. foreign language keyboards).

As you say, a blanket warning that the customer's phone may be compromised is unhelpful. Warning customers who have a custom keyboard of the risks those keyboards pose (similar to the warning Android displays at custom keyboard install time)[0] could go a long way towards educating customers.

Signal markets itself as a one stop solution to privacy issues. I think it makes sense that they should outline the areas where they cannot, in fact, assure the customer's privacy.

[0]: https://support.swiftkey.com/hc/article_attachments/11501105...

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

#126
post #59

Elon Musk should tweet about Matrix. Signal team seems completely irresponsible here. Censorship in countries where this app could help puts opponents lives at risk and already led to executions.

+1 for Matrix. Signal is a honeypot.

It looks more and more like it.

I even wonder now if they don’t have ulterior motives.

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

#127
post #30

Earlier quoted context omitted.

Exactly, according to NGO's people get lashed and jailed for online activities. After Signal has been blocked being detected could actually endanger peoples life. https://freedomhouse.org/country/iran/freedom-net/2019 https://freedomhouse.org/country/iran/freedom-net/2020

Was the better solution here that signal does nothing?

Possibly, or at least make it very clear to users that they can still be detected.

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

#128
post #78

Even if I agree with the principles of the anti-censorship people, to be an activist to apply pressure on Signal for features instead of forking and building solutions is suspicious to me. Signal does a great job of frustrating mass interception, which I think was its original point. Inventing new criteria and re-framing their product as inadequate for this scope change as an activism play seems insincere. We can exp…

> 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 exercise their prerogative to reject meta- and political ploys. Sure, talk to users, get features, but pressure? Treat it like a weed.

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

#129
post #109
post #88

Earlier quoted context omitted.

"Important: Keyboards and IME’s can ignore Android’s Incognito Keyboard flag. This Android system flag is a best effort, not a guarantee. It’s important to use a keyboard or IME that you trust. Signal cannot detect or prevent malware on your device." https://support.signal.org/hc/en-us/articles/360055276112-In... Sure, the app should say that too, not sure if it does. Also, the small team of developers can only fix s…

That was only added 19 days ago - after months of people (politely) asking for it to be acknowledged as a serious concern. https://github.com/signalapp/Signal-Android/commit/0a29ffcf4...

Shouldn't Signal then also warn or refuse to work on Android versions with known vulnerabilities? Or if there are apps installed on the device with the accessibility permission?

Where would you say the line should be drawn?

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

#130
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…

[deleted]
Post reply on HN