Live data from Hacker News

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

github.com

271–280 of 290 posts

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

#271

Earlier quoted context omitted.

I'm sorry, but we don't read replies longer than 140 characters or that use the word "persecuted". Please create a new account and re-submit your argument in the form of a haiku. Having made rules is not sufficient for those rules to be just. Rules are not themselves authority bearing - nor can one side be upset when they make obnoxious rules and get push back. When you respond to criticism of those rules by deleting…

> Having made rules is not sufficient for those rules to be just Quite. And if one doesn't think the rules are just, then simply don't play the game. However, rules such as "don't spam an issue", "don't spam a PR", "don't insult others", "please use the forum for this discussion" strike me as being simple, sensible and just rules. Which rules are unjust, in this context? > Rules are not themselves authority bearing -…

> I refute this statement with the following..

If any of those so much as raise an eyebrow, you must be the most sheltered darling on the entire internet. "Moxie and Signal is shit"? Really? I get called worse names in online gaming by kids.

> ..their offending material was deleted because it was an unhelpful...

Their offending material was a security issue! A fair amount of people seem to share their concerns. If it's in the wrong place then move it, and if it's a duplicate then close it and add a link to the original where conversation is happening. If you can't handle basic moderation of your forum, then stop using your damned forum and maybe use github issues like every other project.

> In a dictatorship...

Yeah, Signal can throw a tantrum, take their toys and go home. So can us as their userbase and the people who recommend it. Right now I'm one of those people who can be reached on Signal and who recommends it to others - and if Signal can't find a way to appropriately receive feedback then I'm no longer going to be doing that.

> Once they started their abusive behaviour they had to be shut down..

No. They didn't. Signal staff could have literally just responded: "Hey, thank you for the report, we're examining this now and will update as we can. Please mind the language." That's literally all it would have taken. Instead Signal continues to stick it's head in the sand and ruin it's relationship with it's users.

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

#272

Do I have it correct that the anti-censorship team refused to take the trivial step just to copy/paste their original issue on a forum as suggested by the project?

If you see their timeline and screenshots here [0], it says they weren't allowed to post in the forum. [0] https://github.com/net4people/bbs/issues/60

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.

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

#273

Earlier quoted context omitted.

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?

There's some missing nuance here. Naomi Wu documented this much better than my summary, but the short version is that you need an IME keyboard for Chinese text entry, and the only one that's any good (and so, has a huge install base) is an application created and owned by a corporation with strong ties to the Chinese government. When there's a security rake-in-a-darkened-shed that a large fraction of your users will…

First, I speak Chinese, I understand what the IME thing is about. I agree that the "Incognito Keyboard" flag is a miscommunication, it should say "Politely tell my IME don't use my input to make smart suggestions", but IMO it is more of an OS issue instead of application issue. Android decided this should be called "IME Incognito Mode", but in reality it is not enforced and merely a hint to the IME. Maybe in addition to calling out Signal, we should also try to convince Google to change the name?

For "pop a dialog about this", I don't know, that's an interesting idea, but it is hard to draw the borderline if you pursue this route.

For example, do you know that Tencent QQ bundles a full-blown endpoint security solution trying to "protect their users" and warn them their computing environment is compromised? To the point it installs a kernel driver to do the detection. Most of my tech-savvy Chinese friends believe this is bad, not only because the possible privacy dilemma but simply because it is not an messaging app's duty to ensure the user have a safe computing environment. Surely Signal can pop up a dialog about the IME concern, but what's next? When somebody bring up an interesting cross app side-channel leak on Android, should Signal scan the installed package list, try to flag any "suspicious app"?

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

#274

Earlier quoted context omitted.

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 feel like this is somewhat disingenuous. IME keylogging is a known, serious, and frequently exploited issue that affects a substantial portion of Signal users. Signal's "Incognito Keyboard" setting didn't mention that the flag can be ignored, which was misleading and dangerous. But yes, warning about accessibility settings if there's evidence of that being an attack vector seems like a good idea. I don't know about…

> if there's evidence of that being an attack vector seems like a good idea

Actually *most* Android malware use accessibility APIs to perform malicious action, random example from a quick Google search: https://medium.com/axdb/%EF%B8%8F-dissecting-defensor-a-stea... . That's simply because this is the most convenient way to perform malicious actions on Android without an exploit. Sure you have to convince the victim for permission, but with a nice lure people usually just fall for it.

It is much much more prevalent than malicious IMEs. Now help your "freedom in danger" friends by raising this up as a security vulnerability to Signal developers plz! /s

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

#275
post #257
post #241

Earlier quoted context omitted.

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.

That something could easily get them killed.

They must already have been killed then. Clearly there are relevant numbers of users using Signal before the TLS proxy was published.

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

#276
post #232

Earlier quoted context omitted.

But where are they supposed to do the more communication? Surely they can't go reading and responding to every thread online that discusses Signal - there's just so many of them. In GitHub, too, issues often get duplicated or drowned in comments. (Although I strongly disagree that they should be saying when they are going to implement it, as that's only setting themselves up for failure: unless it's almost ready, the…

> But where are they supposed to do the more communication? Surely they can't go reading and responding to every thread online that discusses Signal - there's just so many of them. They could put out an official statement on their web site about the matter that everyone can reference. "We intend to do this and here's the way we intend for it to work, and we expect it to take roughly 1 year ±6 months to implement. Her…

> This isn't rocket science; plenty of other organizations have ways of disseminating information to millions of people so that everyone knows what's up.

Is that so? Do people know when WhatsApp is going to add feature x or address bug y?

> Thanks, that's a small step in the right direction which I hadn't seen. Still, it comes after years of being almost entirely mum on the subject

Does it? Or is it possible that you also hadn't seen all earlier instances where they made statements like that? It's just that that sounds very possible to me, given how many different issues there are that affect many different people.

(In addition to the other questions you mention seem unanswerable, unless it really is there one and only number one priority, which seems unlikely given e.g. events like the outage not too long ago.)

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

#277
post #211

Earlier quoted context omitted.

Fork the client and the server then. Yes, I've seen from other comments that the server repo is apparently rarely updated. If that's significant to getting a working client, probably fork the client from earlier; most likely, it you get a significant number of users, you're going to need to get really familiar with the server environment anyway. Running a server environment is probably time consuming ane expensive, b…

That then means you can't communicate with others running the normal Signal client. Signal is not a federated protocol.

> That then means you can't communicate with others running the normal Signal client. Signal is not a federated protocol.

You also can't communicate with WhatsApp users directly either.

If your fork of Signal in better, then you should have no difficulty it convincing people to switch to it. Just because the software is open source, you're not entitled to connect to and use someone else's service in any way you like.

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

#278
post #89

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…

Signal is open source in the same way pfsense is: it is impossible to actually build everything current from publicly available source.

[deleted]

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

#279
post #238
post #109

Earlier quoted context omitted.

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

What would you consider to be an acceptable length of time for a feedback cycle for an understaffed organization who gives away their services for free? I think "months" can be entirely reasonable. At this point you're not complaining about the end result -- they did actually implement something as a result of the feedback -- you're just complaining about the time it took them to do so. Which is IMO pretty silly, as…

It took well over a year for them to address it, and only after blocking many of the people who raised the issue and denying it was an issue. The nature of the problem meant that people were being detained because Signal was misrepresenting the degree of protection it could reasonably provide.

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

#280

Earlier quoted context omitted.

You could first charitably strengthen their argument by silently correcting “exit nodes” to “nodes”. The core point stands.

I don't think the core point does stand. 1. To deanonymise a hidden service connection you need to observe the traffic of all of the nodes in the circuit. 2. OK, let's say your adversary controls all of the nodes in the circuit and deanonymises the endpoints. Now what? You're no worse off than you would be if you weren't using Tor in the first place, so it's not an argument against Tor at all. All it's saying is "the…

> the absolute worst case of using Tor is no worse than the best case of not using Tor

While this is true I just wanted to point out that one does in fact not need *all* the nodes. It is possible to perform traffic analysis and infer which nodes are used by a certain user even if the attacker only controls a part of the nodes. [1]

While this of course doesn't change the fact that using tor is a good idea, one should not let themselves be lured into a wrong feeling of security when using tor.

[1]: https://murdoch.is/papers/oakland05torta.pdf

Post reply on HN