Live data from Hacker News

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

github.com

161–170 of 290 posts

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

#161
post #149

Earlier quoted context omitted.

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…

I think jsiepkes addressed this quite well in a sibling comment: >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?

I don't see how this is related... In this case they are talking about known vulnerabilities on specific Android versions. Here we are not talking about a specific vulnerability but about the way Android works and how custom keyboards function.

Perhaps the accessibility permissions are relevant. If Signal could detect these settings and warn the customer if these settings are egregiously open, that would be a valuable feature in my opinion. To me, support for older versions of Android sound like an entirely different discussion.

Signal does include the "incognito" function[0]; Signal is already taking some steps to address the issue. However I'd argue that many people have likely forgotten that they ever installed a custom keyboard and if it was pre-installed on their phone they may not be aware of it.

[0]: https://support.signal.org/hc/en-us/articles/360055276112-In...

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

#162

Reminds me of the way that signal handled RealSexyCyborg's report of how 3rd party keyboards often leak data.

By blocking people that abuse them and by having rational debate drowned out by drum beats? I agree.

No, do not put words in my mouth please.

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

#163
post #146

Earlier quoted context omitted.

I do not see any evidence of this in said quote.

You don't see why making such a pull request would be inappropriate? Do you understand what pull requests are for? Does this look like an attempt at productive contribution to you? https://github.com/signalapp/Signal-TLS-Proxy/pull/15 Is this a good patch? It just drops a random file into the repo. https://github.com/signalapp/Signal-TLS-Proxy/commit/40f4d9d... These people decided to abuse the pull request system af…

This has nothing to do with my post.

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

#164
post #65

Earlier quoted context omitted.

How exactly do both parties sit down to discuss their grievances when the incumbent party is clearly banning the party with a different perspective?

They're banning the other party for their abusive language and behaviour, for their unsubstantiated, bad-faith claims of suppression and for misusing project resources. On top of the fact that they're not listening to why their assertions are incorrect. Any party acting in such a belligerent, infantile manner is going to be banned since they have proven they cannot act like grown-ups in a grown-up setting.

That's a fair point and I agree with you. Something I've been wondering as of lately, what can we (as a society) do to move off the edge of high emotions? I feel as if it's a common theme anywhere I look.

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

#165
post #21
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…

It's more important how we all feel about each other and our drama than the fact there isn't a currently easily available obvious way to have private secure conversations. Your "they are not being constructive enough" is actually very unconstructive, because it drags the conversation into more drama. The tone is not more important than the facts. It never is. Im not suggesting you have some alternative motive to defl…

>The tone is not more important than the facts. It never is

I think this framing is wrong. Tone and facts are both important (often equally so) and must both be addressed in parallel tracks.

If someone rudely raises concerns about the security of your product, it's fine to ban them as long as you also address their claims of insecurity. You can kill a community by not addressing claims of technical flaws and you can kill a community by not enforcing standards of conduct within it.

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

#166
post #31

Moxie - and the Signal team - seems to have a real issue taking feedback from outside experts. See the way he has been completely dismissive of the IME vulnerability highlighted by Naomi Wu and others. I remember back when it was TextSecure - I tried to raise some usability and security issues. First I was ignored, then dismissed, then - a few years later - they implemented some of the changes. I still use Signal. Bu…

I've submitted 10+ signal bug reports (none security related) going back to the TextSecure days. I've never had any rude or dismissive responses from the team, but have had my issues hijacked by other people with the issue being overly demanding or rude.

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

#167
post #159
post #119

Earlier quoted context omitted.

>is that a warning is better than lulling people into a false sense of security. But in the end any such warning is meaningless as it can't possibly be acted upon. >Again, your phone may not be compromised but your IME could still be malicious. If you're using a malicious keyboard app I think it's fair to say that your phone is compromised.

It can be acted on: you can realize that you probably shouldn't talk about everything using Signal despite the person urging you to install it swearing that it's secure. (which was the exact event that was given as a reason to add this: some journalist telling Chinese students(?) to use Signal to talk to them freely)

Should Signal then come with a blanket warning “Do not trust Signal!”?

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

#168
post #21

Earlier quoted context omitted.

It's more important how we all feel about each other and our drama than the fact there isn't a currently easily available obvious way to have private secure conversations. Your "they are not being constructive enough" is actually very unconstructive, because it drags the conversation into more drama. The tone is not more important than the facts. It never is. Im not suggesting you have some alternative motive to defl…

People respond poorly to abuse. This is basic human nature, trying to fight against this is a fool’s errand.

I agree, it is a chain of poor responses to abuse, these people probably considered the original response that they got (along with having their pull request deleted) as an abuse which is why they responded in that way.

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

#169

A group of security researchers who: * Publish the exploit before vendor know it * Publish the exploit before vendor delivered the patch * Send their own opinion to every media possible (including ycombinator) without mentioning the full event, and using new account to looks more neutral * Disrespect other people * And also have their own "secure" software (v2fly, v2ray, ...) Okay, looks like we need to have a new de…

> * Publish the exploit before vendor know it

> * Publish the exploit before vendor delivered the patch

It's called full disclosure and it is the only ethical way to handle it.

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

#170
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.

Here is how we do things, we responsible security researchers. Do things by following steps:

1. Is this a security vulnerability, or simply a bug? If just a bug, send to Github Issue, or send to the user forum, according to the maintainer's instruction (Signal use the forum, instead of issue). If this is a security vulnerability, go to step 2.

2. Is there a secure channel to contact software provider, or the provider can give a secure channel? For Signal, the best way is open a issue to say "hey we found a vuln, any PGP pubkey i can trust". If they did not provided after 14 days, go to step 4b. If they provided, go to step 3.

3. Contact with the provider and tell them what this vulnerability is, and how to fix it. Now, it's provider's responsibility to track down the bug fix flow. If they fixed it, delivered it, and told you their customers are all safe now, go to step 4a. If anything else happened (e.g they refused and think this is not a bug), or 90 days passed, whichever comes first, go to step 4b.

4. Finally:

4a. In this case, vendor fixed everything, patches should have been delivered, so whatever those vendor thinks about, you can just write a blog and says "i found a vulnerability in some software, here is the PoC". If you have a CVE number, congrats, now you can write an article about it. Now things are all done, and you can hunt next bug if you want.

4b. In this case, either vendor does not want to fix this bug, they failed to fix this bug in time, they failed to manage their software in time, or they just don't want to give a thing about you. This is the vendor's failure, not yours. So now you can write a blog and says 'here is a 0 day, try it if you want, have fun'.

So this is a general ruleset of how we do things. The word, "Productive", especially when it is used to describe doing a job very quick, is sometimes in contradiction of our primary object. We are fuzzing and digging for vulnerabilities to *make users safer*, instead of *being productive*. To protect users, protect ourselves, and protect everyone from being attacked by evil maids, we (responsible security researchers) all agree following this rule, to ensure everyone can make profit from finding vulnerabilities. If I failed to tell you what is a responsible disclosure, search it on Wikipedia. Most teams are following this rule, including Project Zero from Google, MSRC, Amazon's bug bounty, BugCrowd, and thousands of other platforms/teams.

Let's go back to the topic: Why I think those people are gangsters?

1. They directly send the full exploit, not even a simple PoC. This is far beyond the basic consensus. Once they made that, all rules above is no longer suitable, because they are just responsible security researchers. I don't think they deserve any CVE numbers, or any other vulnerability program's credit, except for an warrant from FBI, or China's MPS, since this is simply a criminal behavior.

2. Closing an issue does not mean ending an talk. Signal's team clearly said they should go to the forum, but they are simply not following the rule. Signal also have a bounty e-mail (https://support.signal.org/hc/en-us/articles/360007320791-Ho...), but clearly those gangsters just ignored it, or they will fill their mailbox with PGP signatures.

3. They claims this is a vulnerability, but they are just not treating it as a vulnerability, since they simply did not think releasing PoC is a risk for users - fun fact, security for users is their weapon for all articles they have published, including to the bleeping computers (https://www.bleepingcomputer.com/news/security/removal-notic...).

4. In a private Chinese group, one of the author's followers commented on this event: "They should just use V2Ray for that", and the author replied with agreement: "Why build your own software instead of using good old ones?". I believe this is enough for me to believe they are not having a good faith to Signal, or users of Signal.

Let's leave there and find more vulnerabilities of GFW, instead of Signal. This is just a amusing joke, presented to you by some V2Ray authors, to propaganda their own software.

Post reply on HN