The above post is their reaction, which feels more like them lashing out rather than attempting to uphold the greater values of the anti-censorship community. I feel that it doesn't benefit anyone that they behaved this way, choosing to attack the Signal team and the reporter of the article below, rather than resolving the issue productively while allowing the community to continue focusing on their mission.
[1] https://www.bleepingcomputer.com/news/security/removal-notic...
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 deflect the facts. Any one could have written this reaction.
The top comment on a thread like this is always the same. Talking about tone. But I don't mean this offensively, I'm sure I've done it myself as well at times, but it feels like theater. Like a journalist asking a question they know they won't get an answer to. Talking about drama is the same participating in it.
So what should we use instead of signal?
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.
> 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.
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...).
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.
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.
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 :(.
We don’t live in the same world. Without proper tone, my message is never received. And yours is?
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 unfortunate that he's still starting drama with everyone instead of doing any self-reflection.
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.
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.
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.
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.
The fork option is there and always has been.
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.
I found the behavior and statements around this to be the kind that make the situation worse rather than make it better. They appear to be working against their own goal and may not realize it.
>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.
"We are the underdogs, doing the real work, and yet unappreciated by many people."
This is the number one reason why people's tone gets sharper and sharper in online "communities", and often they are 100% right.
Most online "communities" devolve into cliques, where the powerful gang up on dissenters. Often the dissenters indeed do a lot of real work behind the scenes, while 80% of the powerful are well spoken parasites.
The powerful then resort to censorship, which escalates the situation.
In this case, who cares about resolving issues "productively" if people's lives are at stake?
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's not ideal even to circumvent censorship. But they're apparently working on something better, and all this distraction is not helping.
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 more difficult for censors to fingerprint the traffic than it would be if static self-signed certificates were used instead. In short, everything is designed to blend into the background as much as possible.
They should probably make that post less reassuring and list the exact risks.
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.
I don't understand. How would you circumvent censorship of the protocol without obfuscating the protocol?
It seems to me that signal has never claimed to be able to hide that it was being used... until now?
But thanks for posting the thing from Moxie, it does sound quite reasonable.
What would be useful to me and presumably other HN readers is a clear summary of the tech involved, readable by an audience who is technical but not security/circumention experts. Like, the people complaining could be spending time on that, to educate users and developers, instead of doing... whatever they are doing. That seems to have turned into a much less interesting argument about etiquette or something.
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
End-to-end encryption means content privacy but not necessarily meta-data privacy or anonymity.
That is a very odd statement.
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?
Why isn’t Signal just a Free and open source, infrastructure-less p2p solution? Maybe the goal isn’t really security or privacy after all...
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.
You can find any number of infrastructure-less p2p solutions. The number of users they have compared to Signal might be illuminating.
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.
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.
Using a non-repudiatable signing system to promote claims about how a proxy is easy to detect comes off as very hinky to me, to use a technical term.
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. But the way the project is run is, dare I say, arrogant and dismissive.
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. Today I still run into people who have no idea that Signal is storing their profile information and their contacts on signal's servers, and that opting out of setting a pin will not prevent that, and 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)
If the Signal team does indeed have a real problem with taking feedback and criticism, a better approach might've been to gather support and enter into long-term negotiation over Signal's future relationship with the community. This would make its development a lot smoother and prevent anger and bruised egos from building in the future.
Why call it "the IME vulnerability" anyway? This isn't about a vulnerability, we're discussing compromised phones. "IME vulnerability" seems designed to make this sound like a Signal issue, which it isn't.
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.
Inventing new criteria and re-framing their product as inadequate for this scope change as an activism play seems insincere. We can expect this kind of pressure to be applied to all BDFL-run software projects, as I think there is an emerging organized play to insert new governance over foundational internet software.
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?
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.
https://www.reddit.com/r/signal/comments/l5dug8/signal_serve...
Would it be better/easier to have an up-to-date server? Sure, but they don't have it, and that's life.
There's no exploit or vulnerability here (despite their use of the "PoC" and "responsible disclosure" terms that apply to such things). The fact that you can detect a Signal proxy as a Signal proxy isn't a vulnerability; if it gets censored you're no worse off than you were if that proxy didn't exist: the main Signal servers are censored in Iran already. Indeed, this is the Signal circumvention proxy working precisely as designed.
As I understand it, these people got banned from the Signal forum for spreading this FUD there, too. Predictably, they started accusing Signal of some coverup. They managed to get an interview to further publicize their FUD, but eventually reason prevailed and that was pulled by the author, too.
Sometimes I really wonder the motives and identities behind the people causing such massive and unnecessary drama and fear in the community surrounding the only mainstream, reliable, end-to-end encrypted messenger out there. iMessage and WhatsApp both got their end-to-end crypto backdoored en masse via plaintext backup/escrow systems, but Signal remains generally safe and secure (provided general endpoint security practices are followed). These sorts of FUD attacks make me wonder about why they're happening, and the motives and incentives of the people causing them.
One of the people harassing Moxie about it on Twitter has <50 followers and an account that's only ~2 years old, with only a handful of posts in that time. My money's on sockpupppets.
1: https://github.com/net4people/bbs/issues/60#issuecomment-775...
There is more risk than just "if it gets censored". If the proxy can be detected, so can users of that proxy. If users of a proxy can be detected, they can be punished for that.
To what extend this actually happens, I am not sure of. So the severity of this vulnerability is unclear to me. 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. After all, we want to help against the blocks because we believe the blocks to be immoral.
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.
In this case, it's pretty boring. They are just a group of "your average power users" or "wannabe programmers" in their highschool or junior years who happened to be born in China so had some exposure to anti-censorship. Being in their overconfident period of life, they pass by various myth they don't really understand as truth. The community is quite toxic but usually they don't cause trouble outside of their own circle, but when it happens, I don't know how to deal with them either.
They also misuses words like "vulnerability" or "responsible disclosure" because some of them have read a lot of news about security research, thought it is extremely cool but have no idea what it actually means.
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.
Let's hope it will remain just a messaging/videocall app.
This ‘statement’ is quite weird. Is it normal to declare oneself an oppressed minority over a github issue?
I feel like we should be a bit more charitable to people who make things. Otherwise nobody will make anything anymore...
https://community.signalusers.org/t/how-to-get-signal-apks-o...
What happened in minute 2 to the present? Did Signal ever approve them to post on the forum? They don't say.
a) decrypt your entire message history, even if you've deleted it from your endpoint
b) prove that you're the author of every message, because only your private key can be used to craft the digital signatures.
Signal solves both problems. For dissidents' communication, PGP is hard to use and incredibly dangerous even when used correctly. It needs to be killed with fire and buried next to nuclear waste in a container made of Beskar or something.
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)
The TLS proxy is not sufficient. Marlinspike addressed this in their incredibly childish PR [0]:
>As we said in the blog post, it is nothing more than a simple TLS proxy as an interim solution to help people while we're working on something more scalable and more robust
I'm not so sure they made it clear they were working on another solution in that blog post [1], but it's a known problem that proxies can be fingered. I don't see the value add here and I can't read this as anything other than "boo hoo, we weren't listened to" (which is not surprising, given their behavior)
[0]: https://github.com/signalapp/Signal-TLS-Proxy/pull/15#issuec...
It does not cross their mind that the users are immediately endangered too.
They don't understand that it is very easy to identify the proxy users once the Signal proxies themselves are detected?
I'm here replying on the top level to this comment, because I think this is very important: https://news.ycombinator.com/item?id=26076113
Edit:
Actually it is because it is a different problem they are trying to solve.
What Signal is solving by these additional proxies is to avoid being blocked. So this is orthogonal to avoiding the detection of users.
The real way to avoid detection of users is going through something like Tor.
Edit 2:
The real problem is that, in countries where Signal is blocked, it is ALSO forbidden and illegal.
If it was just blocked and not forbidden, nothing wrong in working around the blocking.
But actually permitting users to work around the blocking when it is illegal is not helping them, unless there is also a way to hide them. Else it helps them commit (overtly) the crime for which they risk many troubles.
https://freedomhouse.org/country/iran/freedom-net/2019 https://freedomhouse.org/country/iran/freedom-net/2020
And hilariously enough also demonstrated that they don’t know how to use PGP.
Signal team seems completely irresponsible here.
Censorship in countries where this app could help puts opponents lives at risk and already led to executions.
I even wonder now if they don’t have ulterior motives.
* 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 definition of "security researcher".
I think Signal did what they should do when communicate with those "trick or treat" guys: treat me with fame, or I'll trick you with a PoC. Is there a better word to shorten this review...? Oh there is: robber.
> * Publish the exploit before vendor delivered the patch
It's called full disclosure and it is the only ethical way to handle it.
haha
What an entitled, self-serving, narcissistic framing. Even if their technical claims are 100% correct, they have almost no credibility issuing propaganda like this. Yikes.
If they think wasted hours programming solutions not getting adopted by OSS makes them some special oppressed group then they must be new to this whole thing. That’s such such a common scenario in OSS and hacker culture in general it’s comical. There used to be a special pride in doing the thankless work, especially in infosec.
Or maybe I’m just getting old and the new social media/political culture status quo has brewed up some entitled people where victimhood is the common currency.
They can't eat their cake and have it. If they advise vulnerable groups to use their technology, then they're morally obligated to explore and mitigate any and all issues brought to the table.
Signal has lots of funding, so getting "insulted" is not an option — in my view that only applies to FOSS maintainers who work for free.
And, of course, someone who is a bit more diplomatic may have better luck getting some of these issues across to the development team in an impartial manner.
Why is the lead Signal developer responding to the public on GitHub and Twitter? It is really helping the project? At this point I'd argue that it's actually hurting the project as we see more of these pointless and public flame wars. Others have pointed out the similarity between this situation and the IME keyboard kerfuffle a couple weeks back.
If I move to something else it had to be fully open, not just the source of the app but the network too. Movie is just creating another walled garden. A lot less microphones hanging in the trees than WhatsApp but still a walled garden.
Doubly so if the complainants claim to be experts of some kind.
I admire the people that put in time and energy to create a safer future for us all.
Hope that this is not going to be taken the wrong way, but whenever I read such threads (and again - I respect all the people involved, their efforts and the importance of this issues) - I can't help but being reminded with this: https://www.youtube.com/watch?v=a0BpfwazhUA
