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

Reading the config in the TLS repo, it seems to me that the censorship is at the domain level.

So I guess they're trying to pop up as many endpoints as possible to circumvent that.

I don't know the details about the network block though, so I might be mistaken. But the nginx config in that repo is purely a TLS proxy. Nothing magical happening there at all, just an entrance node to the main signal network

Ignoring the rest of the noise this seems to be the critical question here.

My read on that statement was "the censors can't just /dev/null anything with a plaintext CONNECT".

Given its broad user base, it wouldn't hurt for Signal to clearly state "we can't keep the fact of the communication private, only the contents".

That would short-circuit attempts to gain notoriety by pointing out obvious facts and calling them vulnerabilities. It's also common sense for anyone who knows their way around a puter, but that's not Signal's median user.

"Privacy" products are a market for lemons, and Signal's public messaging should strive to insulate its users from FUD.

It seems like the phone number is used mainly for matching you up to your contacts, and secondarily used for a first level of authentication. Signal has always encouraged independent verification of folks' public keys for sensitive communication.

Whether or not AWS is risky, I don't think signal has any increased risk hosting their infrastructure on it vs. any other service. The whole point is that comms are end-to-end encrypted from handset to handset, and so any data in Amazon's hands is encrypted.

> Why does it need your phone number?

Great question! It's a good way to make it easy for general-purpose users with limited technical expertise to adopt, use, and find one another.

> Seems pretty weird for a “secure” program.

You're right! It's definitely weird, but it's also understandable as a tradeoff in favor of less technically adept users. It's not one I'm in love with, but I think it makes sense.

> And why does it use AWS? Isn’t that subject to all kinds of privacy risks including National Security Letters?

The risk from NSLs depends a lot on what is hosted. If it's opaquely encrypted blobs, there's minimal risk. And where could things be hosted that wouldn't be subject to privacy risks from a government of some sort?

> Why isn’t Signal just a Free and open source, infrastructure-less p2p solution?

That's such a good idea that Signal is already a Free and open source solution!

That said, nothing is ever actually infrastructure-less, just like no data store is actually schema-less. There's just explicit infrastructure and implicit infrastructure. Implicit p2p infrastructure is not immune to governments or NSLs, and is often subject to more by virtue of being in more countries.

Using phone numbers as identifiers for encrypted messages is the core feature of Signal. It was marketed from day one as a drop in SMS replacement. Initially it even used SMS as the transport for encrypted messages. It was literally called "TextSecure".

You can find any number of infrastructure-less p2p solutions. The number of users they have compared to Signal might be illuminating.

Quick answer: Find the right one to blame, please.

If you think that, just by making authorities know your phone number is registered on Signal is dangerous enough for you to be arrested, you should not use Signal.

Signal, like any other software, can not solve political, or dictatorship. Signal is a chat app, not a magical tool, even if it is helpful for those objectives. That's what we mean when we says "security is layered".

So, if your government have unlimited resources (that is to say, they can simply arrest and sentence you if they *think* you *may* using Signal, Telegram, Whatsapp, Tox chat, ..., without judicial review), then maybe Signal is not your biggest problem.

Reading through the PR in the link, I can see where Moxie is coming from. There's very little actual discussion happening, mostly just flamewar-lite. Maybe the other PR's/issues/forum posts are better.

What’s odd about it?

I do wonder how Moxie knew this guy knew that GH is not used for discussion. Maybe the only way to tell is to see that there are no other active discussions?

>If their issues are closed (and Signal does not seem interested in discussing this)

Signal merely asked that they post on community.signalusers.org instead of Github.

>they feel like this is actively putting peoples lives in danger

That's obviously bullshit though, this can't possibly put peoples lives in more danger than using signal without a proxy a week ago would've.

This isn't putting anybody's life in danger - to my rough understanding the only thing detection of a proxy allows for is its takedown. I doubt the Iranian government has the resources or will to trawl their entire net for these proxies and trace their physical locations. What I meant by resolving the situation in a more productive way entails taking a step back and considering the situation outside this Twitter and Github row.

Both the Signal team and this anti-censorship BBS strive towards the same values, and the only thing drama and indignation does is to crack and weaken the effect of the community as a whole. The public sparring should stop and longer-term dialogues should be held to consider everyone's points and come to a conclusion that reasonably satisfies all sides. Depending on emotional investment this may be tough to do at the moment, but down the line it will do wonders for increasing cohesion and productivity.

Start their own app that's better.

The fork option is there and always has been.

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.

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.

For starters, don't name your proof-of-concept repo "fuck-signal-tls-proxy"?

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

I think we are both talking about tone. While you are saying that expressing emotions and the drama is important in a discussion over Signals' future, I believe that such conduct only drives a wedge into it. These issues are emotional and affect important freedoms, but while expressing them is important doing it in such a high-profile, damaging way can only bruise egos and create even more tension. Instead, both parties should sit down and take a long, serious look at their grievances and how they will address them.

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.

> So what should we use instead of signal?

Threema is one alternative.

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

This is an error software engineers sometimes make.

When working with human beings, tone matters. Tone always matters. "Nature cannot be fooled," but presenting facts with the wrong tone can lead to them being discarded, harming the project and/or people involved. You get better outcomes recognizing that people make better decisions when they aren't emotionally tilted.

The successful projects operated by people who don't know how to interact with other people are significant outliers (and in some cases, their creators and maintainers have recanted their past approach as counter-productive, ref. https://arstechnica.com/gadgets/2018/09/linus-torvalds-apolo...).

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

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

> The tone is not more important than the facts

Of course it can be. If your tone is so bad, that nobody listens to you or implements things that you want, then it doesn't matter how right you are on anything.

Getting stuff done and solving problems relies on way more things than just being right.

> Im not suggesting you have some alternative motive to deflect the facts.

Ok but by making these comments you are also deflecting from real problems that having a bad tone causes.

> there isn't a currently easily available obvious way to have private secure conversations.

Ricochet[1] works really well. It uses Tor hidden services to communicate. Your Ricochet ID is your onion address. To add a contact, you input their Ricochet ID and a short message, and Ricochet connects to their onion address and sends a contact request. If the contact request is accepted then you'll each show up as a contact on each other's client and can chat whenever you want.

Tor is really perfect for this, you can't get more private or censorship-resistant than Tor.

The UI is currently not great, but that's not a protocol problem.

The biggest problem with Ricochet is that hardly anyone is using it.

Private secure conversations: yes.

Easily available: yes.

Obvious: sadly not, for most people :(.

[1] https://ricochet.im/

Telegram?

I think the point is that these people just sound like they are barking up the wrong tree. They're bitching at a non-profit org who gives away their services for free for not doing things exactly the way they want. And then getting self-righteously upset when said non-profit bans them for acting in an abusive manner.

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

This is 100% wrong. Tone does matter. If you want someone to do something for you, acting entitled and insulting them usually isn't going to get you where you want to go. Unfortunately straight facts don't sway hearts and minds. That is just how human psychology works. I wish it were different, but wishing does not make it so (speaking of facts!).

The Signal team does not owe these people a way to conduct private secure conversations. Yet they are working on it anyway, because they believe it's the right thing to do. And I bet it's pretty demotivating for a bunch of people to come and tell them that they're doing it wrong and their current interim efforts are useless. No one is owed an explanation or dialogue from the Signal team, and behaving aggressively in order to demand one is about the most unproductive thing they could do.

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

We don’t live in the same world. Without proper tone, my message is never received. And yours is?

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.

FWIW, my experience with Signal sadly confirms this. There’s a critical issue for years with the iOS app that there’s no way to backup or otherwise extract your chat logs (contrary to the usual behavior of iOS apps which automatically backup to your computer or iCloud), no warning of this when you first install, and almost no communication from developers on the subject for years despite huge numbers of complaints.

They hide behind the shield of being volunteers to justify not addressing or communicating about any user concerns, but they also want to play in the big leagues and have hundreds of millions of users who would otherwise be using other chat platforms.

As they've claimed, this is a security vulnerability, instead of a software bug. If they really think this is a vulnerability, send to Signal's email: https://support.signal.org/hc/en-us/articles/360007320791-Ho...

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 would have been. But it’s also a fact that if a system is broken in some way then that hard truth remains true even if it’s wrapped in layers of shit. The ultimate losers will be the users.

At this point, a clear demonstration of how Signal's current design fails to keep users safe forwarded to the New York Times, WaPo, and Fox News would be a lot more valuable than shitposting via the Github PR system.

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.

> Signal still haven't updated their privacy policy to reflect it either (it still states "Signal is designed to never collect or store any sensitive information.")

They don't need to update their privacy policy because they never have access to the profil information.

Technically, the encrypted profile information and your messages (when they are in transit to your contacts) are being stored on their servers in the exact same way. The only difference is that messages are deleted afterwards whereas your profile is stored permanently until you decide to change it. That doesn't make the profile information any less secure, though. Yes, maybe in 20 years someone will be able to break AES-256 (or whatever symmetric encryption algorithm they use) and then the stored cyphertext version of your profile information might be valuable. Personally, I doubt it. But even if I turn out to be wrong: The possible attack vector against your profile information is the same as for messages: After all, tomorrow Signal could get convinced by an intelligence agency to permanently store all your encrypted messages from now on and then the exact same risks of AES-256 getting broken would apply.

Conclusion: When Signal says they're not collecting any sensitive information, they mean that they themselves don't have access to any such information because it gets encrypted. This is the promise of end-to-end encryption. They're not promising anything beyond that.

In particular, they can't promise that the encryption will never get broken. No one knows. And no one in their right mind would promise anything like that. But at least they do everything to mitigate that risk by openly publishing all their cryptography algorithms for peer review and actively participating in scientific research surrounding that topic.

> I still run into people who have no idea that Signal is storing their profile information and their contacts on signal's servers

The precise meaning of the phrase "Signal is storing their profile information on [their] servers" vs. what the average person will actually understand here, are two entirely different things here: Most people will think that Signal stores that profile information in cleartext on their servers – because that is the current status quo with almost all popular online platforms – when in reality this is not the case.

Normally, I would be saying at this point: Please stop spreading FUD. But I do agree with your statement that

> If you're promoting your service to people who risk their lives and freedom by using it you need to make it 100% clear to them what their risks are.

Signal could indeed do a better job here. In view of the above, however, I'm having the feeling the risks weren't really clear to you, either? (No offense)

They're not. They released something as a stopgap measure that will help some, but not all, people in Iran get back on the app, because their better, longer-term solution is not ready, and they believed that people there needed at least something in the short term.

Was the better solution here that signal does nothing?

A fork won't tell people that doesn't use it that the original project they forked is dangerous to use. The proxy shouldn't be there in the first place unless it actually worked. I'm not saying i agree (or disagree) with the current issue's writers but this isn't the first time Signal have put their head in the sand when a problem was pointed out to them. It has become a well-known pattern of Moxie's.

Signal discourages third-party clients.

https://community.signalusers.org/t/how-to-get-signal-apks-o...

I think we should ask this guy how he build it ?

https://www.reddit.com/r/signal/comments/l5dug8/signal_serve...

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.

Has the year-old code somehow "gone bad"? At worst they can roll back to year-old versions of the mobile clients as well, and start with that as a base.

Would it be better/easier to have an up-to-date server? Sure, but they don't have it, and that's life.

> some of the shadowsocks team signed the statement

And hilariously enough also demonstrated that they don’t know how to use PGP.

No, do not put words in my mouth please.

All I see there is the automatic hold which they took a screenshot of, apparently one minute after it was issued!

What happened in minute 2 to the present? Did Signal ever approve them to post on the forum? They don't say.

I've seen a growing number of anti-Signal posts and activism lately, mostly surrounding the (well-documented) design tradeoffs that Signal makes for usability and privacy (such as opting to use phone numbers for usernames, to avoid having to store contact lists/social graphs on Signal servers), or their famous decision not to federate/interoperate.

Perhaps it's just criticism growing in lockstep with Signal's overall growth and notoriety, and there aren't any concerted efforts to discredit Signal and sow doubt about using it because it's harder for the intelligence agencies to surveil. I'd like to live in that world.

I'm not sure that I do.

> What is clear, is that this is a vulnerability. Circumventing blocks tends to be illegal. If we want to help people circumvent such blocks, we need to help them from being caught as well.

Nah, circumventing a block doesn't imply obfuscation of any kind. Signal's normal server connections are not obfuscated, there is no reasonable expectation that a connection to it via a proxy would be, either.

It seems like people are considering this a vulnerability because accessing Signal (via a proxy or otherwise) in Iran is illegal (as I understand it).

It doesn't seem like people would view this as a vulnerability if that weren't legally the case, so I don't think that points to this being a vulnerability in the software.

They would have no other choice but add group and social features. That's what non-tech people come for.

This ignores demonstrated harm* from the combination of human behavior and low-effort large-scale communications.

* https://en.wikipedia.org/wiki/Indian_WhatsApp_lynchings

You do not have to sign anything when you use PGP for encryption.

>decrypt your entire message history, even if you've deleted it from your endpoint

But how many people actually delete their old messages? If they don't then forward secrecy doesn't help. They get your messages when they get you key material.

Encrypted instant messaging is inherently less secure than something that can be performed offline like encrypted email because the key information is exposed all the time. So it is much less likely that you will have your key information exposed in the first place with encrypted email. An instant messenger on a phone can normally be defeated simply by grabbing your unlocked phone from your hand and scrolling though your old messages.

>prove that you're the author of every message, because only your private key can be used to craft the digital signatures.

A private key that in the case of, say, PGP does not have to be associated with any particular identity at all. Also, PGP offers actual deniability by simply not signing the message in the first place while, say, Signal only offers a particularly weak version of forgeability[1] which is problematic in general.

[1] https://articles.59.ca/doku.php?id=pgpfan:repudiability#forg... (see Forgeablity Light)

My first reaction was that surely this must be satire, because the last thing I ask myself reading that post is "but how do I know these 2FA GitHub accounts are not hacked?!" ...

I don't mean to argue, but I believe github's account system with 2FA should be more than secure enough. If it's not, then why even start a bbs there? Why not just use a signed & encrypted email chain? Seems trivial, especially for what wants to appear to be security professionals.

It's a LARP, not about a strong focus on security. These people do not normally sign their comments.

And many of them providing digitally-signed statements such as "I agree with this article" which anyone can simply copy and paste into any other discussion, at any time. I'd suggest that implies a dangerous level of understanding of the tools they're using.

It looks more and more like it.

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

"Full disclosure is the only ethical way to handle it".

haha