search

privacytools / privacytools.io

🛡🛠 You are being watched. Protect your privacy against global mass surveillance.
https://www.privacyguides.org
Creative Commons Zero v1.0 Universal
3.11k stars 388 forks source link

❌ Software Removal | Signal #779

Closed ghost closed 5 years ago

ghost commented 5 years ago

Problem with Signal

Signal has copious privacy issues making it unfit for privacytools.io endorsement.

  1. Users are forced to supply a phone number to Signal (https://github.com/privacytoolsIO/privacytools.io/issues/432) (diagram of mass surveillance)
    1. Phone numbers are forcibly tied to legal identities in some countries (e.g. many European nations force carriers to copy ID cards)
    2. Phone numbers are usually not gratis -- the payments of which are traceable. Even cash payments trace to a shop.
    3. Privacytools.io target audience is unlikely to go through the hoops of getting an anonymous phone number. They will give in to convenience and supply a sensitive phone number.
    4. Signal's claims to the contrary do not obviate the above points. It's a broken registration process from the standpoint of privacy, all to serve a centralized master. Note that Jami (decentralized) does not require phone number registration, and Wire (centralized) does not require phone reg. if the desktop app is used and it's optional for their mobile app.
    5. Some people in the US will buy burner phones and thus financially support one of the four privacy-abusing mobile phone carriers. Signal compels people to feed companies working to the detriment of everyone's privacy, when those four carriers should be boycotted.
    6. Signal retains a record of users phone numbers for account recovery purposes. This means:
      1. Users who choose to supply a number they do not keep control over (e.g. a hotel phone) are vulnerable to an attacker exploiting that to initiate account recovery.
      2. Metadata is linked to identified individuals (and it has been subpoenaed)
      3. If those records are ever breached everyone is needlessly exposed.
    7. The privacy abuse is viral. When a user opts to sacrifice their own privacy by registering a phone number, they become bait by which their friends are pressured to make the same compromise in order to stay in touch. This is effect a consequence of both phone reg. and part 7 (network protectionism).
    8. Entities with no connection to OWS are able to deanonymize Signal users using phone number cross-referencing.
  2. Users are forced to feed Google.
    1. APK download requires users to connect to Google's server and execute non-free javascript
    2. Playstore pushed
      1. Directing users to Google Playstore is contrary to the mission of privacytools.io. From the PTIO front page: "You are being watched. Private and state-sponsored organizations are monitoring and recording your online activities. privacytools.io provides knowledge and tools to protect your privacy against global mass surveillance." By knowingly sending users to signal.org who are then sent to Google Playstore, privacytools.io is failing their mission and betraying the users. At a minimum the link on privacytools.io should be to the APK page that is anchored to the bottom of the page. At least the risk of subjecting novice users to advanced tools is less serious than subjecting them to Google's walled-garden of surveillance.
      2. Google accounts are required to access Playstore even when using a third-party app.
      3. Registering for a Google account is in itself a privacy abuse, the process of which requires having a phone number (one abuse) and then disclosing that number to Google (another abuse).
      4. Use of the account to access the Playstore abuses user privacy through Google tracking (Google keeps track of apps you download and your IMEI number). From this Google also knows all the vulnerabilities a user has. Google also records users’ IP addresses and browser prints when logged in, which is later used to link to logged-out traffic and behavior.
      5. Users who bought an Android without a PlayStore^(tm) license are excluded if they are not advanced enough to use third-party hacker tools, and those who are advanced are outside the scope of privacytools.io target audience and still must use a Google account (thus still subject to the abuses of using the Google account at the Playstore).
      6. Playstore is scientifically proven to be relatively insecure compared to F-Droid in the "Understanding the Security Management of Global Third-Party Android Marketplaces" article. (see also F-Droid: The privacy-friendly alternative to Google Play Store)
    3. Google's reCAPTCHA used
      1. Google's reCAPTCHAs compromise security:
        • anonymity is compromised.
        • (speculative) could Google push malicious j/s that intercepts user registration information?
      2. Users are forced to execute non-free javascript (recaptcha/api.js).
      3. The reCAPTCHA requires a GUI, thus denying service to users of text-based clients. If someone were to develop a third-party non-graphical plugin or app, OWS is now dictating that all Signal apps must support a GUI and it must also be javascript capable.
      4. CAPTCHAs put humans to work for machines when it is machines who should be working for humans. PRISM corp Google Inc. benefits financially from the puzzle solving work, giving Google an opportunity to collect data, abuse it, and profit from it. E.g. Google can track which of their logged-in users are visiting the page presenting the CAPTCHA.
      5. The reCAPTCHAs are often broken.
        • E.g.1: the CAPTCHA server itself refuses to give the puzzle saying there is too much activity.
        • E.g.2: captcha
      6. The CAPTCHAs are often unsolvable.
        • E.g.1: the CAPTCHA puzzle is broken by ambiguity (is one pixel in a grid cell of a pole holding a street sign considered a street sign?)
        • E.g.2: the puzzle is expressed in a language the viewer doesn't understand.
  3. APK download is implemented in a privacy-hostile manner:
    1. ^ That link is hidden. From the landing page users are directed to Google Playstore exclusively. There is also no way to navigate to the APK download from the home page. The only way to get the APK page URL is word-of-mouth or searches on 3rd-party websites.
    2. The small minority of users who will actually take initiative to proactively search for the APK may or may not discover this buried page, which the Signal project calls the "Danger Zone". And these users are not the ones that Signal puts at risk with Google surveillance- it's everyone else.
    3. Those who find the page will only see Signal pimping Google Playstore again. Many won't realize they must scroll down to see the Danger Zone. Fooled me a couple times. Even after I knew about the APK download I thought the download option got removed but I actually neglected to scroll down.
    4. The page says "The safest and easiest way to install Signal for Android is through the Google Play Store" (emphasis mine).
    5. Visitors of that page who use the noscript or uMatrix plugin do not get an APK download link. They see a blob of text below "Danger Zone" which doesn't include a link so they won't even bother reading it. If they do read it then it just appears like a broken page. They actually have to realize that they must enable javascript from Google in order to render the download button. So making a connection to Google is still inescapable even for the APK download.
    6. The Signal project says that link is for "Advanced users with special needs". So not only are they undermining their more secure distribution by calling it dangerous (when really it's the Playstore link that should be in a "Danger Zone"), they also say it's only for a subset of advanced users - this is not the audience privacytools.io is targeting. The privacytools.io audience should be able to find the app on f-droid.org.
  4. Platform limitations (due to refusal to cooperate)
    1. Open Whisper Systems takes a hostile posture toward developers of third-party apps like LibreSignal for using OWS-owned networks and having "Signal" in the name (likely it's the "Libre" they really don't like, but use of "Signal" invokes legal power).
    2. No official Debian distribution. Debian is the most common linux distribution and it's known for high quality standards and high standards of software freedom. The fact that Open Whisper Systems distributes an Ubuntu package directly from their own repository calls into question why they've not achieved the quality standards of having an official Debian release. One side-effect is that #debian on freenode will not support unofficial packages and in fact they advise against them. And in this case support is lacking (see the next section).
  5. Users seeking support are forced into CloudFlare.
    1. CloudFlare mushrooms into many privacy abuses, listed here
  6. Signal is centralized on Amazon AWS.
    1. When users connect to AWS, privacy abuser Amazon gets their IP address and likely knows they are using Signal. That IP address can then be cross-referenced to other activity recorded by Amazon (both their shop and other AWS-based services like Wire). (This is speculation - investigation needed).
    2. There are several privacy-related ethical problems with AWS.
  7. Network protectionism: the Signal network is a closed walled-garden in itself. "Open" Whisper Systems does not allow tools developed by others to use their network. OWS also will not federate their network with another network. So they've capitalized on the marketing benefit of free software licensing but implement a policy that prevents the freedoms of free software from actually having a practical usable effect. They do this while telling users: "As an Open Source project supported by grants and donations, Signal can put users first."
  8. Detrimental partnerships that aid privacy abusers:
    1. (Facebook) OWS contributed to the development effort of Facebook Messenger and WhatsApp
    2. (Google) OWS contributed to the development effort of Allo

Playstore history

The Signal-Playstore discussion (quite rightly) never dies. Threads keep popping up over the years and moving, but one thing that never changes is the project's unwillingness to deviate (in short, they want their stats). The most recent discussion lives here if anyone wants to follow it.

Perhaps it's worth mentioning that Google can possibly exceptionally be avoided entirely if a user downloads the source code and compiles it from scratch. I've not verified that, but it's somewhat moot anyway since privacytools.io target users would not be doing that.

bad players involved with OWS Signal

entity walled-garden? direct privacy abuse w.r.t Signal indirect privacy abuse
Amazon no Amazon sees all connections, IP addresses, can associate to their webshop data OWS feeds this notorious privacy abuser
Apple yes iTunes tracking funds anti-privacy lobbyists
CloudFlare yes sees all web traffic to OWS support site and blocks Tor users OWS feeds this notorious abuser of privacy and net neutrality.
Facebook yes none OWS contributed to the development effort on Facebook Messenger and WhatsApp projects
Google yes user tracking in many different ways via playstore and captcha OWS feeds this notorious privacy abuser and PRISM corp
OWS yes (OWSs own system is a walled-garden) forced participation in telephone systems and forced disclosure of sensitive phone numbers subjects users to privacy abusers in this table
phone vendors no some (e.g. Motorola) caught putting spyware on phones; factory configs hinder security most phone makers fund anti-privacy lobbyists
phone service no CDMA/GSM tracking; reduces the security of phones all US carriers are privacy abusers and also fund anti-privacy lobbyists

Prostitution ring diagram showing privacy abuses:

(PDF) ows_signal_design

five-c-d commented 5 years ago

Let us concentrate on Jami, for the moment, and see if we get anywheres.

PFS*2, CBR*5, IP*2

Does Jami implement perfect forward secrecy, in their crypto? This quote suggests that it does, but from the comments below it looks like they have PFS at the session level rather than regularly rotating. The quote is a couple years old though, and the privacyToolsIO listings ought to reflect whatever the current status is. Moreover, it sounds like the IM portion of Jami is *not* discussed there at all, which begs the question: does Jami use PFS in their IM, and if so to what extent? Does Jami have CBR to try and mitigate phonologically-driven attack-vectors? I do not see anything which says they do that, but I do not see anything to the contrary either. You can insist that I do my own research if I want to push Jami onto the list of WorthRecommending for IM, and if I want to push Jami into the top3 for the VoIP listings, but I do not want such things. You *are* wanting such things, and thus, upon you, the burden of proof is placed. You claim that signalapp is worse than Jami since it uses minimized jquery downloaded from a google CDN when one downloads the sideload-APK flavour and encourages playstore for everyday endusers instead of sideload... moreover, although Jami is detected as having GoogleFirebaseAnalytics in their playstore-APK-but-not-their-FDroid-flavour, that somehow still makes it superior? Signalapp uses CBR in cryptocalls, and you don't wish to say whether Jami does that or not, just insisting the Jami is "more aligned" and signalapp is evil because telcos are evil and anybody paying money to a telco is evil and signalapp requires valid working phone nums which means they are evil! I can follow your line of argument, I suppose, and might not even disagree, but none of that answers the question: does Jami use CBR? Perhaps my web-search skill is weak today, and they do, or perhaps they use some other TLA for the same conceptual idea. But CBR *is* needful in cryptocalling, if privacy is the goal. And because Jami-fka-Ring.cx supports five different audio-codecs, I guess that means the CBR question needs answering for all five. Similarly, does Jami use PFS on a per-session slash per-cryptocall basis, or more often? And over in the IM category, does Jami use PFS for every message like signalapp, or less often like MegOlm? As of 2017, one of the Jami developers said that revealing IP addresses during cryptocalls was baked into the architecture... is that still the case in 2019, though? Signalapp sometimes-and-sometimes-does-not reveal IP addresses in a nuanced way, but there is an option to forcibly relay-all-calls which can be acceptable if the enduser distrusts the opsec of their contacts (causes higher latency though and this can lead to more problems with dropped calls or audio-quality in theory... in practice it does seem functional though per my anecdata).

And no, I didn't miss your suggestion that signalapp should be deleted completely from the IM category, deleted completely from the VoIP category, and then a new category of "SMS-apps" created... but you just fail to understand how SMS-integration works in signalapp. (And the new category is a bad idea.) As with providing evidence that Jami is deserving of being promoted from WorthMentioning to Top3 in VoIP, and from NotWorthMentioning to Top3 in IM, being 100% on your plate, providing evidence that signalapp-for-SMS deserves to be added to your suggested-new-category, is something I will leave to you.

p.s. But the more fundamental point here, is that "just google it" actually does not address the core question: is the codebase in question well-vetted, when it comes to the crypto? Is it high-quality in terms of the crypto-implementation, and in terms of the crypto-system's overall architecture and choice of primitives and whatnot? Only way to answer that question is by looking at the reputation of the cryptosystem in question amongst respected cryptographers. Ask any respected cryptographer and they will tell you the same thing ;-) Which is a bit circular, if you ask me, but there you go. Has the Jami codebase been audited by cryptographers, or by respected security-researchers? What do they say about it, and how respected are they, and what do they say about the other tools in the IM and/or VoIP lists?

no one in this thread ever claimed that absence of exploits was in any way the highest standard of security.

Yes, that is a true statement, but not the whole truth. Instead, you just claimed something only slightly less silly: that every cryptosystem in this list -- ANY of the 'competitors' -- was equal to the Signal Protocol as implemented in signalapp. The correct term for what you listed is 'alternatives' rather than competitors, most are not even in the same universe competitively. And the assertion that they are all 100% as well-vetted in terms of "payload privacy" aka the soundness of the overall crypto-system as signalapp, is Not Even Wrong... it reflects a fundamental misunderstanding of how cryptosystem quality is determined.

strypey commented 5 years ago

I just want to thank @libBletchley for compiling this exhaustive list of issues with Signal, complete with reference links and comparison tables, and for patiently debating the OWS apologists who inevitably show up with the same, tired talking points whenever Signal is criticized anywhere on the net. It's a great relief not to be the person trying to cut through this sort of noise for a change. I've been following the threads about LibreSignal, F-Droid distribution etc for some time, and discussed them at length a couple of times on the fediverse. Very little of what @infosec-handbook and @five-c-d have said here is new to me, and all of it follows the usual pattern of wilfully missing the point, slaughtering strawmen, and appealing to authority.

On that point, AFAIK Snowden's most recent endorsements of Signal date back to 2015. A year before Moxie threatened LibreSignal, gave the middle finger to the F-Droid team, posted his 'Ecosystem is Moving' anti-federation rant, and started working with FarceBook(?!?), all of which happened in 2016. OSW still has Snowden's face on their marketing site, quoting a remark he made years before all that happened, saying:

"Use anything by Open Whisper Systems."

In 2017, Snowden posted a message on the birdsite saying:

Wire seems like a reasonable alternative to Signal, it's just less well-studied. Also lets you register with anon email instead of a phone #

So it seems like Ed agrees this is a privacy issue. But really, endorsements by celebrity hackers can only ever point to candidates for inclusion, not do your reviewing for you. What matters are the verifiable differences between the tools available, not who else endorses them.

Herohtar commented 5 years ago

AFAIK Snowden's most recent endorsements of Signal date back to 2015.

Since it seems to be under question a lot, just wanted to point out that Snowden has commented on Signal as recently as February of this year: https://twitter.com/Snowden/status/1094963047129628674

five-c-d commented 5 years ago

appealing to authority

Methinks when it comes to privacyToolsIO, appeal-to-Snowden is pretty solid ground ;-)

Which means I was quite interested to hear his take on wireapp, thank you, much appreciated. And it seems a reasonable stance, that Snowden is taking: wireapp is less well-vetted than signalapp, but phone-num-optional is a significant win.

slaughtering strawmen

This is your post @strypey , updated a couple months ago in January, excerpted:

And to me that sounds like a reasonable argument, not a strawman in need of quixotic lance-charge. You are speaking from the enduser's perspective and needs: phone-num optional, smartphone optional, GDPR jurisdiction, non-Five-Eyes albeit not to the same extent as protonmail, libre-licensed, e2e on-by-default, user-friendly.

Specifically you are NOT arguing that phones are evil and thus must be boycott'd on ethical grounds, just, that phone-nums are privacy-sensitive and endusers know it. Plus, user-friendly apps are essential if we want people to actually use the privacy-oriented apps, and not go back to unencryptedGSM/skype/whatsapp/fbMsgr/etc, we seem to agree there also

same, tired talking points

There are only two big negatives that I think really matter, with respect to wireapp: that it is less well-vetted crypto than signalapp, and that it collects way too much metadata. Even when federated someday in the future this would remain a worry for me because most endusers would not run their own wireserver, assuming old patterns remain the norm... knowing "half the metadata" is as good as knowing all of it, for any particular pairwise interaction, just like only seeing "half the chat-history" by rootkit'g one endpoint only.

On the positive side, I would also add wireapp's up-to-10-way confcalls feature. Now, although the metadata-downside is inherently worse for group-calls and groupchats, network-level adversaries with the power of NSA or Amazon (and to a lesser extent Apple and Google) can use timing-analysis paired with their extant non-signalapp-specific datasets, to deduce most of the groupchat-memberships even with the signalapp perimeter. Unless that is, quite a LOT of the group-members are religious about their opsec, unfailingly utilizing Tor/VPN/etc as recommended by privacyToolsIO.

patiently debating

But unless I'm badly misinterpreting your words, you sound like you are recommending that wireapp be promoted to first-listed-in-the-Top3, for VoIP listings, not sure what your position is for IM listings, and that signalapp be ... what exactly?

a. Move signalapp#1 in VoIP to second-listed, so that signalapp#1 swaps places with wireapp#2? Linphone#3 would remain unchanged.
b. Move signalapp#1 in IM to second-listed, so that WorthMentioningExperimental wireapp leaps to #1, and RiotMatrix#2 falls to #3, bumping about-to-be-demoted-anyways Ricochet#3 to WorthMentioning, thereby making Ricochet roughly swap places with WorthMentioning-wireapp? c. Demote signalapp#1 in VoIP to WorthMentioning, leaving wireapp + linphone + jitsi in the top3, and signalapp less-prominently mentioned with Tox + Jami? d. Demote signalapp#1 in IM to WorthMentioning, so that WorthMentioningExperimental wireapp leaps to #1, and RiotMatrix#2 stays where it is, maybeRicochet#3 holds position or is swapped with RetroShare? signalapp would be less-prominently mentioned with the various XMPP-OMEMO clients + the new StatusIM?
e. Or, do you agree with @libBletchley that signalapp needs to be not just taken out of the first spot in both categories, not merely demoted to WorthMentioning, but removed outright as evil, mayhap to someday be reinstated within some new category that does not presently exist? f. None of the above / other please specify :-)

As the apologist here, I argue for plan#z, which is the status quo since 2016 is upheld, and signalapp remains in the first-listed position for IM and also the first-listed position of VoIP. Wireapp is already second-listed in VoIP, and if e2e confcalling is considered valuable enough, and metadata-risks sufficiently mitigated by optional non-phone-signup, the case could be made to swap it with signalapp aka plan#A... though I would want to see whether Firebase was enabled in the APK versus dormant, that significantly changes the "non-phone" calculus if true. Anything like that is very different from plan#E obviously!

privacytoolsIO commented 5 years ago

I think it's time to split content on privacytools.io into two sections:

1) Aimed at regular users who are looking for an easy to use alterantive for lets say "WhatsApp" and we could for example suggest "Telegram" with some notes.

2) Aimed at very privacy conscious users who want to walk to extra mile, join discussions like this one.

We can't please both groups with the same recommendations.

five-c-d commented 5 years ago

So, the primary stuff in section one, would say something like:

That sort of thing, is what you have in mind?

(Telegram does not have end2end crypto for groupchats AT ALL, is my understanding, so I would ask you please keep it on the never-to-be-recommended-badlist however :-)

Then, further down the page, a second section, which would be for more hardcore folks:

And why stop there? Section three with TUI, here we come :-)

To be in the first list, would need a polished windows version of the software (also OSX support), playstore APK with >50k reviews (also iPhone support), and a dedicated wikipedia page, maybe? To be in the second list, would need to be... what exactly, how is the group of very-privacy-conscious-endusers being defined here? What is the split-point?

ghost commented 5 years ago

Thread thesis: remove Signal (nothing more)

Does Jami have CBR to try and mitigate phonologically-driven attack-vectors? I do not see anything which says they do that, but I do not see anything to the contrary either. You can insist that I do my own research if I want to push Jami onto the list of WorthRecommending for IM, and if I want to push Jami into the top3 for the VoIP listings, but I do not want such things.

You are wanting such things, and thus, upon you, the burden of proof is placed.

First of all you're conflating factors that are orthogonal to the thesis. The thesis is simply to drop Signal endorsement. Whether the Jami endorsement changes is fog; it can be discussed as a separate issue. You can attempt to suggest different criteria to look at if you want, but you brought a half-baked idea. You didn't even make a case for why these half-baked ideas are even worthy of consideration, nor did you supply enough information for anyone to make a comparative decision. Consequently, it yielded you nothing because you don't understand that it's your burden alone to support your own line of reasoning.

Support your own ideas well or let them fall.

code quality does not matter when the design is broken

is the codebase in question well-vetted, when it comes to the crypto? Is it high-quality in terms of the crypto-implementation, and in terms of the crypto-system's overall architecture and choice of primitives and whatnot? Only way to answer that question is by looking at the reputation of the cryptosystem in question amongst respected cryptographers.

Even if every line of Facebook's code were written in SPARK Ada to a standard that lives could depend on, documented mathematical proofs of correctness, reviewed by 50 engineers, and the whole code had 6 different objective third-party audits, with 100% branch-coverage in testing, Facebook would still be unfit for PTIO endorsement. The reason is because the privacy flaws are in the design and company policy.

It doesn't matter how high quality the Signal code is when the Signal design and OWS policy both subject users to mass surveillance.

Snowden and the problem with endorsements

Since it seems to be under question a lot, just wanted to point out that Snowden has commented on Signal as recently as February of this year: https://twitter.com/Snowden/status/1094963047129628674

It's clear that Snowden does not endorse Signal. He's given endorsements in the past but when asked specifically about Signal he's afraid to endorse it as you can see.

Snowden and Schneier both are quite competent when discussing high-level theoretical concepts. When it comes to what they use themselves (e.g. Schneier w/MS Windows and Snowden with Signal and other bad tools and online services) and making specific endorsements, their reputation doesn't follow. And Snowden knows that; it's evident in his careful phrasing.

The problem with looking at what they use is that their own threat model differs. Especially Snowden, whose own threat model is all about targeted surveillance not mass surveillance. Snowden very likely uses Haven. Snowden very likely needs notifications when his living space is disturbed. Haven is limited in that it can only use Signal or SMS to send the notifications, and SMS implies realtime tracking. So Snowden is likely forced to use Signal as a consequence of his personal situation.

Both Snowden and Schneier have agendas to reach out to the masses, which gives an ironic bias to connectedness over security. They're willing to compromise their own security to some extent and choose tools and services (e.g. Twitter) to support their higher public service mission of reaching out to large numbers of people. Most normal people don't have a practical need connect with as many people as Snowden and Schneiere.

The problem with what they endorse is that the endorsement is largely guesswork about what threat model they think the general public cares about, along with their own perception of the technical capability of the audience that the endorsement is for. These guys are neither psychologists nor scientists. Their perception of what they think users' threat model is doesn't necessarily capture the PTIO threat model, while their idea of what the user can handle in terms of complexity is also guesswork that neither of them are experts on.

Methinks when it comes to privacyToolsIO, appeal-to-Snowden is pretty solid ground ;-)

Obviously not, because Snowden likely needs Haven, and also he has yet to debunk any of the facts presented in this thread. Nothing he said indicates that the factors at hand had any part of his choice of personal tools. This is why your appeal to authority fails. Perhaps you can try to motivate Snowden to address the post-2015 issues, and frame it not as what he uses himself but under our very different threat model. Apart from that you're still just pissing in the wind with a red herring of an appeal to authority. Nothing Snowden says makes any of the flaws presented here go away.

Snowden would also be capable of circumventing some of the issues in the OP. He's quite capable of compiling his own copy from source, and he probably doesn't even need a burner phone - many people would facilitate the phone verification for him. Once Snowden has an account, he has bigger things on his plate than thinking about the viral privacy abuse effect of becoming bait by which others are compromised.

Snowden is taking: wireapp is less well-vetted than signalapp, but phone-num-optional is a significant win. ... There are only two big negatives that I think really matter, with respect to wireapp: that it is less well-vetted crypto than signalapp,

Again, you've been told many times now that the Signal code quality is irrelevant when the tool is doing the wrong thing. It's the wrong design for the PTIO mission.

ghost commented 5 years ago

(unrelated reply to @BurungHantu1605 moved here.

five-c-d commented 5 years ago

Snowden and Schneier have agendas to reach out to the masses

Agreed, and this is an important nuance, which should color how we interpret what they say.

But what do you think the mission of privacyToolsIO would be, if not that same mission? Perhaps not ONLY that mission, but I think that is a part of it, maybe even the main part. See next point, about achieving critical mass.

It's the wrong design for the PTIO mission

Thank you for the improved tone, it is helpful, and appreciated. We just disagree on what the mission is, I think. Not even that, really... we both agree that the mission is stopping mass surveillance, but your strategy is more aggressive and mine is more incremental. Obviously I think my strategy is superior ;-)

stopping mass surveillance, requires achieving critical mass

You think the mission is "recommend signalapp in 2016-2018 but then drop it completely in 2019+ because it requires phone-nums and those are evil because telcos support mass surveillance -- and wireapp is an ever-so-slightly better option now despite the tracker in the apk and despite the metadata-scarfing because phone-nums are optional." You are willing to **settle** for recommending wireapp in 2019, but you see that as only a temporary measure, soon they will also be boycott'd on ethical/political grounds: they run on AWS and Amazon is evil, so just as soon as Jami or whatever can replace wireapp, the better, maybe by 2020 Jami will have enough of the bugs worked out and then wireapp can also be completely dropped forever. In short, your strategy for privacyToolsIO fighting mass surveillance, is to recommend endusers install the flavour-of-the-year. Or to put it more kindly, that they install the best available privacy option at the time. I don't disagree that would be a nice plan. I just disagree that plan will actually work. Endusers won't change messengers every couple years, and if privacytools starts recommending that, it will no longer be giving recommendations to the masses, it will be giving recommendations to privacy-nerds-only. Everyday endusers don't care enough about privacy to stop using windows10, and when they *do* stop using windows10 it will be for a *chromebook*. Why should we care? Because, if you want to end mass surveillance, you need a plan that will actually get *the masses* to install privacy-oriented software, NOT just a plan that works for privacy-nerds-only. The masses will NOT install the currently-best-available-privacy-option, year after year after year. It is too much hassle. The proof is in the pudding: privacyToolsIO recommends Firefox and Tor on something-other-than-Windows, has since 2015, but Chrome-on-Windows has higher market-share. Similarly, privacyToolsIO recommends Signalapp and protonmail, has since 2015, but people use whatsapp-by-facebook (acquired 2015) and gmail-by-google. So to me, the situation is very simple: if we want to thwart mass surveillance, we need to wean the masses from gmail to protonmail, *even if they are still opening it in a chrome browser on windows*. We need to wean them from whatsapp/skype/imessage/SMS over to signalapp, *even if they leave those installed on their playstore smartphones*. In short, I think privacyToolsIO mission is to incrementally and pragmatically end mass surveillance, by ratcheting up the privacy-of-the-masses... at the speed-of-change, and with the user-friendly software, that the masses can actually handle. Email, IM, VoIP, even OSes... these are all network-effect industries, which means that a successful incremental strategy will seem "slow" compared to flavour-of-the-year cutting-edge-hardcore ... but the incremental strategy goes exponential, if it works (once you get 100M endusers you tend to have a billion endusers within a year). Linux on the desktop never hit critical mass, and never made it to 100M endusers, which to me is *why* it is only used by "extreme" privacy-folks like ourselves as a daily-driver. But if we have to communicate with people that are running whatsapp from the playstore and gmail on their win10 box, where is our privacy? I want the masses converted so that ***I*** can actually reap the benefits of running linux-on-the-desktop, etc :-) If privacyToolsIO was to recommend the-most-privacy-conscious flavor of Linux, the ideal distro for privacy, that would be a flavour-of-the-year strategy: one year it would be TailsOS, one year it would be OpenBSD, one year it would be Trisquel, one year it would be Kali, one year it would be TinyCore+Qubes, and so on. Hardcore endusers would be happy to upgrade their OS every nine months, right? But instead the recommendation is pretty stable: **always** has privacyToolsIO recommended Debian-or-Trisquel, and in a separate category, Qubes-or-TailsOS, there is not a lot of hopping&bopping because -- I am indulging in a little mindreading here of the website founders -- the intended audience is NOT hardcore folks willing to install a new OS every 9 months, the intended audience is *people running Windows 10* that need to be educated into even KNOWING there are better options. Both of us want to be able to cryptocall our mothers, the question is, what strategy will achieve that? My mom has signalapp, but with her cellnum... she publishes her cellnum on her business-cards, too, and has for years now, that ship has sailed. :-) She would never be able to figure out how Jami usernames work, let alone install Ricochet while hand-upgrading the Tor. I'm capable of that stuff, though, so it makes sense that privacyToolsIO can recommend both Ricochet and Signalapp, endusers pick what works for them. You @libBletchley on the other hand, presumably have a mother that was able to install Jami themselves, or was willing to let you help them install it, or whatever. Which is fine, in the pragmatic sense: you don't need to cryptocall my mom, and I don't need to cryptocall your mom. If for whatever reason THEY needed to cryptocall each other, they would just fallback to unencrypted GSM most likely... but it would be better, if they would figure out which of them would install the tool preferred by the other. PrivacyToolsIO is supposed to *help educate them* so they **can** figure such things out, on a sensible basis.

Additionally, I also think that privacyToolsIO folks -- the people with commit access I mean not just the people that comment here in github and over on the subreddit -- need to decide on The Purpose of the site.

It sounds like the founder of the website is leaning towards HybridPurpose#3: split the recommendation-listing into a section at the top for everyday endusers ("the masses") which has ONLY easy-to-use things and takes a pros&cons approach, then separately, a section for hardcore folks that are willing to go the extra mile.

If a particular endorsement is a tool that is not user-friendly, it could be tagged

Yes, exactly.

I suggest an icon of a big brain for the advanced tools

No, this is the wrong psychology. That is purposely telling people running windows 10, hey you are an idiot. If they upgrade to Linux Mint, well we would STILL be calling them an idiot, anyone with a BIG ENOUGH BRAIN would be running OpenBSD on an air-gapped computer with drivers hand-compiled from source!

That is not how to sell privacy :-) We want the masses to enjoy it as then incrementally boost their privacy. They will feel smarter, every time they level-up. So my suggestion is that we don't treat the levels as some kind of IQ test. Plenty of perfectly intelligent people run android smartphones with playStore, and plenty of not-that-smart people are 100% capable of using F-Droid, if they only knew about it. This is an education problem, not a how-many-people-can-we-insult problem. Implying they have small brains is not helpful, but we can flip that around and question how much of a privacy-wizard they are. Most people think privacy-software, and software in general for that matter, is a kind of magic, so this is a good analogy methinks.

what's YOUR privacy-wizard-level, dear reader? 🧙x1, 🧙x2, 🧙x3...

The level-up idea would be like this: * Section #1: better privacy, for everyday folks, requires overall wizardryLevel: basic * Section #2: even more hardcore privacy, requires overall wizardryLevel: advanced * Section #3: extremely hardcore privacy, requires overall wizardryLevel: very advanced Wizardry-level is about how tech-savvy somebody is, but also, about how much HASSLE they are willing to undergo. The normal everyday person is not going to necessarily be capable of manually upgrading the Tor-version to keep Ricochet secured. But even people like myself that are ABLE to do so, might not be willing to go through the hassle. Similarly, the normal everyday person is not going to necessarily be WILLING to mess with "ricochet:302af383208" as their username, that requires some wizardryLevel during operations. Same thing with long complex passwords: most people are unwilling to deal with the hassle of memorizing a couple dozen of those (very advanced wizardry-level), and some people won't use ANY password and want possession-of-my-phone to be their proof-of-identity (basic wizardry-level), but plenty of folks are about in the middle where they will memorize **one** complex password and use it to unlock their KeePassXC/bitWarden/etc. Wireapp stores metadata server-side, which is basic wizardry-level: at least they are not storing it on facebook-servers like whatsapp! :-) Signalapp stores metadata client-side, which is advanced wizardry-level: there is still a server, but only Amazon and the NSA have the skills to do the timing-analysis, once SGX enclaves are used throughout. Jami has very advanced wizardry-level: there **is** no server to store metadata. RiotIM+MatrixOrg central servers is > [readership] won't be frustrated with PTIO > b/c they were sufficiently warned > about what they were getting into Exactly. If we are careful to lay out the pros and cons, and indicate the wizardry-level of each thing, this should work out great. Here is https://www.privacytools.io/software/voip/ after re-imagining it as a table of wizardry-levels, 🧙🧙🧙 meaning very-advanced, 🧙🧙 meaning advanced, 🧙 meaning basic. Added whatsapp for comparison-purposes, left out linphone jitsi tox because I don't know them well enough. |voip tools | signalapp | wireapp | jami | whatsapp | |---|---|---|---|---| |logins/identifiers? | 🧙 | 🧙🧙 | 🧙🧙🧙 | ⚠️cellnum 2 fb | |server metadata? | 🧙🧙 | 🧙 | 🧙🧙🧙 | ⚠️all 2 fb | |cloud backups? | 🧙🧙🧙 | 🧙link | 🧙🧙🧙 | ⚠️media&docs 2 fb+goog | |mobile install? | 🧙 | 🧙⚠️ | 🧙🧙⚠️ | ⚠️trackers 2 fb | |laptop install? | 🧙🧙 | 🧙 | 🧙 | ⚠️⚠️ | |tablet install? | 🧙🧙🧙 | 🧙? | 🧙🧙 | ⚠️ | |use in a browser? | former | 🧙 | no? | ⚠️reverse-tethered | |user-friendly? | 🧙 | 🧙 | 🧙🧙 | yes | |et cetera, etc... | x | y | z | warningNotes | More wizards does not always indicate "better" ... it depends on the enduser. Often more wizards indicates "MORE HASSLE" rather than anything else :-) It is a huge pain to install signalapp onto tablets, although it can be done... the code runs, but it requires a lot of tedious messing around to get there. > maybe someone would travel to Czech for a burner phone, compile the code, use a special ungoogled ROM, etc There are a lot of those people, actually :-) Or at least, I was surprised at how many people are willing to do that kind of stuff. Don't forget hitting ctrl+u to bypass the minimized jquery bundle when you install signal4desktop on your favorite linux distro ;-) But in a way, this is the whole point of the wizard-levels: it tells endusers how difficult it is, to do such things. Getting a phone-num not linked to your financials and not hooked to your identity-card is tough, 🧙🧙🧙 kind of thing. Getting a phone-num which is linked to you in some fashion, but is a secondary phone-num different from your main cell-num, is often sufficient for most use-cases, and that is 🧙🧙 level of difficulty/hassle, plenty of services offer voip nums for under a buck a month, and you only need to register once, afterwards everything is internet-only. The majority of signalapp endusers though, do not bother with such things: they download from playstore, and pump in their cellnum, because it is less hassle. Similarly, I suspect the majority of wireapp endusers either pump in their cellnum, or their gmail ... hardly "anonyized" in any real sense! But getting a protonmail is 🧙 basic wizardry kind of hassle, and using that protonmail to signup for wireapp is also not THAT difficult. Jami has the best signup-anonymity... but the worst operational-hassle! Overall wizardry-level required to use Jami is probably "section two: advanced" ... but both wireapp and signalapp belong in section one, since they are user-friendly enough for everyday endusers (mere mortals without special tech-savvy skillsets) to install & use today. As jami gets more platform-parity and improves user-friendly levels, it will be ready for section#1 placement in a year or two. Similarly, if wireapp introduces federation, the will gain a wizard-level in their server-side metadata box, and if signalapp starts offering phone-num-shielding during usage it will gain half-a-wizard, and if it starts offering non-phone-num registration it will gain a full wizard, and if signalapp implements p2p mesh it will get three wizards. So there is a clear pathway to improve the table as circumstances change. But at the same time, we don't have to completely rewrite everything each year... the overall table will remain relatively stable, just, the column-placement in 1st/2nd/3rd/etc may change from year to year as the "best app" gradually shifts from app to app. Which raises the question... assuming signalapp and wireapp are in section#1... do we also list them in section#2 for comparison-purposes? If so, the ordering/placement would be different: signalapp and then wireapp (less users and more UI-related bugs allegedly) in section#1, but in section#2 aimed at hardcore advanced-wizardry-level endusers Jami might be first-place in the lefthand column followed by wireapp, with signalapp near the bottom because of the phone-nums... and in section#3 if that exists, Tox followed by Jami with signalapp in the middle and wireapp at the bottom because of the server-side-metadata. This would lead to some "duplication" but I think it would be helpful, because each section is aimed at a different readership (and the ones reading section2 and especially section3 are going to be VERY savvy folks).

We are coming close to making real progress here, it seems like.

tools that they actually can handle without issue

To me this is straightforward: if the everyday endusers CAN actually handle the tools, then put them in section1, and if not, section2. It is a judgement call though, and goes back to my question above... what is the split-point, between section1 and section2? What does it mean to say "this is a privacy-tool which needs overall level-two-wizardry from the enduser"?

Are we talking about how much tech-savvy level they display, e.g. confidence with CLI during installation-phase? Are we talking about their privacy-consciousness-level e.g. whether they are averse to server-side metadata and/or averse to phone-nums-as-identifiers? Or is it more of a "popularity contest" where tools in section#1 will be tools that have large userbases and plenty of forums/helpdocs/etc, whereas tools in section#2 will require more independence to troubleshoot? I think the last thing is easiest to demonstrably measure, but I'm not sure it is The Best For The Readership to split stuff in that fashion.

ghost commented 5 years ago

But what do you think the mission of privacyToolsIO would be, if not that same mission?

This should probably go to another thread, but I think the mission statement should change from:

"You are being watched. Private and state-sponsored organizations are monitoring and recording your online activities. privacytools.io provides knowledge and tools to protect your privacy against global mass surveillance."

to:

You are being watched. Private and state-sponsored organizations are monitoring and recording your online activities. privacytools.io provides knowledge and tools to protect the privacy of the masses against global mass surveillance.

This would define that goal as reducing mass surveillance as much as possible for most users. This is in fact why Signal is unfit. It is the masses (composed mostly of the typical user) who is exploited by the mass surveillance that OWS subjects users to. Users who are both advanced and also unusually extra motivated can avoid some of it (assuming they're still willing to financially sponsor privacy abusers), but this is not who PTIO should be targeting. And in the case of Signal, even when an advanced user escapes most of OWS privacy abuses, they are still contributing to viral privacy abuse because they will have friends who are vulnerable.

but your strategy is more aggressive

It's not "aggressive" to simply avoid a tool that directly subjects it's users to mass surveillance. It's actually an aggressive move to try to push users toward such a tool by endorsing Signal.

You think the mission is "recommend signalapp in 2016-2018

This is a straw man. I never endorsed signalapp.

I might endorse for some corner-case obscure cases, like if someone needs Haven alerts, but it's unfit for IM and voice categories.

Nevermind.. i was hasty there.

but then drop it completely in 2019+

Yes, that is the correct move given what we know now.

because it requires phone-nums and those are evil because telcos support mass surveillance -

I'm not going to restate the whole rationale. There are copious problems enumerated in the OP. The OP pretty much covers everything because I kept adding to it as new issues emerged. The rest of the thread just gives a detailed expansion of the issues in the OP.

If you need a single significant summarizing reason, one of the major reason for PTIO to stop endorsing Signal is that the endorsement actually sends people into a surveillance trap. PTIO is proactively working against its own cause by suggesting Signal and setting users up for more of the mass surveillance that they came to PTIO to avoid. It's an embarrassment that triggers trust issues and ultimately it's a credibility problem for PTIO.

In short, your strategy for privacyToolsIO fighting mass surveillance, is to recommend endusers install the flavour-of-the-year.

Welcome to the information security arms race, where we don't choose lousy tools on the basis of resisting change. Trying to cling on to an insecure option because you want stability is your business (and every user's choice to do so), but it's poor security advice.

I don't disagree that would be a nice plan. I just disagree that plan will actually work.

Actually it's failure to stay current with security developments that doesn't actually work.

Endusers won't change messengers every couple years,

That's fair enough and that's on them. Security advice that doesn't keep up with the state of the art is a recipe for disaster. Users are free to keep up or not, as they choose. Either way it's a bad idea for PTIO to not give the best advice for the information we have at the time. Otherwise if we're not going to keep the webpage current then what are we doing here?

Endusers won't change messengers every couple years, and if privacytools starts recommending that, it will no longer be giving recommendations to the masses,

Not keeping up with the state of the art and maintaining a stale website with outdated advice is exactly how you lose both the masses and the experts.

My mom has signalapp,

Now we know why you're so biased.

My mom uses Wire and protonmail. We need to find out what @BurungHantu1605's mom uses, because I guess he'll make the decision about what to do with Signal.

(edit)

Regarding the whole wizardry idea, users would want to know the complexity and effort entailed by taking on a new tool. So it would be useful. But we'd want to present it in a way that doesn't clutter the page and overwhelm them - or distract them from the shortcomings lists that are needed.

five-c-d commented 5 years ago

(edit) Regarding the whole wizardry idea... present it in a way that doesn't clutter the page and overwhelm them - or distract from the shortcomings

(edit2) Yes, correct. The classic way that the website was arranged, was all one long HTML page, but currently it is in the midst of a design-revamp. So we arrived in the nick of time ;-)

wizard-level stuff is summarized on the new "tier2" webpages

Tier1 is the new homepage, with links to tier2-and-important-tier3 portions of the website. No tables full of detailed wizard-level-info here on the tier1 homepage, but might explain "3 wizards means some hassle" or otherwise briefly define the glyph-meanings. Might also indicate that installing a new OS is a three-wizard hassle, installing a new provider is a two-wizard hassle, and installing a new browser or IM app is a one-wizard hassle. PSaaS offerings are 100% zero-hassle :-) * https://www.privacytools.io/ == #1 Providers: email, VPN, DNS. #2 WebBrowsers & addons. #3 OtherSoftware: IM, voip, etc. #4 OSes. #5 "PSaaS": privacy software-as-a-svc, searX + mastodon + matrixRiot + writeFreely + privateBin Tier2 pages are where the most good can be done, with some terse overall-wizardry-level tables replacing the barelinks * https://www.privacytools.io/providers/#os == vpn email cloud socialNetwork dns searchEngine webhost pasteSvc , these are barelinks to 8 subcategories * https://www.privacytools.io/software/ == emailClients emailAlts IM VoIP fileShare selfCloud fileSync passwdMgr calendar fileCrypto privaNet noteTaking otherProductivity , another 13 barelinks Tier3 pages will continue to use the wizardry-level stuff, but with more exactness (detail-rows not summary-rows), as well as having the wizard-indications stuff intermixed with prose that gives sufficient explanations and details, now that there is enough room. For example, here is the browser-page. * https://www.privacytools.io/browsers/#browser == Section1: TorBrowser Firefox Brave. Would reformulate this as 3-columns-with-many-rows, rather than just 3-columns-with-3-paragraphs. Footnotes and explanatory prose immediately beneath the wizard-rows. * https://www.privacytools.io/browsers/#addons == Section1continued: PrivacyBadger uBlockOrigin CookieAutoDelete DeCentralEyes TOSDR. Section2 == uMatrix NoScript. * https://www.privacytools.io/browsers/#about_config == Section3: walkthru of about:config tweaking * antiSection4: Chrome, Edge/MSIE, Safari, et cetera ... could be several more worth analyzing, 45%to64% chrome, 15%to23% safari, 2% msEdge + 3%to6% msie, 4%to5% firefox, 3% samsungInternet, 1%to3% opera, 1%to4% UC browser, 1% aospLineageOS, per https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Summary_tables Tier3 example numero deux, the VoIP page: * https://www.privacytools.io/software/voip/ == Section1: signalapp wireapp linphone. Section2: jitsi tox jami. Would reformulate these into two three-column-tables, footnotes and explanations in prose interspersed. * Section3 [new/suggested]: advanced tips on using optional features of wireapp (register with non-phone-num and avoid APK-version) as well as signalapp (register with secondary num and use non-stock addressbook-app), similar to the about:config walkthru of the browser-page. * antiSection4: skype viber hangouts. could be several more worth analyzing, facetime googleDuo LINE telegram whatsapp threema SilentPhone https://en.wikipedia.org/wiki/Comparison_of_VoIP_software#Secure_VoIP_software

Well, my mom only uses signalapp because I forced her to install it :-) If she needed encrypted confcalls she would need wireapp, if she needed encrypted email then she would need protonmail... plus somewhere to write down the protonmail-username-and-the-protonmail-password ... and probably also the protonmail-login-URL. "When your memory goes, don't worry, just forget all about it!"

Signalapp is easier because she just needs to have her phone with her, and know her own phone-num, and she has signalapp. Which is why it is a one-wizard solution: not as private, but very low hassle. But don't worry, she didn't start supporting telcos just to install signalapp, she already financially contributes, no virality-of-telco-ness there, promise! ;-)

copious problems. Feel free to re-read the OP. The OP pretty much covers everything

Yes, you have a long list.

long lists of Political Transgressions, do *not* lead to good listing-decisions

If your list of copious problems was applied EVENLY, to all the privacyToolsIO listings rather than JUST to signalapp, you would have to tell your mom to uninstall wireapp. Which you *would* have to do, in a year or so when Jami gets better platform-parity, and were privacyToolsIO to implement your aggresive strategy. Your list is a purposely biased list, in other words: you want to use it to delist signalapp, on the basis that they host on AWS ...just like wireapp! On the basis that they use google fonts on their support-pages-webserver... whereas jami and wireapp put GoogleFirebaseAnalytics into their *apps* directly! This is, to be blunt, not arguing in good faith. This is throwing a huge amount of crap and hoping some of it sticks. But the real problem for you, the unforgivable Political Transgression of Signalapp, is that you want it delisted and exorcised from privacyToolsIO to 100%, on the basis that phone nums are needed by signalapp, and some USA residents might buy a secondary phone, indirectly subsidizing the telcos *because signalapp forces them*. (This is true, I'm one of the people in that exact category :-) But wireapp also uses phone-nums, by default, right? Yet they get a pass. Not, they have an advantage there... signalapp is evil, wireapp is golden, and LOOK at the huge list of crap proving how evil signalapp is (just don't ask about wireapp we will have their political show-trial some other day, once jami is ready to assume the throne... temporarily, always temporarily). Point being: you will give up almost anything on your big list of the sins of OWS, when it comes to **any** project not run by Moxie. Because you have a goal, and you are letting the ends justify the means. In particular, you will *find a way* to make the Snowden endorsement meaningless, which only signalapp has -- though he did say that wireapp was reasonable that is true also -- no matter HOW hard you have to twist his words. That is what it means to be "aggressive" when arguing. It does not need any scarequotes, you are absolutely positively being balls-to-the-wall aggressive. Well, okay, you are being LESS aggressive and more conversational now. But your strategy is not incremental and laid back, your are wanting improvements and wanting them NOW :-) For fairness, you would have to tell the privacyToolsIO people to stop using github and do not DARE think about gitlab it MUST be notabug the only flavour-of-the-month state of the art issue-tracker, github is evil, because microsoft is a corporation *that drug-tests their employees* holy moly. Which is just what you did, of course, you are nothing if not consistent. And to me, that goes to show that you are a wee bit unreasonable. There are a lot of websites which have unreasonable attitudes, but github tends to be pragmatic attitudes: does the code work? Is the crypto sound? Rough proof that everyday endusers can utilize the app because it has a lot of downloads, rough proof that developers like the app because it has a lot of github stars? Okay then, that is good enough. > edited the OP to add As an aside, I can confirm that your edit of 3 hours ago is not showing up in the #843 OP, though I can see the earlier edits you made. Maybe there is some byte-limit or rate-limit you are hitting? And speaking of edits, you can go ahead and copy-paste every bad thing you say about privacytoolsio in 843 over into this OP for 779, because signal foundation has all their repos on https://github.com/signalapp and even links to github *right from the homepage* signal.org in the footer. Though I would prefer you just *link* to 779 and say "all the same things apply to OWS which uses github". But like one of the privacyToolsIO people said, just because microsoft is corporation does not alone make them evil, win10 is bad for privacy because it is full of trackers and spyware, but github is less-bad. Plus, I will add: whether microsoft drug-tests their employees has **zero** to do with whether github is a good issue-tracker for a privacy-oriented website. Zero. Changing the issue tracker is a lot of work, and will have a bad outcome, so the work is wasted: the current stable platform and github has a significant developer-community and THEY WON'T FOLLOW when you uproot and move to a new issue-tracker flavor-of-the-month. Because privacyToolsIO does not rule the universe, and most people don't see a huge privacy-problem with github. PrivacyToolsIO *is* a cool project, don't get me wrong, but, it is just *not* going to be a lever long enough to move the world off github in 2019.

To you it is a moral issue, so you take the aggressive stance: get off github or you are bad. Anybody that would use signalapp has a small brain. And if you met my mom, you would tell her she has a Small Brain because she isn't running trisquel, and crikey she OWNS a smartphone, and oh good lawd is that signalapp running on your PHONE, what evil person sucked you into signalapp with virality of the network-effect?? It was me, I confess. :-) My point here is that, if the goal of privacyToolsIO is what we both think it is, there are very definite limits -- inherent to everyday humans because they ARE everyday humans -- that will make your aggressive strategy impossible to realize. In practice, following the aggressive strategy just flat out fails to work.

to protect  your  the privacy of the masses against global mass surveillance

Right, excellent suggestion, I would e-vote for that, sure. But think what that altered statement really means. If you want to protect the masses against surveillance, you educate them in a way that leads to achieving mass adoption. If you call everybody idiots all the time, and force them to reinstall everything they own, and then force them to reinstall everything AGAIN the next year, and AGAIN the year after that, they are going to stop listening. Which is why the current statement says your privacy: it is speaking to the readership, people who are reading the www.privacyTools.io listings. Not about "the masses" in the abstract. Just, you-the-reader, and the collective-you, the readership. It is definitely a question, what the intended audience actually is.

You want the intended audience to be people like yourself and myself, hardcore folks who are willing to uninstall as needed, comfy with an endless complex treadmill of patches and upgrades and tweaks, et cetera. But I want to be able to tell people "hey skim through www.privacyTools.io and then check back with me if you have questions about anything" ...and not people like myself, people like my mom, everyday people that need advice.

So the question is, what kind of people is privacyToolsIO speaking unto? And is the goal to improve privacy for the readership (see previous question on who exactly the readership actually is intended to be), in the short term? Or is the goal, to improve the chances of achieving mass adoption of privacy-enhancing technologies in the coming decade or two? If the audience is a niche one, of cryptonerds and FSF-moralizers, then I will be the readership. If the audience is everyday people, then I will be the person who evangelizes the listings, and tries to get everyday people to be in the readership. So either way I'll stay involved, just, passively involved in strategy1 versus actively involved in strategy2.

failure to stay current with security developments that doesn't actually work

Sure, this is true. It is practically a truism. But staying current means, using well-vetted crypto invented in the past few decades. It does NOT mean, using crypto that was invented in the past few days. If you are cutting edge, it CAN mean using crypto that was invented in the past few years, though.

two good strategies: LTS versus rolling-release

Security of cryptosystems is a hard problem, because they look fine until you start to notice the holes. Signalapp does not depend on SSL/TLS, because Moxie spent years poking holes in CA/PKI/etc implementations and decided it is just never going to work (signalapp has TLS but they are pinned certs baked right into the APK ... reason number 3852983 why federation would be risky since every federated server would have to provide their very own pinned cert ... and you just busted the distribution-chain wide open and re-invented the CA/PKI/etc wheel again). Google and Microsoft and Apple tell me that if I want to stay secure, I have to let them send me automatic updates. But am I really secure, thataway? Because along with the security patches to non-zero-day exploits, I also get a lot of stuff I don't really want. So much stuff that I cannot possibly review the security-ramifications, let alone the privacy-ramifications. And of course, most of the "stuff" does not even HAVE source code with libre-licensing, so I would have to chug through the machine code if I wanted to audit the endless flow of patches. Different people have different approaches to PROPER security of a linux distro, however. You are a debian person, so you understand the LTS model, which is best exemplified by the policies of the CentOS project: ten years of security-patch backports, and **NO** feature-upgrades that are not security-related except at specified times, with plenty of room to audit the incoming upgrades before they happen, and field testing in Fedora of all the codebase first. I think this is what privacyToolsIO listings are supposed to be: a list which rarely changes, moves slowly, and reacts quickly to patch security-flaws, but *only if they are really security flaws*, not if they are just latest-php-flavor-of-the-month. The "opposite" approach to securing a linux distro is the rolling release model, best exemplified by Arch/Parabola. There is no backporting, because you are always running the latest codebase, and **so is everybody else** running Arch. You might download new security-patches once a day, or multiple times a day. Or maybe you are "lazy" and only do that process a couple times a week. But you do a lot of updates, because you are staying on the bleeding edge, so that you always have the latest patches. This is a viable model. I have been both kinds of distro-enduser, and they both have their headaches. The main headache with Arch&friends is the constant churn... *something* is always breaking/broken. There is a lot of fiddling around, to keep the system fully working. The main headache with CentOS and similar efforts, is the lack of churn... *something* is always missing/obsolete. There is a lot of fiddling around, if you *really* need something that didn't exist FOUR YEARS ago when the centos-flavour you happen to be running first saw daylight. Most everyday endusers want to have their cake in the fridge, and eat that cake from their plate, simultaneously. They want the latest features. And they want rock-solid reliability. And they want, most of all, zero fiddling. Plus, proper privacy would be nice, if it is not too much hassle, of course. What is the correct way for privacyToolsIO to behave, going forwards? I think it should be an "LTS listing" of the best most well-vetted options of 2019: debianLTS, firefox, signalapp, wireapp, mullvad, protonmail, and so on. You want it to be more aggressive: signalapp declared obsolete as of 2018, wireapp declared obsolete as of 2020, jami declared obsolete as of 2022, and so on... which is a "rolling-release listing" not an LTS listing. For the 2019 listing, you -- and I'm exaggerating for effect here not being accusatory -- you would have parabola, torBrowser-git, statusIM, jami, cryptoStorm.is, bitMessage, and so on. Nothing wrong with those things... for me. But for my mom, there is no way she will install parabola Linux and update the OS twice a day, compile her own torBrowser, deal with the just-hatched StatusIM, work around the platform-parity troubles of Jami (and setup her own Ethereum-based username), figure out how to get online when the only one of the 28 cryptostorm server-nodes on her continent has an outage, decipher the source code of bitmessage's gitlab repo because she could not locate the user-forum, and so on. Just. Not. Happening. Sorry. Not. Sorry. And were I to somehow convince her to put up with all that crap... and then come next holiday visit a year later, told her to uninstall EVERYTHING because it was no longer the cutting edge in privacy and gotta keep up with the Joneses ... that would be when the hammer dropped and my bubble was burst. By contrast, she already uses some of the tools on the LTS list, and I can probably get her using the majority of them over the next few years. She sees the news, and it is full of data-breaches and privacy-screwups and bad people running for office and she is no dummy. Not wanting to mess around with installing and configuring and learning to use Jami, does not mean she has a Small Brain, it just means, signalapp is good enough for her right now. And by *not* bothering her to upgrade her IM app, means I don't wear out my welcome... and instead I can bother her to upgrade her OS or whatever the project is that holiday-visit. Plus not be sent to sleep somewhere else ;-) I like mom's cooking so there is no way I'm going to tell her "hey remember when you installed signalapp in ten minutes that time... well we are going to install jami today and it will be So Much Fun to learn all the new stuff." Fun for me, maybe, but for her a nightmare of a timesink that she will never really benefit from, she won't be able to pass it along, SHE needed help installing it. Whereas, with signalapp, she can tell her [insert social group here] of other people "hey this is cool you can install it and cryptocall me" and they CAN actually do that, as long as they own a phone. Unlike yourself and myself, that is true of 90% of the populace older than age 18 these days, roughly speaking. That's probably an underestimate actually. What percentage of the populace has the wizardry-level needed to install and use Jami? Way lower than 90%.

If the goal of privacyToolsIO is to educate everyday endusers, in the hopes of achieving critical mass for the political idea that there is such a thing as privacy and that it is a valuable and valid value-stance, then LTS listings are the way to go. Very little churn, no lists of political transgressions (unless applied evenly and fairly to the entire listing of all apps), everyday endusers as the intended audience.

If the goal of privacyToolsIO is to educate privacy-nerds so they can have a central place to share the latest in cutting-edge software-recommendations, rolling-release listings are the way to go. Pick an specific target niche -- might be people that love libre-licensing or might be people that fear corporate surveillance or might be people that fear state-actor surveillance or might be the small central portion of the venn diagram which is all three of those things simultaneously -- and then concentrate on making best-of-the-best esoteric tools get more exposure to early adopters. But don't expect my mom to read the listings, let alone install any of the software. She's a smart cookie but she doesn't have time for the hassle of constantly re-inventing her tools, she wants to USE the tools, not tweak with the toolbox.

strypey commented 5 years ago

@Herohtar

Snowden has commented on Signal as recently as February of this year

Thanks for the link. But again I have to agree with @libBletchley , this is no longer a glowing endorsement of "anything made by OWS", but more like an admission that he still uses Signal even though it no longer deserves the reputational capital that past endorsement has given it (just web search "Signal" and his name to see how may tech journalists have used that endorsement in their headlines). I can understand the temptation for OWS to leave that glowing endorsement on their site, but when measured against that Feb comment, it's hard to argue that it isn't misleading.

Snowden may be still using Signal because he isn't yet convinced enough of any potential replacement to go through the transmission pain of switching tools. This is the situation we all find ourselves in at times, which is why it's valuable to share our knowledge and strategies in places like PTIO. To that end, we can all contribute more light than heat by being careful to show respect for each other during these discussions, for each other's knowledge and strategies, and for the time we are all putting in to share them. To that end I want to clarify that my last comment was intended as a criticism of a pattern of communication I find unhelpful; OWS apologism. Mainly, asking critics to disprove OWS claims (like the claim that the proprietary Google Play Store is more secure and privacy-respecting than the free code F-Droid system), thus reversing the burden of proof that rightly belongs on OWS. It was rude and patronizing of me to dismiss anyone as "OWS apologists", and I apologize for that.

@five-c-d

But unless I'm badly misinterpreting your words, you sound like you are recommending that wireapp be promoted to first-listed-in-the-Top3, for VoIP listings, not sure what your position is for IM listings, and that signalapp be ... what exactly?

At the risk of sounding melodramatic, our situation is that we are giving strategy advice for waging a (non-violent) guerrilla war against a global network of powerful adversaries. Some of them make the tools (hardware, software, networks, and servers) available for use by the people we want to advise, which make it a very hard job.

The most important thing when trying to give such advice is to openly acknowledge that there are no right answers, just 'less wrong' ones. So I actually disagree with @libBletchley that Signal ought to be removed from PTIO altogether. As I mentioned in #729 this is more likely to be seen as an omission than a non-endorsement anyway. But I absolutely agree that the PTIO ought to be transparent about the downsides of Signal listed in the OP, and be similarly transparent about any other tool listed on the site.

Sites like PTIO are valuable because they gather relevant information in one place to save people a lot of web searching and source filtering, and guide them through some of the considerations they need to take into account when choosing privacy tools. But we are not the ones who live with the consequences of people's software choices, they are, and that includes anything that might go wrong as a result of treating a hierarchy of endorsements as gospel. So quite frankly I think that instead of treating the whole thing like the privacy Oscars ("... and the winner of Best Private Chat App for Mobile is ...") it's wiser to simply tell people what tools we use, and be honest about their pros and cons. IMHO weighing up those pros and cons for their own situations ought to be explicitly left in their hands.

The second most important thing about strategy advice in a guerrilla war is that the 'less wrong' answers are not only based on what might work best right now, but what gives us the best chance of not losing the war. In other words, we need to look at each tool or tactic based not only on its technical merits today, but also what we know about its past, its direction of development, the statements of its creators, and the nature of the organizations those creators run and partner with, and so on. Right now, the Signal and Wire apps both have pros and cons that could be said to cancel each other out. But I find the creators of Wire to be both more cooperative and more transparent than the Signal creators, on a whole range of issues. I like the directions Wire have said they are heading in (federation, F-Droid distribution), and I note Signal have consistently dismissed and ruled out ever going in that direction. It is for these reasons, as well as the relative merits of Signal app vs. Wire app right now, that I use and endorse Wire over Signal.

ghost commented 5 years ago

Design flaws

copious problems. Feel free to re-read the OP. The OP pretty much covers everything

Yes, you have a long list.

I've simplified it: ows_signal_design

This makes it clear that the Signal endorsement makes the mission objective (to provide "knowledge and tools to protect your privacy against global mass surveillance") is a lie as long as Signal is endorsed.

politics matter

long lists of Political Transgressions, do not lead to good listing-decisions

You may not be interested in politics, but privacy-hostile policy is absolutely a factor in avoiding mass surveillance, and secondary to direct privacy abuses (which Signal causes the most of).

Wire: phone is optional

But wireapp also uses phone-nums, by default, right?

Wire desktop users are not even asked for a phone number. Mobile users have a choice between phone and email reg.

helping the masses

If you want to protect the masses against surveillance, you educate them in a way that leads to achieving mass adoption.

Mass adoption of a tool that subjects users to mass surveillance works against the agenda. PTIO supports mass surveillance by endorsing Signal.

(again) code quality still doesn't matter when the design is broken

But staying current means, using well-vetted crypto invented in the past few decades. It does NOT mean, using crypto that was invented in the past few days.

Well-vetted crypto is only a useful factor for comparing tools that are not broken by design.

guerrilla war tactics

In the context of fighting a war, it's important to not miss opportunities for a tactic that yields a significant utilitarian effect. So let's compare two tactics:

Effect of removing endorsement
  1. headlines "OWS Signal loses privacytools.io endorsement" splashed across social media
  2. users who know what Signal is but don't know PTIO exists get a strong temptation to see what this is about
  3. OWS deceptions and shenanigans exposed:
    • "The safest and easiest way to install Signal for Android is through the Google Play Store"
    • "Free for everyone"
    • "As an Open Source project supported by grants and donations, Signal can put users first."
    • "no creepy tracking"
    • "Just open technology"
  4. significant number of people learn about many Signal pitfalls, thus increasing demand for tools that avoid the pitfalls, and promote truth and transparency
  5. awareness of PTIO increases
  6. credibility of PTIO increases
  7. the public learns that PTIO is not simply a crowd follower, but that they actually do their homework
  8. public perceived credibility of OWS drops to a realistic place; OWS feels pressure to improve (which doesn't happen in forums trafficked by small numbers of enthusiasts)
Effect of demoting Signal, retaining endorsement
  1. endorsement gets a different color or drops to *worth mentioning*. No one notices because users don't even know color is significant
  2. existing Signal users see that their tool is still endorsed and move on - likely thinking nothing of the extent of the endorsement
  3. prospective users see their their friend's tool is listed, so they go along without further investigation
  4. nothing changes:
    • OWS doesn't care due to lack of impact on their bottom line.
    • PTIO continues telling users they are helping them avoid mass surveillance, while actually sending users into an ecosystem of mass surveillance and walled-gardens.
    • PTIO continues to look just like a trendy crowd follower, with no real insight

doghouse needed

Guerrilla war tactics aside, I agree with @strypey's point that a total absence of Signal would look like it was overlooked. At the same time, PTIO would not generally list other privacy-hostile options like Facebook because that wouldn't risk being regarded as an oversight. So Signal should be listed as clearly not having PTIO endorsement and would need to include rationale that covers the points here. Couple approaches:

I think a "doghouse" could capture the idea that tools therein are being called out and punished possibly on a temporary basis. Perhaps different than Schneiere, we could even reserve the doghouse for past endorsements that could reacquire endorsement in the future.

strypey commented 5 years ago

The important bit in the rant about guerrilla war strategy is the "less wrong" bit. I agree that Signal has some serious flaws that they refuse to correct, but I think it's overstating the case to deny that when it comes to user privacy and software freedoms, it's less wrong than most corporate-owned chat apps. It's also less wrong than Telegram in at least one way; OWS publishes source code for their server and Telegram doesn't. These differences are important. I used a push button phone until very recently, so as to avoid using iOS or vanilla Android with their proprietary code and risk of back doors (trying to avoid mass surveillance), but that meant any communication I did over the cell network was unencrypted (subject to mass surveillance and at risk of targeted surveillance), so neither option is "right", but which is less wrong?

If we made a complete list of every criteria that needs to be met for 100% protection of privacy, the only viable recommendation in 2019 would be "don't use computers or the internet to communicate". I tried this for a year (book in the works) and it's no longer viable for most people. So the critical question is, what advice a) is practical in 2019, and b) if followed, will facilitate people using less wrong options so we might get to the point of meeting all the criteria at some point in the future. This is what I mean about strategy that ensure we don't lose the war.

ghost commented 5 years ago

it's overstating the case to deny that when it comes to user privacy and software freedoms, it's less wrong than most corporate-owned chat apps.

Software freedom is rock-bottom with OWS. We've evolved to a point where the general public finally accepts the idea that software must be free to ensure security, so to say that a superficial free license is somehow adequate in situations where software freedom is denied in effect and in practice through network protectionism and trademark bullying is selling the movement short -- particularly when other tools are truly free software (not a label masquerading as such the way OWS uses "free software" as a marketing slogan that fails to empower the users).

It's also less wrong than Telegram in at least one way; OWS publishes source code for their server and Telegram doesn't.

Telegram is a low standard to set the bar at because Telegram also subjects users to the mass surveillance of phone registration. Of course a PTIO endorsement should do better than Telegram and any apps (corporate-owned or not) that are as sloppy as OWS about privacy.

We can do better than this system.

If we made a complete list of every criteria that needs to be met for 100% protection of privacy, the only viable recommendation in 2019 would be "don't use computers or the internet to communicate".

The criteria I'm after is the lesser of evils, which always leaves an option. OWS Signal fails that by a long shot, and for PTIO to endorse something worse than the lesser of evils would be a betrayal. Signal gives ground to many of our mass surveillance-pushing adversaries needlessly with reckless disregard. Telling a privacy abuser that they are doing good work (endorsement) from the user standpoint also denies users potential progress toward mass surveillance avoidance by keeping the standard of privacy low.

strypey commented 5 years ago

@libBletchley

to say that a free license is somehow adequate when software freedom is denied in effect through network protectionism is selling the movement short

I agree, which is why I didn't say that. I just pointed out that making source code available under libre licenses makes it measurably less wrong than tools whose owners don't. My point is that educating people about these kinds of measurable differences, and why they matter, empowers them to evaluate the available tools for themselves, in the context of their own specific situations.

For example, a person could eliminate all the proprietary tools and evaluate what's left. Or they could eliminate all the tools that aren't ready for mainstream use (bleeding edge alphas, betas, bad UI etc), and see if anything that remains has source code available. Applying either of these heuristics to encrypted chat apps (including voice/video) in April, 2019 would probably leave them choosing between Signal and Wire. At which point other criteria, like the ones you list in the OP, can be used to guide their choice, based on their specific needs.

The criteria I'm after is the lesser of evils, which always leaves an option. OWS Signal fails that by a long shot.

That depends on what you include in the list of evils. If the list includes only the well known chat apps (Skype, WhatsApp/ FBM, Hangouts/Ello, FaceTime, Telegram, and Signal), Signal would be the lesser evil. If we expand the list to include Wire, you and I would agree that Wire is the lesser evil, but this doesn't appear to be the consensus position here. If you add Jami to the list, it would definitely be the lesser evil regarding protecting users from service providers (there aren't any) but given that it's far from feature complete compared to any of the other apps in the list, it may not make sense to include it.

I think @five-c-d makes a fair point about applying the same rigour to our analysis of other tools, including Wire, which also has a number of failings in April, 2019; proprietary dependencies preventing packaging in F-Droid, no server>server federation (yet), desktop clients using Electron (as do Signal's) etc. Making fail list similar to the OP for each of the other chat options (and other tools PTIO lists or could) could help to ensure fair apples-with-apples comparisons among tools (within categories and maybe even across them).

Regarding the concern @five-c-d raise about tool churn, and about geeks communicating with non-geeks, this is a good reason not to endorse walled gardens like Signal. If PTIO endorses apps that communicate over open protocols; federated protocols like XMPP or Matrix, or P2P protocols like Tox or the protocols Jami uses, then different users can choose different tools for their specific needs, which inevitably change over time as do the tools themselves, while still communicating over the same network. I agree that cross-platform support and self-teaching UI is essential for any of these tools to actually retain users though. This need to evaluate options on multiple criteria, where an app may be much better on some and much worse on others, is why I'm sceptical about endorsement vs. education.

t1011 commented 5 years ago

Telegram is a low standard to set the bar at because Telegram also subjects users to the mass surveillance of phone registration. Of course a PTIO endorsement should do better than Telegram and any apps (corporate-owned or not) that are as sloppy as OWS about privacy.

Telegram has no right to be mentioned on PTIO due to the fact that it does not apply to protected instant messengers (I hope you don’t need to explain why)

five-c-d commented 5 years ago

Rigour to our analysis

If you look at the simplified analysis, every major Bad Player that signalapp touches and political transgression that signalapp makes, wireapp also suffers from ;-) With possibly the exception of Cloudflare? though wireapp uses different trackers in their support-website... which is also their wireapp-for-web site and their download-site. The APK also has a tracker, though I'm not sure whether it is present-but-non-enabled, or present-and-active.

Optional ability to register with an email, is not much help, if you are tracked via cookies or APK or whatever... and like signalapp, so many wireapp folks use an identifier associated with their realworld identity, that it is effectively impossible to claim wireapp is "anonymizing" in any real sense. Worse: all social-graph info is stored as server-side metadata, so even people that take great pains to evade the tracking-cookie and shield their IP and register with a protonmail username completely disconnected from their real-world identity... are easy to shadow-profile from their less-privacy-conscious contacts and the social-graph dataset.

'best' tool depends on what matters most to the enduser

Signalapp is not perfect, and apples-to-apples comparisons across disparate tools with divergent goals are truly hard (wireapp is aimed as beating skype and signalapp is aimed at beating whatsapp and riotim is aimed at beating slack and those result in different tradeoffs being made). But I've done the apples-to-apples comparison, in my head at least ;-) If what you mostly care about is metadata-resistance, and well-vetted crypto, and fully libre-licensed source, then signalapp is hard to beat. RiotIM has zero metadata-resistance unless one runs their own homeserver... and whilst I might do such a thing, I cannot ask all my contacts to also do such a thing. The crypto is not as well-vetted, and is off by default unless the server enforces crypt (cf you-must-run-your-own-homeserver). Wireapp is bad on metadata, somewhat obviated by the ability to use an email-identifier... but the risk of shadow-profiling should any of my *contacts* be less than scrupulous in their opsec, and the trackers which seem to never go away, are non-negligible concerns. If what you mostly care about is 100% libre-licensing, GTK-native Linux client, ability to self-host, then RiotIM is clearly the winner. And by self-hosting, you get the metadata-win, as long as you are *very* competent at hardening servers at least. Signalapp is very difficult though not quite impossible to self-host, but it doesn't federate so you have to modify the client-app to be able to switch servers dynamically, a big pain. You can get a TUI-mode client, or an electron-client, or an android-in-a-VM client, but not a GTK-client yet. Wireapp is less difficult to self-host, is thinking about federating someday-maybe, and because of the email-identifier-thing and the web-client-option is less of a pain to dyna-switch (as long as you don't mind having multiple personas). They even have an old prototype GTK-client, https://github.com/wireapp/coax but it is pre-alpha quality and seems dormant... so probably you are stuck with electron-wireapp or wireapp-in-a-browser-tab. If you mostly care about not needing to have a phone-num, political tone (as distinct from actual *behavior*), and cloudflare-specifically, then **maybe** wireapp is a win during 2019... but almost certainly by 2020 the goalposts will have moved and Jami will be on top. > Telegram has no right to be mentioned I think Telegram is what the in-the-doghouse-for-now idea was invented for :-) And for that matter, whatsInstaBook. If what you most care about is convenient cloud-backups, and slick-feeling UI, and how popular the app is, then these *are* options though. Just, not privacy-respecting options.

Regarding the concern five-c-d raise about tool churn... federated protocols like XMPP or Matrix, or P2P protocols like Tox or the protocols Jami uses, then different users can choose different tools...

Uh, that sounds like the opposite of my worry :-) My issue -- well okay one of my many many issues -- is that I don't want the privacyToolsIO listings getting rewritten with the latest fad-tool every few months. Everyday endsusers won't stomach the hassle of switching to yet another linux distro, switching to yet another messenger, switching to yet another webmail provider, switching to yet another VPN, switching to yet another browser... because LAST year's recommendations are now "in the doghouse".

XMPP is practically the case-study in tool-churn. Every platform has a different tool! Every couple of years a new xmpp4ios tool becomes temporarily dominant, then fades away. Same for all the other platforms. If you care about OMEMO at least, if you just need unencrypted then almost anything will do that. The protocol is quasi-stable slash meta-stable, and to a lesser degree the server-side tools are reasonably stable (ejabberd versus prosody 90% of the time are the maximum-privacy-oriented self-host options methinks).

If the list includes only the well known chat apps (Skype, WhatsApp/ FBM, Hangouts/Ello, FaceTime, Telegram, and Signal), Signal would be the lesser evil

To me this is the critical factor. Add in WeChat/QQ, SMS, Discord, iMessages, Viber, LINE, as well... and possibly duo+gmail rather than hangouts+allo which are now defunct... and you have sketched the sub-industry with >1% marketshare and mindshare. Messengers are a network-effects phenomenon: climbing those walled-garden strongholds, is exponentially harder, the smaller your 2019 userbase. And if you want the masses on your side, so you can defeat mass surveillance, there has to be a plan which beats the competition. Cross platform is necessary but not sufficient, solid UX is necessary but not sufficient, the competitors also have those things.

Feature-comparisons are a possible solution to our conundrum here, but hard to implement. I'm working on trying to lay out how I think it could be done (offline as yet)

ghost commented 5 years ago

Phone number issues: https://www.reddit.com/r/signal/comments/bfqdfj/how_is_this_possible_unfortunately_it_is/

ghost commented 5 years ago

Good find @zexi3453. Paragraph 1.viii added.

It would be interesting to know why any mass surveillance opponent finds mandatory phone registration acceptable in the slightest. I suspect if someone has a phone and they can't see beyond themselves, then they've already accepted and conceded to mass surveillance to that extent. So then they're only looking at the phone number disclosure to Signal and consider that insignificant, which is ultimately detrimental to everyone.

To give just a part of the big picture, these are some problems with endorsing any phone registration mandate:

(PDF) phone_registration

Note that I've omitted the huge graph that mushrooms out of forcing procurement from phone vendors, none of whom are clean. The graph is a clusterfuck teeming with needless privacy abuses as it is.

five-c-d commented 5 years ago

@zexi3453 as you can see from reading the thread, the problem was an untrustworthy insider. This is not a flaw in how signalapp works, so much as it is a violation of the assumption that "when Alice sends a secret message to Bob she trusts Bob with that secret". There is no way to build a piece of encrypted chat-software without that assumption, and signalapp is no exception to that blanket statement.

signalapp and the insider-threat in various guises: he-said-she-said, protocol-level deniability vs beyond journalistic-insinuation-level deniability, spycam shoulder-surfing versus custom-phone-label in the addressbook, how to disable addressbook-integration when necessary, and why the KiddieKam attack-vector makes it literally impossible for any software to save Alice from untrustworthy insiders

1. the reddit-thread describes an endpoint-compromise where one of the **participants** in the conversation leaked the message-contents and the metadata to the press. Signalapp cannot save you if you trust somebody with secrets, and the person backstabs you. And neither can any of the other chat apps :-) It is true that signalapp tends to not pretend it can make you pseudonymous, whereas something like Threema -- closed source and thus not in the privacyToolsIO listings -- assigns each person a randomized 5193892429842395 type of threema-identifier seems to be better in that respect. In a sense Threema *is* better because it is somwhat more plausible to deny that Alice is the human behind 5192892429842395 ... but even then, it is a case of he-said-versus-she-said (Alice saying "that is not my threema identifier" versus the conversation participant Larry who leaked to the press saying "oh yes it is her threema identifier she is lying") 2. signalapp actually does address deniability at the protocol-level: it is perfectly possible, when Alice with signal-identifier +1-111-111-1111 is actually in a chat with Larry at his +6-666-666-6666 signal-num, for Larry to falsify the transcript by altering his SQLCipher database. It is also possible for Larry to falsify the screenshots without falsifying his signalapp DB, and either technique will dupe some journalists. You can fool some of the people all of the time, and all of the people some of the time, as the old saying goes. But mathematically speaking, Alice is on solid ground if she wants to say "that is not my signal-num" because in order to register +11111111111 all that is needed is *temporary* control of the unencrypted SMS-reception of that telco-num. (Signalapp has a registration-lock-PIN to defeat most sorts of SS7 and bribe-the-telco hijacks of Alice's num.) In other words, Alice can plausibly claim "that looks like my telco-num but I don't use that as my signal-num" and back up her story by registering with some secondary-num as her signal-num on her primary handset... might be landline or online-voip-num or whatever... the signal-num need not match up with the simcard-if-any in the android-device Alice is utilizing. In reality this protocol deniability feature is often not THAT useful, because when one of the conversation-participants is planning to backstab the other, it is usually pretty straightforward to get something 'on the record' which only Alice would know, or otherwise "prove" that signal-num +11111111111 is in fact the same Alice as the person with cell-num +1-111-111-1111. Signalapp is better than most other chat-apps in this respect. With something like wireapp there is server-side proof that wireapp-identifier "alice@aliceEnterprises.com" was communicating with "larry@evil.inc" on Monday January 1st at 1:11pm ... so although Alice can **claim** somebody hijacked her work-email, but Larry is saying to the press that oh no it is really her alright, and here is my phone-transcript of chatting with Alice on 1/1, the wireapp server will back me up. And Larry is correct, the wireapp server DOES back him up, even if Alice has deleted her side of the conversation in the meantime. Even if Alice has unregistered her wireapp uid, *Larry* is still a registered wireapp enduser, and thus I believe the metadata about Larry's conversation with Alice is still stored -- BOTH people have to delete their wireapp identifiers before the server-side metadata is wiped. If instead of talking about one of the conversation-participants leaking to the press, and you are instead talking about one of the conversation-participants leaking to NSA/GCHQ or CIA/MI6 or at least a powerful law-enforcement group like FBI/EUROPOL, the barrier is much worse, because if the governmental agency has subpoena power over AWS servers and VPN-providers or ISPs on both ends of a chat, they can often using network-layer metadata about what IP sent what size of packet at what time, to put two and two together and show beyond a reasonable doubt that Alice and Larry were communicating. (This network-layer risk applies to signalapp as well a wireapp ... it is less-applicable to things like Jami. as long as **both** endusers are exclusively using RingCx hash-identifiers without ethereum-usernames and without SIP-nums associated at any point, but probably the most resistant to such attacks is the now-dormant Ricochet project which uses ricochet:abcd1234123421512 type hash-nums as the sole method of identifiers and Tor as the sole method of transport, if memory serves). 3. outside the protocol-deniability level, there is the question of shoulder-surfing. From the scant details available, it sounds like this was a conversation-participant purposely leaking. However, it is plausible that what actually happened was a paparazzi-attack-vector: one of the participants was conversing on their endpoint-device, and the press used a combination of a telephoto-lens and a high-resolution digicam to record what was visible on the *screen* of the device, without the device-owner knowing what happened. This could happen if the device-owner was in a public place like a restaurant when sending&receiving messages, or this could happen if the device-owner was in their own home but failed to fully close the curtains on their nice big window facing the street. This is also possible with lower-tech shoulder-surfing attacks, where the adversary just stands nearby and peeks over Alice's shoulder whilst she is messaging. No software can truly protect you against this kind of in-person on-the-scene type of attack-vector, because the adversary is breaching physical security rather than breaching the crypto. Alice is the intended recipient, and Alice's device is the authorized device, but if Alice is using that device from an unsecured location, or if the adversary has found a way to peer into Alice's bedroom with a telephoto-lens setup from the building across the street, signalapp cannot save her. There *are* some workarounds which Alice might consider utilizing, however, and that signalapp already does support, however. Addressbook-integration is enabled by default, and Alice can set the names of the people in her contacts-app (the stock one or a more secure and privacy-conscious addressbook app of her choice) to whatever she wishes. Signalapp also supposed the "custom label" field of the addressbook-app, which allows Alice to set the display-phone-num to whatever she wishes, as well. Finally, signalapp will show the signal-avatar of the person Alice is chatting with by default, but if Alice has configured a custom addressbook-avatar for that contact, it will be displayed instead. This effectively allows Alice to anonymize the titlebar of her sensitive contacts, or of all her contacts, on the primary conversation-list screen when signalapp first opens, and on the chat-history screen. Instead of saying "Larry Leaker, avatar-of-larry's-face.jpg, +6-666-666-6666" at the top of the chat-history with Larry, it would say whatever Alice specified: "Agent L, avatar-of-a-llama.png, +6-___-___-__66" for instance is a good choice. None of this is on by default, because it would make signalapp almost unusably difficult for the everyday enduser, but for endusers at risk of paparazzi with telephoto lens gear or shoulder-surfing thugs or anybody with high-rez spycam gear, it is a helpful feature. Alice can also obscure her chat-messages if she is careful to use asynchronous voice-notes and synchronous cryptocalls audio-only, rather than textual messages and videocalls which might be lip-read by a high-rez spycam conceivably. None of these measures are any help if the person Alice is communicating with is untrustworthy, however: Alice can set her signal-profile to "Agent A" and set her signal-avatar-pic to "alligator-in-africa.jpg" but Larry can tell the press 'oh yes Alice at AliceEnterprises is really agent-alligator' and give out her signal-num as well. Alice can use a num which is not tied to her identity, but this merely reduces the situation to he-said-she-said... Alice **has** to tell Larry 'okay her is my identifier' in order to securely communicate with him, no matter what else she does. Which is true no matter what software app they utilize, of course. If Larry leaks, Alice is in trouble. Signalapp has default settings which might get Alice into trouble... but only if Alice is trusting somebody untrustworthy, in which case, no matter WHAT software Alice is using, she is in trouble! 4. Although it is on-by-default, to allow things like the setup described above where Alice and Bob are able to use custom-label-fields to obscure their phone-nums on both ends of the conversation from spycams and shoulder-surfing, it actually *is* possible to setup signalapp without tying into the addressbook-app at all. During installation, you just deny contacts-permission to signal4android or signal4ios, whatever the smartphone you have, and then you get a tabula rasa when you register your signal-num. (Which is typically not linked to your identity if you are going through the hassle of denying addressbook-integration entirely.) To communicate, one side or the other needs to initiate a chat-session and pump in the signal-num of the other person... this is a one-time-per-contact thing, and I do it like this, it is not too annoying as long as you don't CONSTANTLY find yourself meeting new people all the time. If you are a traveling salesman or something, addressbook-integration is essential and you should get a privacy-respecting addressbook&crm app. But if you have a few dozen contacts that don't rotate their phone-nums all the time, signalapp without any addressbook is pretty straightforward to utilize. They all have to be willing to configure their signal-profile-nickname and ideally some kind of signal-profile-avatar, but for the most part whoever is the most nerdy person can deal with initiating chat-sessions and managing groupchat-memberships and that kind of thing, the others set their own profile-info at install-time and are done messing with anything until they upgrade their handset. I recommend keeping a "backup copy" of your signalapp contacts either on a piece of paper stored in a secure location, or if you are on signal4android you can export the encrypted-backup-blob and copy the file over to somewhere -- keep the 30-digit restore-passphrase of the backup-blob in a secure location where Eve cannot get it, because the verified-safety-nums are also in the backup-blob and you don't want Eve impersonating you. Stolen or confiscated handsets are not catastrophic so long as you have either the paper-hardcopy of your metadata or the encrypted-backup-blob and the paper-hardcopy of the decrypt-passphrase. There is no option to set a custom-phone-label within stock signalapp when addressbook-integration is enabled, but it is a two-liner change to the codebase if you want to hand-compile your own APK every few months which disables the phone-num at the top of the titlebar without needing to install and encrypt any privacy-respecting addressbook-app. 5. At the end of the day, however, signalapp is just an app. It is a piece of software. It runs on your system. You cannot assume that the other person in a chat with you is running the exact same software, exact same OS, and so on. If they have weak opsec, if they are being surveilled with a telephoto lens whilst messaging with you, if they are a leaker or otherwise willing to backstab you, they are **untrustworthy** and no software can make them trustworthy. In particular, this is a variant of the most common complaint about signalapp that I hear in the forums, when things like this come up: "...for those... using their real phone number... [name&num] should not appear above texts [in the chat-history] where a recipient you thought you trusted can screenshot..." Or variations on that same theme: signalapp should 100% guarantee that remote devices will delete whatever is sent, signalapp should 100% guarantee that remote devices cannot copy and paste from signalapp into an email client, signalapp should disable the ability to take a screenshot and if Larry tries it should shoot lightning-bolts into his fingertips and then wipe his device for daring to think about leaking Alice's secrets, and so on. This kind of thing is utterly impossible for any app to accomplish. I'm not talking hyperbole here, I mean impossible in the literal sense of Not Possible to implement. If you trust the contact not to leak your info to the badguys, and your trust was misplaced and the contact decides to leak your info to the badguys, signalapp cannot save you, and **no** software can even hypothetically save you. Even if you granted that both ends of the conversation were using DRM-lockdown OSes with remote attestation and mandatory biometric unlocks which provably guarantee that Alice-the-human is chatting with Larry-the-human and both of them are running 100% the right codebase-hashes from the baseband firmware to the OS to the device drivers to the chat-app...

...if Larry wants to leak info, he can. All he needs is the desire to backstab Alice, and any digicam whatsoever to capture the 'secure' device he is holding in his right hand, with the Fischer Price KiddieKam in his left hand. Alice cannot stop this nor detect this, and neither can any mere software, even software with full control of the ENTIRE device-stack in Larry's right hand. Because quite literally, the right hand does not realize what the left hand is doing, as the old saying goes.

why any mass surveillance opponent finds mandatory phone registration acceptable in the slightest. I suspect if someone has a phone and they can't see beyond themselves, then they've already accepted and conceded to mass surveillance to that extent. So then they're only looking at the phone number disclosure to Signal and consider that insignificant, which is ultimately detrimental to everyone

Your "question" was obviously intended to be rhetorical, but I'll go ahead and lay it out for you just in case you still haven't really figured it out. If you are just saying such things for the sake of 'winning' then please just ignore this, you have heard it before :-)

signalapp is better than wireapp, and much better than jami

I'll put it more bluntly this time, to see if I can get through to you, @libBletchley You don't like telco-firms. You don't own a smartphone. You don't even own a PHONE anymore, or control a telco-num of any kind, because that financially supports telco-firms, and you are boycotting them entirely until they are destroyed by the rise of Jami-fka-RingCx-fka-SFLphone. You think anybody that owns a phone is either a stupid person with a small brain, or an evil person with ulterior motives. You feel superior, because you (nowadays) stick to your principles, no longer trying to acquire quasi-anonymized telco-nums, and you look down your nose at anybody who is unwilling to live their lives on your terms. You don't care than 99% of adults own a phone. They are wrong and you are morally superior. You run Linux-for-the-desktop, and you approach that in exactly the same fashion: anybody who runs Windows or OSX or iOS or Android or **anything** but 100% libre OSes, must have a small brain. You don't let yourself think about binary blobs much, or about libreboot ;-) Or maybe you bought a Librem15 which somewhat minimizes those kinds of things. But since you run Debian rather than Trisquel, according to your past statements, I suspect you are just willing to compromise a slight amount. And you have a github-uid, so obviously you are financially supporting microsoft by refusing to boycott their properties, tut tut, what will that do to your uncompromising stances. You think anybody that uses a mainstream operating system (on phones or on laptops or on desktops) is either a stupid person with a small brain, or an evil person with ulterior motives. You feel superior, because you (mostly) stick to your principles, no longer running anything but Debian, and you look down your nose at anybody who is unwilling to live their lives on your terms. You don't care than 99% of adults use a mainstream OS. They are wrong and you are morally superior. As I keep repeating, if you want to thwart mass surveillance, you have to educate the masses, you have to get the masses to use software that will help thwart mass surveillance, and that means that there will be pragmatic compromises along the way. If you think that Linux-for-the-desktop in the hands of a super-nerd is more secure&private than windows10 in the hands of an everyday enduser, you are 100% correct. If you think that *this alone* means the everyday enduser has a small brain, you are completely wrong. And if you think that assuming 99% of humanity is 'normies' and telling them to their face they are stupid while you sneer at them, will improve the userbase of Trisquel and Jami, you are in a fantasy-land. The masses are already in possession of a telco-num. *All of them*, including you-in-the-past before you decided to go cold turkey and boycott the industry to try and improve privacy and fight mass surveillance. The masses already give out their phone-num to people they communicate with. *This is how communication has happened since the early 1900s when telephony was invented.* They use their addressbook-app on their smartphone as a way to manage their social-graph. *That has been going on for decades and 99.9% of adults do it.* When you give these people signalapp, they can start to have cryptocalls and crypto-texting and NotesToSelf stored in SQLCipher with minimal metadata-leakage, because the server is explicitly designed **not to need** metadata. But if you want them to actually use it -- aka if you want hundreds of thousands of reviews and tens of millions of downloads like signalapp has achieved in the past nine years -- you have to make it work on platforms they already own (hint: not just work on Linux-for-the-desktop), and you have to make it easy enough for them to remember their identifier (hint: not a RingCx hash-uid nor Ricochet hash-uid), and find their existing contacts (hint: by using EXISTING emails and telco-nums just like signalapp and wireapp do *despite* the design-compromise that inherently represents). Ideally, it is best to make it *possible* for extra-privacy-conscious super-nerds to anonymize their usage of the app. But anonymity is very tough if the adversary is powerful enough. At best you can get only pseudonymity these days; shadow-profiling and network-layer timing analysis and the ever-expanding tracking-industry are too powerful to fully evade whilst communicating with almost anybody And indeed, if you look up above, you can see that is what is offered by signalapp: the possibility to achieve a modicum of anonymity, and strong metadata-resistance server-side where the opsec-conscious enduser has little power compared to a sophisticated Eve bent on mass surveillance (Eve *always* tries to pwn the server-cluster because it is the cheapest most effective way to implement mass surveillance).

By default, signalapp assumes that everyday enduser will register with their existing cell-num, and will integrate with their existing addressbook-app. In exchange for those design-compromises, that reduce the illusion-of-anonymity and the achievement-of-pseudonymity, the endusers in question get a huge upgrade in privacy from unencrypted telco calls and fbookMsgr chats: well-vetted on-by-default crypto, almost no metadata-leakage, and a lot of options to improve their privacy-stance over time, incrementally. (Safety-num verification and reg-lock-pin and custom-phone-label and signal-profile and non-stock addressbook-app and denying addressbook-integration as discussed up above plus a whole bunch of other things not mentioned here explicitly.)

Wireapp makes some of the same design-compromises: it assumes people will want to register with their existing email or their existing cellnum. And they do. But it also makes very different design-compromises: it assumes people don't care about metadata, and stores it all server-side, making a huge juicy target for any cracker-group or government agency with subpoena powers in the USA or over Amazon server nodes in the EU. With wireapp crypto is a checklist-feature: they see it as something worth having, and intended to have it, but then, they didn't actually have it at launch, despite the mistaken claims of the marketing-materials. So they added it later, by making an inspired-by-sig-protocol knockoff.

wireapp is definitely a reasonable option though, especially if you need a key feature that it offers but signalapp does not

Is wireapp good crypto? Well, that is hard to say, but it is not *awful* crypto, despite Moxie's complaining about the wireapp inspired-by codebase. Proteus is not as widely-field-proven and not as well-vetted as signalapp's crypto, which has been on-by-default since 2010 in one form or another, from the very beginning (back in those days signalapp also did not have any metadata-resistance... just like wireapp still has none-to-speak-of). Wireapp also used to be partly proprietary, though nowadays they are not. Signalapp too used to be partly proprietary, and although it was libre-licensed earlier than wireapp, it wasn't by much. So I don't see a lot of huge differentiation between the two software apps, when it comes to 2019 recommendations: signalapp is better-vetted crypto and about 10x more widely-used (millions of people is "medium-small" in the messenger-industry however), as long as you don't mind the workarounds needed to deal with telco-num identifiers it has best-in-class metadata-resistance. Wireapp is okay crypto, small-but-not-tiny-userbase, terrible on metadata-resistance but that is partly mitigated by the opt-in-email thing. Caveat: however, only as long as you and all your contacts are careful to use Tor+VPNs and avoid the tracking-cookies and hand-compile your own APK without firebaseAnalytics... in which case email-optional is a significant win. If you are communicating with everyday folks however, the email-thing is going to give you a false sense of security: any Eve sophisticated enough to get five minutes with the server-side metadata will be able to shadow-profile you without any problem whatsoever, and the servers are such juicy targets this is almost impossible to imagine wireHQ folks preventing it. Worse, because wireapp offers a web-client version, Eve just needs to find the weakest link in the groupchat and then get some malware onto *any* browser they ever use to capture their wireapp credentials and pwn the entire groupchat. Whether this matters depends on the threat-model, aka who the likely adversary is, how sophisticated they are. Both of these options are 100% libre-licensed, 100% non-federated at the moment (signalapp was federated 2014-2016 and wireapp wants to be federated "someday"), 100% running on AWS, and 100% making compromises in their ancillary support-website-areas because of small teamsizes. Both have not-yet-crystal-clear business-models, though wireapps is pretty obviously going to be some kind of freemium-thing and signalapp's is pretty obviously going to be some kind of donation-and-endowment thing via signal foundation. Either one of them could someday grow to become the messenger-app which beats out whatsapp-and-skype-and-friends, but neither one of them has done so yet. It is a prediction-problem, as well as a what-to-recommend-today problem: will most endusers be better off with bob@outlook.com as their wireapp-identifier and the downside of server-side metadata? Or will most endusers be better off with +2-222-222-2222 as their signalapp-identifier and the downside of financially supporting the telco industry as a means of spam-prevention within signal-network? To me the answer it "it depends on whether Bob needs 10-way stream-encrypted confcalls with weak metadata resistance... or N-way purely-client-side-managed pairwise-encrypted groupchats of 50 people... if the former then wireapp, if the latter then signalapp." But in the long term, signalapp is clearly fighting to thwart mass surveillance, with one cofounder of signal-foundation endorsed repeatedly and in no uncertain terms by Edward Snowden and Bruce Schneier, and the other cofounder of signal-foundation being the facebook billionaire who now advised everybody to Delete Facebook. Will they ever fix the cloudflare screwup, at some point along the way? Will client-side federation ever occur, at some point? Sure, I hope so. I've recommended as much, and I don't have much pull, but it might happen, time will tell. Wireapp might someday federate, lessen their metadata-resistance weakness (by copying what signalapp does like they did the last time with Proteus most probably), and coming up with a novel way to allow people to register with any valid email address yet somehow prevent spam from consuming the entire wireapp-network AND not stoop to decrypting everything server-side. I'm not very hopeful there because to me wireapp is a typical startup: they are using the freemium endusers as unpaid beta-testers, and they are proprietarizing the key features into their enterprise-grade payware proprietary codebase. If they get popular, just like Telegram they will (my prediction) move to further proprietarize All The Things and thereby monetize the userbase.

Maybe I'm wrong and wireapp's crypto will turn out to be rock-solid and their lack of metadata will not matter thanks to billions of federated nodes with awesome remixer-negotiation protocols and unlike every freemium startup I've ever seen they will libre-license everything as soon as they achieve success. If so, great :-) But my jaded prediction is this will just not happen. Wireapp is wanting to achieve lock-in, exactly like skype wanted to achieve (and largely succeeded in the corporate arena in western countries at least -- still around 300m monthly endusers and most are corporate).

Maybe I'm wrong about signal foundation, and they will sell out to corporate partners a few years from now thanks to subtle loopholes in the as-yet-unrevealed bylaws, rather than concentrate on thwarting mass surveillance by getting a billion endusers for signalapp and then implementing remixer-tech and anonymizing-identifiers once the spam-prevention worry is properly solved. Could be they fail to get to a billion endusers, could be the follow the wrong strategy, could be they are aliens from planet zorg ;-)

ghost commented 5 years ago

the problem was an untrustworthy insider.

When you have a huge userbase and a consequently large staff to support the system the risk of untrustworthy insiders is high. The risk per engineer is also heightened by the fact that high numbers of users concentrated in a centralized walled-garden (due to network protectionism), making it a central location for compromise of any Signal user in the whole network.

Google struggles with insiders snooping on emails of those they know and occasionally has to sack people for it. You're still trying to give OWS sympathy credit for being popular. The OWS insider threat is not controlled for and that's another problem w.r.t. endorsement.

This is not a flaw in how signalapp works,

Actually it is:

I've already exposed the problem here: https://github.com/privacytoolsIO/privacytools.io/issues/779#issuecomment-481209438

OWS gets the metadata of identified users, thus requiring a hell of a lot more trust than necessary.

"when Alice sends a secret message to Bob she trusts Bob with that secret". There is no way to build a piece of encrypted chat-software without that assumption,

This is a red herring. The problem here is Alice is trusting Mallory not to expose her identity or the fact that she is talking to Bob. Signal competitors have managed to design systems that are not vulnerable to this.

....You think anybody that owns a phone is either a stupid person with a small brain, or an evil person with ulterior motives....

The emotional line of reasoning is a failure of a personal attack. There is copious mass surveillance attached to phone registration and you don't address any of it. The mass surveillance inherent in phone registration is unacceptable particularly in light of existing systems that don't have this problem. It's a bad idea and contrary to the mission to needlessly accept mass surveillance.

You don't care than 99% of adults own a phone.

Actually it's 95%. But this is irrelevant. Whether I'm in the 5% is also irrelevant. The 5% are needlessly hit with privacy abuse to a very perverse extent. And it's still an abuse to force the other 95% to use and retain their phones in ways that feeds mass surveillance while also preventing those in the 95% from joining the 5%.

As I keep repeating, if you want to thwart mass surveillance, you have to educate the masses, you have to get the masses to use software that will help thwart mass surveillance,

You need to take your own advice and stop pushing software that subjects its users to mass surveillance. This is not the education they need.

five-c-d commented 5 years ago

You don't understand what occurred, methinks.

When you have a huge userbase and a consequently large staff to support the system the risk of untrustworthy insiders is high

The journalists did not figure out who the people were in the signalapp conversation, by talking to somebody at OWS or at Signal Foundation.

The journalists figured out who the people in the signalapp conversation were, by getting it straight from one of the people participating in the conversation, or from the screen of their device perhaps (the reddit thread does not say which). The journalists say:

That is what I mean by "untrustworthy insider". A person inside the conversation not a person inside OWS :-)

Google struggles with insiders snooping on emails

Because gmail is not end2end encrypted! Signalapp is, and all metadata is end2end encrypted, except three things: last day/date that the signal-num (any associated device) connected to a signal-server (any server-node), the time/date that a signal-num was initially installed&registered, and the signal-num itself (which can be any telco-num ... including one that is quasi-anonymized by virtue of not being linked to one's identity). You know these, and you even tried to do it, just, the simcard you bought did not work with the carrier-tower in your neighborhood, or something.

They've designed the system to collect info that doesn't need to be collected.

As explained above, you don't understand what you are talking about. You assert there is no need, the need is explained, and you go back to asserting there is no need.

Unnecessary collection is always vulnerable to exfiltration from outside attacks as well as the insider threat.

You don't understand what you are talking about. There was no exfiltration. One of the people that was a legitimate recipient of the groupchat records (according to the journalists at least -- though it could also have been 'obtained' in less savory fashion such as device confiscation or similar) voluntarily leaked the chat-messages and the chat-metadata.

Signal-server does not even contain any metadata that would ALLOW signal-server admins to know who was participating in such a conversation, unless they reprogrammed their server-nodes to track IP addresses and such, rather than storing the info only in RAM and deleting it ASAP just as soon as the associated async messaging-transaction was completed. Even if this was done, it would only permit phone-num to IP linkage (and only then if the people involved were not using VPN and not using Tor and not using phone-nums not linked to their identity). Signal-server nodes never ever touch message-body info. Signal-server nodes cannot serve up malicious code either, because unlike wireapp there is no webapp version, the distribution chain does not go through signal-server-nodes, it goes via appstores for 99% of the endusers (and via sideload plus cert-check for the rare few that using the apk download). The code-signing is done on separate air-gapped systems, and the main client is a reproducible-build setup so even a pwn'age on those boxes would likely be caught.

Now, if you do want to talk about wireapp, or matrixOrg, then absolutely a person with access to those server-clusters can provide metadata about who talked to whom: email addresses and the associated IP addresses, as well as potentially any EXIF metadata and docfile-metadata that was uploaded in the case of MatrixOrg (via the on-by-default in-the-clear chatrooms I mean). All that stuff is stored, and on purpose, by the architectures of those apps. Whether that is a risk, depends on whether there is a cracker able to get into the server-nodes, and exfiltrate metadata. MatrixOrg central servers were cracked into a the beginning of April, with the hashed login-passwords of 5M endusers exfiltrated (where no server-side rate-limits can apply).

Signalapp is not as much at risk of rogue sysadmins, nor of server-side compromise, because it does not use login-passwords at all (smartphone-possession is used during operation -- or during linking to a slave-device -- and ability to receive inbound SMS plus the registration-lock-PIN are used to prove telco-num control during registration at install-time). It also doesn't store metadata at all, except for the three things listed above, so signal-server nodes are NOT juicy targets. Eve only will bother to crack into one if she wants to perform timing-analysis, and she can do that at the AWS router-level if she is powerful enough (NSA/etc) without needing to risk the PR backlash of cracking into a server-node and staying their undetected long enough to do the timing-analysis.

The problem here is Alice is trusting Mallory not to expose her identity or the fact that she is talking to Bob. Signal competitors have managed to design systems that are not vulnerable to this.

You completely do not understand what you are talking about. Please check your premises. Or give me a link to a piece of software, that allows a group of people to have a groupchat, and prevents THE PEOPLE IN THE GROUPCHAT from leaking the messages and participants to the press, while simultaneously all knowing the sender of each message in the groupchat, and all knowing the contents of the messages sent to the groupchat. This is not "tough but all the signalapp competitors did it somehow". This is literally impossible.

ghost commented 5 years ago

That is what I mean by "untrustworthy insider".

My original understanding from the article was that it was someone in the conversation, but your reply said "untrustworthy insider" which implies in the org, which then caused me to question my original understanding. You should not use "untrustworthy insider" to describe someone in the conversation when in the discipline of infosec we reserve the insider threat to mean someone within an organization with privileged access.

They've designed the system to collect info that doesn't need to be collected.

As explained above, you don't understand what you are talking about. You assert there is no need, the need is explained, and you go back to asserting the need.

This is a red herring. OWS collects info that doesn't need to be collected (phone numbers). That is the case regardless of what leak happens in any particular incident. But in the incident at hand, it is in fact the reckless role of phone numbers in Signal's design that enabled the compromise.

Signal-server does not even contain any metadata that would ALLOW signal-server admins to know who was participating in such a conversation,

The weasel-wording here is "contain". As far as we know, they don't store the data, but that's a matter of trust. OWS sees the data and that disclosure can lead to other things.

five-c-d commented 5 years ago

No, it is not a matter of trust, they were subpoena'd by the feds in a Virginia court case.

No, it needs to be collected, because when you base signal-identifiers on phone-nums, you don't need usernames and passwords, and you don't need to store them server-side. MatrixOrg centers servers were cracked into, the adversary exfiltrated the password file (hashed but now ready for offline password-cracking clusters with no rate-limits possible), and there was metadata of every single person -- as well as copies of their unencrypted chat-histories which is the default on MatrixOrg/RiotIM client-apps.

They also left their code-signing keys, which could result in homeserver compromise despite federation architecture, on the central servers. (Which to be fair is a mistake they won't repeat. But it points to an architectural mindset which is just The Wrong Mindset, one shared by wireapp devs: maybe with federation we can mitigate server-side metadata. The problem is that this does not really work. You have to go full decentralization p2p like Jami ... or even better onion-style decentralization with anonymity-features like Ricochet ... or you have to go hardcore at distrusting your own server-nodes, by design.)

Signalapp is architected explicitly to distrust the signal-server nodes.

You should not use "untrustworthy insider"

Point taken, you are correct that 'insider' sometimes means "person inside the provider's infrastructure" ... but the far more common meaning is "person inside the same firm/group" as far as I'm aware. And I kinda figured you had read the article that the reddit-thread links unto :-) This was very clearly a groupchat participant, or somebody claiming to be one who got the chat-history in some other fashion perhaps. There was not any involvement by signal-server nodes, nor by signal-foundation personnel, at any point. No software could possibly prevent that kind of a leak. No hardware either, for that matter.

Your original point 1.viii still is a sound one, which is that phone-nums can be linked to identities. But your failure is that you refuse to take that sound point, and apply it to wireapp (just like the point about AWS and the point about indirectly financially supporting telcos and so on and so on).

Well, your other failure is that you are sooooo trying to get signalapp that you cannot even read what is being clearly said, by Snowden or by me or by The Guardian, but just assume "obviously this is more proof of how evil OWS really must be". And then insulting me for pointing out the facts ;-) I like you, you really care about privacy, but you are like a broken record and you don't apply findings carefully and with rigor. You do a huge amount of work but it is all done with the any-means-are-justfied-by-my-ethically-superior-ends type of vibe that is sub-optimal to keeping discussion on an even keel.

ghost commented 5 years ago

No, it is not a matter of trust, they were subpoena'd by the feds in a Virginia court case.

OWS was able to comply with the subpoena precisely because they needlessly identify their users. The same subpoena going to a competitor like Jami would get the response "we don't know which of our users is the person you need the data on because we don't collect phone numbers or identifying information." Jami would first need an IP address on the subpoena, and this would only trigger action if the user doesn't use Tor, and also the user connects to the same federated server that's being subpoenaed.

No, it needs to be collected, because when you base signal-identifiers on phone-nums,

Phone numbers do not need to be collected and Jami proves that. OWS designed their system to require it, but it's a broken design. Of course, as I've shown in great detail mass surveillance is rampant in every aspect of the OWS Signal system, so their design is not even trying to avoid mass surveillance. They only need to market the idea that it's secure.

you don't apply findings carefully and with rigor.

This looks like that "accuse the other of that which you are guilty" fallacy. The detailed findings of Signal subjecting users to mass surveillance are well documented and remain uncountered. There are only excuses in this thread for why they subject their users to mass surveillance and some weak attempts at claiming all their competitors are equally flawed.

ghost commented 5 years ago

Due to popular demand, I've produced a diagram for Jami showing all the links to mass surveillance as I've done for OWS Signal.

(PDF) jami

That's it. Bit boring indeed. Here's a slightly more interesting Venn diagram: jami_venn

(edit2) So I've made the Jami diagram more interesting: jami

five-c-d commented 5 years ago

because we don't collect phone numbers

So your stated position, is that Jami, which is funded and developed by a Canadian firm in a Five Eyes jurisdiction, is immune to subpoena because they don't collect phone-nums?

okay then. and what happened to wireapp, again?

You think that the ethereum blockchain usernames are impervious to law enforcement? You think that the IP address of an everyday enduser, when the Jami APK is auto-updated, will somehow be invisible and undetectable? You think that the playStore version of the Jami APK, which has firebaseAnalytics therein (unlike the fDroid version right which makes it fiiiineeee), will somehow evade any sort of identifiable associations? You know that Jami is not a silver bullet. There is something about DHT nodes as well, which I don't fully understand... I suspect there are few enough people traversing them, that network-layer monitoring might uniquely identify conversation-participants, in pretty much exactly the way the RIAA/MPAA was able to serve DMCA takedown notices on bittorrent endusers... but that is speculation at this point. More importantly, you know very well wireapp collects phone-nums, and when they don't collects emails -- nowadays most everday endusers have gmail address which are their legal name. Wireapp prefers to collect both of those, just like Facebook: give us your phone-num so we can keep your facebook-page under your legal name from being hijacked, your privacy is very important to us. Plus uses tracking-cookies at the point of download, and maybe the firebaseAnalytics in the APK as well (unclear whether the tracker is enable or just present-but-disabled). Yes, I understand your position. You think decentralized messengers are the true solution. And from the lwn link I gave way back up there, you also understand Moxie's position: decentralized messengers are easy pickings for predatory proprietary competitors. My position is more nuanced: I think both things are correct. But I'm primarily interested in thwarting mass surveillance, and I think the chances of Jami overcoming their incredible deficit in usability and userbase-size and mindshare/vetting is basically zero. I don't mind people using it, but only signalapp and to a lesser extent wireapp (due to less vetting) are feasible options to catch up with the network-effect powering whatsInstaBook. But my position on wireapp is not nuanced: they store all the metadata-server side. They are not federated now, and as a freemium project which monetizes the userbase by withholding key features, I don't think they ever will be. Where is your diagram for wireapp, listing their political transgressions? It is less boring than your Jami diagram, as you well know :-) If you make a legit wireapp diagram, mirroring the exact structure of your signalapp diagram for ease of comparison, and not pulling any punches, then we will be a lot further along methinks. > Phone numbers do not need to be collected and Jami proves that I notice you skipped right past wireapp, and onto something else... because the ends justify the means, right? Anything to achieve your endgoal. Whoever screams loudest into the megaphone about the political transgressions will always be the 'winner', eh? I submit you have not made the case. Jami does not require phone-nums, but Jami does not prove that is a viable approach. Quite the opposite. It has such a vanishingly small userbase, despite being deployed six years before signalapp and five years before whatsapp were even *shipped* that I disagree it is even something that can be said to work at all. It has such as complicated set of identifiers that I cannot even figure out *whether* it is spam-resistant at scale. Has anybody vetted the crypto? Oh, but it is the Only Ethical Choice because telco firms are the devil, so that makes up for all the shortcomings? No deal, sorry. The design of OWS is to start by assuming that everyday endusers will NEVER accept "ricochet:328abae3820283" as their identifier. This is a sound design-decision, because in fact endusers won't accept that :-) You are able to deal with it, I am able to deal with it, but that is because we are wizard-level-three type people willing to using linux-on-the-desktop and eschew even owning a phone-number at all and deal with complex software all day long for a teensy tiny increase in theoretical privacy. As the famous xkcd shows: actual-actual reality, probably nobody cares about those ultra-secure private messages anyways ;-) I think privacyToolsIO will have the best shot to accomplish the mission to fight mass surveillance, if it concentrates on trying to get people using stock chrome on stock windows and stock whatsInstaBook on stock samsung to start switching over to firefox+3addons on qubes and signalapp on lessGooglyAOSP. This is a huge boost in privacy that will take them from being "the median enduser" to being in the top 10% of all internet citizens in terms of privacy protections. You want everyday endusers -- so you say at least although I suspect you know perfectly well they won't accept it since your own mom uses wireapp instead of jami -- to be immediately pushed into the top 0.01% where they skip right past firefox-on-qubes and start running hand-compiled UngoogledChromium on Linux-for-the-desktop whilst using Jami with ethereum-blockchain-usernames for all their messenger needs and boycott the telcos completely. As noted up above: my mom ain't gonna do that :-) Not because she is not smart enough, but because those tools you prefer just don't satisfy what she needs. Your mom is not the same as my mom, but if your mom is hand-compiling her own LTS kernel to improve her privacy and refuses to own a telco-num or communicate with anybody who does, well, more power to her. But that is so rare it is almost unheard of. If she did all that you suggest, my mom and you could chat on Jami, sure... but she would be cut off from all her other contacts, none of whom have any of that stuff. Since she has a desktop PC rather than a laptop, also she would be cut off from the internet any time she was not in her home office! There are a lot of people that are smart enough to want improved privacy, but not if that means constant tool-churn, and DEFINITELY not if that means they can only have a couple thousand fDroid apps and not a couple million playStore apps ... but then, since they cannot own a **phone** to meet your political demands, they don't even get the fDroid apps do they? Your position on what is 'ethical' aka politically demanded, is just so unpragmatic I don't even know how to break it to you gently that you are tilting at windmills. Nothing wrong with wanting to change the world for the better. Nothing wrong with boycotting all major corporations in the world, if it makes you feel better. But calling anybody who does not follow your lead, small-brained, is just your hubris talking. And it will not help you change the world the way you are wanting to change things either, it will just hurt your cause by making you look bad (since it is bad behavior). If you imagine that privacyToolsIO has the vast mindshare to somehow propel Jami to hundreds of millions of endusers, you are once again just flat out impossible-to-put-it-nicely wrong. It's a fine website, it's in the top 100k alexa-ranking in a lot of wealthy countries, but it cannot alter the tide. This is not the year of Linux-on-the-desktop, sorry. And it's not the year that Jami will catch up to wireapp, let alone signalapp. And because decentralized messengers with long hashnums as identifiers tend to be unpopular, the trend of that entire category of messengers -- which never die out completely but never succeed either -- remaining unpopular is likely to continue. > The detailed findings of Signal subjecting users to mass surveillance Right, because it uses phone-nums, and you hate telcos, and that means only Jami will save us and it must be immediately promoted to top3 and signalapp immediately dropped to the newly-created doghouse. Because you know, if somebody is linked to a bad player, in some tangential fashion -- such as having an apk on the playstore for example -- well that means they are no better than google itself, and privacyToolsIO would not want to *align itself with evil google hypercorp* now would it? You are just screaming into the megaphone. Every point you complain about applies to wireapp, with the possible exception of cloudflare (wireapp has a different tracking-analytics thing... with a tracking-cookie to better spy on their webapp-client endusers... so it's hard to call that "better"). But for you wireapp can do no wrong, and if signalapp does the same exact things it is because they are evil. > are well documented and remain uncountered. I think you confuse "libBletchey refuses to accept their mistakes" with the very different "libBletchey is clearly the 'winner' of the debate". You want a messenger that does not require a phone-handset, and that accepts email-address registration, or better yet, completely anonymous registration, and is 100% libre-licensed. Good. You got one. Go enjoy it. Oh, you want to boost the userbase of that messenger, so that instead of 607 playStore reviews it can finally crack 1k playStore reviews? Good, go promote it. (And to be clear, I mean, go promote it from notWorthMentioning into the WorthMentioning part of the IM category since I agree that makes sense. But jumping it into the top3 immediately makes zero sense, it is not suitable for everyday endusers.) If you can get it to 30k you will have caught wireapp, and 300k will catch up with signalapp-of-2018. Unless signalapp is growing faster because it has a better reputation and better endorsements and better usability and better crypto and works with OSes and addressbooks that everyday endusers already have by default, Jami might even surpass it someday. But you don't want Jami to succeed. You want signalapp to fail, because of all the political transgressions you imagine the people at signal foundation and ows must be guilty of. And somehow, fail to check whether any other messengers you promote as better-without-any-qualification-whatsoever, are guilty of? Even when it is pointed out to you, nothing phases you: oh sure jami has trackers but only in the playstore apk and who uses that? Well, almost nobody, you are correct on that point: 50k downloads, but only a 3.9 rating which suggests a good portion uninstalled shortly thereafter. I'm not interested in seeing whether signalapp can beat jami or wickr or threema or silentPhone, because it has already done so: signalapp has gone from being a niche project to being a well-known name... but only in terms of reputation, not yet in terms of userbase. With luck, it will become either a Minor Messenger with 5% marketshare or a Major Messenger with a billion or more endusers, at which point it will truly become a threat to whatInstaBook and to gmail... until then however, Facebook and Google will continue to dominate (and to a lesser extent Tencent with QQ/WeChat and in certain niches Microsoft with Skype and GroupMe). I'm not interested in seeing whether wireapp versus signalapp versus riotIM should result in two of them being thrown in the doghouse, because I see them as complementary rather than as competitive in many ways: they compete with skype4biz/Polycom + whatsapp/SMS + slack/IRC, which are fundamentally distinct subsegments within the messenger industry, albeit with overlap. PrivacytoolsIO needs to list them all, ideally with a comparison-chart of pros&cons. You already know that wireapp has 99% the same exact like of 'cons' such as "allows the enduser to register with a telco-num which supports the telephony industry and some of them are large USA corporations which have funded lobbyists that advocate for laws which do bad things once bad politicians pass them" and so on.

Mikaela commented 5 years ago

I think the team is currently also in disagreement on what to do with Signal and this issue and may hope that someone else takes the initiative.

I see three two routes forward:

Herohtar commented 5 years ago

OWS was able to comply with the subpoena precisely because they needlessly identify their users.

But their compliance didn't give them any information that was of use. The court already knew that some of the people had been using Signal because they saw the app on their phone, so they subpoenaed with "Give us all the information you have for these two phone numbers" to which the reply was "this phone number registered with Signal on [date1] and last connected to the server on [date2]". The exact same thing would have happened with a non-phone-number identifier, except the subpoena would have looked like "give us all the information you have on [random username]".

ghost commented 5 years ago

But their compliance didn't give them any information that was of use.

It's already too much information because it's a needless disclosure. Registration time and last login time could be sensitive. When you say the information wasn't useful to the prosecutor, you're guessing. The article didn't actually state whether it aided prosecutors in any way to have that information. That's also only relevant to that particular case and not arbitrarily applicable to other situations (PTIO is giving general advice to large numbers of users). At a very minimum, the information could even be used trivially to catch someone in a lie. "No, I don't use Signal..." From there, the lie is used against them in various ways.

The court already knew that some of the people had been using Signal because they saw the app on their phone,

The court need not know if anyone uses Signal. A court could go to OWS Signal out of the pure blue and say "here is a list of phone numbers; we have no idea if any of them use Signal; you tell us, and give us the info if there is any". And if there's a positive, the court could further demand "btw, you currently only log last connect time. Here is an order to log more data for those accounts of interest: going forward, start logging who is talking to these accounts of interest, when, and the duration of every connection, until we say stop."

We also know that Signalapp uses non-free reCAPTCHA j/s. What other j/s is that app grabbing and running? Could a court order delivery of malicious j/s to identified targets and then actually compromise the payload data? This is a risk inherent in having interpreted code downloaded and executed on-the-fly by identified users. (Not to mention Google Playstore could be used to push a malicious copy of the app since Google forces users to login before downloading updates, and Google also links phone numbers to accounts).

The exact same thing would have happened with a non-phone-number identifier, except the subpoena would have looked like "give us all the information you have on [random username]".

That would require the court to know the username, which by extension requires the court to know the user is using the service under subpoena. Unlike phone numbers, that information is hard to get surreptitiously. The user would also know if a court orders them to unlock their device so they can see that info. The expectation of privacy is much higher in this situation. IIRC, the supreme court ruled in California that a cop cannot arbitrarily look through someones phone (4A issue).

We are getting off in the woods a bit to be talking about targeted surveillance in much detail, but what's relevant to PTIO is that it's a case of mass surveillance that leads to targeted surveillance. The mass collection and forced use of phone numbers by OWS Signal and Google's Playstore is rich with pitfalls. It's a playground of privacy abuse.

0xRustlang commented 5 years ago

Hello

@libBletchlay, although signal has some problems, it is one of most secure ways for someone that is in the live/death situation. Replacing it with some other softwares that leak some meta data and/or not audited is really dangerous.

ghost commented 5 years ago

it is one of most secure ways for someone that is in the live/death situation.

  1. PTIO is not for life/death situations. It's for avoiding mass surveillance.
  2. you're wrong. Most particularly if your life depends on the anonymity of you and your correspondents you're stuffed. Life critical scenarios typically entail targeted surveillance in which case anonymity is critical.

Replacing it with some other softwares that leak some meta data and/or not audited is really dangerous.

You missed the Signal/Wire metadata discussion. Metadata is leaked with Signal. Who is talking to who is leaked to OWS by way of a centralized network on which all users are forceably identified, who can then be cross-referenced to google accounts by phone number, whose software can then be replaced with a special version. If your life is on the line you'd be foolish to trust OWS not to log what they see particularly in light of the false statements they've been caught making, and then to trust Google not to cooperate and push a special Playstore version custom tailored for you.

Regarding code audits, I guess you've not followed the 80+ posts but that's also a defeated claim. When the design is broken (as demonstrated) it doesn't matter how solid the code is (which BTW has not been demonstrated anyway beyond hand-waving about popularity - not that it matters).

Herohtar commented 5 years ago

Who is talking to who is leaked to OWS

That is also wrong; sealed sender prevents exactly this scenario.

five-c-d commented 5 years ago

the false statements they've been caught making

Oh? Link please. I notice you elide any evidence of your accusation.

whose software can then be replaced with a special version

You don't seem to know what you are talking about, can you please explain how you imagine this attack vector would work? I'm running signal4android (either playstore flavour or sideload flavour) and.... what happens, how does evil OWS compromise me? Compare explicitly to what happens on wireapp4android (web flavour and apk flavor). Compare explicitly to what happens on jami4android (playstore flavour and fdroid flavor).

that's a defeated claim

You definitely don't understand what you are talking about. You are recommending tools that are less-well-vetted and vastly less field-tested. Quality of the crypto is the baseline for achieving privacy. Quality of the codebase overall (the implementation of the crypto and the implementation of overall app-security and the distribution chain and such) also matter.

Whether a tool is well-designed, has very little to do with whether you like the designer, nor with whether you think the designer committed political transgressions -- such as hosting their servers on AWS like wireapp, or such as including FirebaseAnalytics in some-but-not-all of their build-variants like Jami does.

if your life depends on the anonymity

THIS part, is 100% correct though. It is very hard to achieve anonymity against network-level adversaries. That is true of other apps besides signalapp as well, but it is definitely true of signalapp. It is hard, but not impossible, to get a reasonably-anonymized telco-num, and it is tough to carefully use things like Orbot to achieve IP-anonymization, albeit again not impossible. But doing those things makes you Stand Out and that can be very dangerous.

Signalapp is really not very good if your life is on the line, because, any kind of consumer electronics is not really very good. There is no silver bullet. There are too many ways that security on the handset can break down or opsec of the person can be bypassed.

sealed sender prevents

@Herohtar -- well, it does not PREVENT it but it strongly mitigates it. The adversary with control of a server-node would have to do timing-analysis at the network-layer (using IP addresses), and then iteratively over time (many days or weeks methinks but it depends on who is the target and how large their groupchat-sizes are), link those IP addresses to signal-nums. It could definitely be done though, given a sophisticated enough adversary, with control of enough signal-server nodes, for a long enough timeframe.

If you assume that Signal Foundation is evil incarnate, then absolutely, they have such powers of doing timing-analysis attacks. But yeah, if they were doing that, they just shot themselves in the foot by implementing sealed sender! :-) So in addition to the court-case evidence that metadata is not being tracked, at all, beyond day/date last connected, date/time registered, and signal-num which is any valid phone-num, we also have new code that makes server-side tracking harder, and explicitly puts less and less trust in the server-nodes and the sysadmins thereof.

@libBletchley is under the mistaken impression that signal-server works like wire-for-web, though, which is completely wrong. With wireapp, the server-operator has 100% of the metadata, and can serve malicious code to the first participant that logs in via wire-for-web, as well as to others if they can selectively upgrade the APK ... don't think wire has any reproducible builds whatsoever, on any platform, they are not on F-Droid either so they cannot benefit from such things.

The picture with Jami is far better, they piggyback on the F-Droid reproducible builds for at least some endusers, but of course, one would have to trust their crypto... and the Jami crypto is not very widely-vetted, and not endorsed by anybody outside the consulting firm that writes most of the Jami code, that I am aware.

ghost commented 5 years ago

That is also wrong; sealed sender prevents exactly this scenario.

That's security by obscurity. OWS designed their system such that it must authenticate who connects to their network. When the "envelope sender" is replaced with other data (a certificate in this case), OWS can log that if they want, so you're still trusting them in the end. And that's without even going into mixmaster relay caliber of attacks.

five-c-d commented 5 years ago

OWS can log that if they want

How would you accomplish this? How would they do so? I don't see how they could. Please lay it out in clear language what you are asserting the attack-vector is. Here is the technology being utilized == https://signal.org/blog/sealed-sender/ Here is the codebase implementing it == https://github.com/signalapp

ghost commented 5 years ago

Oh? Link please. I notice you elide any evidence of your accusation.

I've already stated it in this thread. The quotes "free for everyone" among other quotes.

(edit: I've only exposed ~4 or so lies.. I was planning to expose even more and put them all together addressed in detail in a new post if I find the time.)

whose software can then be replaced with a special version

You don't seem to know what you are talking about, can you please explain how you imagine this attack vector would work?

You're quite lost. Google and OWS will follow court orders. Google identifies users before they get access to the repository. From there Google can treat any of their users uniquely if compelled to do so.

that's a defeated claim

You definitely don't understand what you are talking about. You are recommending tools that are less-well-vetted and vastly less field-tested. Quality of the crypto is the baseline for achieving privacy.

You have no hope of understanding this because at least 3 times you've been told that a flawed design makes code quality moot. And yet you continue to go back to the code and ignore the design. The most stark fool-proof way I've expressed this so you can understand is that Facebook could have solid code, yet it's designed to abuse your privacy so it's moot how impeccable the code might be, if it were hypothetically very high quality. Search "Facebook" to see that post.

Herohtar commented 5 years ago

That's security by obscurity.

That's not what that term even means.

OWS designed their system such that it must authenticate who connects to their network. When the "envelope sender" is replaced with other data (a certificate in this case)

And that's not how sealed sender works. The sender info is a certificate to start with. With sealed sender that certificate is encrypted inside the "envelope" along with the message, and then the message is sent to the recipient without the server authenticating the sender. There is no sender identity associated with the outside (unencrypted) part of the envelope.

ghost commented 5 years ago

That's security by obscurity.

That's not what that term even means.

i didn't say what it meant. But from context you seem not to know. The process I described is textbook infosec 101 security by obscurity. Making a data replacement that's traceable complicates (obscures) the traffic and relies foolishly on an unskilled adversary being unable to overcome the complexity.

And that's not how sealed sender works. The sender info is a certificate to start with. With sealed sender that certificate is encrypted inside the "envelope" along with the message, and then the message is sent to the recipient without the server authenticating the sender. There is no sender identity associated with the outside (unencrypted) part of the envelope.

That's not how it's been described. But even if it works the way you claim, the sender or the sender's data still must be authenticated.

Herohtar commented 5 years ago

That's not how it's been described.

That's exactly how it was described, and the article you linked describes that behavior as well. It is poorly worded, but if you read it carefully you will see that they talk about the certificate being part of the envelope that is then encrypted.

five-c-d commented 5 years ago
yes, if the OS is pwn'd then the endpoint is pwn'd, which applies to all messenger-apps. Signalapp has some special features that almost none of the others offer, though

> From there Google can treat any of their users uniquely if compelled to do so. And this is applicable to Jami and also to Wireapp, as well, which you know. Every app that offers a playstore variant, could theoretically be targeted. Any app which does not have a playstore variant, is not really suitable for being listed at privacyToolsIO, because it is not something everyday endusers are likely to be comfortable or confident enough to use. That said: signalapp *is* specifically built to mitigate that risk, unlike any other messenger app that I'm aware of with the possible exception of BriarMessenger (not listed on privacyToolsIO yet). Signal4android has reproducible builds, and these can be checked against the playstore build, as well as the sideload build. There is a volunteer I know who is doing those exact checks, online in public, and more that I don't know about as well. With time this number will only grow, since signalapp has the userbase to attract such difficult verification and double-checking efforts. > Google can treat any of their users uniquely How will they accomplish this? Are you asserting that they can bypass the code-signing checks? The APK is signed by Moxie at Signal Foundation, not by Google. (Jami cannot say this on FDroid is my understanding ... the code-signing is done by FDroid people not by Jami.) It is not *impossible* to imagine that google might subvert the entire playServices codebase just to get a high-value target. Obviously -- they could do this no matter what the enduser was running, jami or wireapp or whatsapp or the stock sms app -- this is a targeted access operation, purely and clearly an endpoint-attack, which happens to be performed by the OS vendor rather than by an "external" cracker, but is otherwise non-distinct as an attack-vector. But what if the person in question is running LineageOS sans playServices, and used the sideload APK direct from signal.org? (That is exactly the kind of person who worries about trusting google and yet wants to run signal4android because it has the best-vetted crypto and it has the reproducible builds so the APK can be verified.) I guess... if they didn't understand how to hit ctrl+u when downloading the APK, and were using their own home IP address without Tor+VPN when they downloaded, theoretically Google might know someone with that laptop, probably installed signalapp, on an unknown device? But like most of your long list of political transgressions, it is a stretch through a long chain of if X then Y which likely means Z and therefore signalapp is evil QED. All of which applies 100% to your preferred tools, with a vengeance: wireapp actually gives you a tracking-cookie when visiting their download-site, and the same place is where their webapp flavour logins happen. Plus: the wireapp APK has firebaseAnalytics in it, as does jami-from-playstore. Whoops. When you come up with "theoretically google could be forced to crack into the handset of any human running signalapp from playstore" ...sigh. You act like you are making a huge J'Accuse ... but all that you are doing is pointing out that smartphones are consumer electronics. You own a laptop, presumably with an Intel later than 2007 or an AMD later than 2013 processor. You run debian. If you assume the CPU vendor or the OS vendor is *the adversary* then is your jami4debian secure? Nope. If you specifically bought a pricey Librem15, or hand-installed libreboot, or something, are you 100% secure against endpoint attacks by powerful sophisticate adversaries? Nope.

yes, if the developers are evil then the endpoint is pwn'd, which applies to all messenger-apps. Signalapp has some special features that almost none of the others offer, though, once again

> OWS will follow court orders There are hundreds of repo-watchers for each flavor of signalapp. The builds are reproducible. The code-signing key-material are on an air-gapped machine. Volunteers are comparing the playstore version to the sideload version on signal.org and there are millions of endusers field-testing the code quality every day. We have an **example** of OWS following court orders. Even fighting in court to beat the gag-order. What the record of the court proceedings revealed, when it was unsealed, was: phone-num X is not a signal-num, and we have nothing else about that phone-num. Plus: phone-num Y registered at date/timestamp, and last connected to signal-server sometime on day/date, and is currently a registered signal-num. The last bit the feds could already figure out themselves. Where are the court-cases that demonstrate how much data wireapp > Could a court order delivery of malicious j/s to identified targets and then actually compromise the payload data? This is a risk inherent in having interpreted code downloaded and executed on-the-fly by identified users. I would also very much like to hear how you imagine this scenario works. As with sealed sender, you just assume the worst is true, and pretend it only applies to signalapp and never to any other messengers, and hurry on past. What is the exact thing you imagine will occur? Where do you believe the javascript is being served from? What point during usage, will Alice's device be at risk of potentially malicious javascript? Are there any mitigations? Assume she is in a groupchat with 99 members. Now, do the same comparison, except this time Alice and her groupchat of 99 members are on wireapp. Can any of them be compromised by Google javascript? Can any of them be compromised by wireapp servers, either because the wireapp devs are evil, or because the wireapp servers are pwn'd by an adversary (cracker group or court order), for instance? Does your answer change if zero of the people in Alice's group ever use wire4web and entirely utilize installed flavours?

the sender or the sender's data still must be authenticated

This is true, but not in the way you are implying. Alice's identity is authenticated over on Bob's device, after he receives the encrypted-blob payload (which signal-server cannot open at any point during transit).

example sealed-sender transmission

Signalapp is designed to be end2end crypto. Say that Alice wants to message Bob, and sealed sender is active (it is on-by-default but not always permitted ... this is related to the anti-spam and block-button if memory serves ... sealed sender traffic is above 80% or something like that, maybe higher by now). * Alice +1-111-111-1111 composes a message to Bob +2-222-222-2222, hits send * the sender-portion is sealed inside a crypto-envelope which only Bob's device can open * Alice's device connects to signal-server, using the pinned certs baked into the APK so that Alice is assured she's connecting to the legit server-cluster * Alice uploads the payload which says "From: sealed. To: +22222222222" * there is a delivery-queue for Bob's device on signal-server, with that signal-num * Bob's device checks for messages and downloads the crypto-envelope * signal-server deletes the server-side copy, after ACK that the download was ok * Bob can decrypt the outer envelope, and then figure out "hey this is from Alice" * this is based on the existing long-term encrypted session between Alice and Bob I dunno if that was all correct, with no omissions and no invalid insertions, but that is basically the process is my understanding. Now, with timing-analysis, and 100% malicious server-node, and Alice and Bob not being careful about shielding their IP addresses with Tor+VPN perhaps, plus enough days of traffic flow, a sophisticated adversary would be able to connect the dots. Eventually, they would figure out that the IP over *here* is +2-222-222-2222 and the other IP over *there* is +1-111-111-1111 ... now, whether that helps Eve any, depends on whether the IP addresses are geolocatable to anything but the exit-node of an anonymizing network, and whether the telco-nums in question trace back to anything but a simcard purchased with fiat cash (or an online voip num purchased with zCash-filtered-BTC-from-a-mixer). Maybe the nums were cellnums, and maybe Alice and Bob used their cellnums *as* their signal-nums ... this is easy and zero-hassle for most endusers, so it is the default. Maybe the IP addresses are their unshielded home ISP dotted-quads, as well -- again, zero hassle, and thus the default. But if so, it would not have mattered whether Alice and Bob were using wireapp (because they would have signed up with their cellnums or with their fname.lname@gmail accounts). And if they are *that* hassle-averse, Alice and Bob would never use Jami at all (or even have heard of it). But I think the more telling point is that, if Alice and Bob were that carefree with their personally-identifiable-info, their choice of software would simply not matter, if up against a sophisticated adversary. Weak opsec and humans that leak their own metadata without thinking it through, are never going to be something that software can solve. No matter how well-vetted the crypto, no matter how solid the design, software cannot make Alice and Bob secure if they are behaving insecurely and making it easy for Eve to pwn them.

Sealed-sender is not a silver bullet. If the OS on either endpoint is controlled by an adversary, or the baseband CPU or Intel ME on either end is controlled by an adversary, or if the humans on either end voluntarily leak to TheGuardian, software apps won't help.

a data replacement that's traceable

Well, please elaborate. How is it traceable? Who can trace it? Somebody that has compromised an endpoint-device? Somebody that has compromised a server-node? Somebody that has compromised the code-signing keys of the APK? I don't see how it can be traced, but if there is a way then I'd like to know :-)

Sealed-sender is quite new -- NOT as well-vetted in other words -- it just was in beta a few months ago. If you see a place where the authentication-to-the-server portion was improperly replaced with the newfangled "[sender] periodically retrieve a short-lived sender certificate from the service" which has the signal-num buried inside, please file a bug at https://github.com/signalapp/Signal-Android/issues or email security@signal.org with the exploit details.

SGX enclaves were in beta from late 2017 through late 2018, and there was a paper published on the ForeShadow flaw which strips that protection.

p.s. “In particular, additional resistance to traffic correlation via timing attacks and IP addresses are areas of ongoing development.” That is the bit I like.

p.p.s. "Free for everyone" is not in the thread per se, you should add that to point_1_v specifically in the OP. You did list that quote it in your PNG file ... still waiting on your wireapp equivalent of that diagram to see whether it has any significant differences from the signalapp version. Specifically, you don't want to own a smartphone, and your complaint is that signalapp requires a telco-num at signup, and therefore is not free-as-in-beer.

You seem to be purposely ignoring that messengers that utilize the internet require a person have internet service. That messengers implemented in software require people to have a computer with hardware capable of executing that software. Moxie told you his software is free-as-in-freedom, and you call him a liar because he won't buy your handset, pay for your ISP bill every month, and provide you a telephone-number? This is pretty rich :-)

It goes back to your misunderstandings of the four freedoms and the LibreSignal situation: for you, the person who wrote the software, and then gave it free-as-in-freedom with client-code and server-code, to the world, is a horrible evil scoundrel. Because that is not enough: you demand that they run a server and pay for all the bandwidth, and you demand they hand over their trademark to anybody who asks, AND you say "oh yes it is in the four freedoms somewhere" that software with no warranty must come with free support and free server-nodes and a guaranteed chance to dilute the trademark?

you apparently don't realize the purpose and big-picture motivation behind them, and the ultimate utilitarian benefit that manifests from the 4 freedoms when there are no shenanigans to pervert software freedom. With only a shallow superficial understanding of the 4 freedoms you're vulnerable to allowing misplacement of power in a way that undermines those who the 4 freedoms were designed to benefit... The software freedoms are declared for the purpose of shifting the power structure to be favorable to the user. The process of codifying the 4 principles into the GPL is imperfect. It's impossible to codify it in a way that catches all possible shenanigans that game the GPL label while shifting power back to the corporation... When an owner of a work goes out of their way to legally undermine people from actually making practical use of the freedoms....

Free-as-in-freedom means you are given the FREEDOM to use/study/modify/share the code, under [A]GPLv3 terms, only. The end.

It does not include a free-as-in-beer handset. It does not include a free-as-in-beer webhost. Those are not anywhere in the four freedoms.

(edit: I've not pointed out all the lies.. I was planning to expose them all together in a new post if I find the time.)

Oh good. When you find the time, I hope you find the recollection to ping me, please. He promised me freedom, but it was a lie, no server bandwidth and no cellular dataplan included? You are completely losing any semblance of objectivity.

blacklight447 commented 5 years ago

Any updates on this,I have still not read any real evidence that signal would not be privacy friendly, except for some pseudo annoyances. Wheter a phone number is bad completely depends on ones threatmodel, and at most would be an anonymity issue, not a privacy issue. Further more can signal be easily used by its apk version which also includes an auto updater. My vote is the close this issue.

Mikaela commented 5 years ago

How about we click the close button until something worse happens and it can be easily replaced?

Mikaela commented 5 years ago

In case there is interest, I became aware that Signal forums had a thread about this thread ending to April 10th.

five-c-d commented 5 years ago

Yeah, that is where I heard about 779, and I linked to that at one point but I'm pretty sure it was buried in the ton of verbiage that libBletchley and I were exchanging.

To be clear, that is the 100% unofficial forum where people that are enthusiasts hang out, and from time to time, signal foundation folks that are "off the clock" in some sense also may appear. The hosting-fees are paid for by the foundation, but the participants are all speaking their own opinions and do NOT speak for the foundation.

SignalUsers is for support-questions that are more complicated than the support@signal.org email helpdesk can cope with, and for feature-requests which don't belong on github.com/signalapp bugtrackers, plus generic "general discussion related to signalapp / off-topic discussion about random things". None of the people commenting in that linked SignalUsers thread (or in this 779 thread for that matter), are Signal Foundation employees, though several have contributed small fixes on github or transifex or things like that. I still hope signal foundation gets rid of cloudflare-linked-GetClicky btw :-) https://community.signalusers.org/t/trackers-and-fonts-on-signal-org/7698 is the main thread.

strypey commented 5 years ago

@five-c-d

Any app which does not have a playstore variant, is not really suitable for being listed at privacyToolsIO

The security of any app installed using the Prey Store is inherently compromised (see what happened to Riot recently for example). So what you're saying in practice is non-ubergeek users have no privacy-respecting options. But this just isn't true. Anyone who is sufficiently motivated to use software that doesn't come with their device can learn to install and use F-Droid. PTIO recommends replacing Windows with GNU/Linux, which I agree with, but it's much more complicated. There's no booting from USB or command line wizardry involved in installing F-Droid, it's a simple set of steps: 1) download .APK from fdroid.org 2) tick the box in the 'Security' tab in Settings to allow app installs from non-Prey sources 3) install from APK 4) search and install the free code apps you want to use

There ought to be ELI5 instructions (more detailed than this, with sample screenshots) for installing F-Droid on the PTIO site, and every page that gives advice on mobile apps ought to say "first install F-Droid" at the top with a link to that page.

strypey commented 5 years ago

@five-c-d

Where are the court-cases that demonstrate how much data wireapp

There aren't any, that I know of, presumably because the company that makes Wire is not registered in a jurisdiction where the government is one of the main adversaries people are trying to protect their privacy from.

Mikaela commented 5 years ago

The security of any app installed using the Prey Store is inherently compromised (see what happened to Riot recently for example).

What happened to Riot recently?

My understanding is that Matrix.org didn't think of its security enough and didn't have sysadmins working on it and got compromised and they had multiple bad practices such as storing signing keys on that server including the ones they used for Google Play releases, so they revoked those in case attacker would have signed malicious APKs with those keys. As a side-effect they had to relaunch the app on Play Store and F-Droid said that they will do similar to avoid additional work for maintainers even if theoretically they wouldn't have to do that.

five-c-d commented 5 years ago

what happened to Riot recently

Yeah, @Mikaela ...MatrixOrg didn't get compromised via playStore somehow, they got compromised via direct attack on their central server cluster ... they had to change their playStore code-signing key (and their synapse homeserver code-signing keys), because they weren't keeping those on air-gapped systems. At least, that is my understanding of the breach; it is pretty complicated. There wasn't any flaw in the MegOlm protocol, there wasn't any flaw in the distribution-chain by which they send out code, there was just a flaw in their normal server-side opsec and infosec, which let the adversary get into their backend server-cluster undetected, and then because of ssh agent-forwarding, get direct developer-level access to the central matrixOrg database... and at some point, stumbled across the code-signing keys!

This would not have impacted the people running their own federated homeservers, except for the code-signing key screwup. This would not have impacted FDroid people any differently than people who installed via playStore, unless I'm missing something? The adversary had access to the backend: they could have uploaded whatever they wanted, and the distribution-chain would happily have passed it along, because the adversary was able to impersonate riot/synapse/matrix developers if they wished.

what you're saying in practice is non-ubergeek users have no privacy-respecting options

No, what I'm saying is that every tool that privacyToolsIO recommends, should BE AVAILABLE through playStore, because that is what everyday endusers typically utilize. And that is the target-audience, the intended readership: everyday folks.

I'm specifically not saying, that ALSO being available via direct download (signalapp which has their own reproducible builds setup) or via FDroid (jami which uses fdroid reproducible build setup) is a downside. Tools offering those options, should be seen as GOOD tools which are doing the correct thing :-) People with the time&knowledge to do so, should use those alternatives, sure, if they want more privacy and don't mind the hassle / wizard-level requirements.

That said, when a tool is e.g. only available via XDA forums, not in FDroid and not in playStore, that tool is flat out unsuitable for normal endusers, and thus does not belong in the privacyToolsIO listings anywhere. Same when you have to hand-compile the APK yourself from github, that is not what most of the privacyToolsIO readership are going to do. I'm not aware of any tools in the IM list or VoIP listings, that are on FDroid but not on playStore... are there actually any such tools, or is this more of a meta-discusion in the abstract, rather than a specific tool we are implicitly chatting about?

PTIO recommends replacing Windows with GNU/Linux

This is not quite true. What the listings say is not so starkly black-n-white:

  1. negatively-pans Windows 10, in some depth (with rationale)
  2. (silently passes over any mention of Windows 7 and of OSX)
  3. positively recommends Qubes (for lin/win/osx), Debian, and Trisquel
  4. has OpenBSD and Arch/Parabola worth mentioning (plus a few others)

That's just the desktopOS listings, there are also mobile device listings (LineageOS + UbuntuTouch + GrapheneOS which are linux-kernel-based), and live-distro (Tails+Knoppix+Puppy which are all linux-kernel-based).

So pretty clearly linux-for-the-win, I agree. But it does not say "never use windows only use linux" anywheres, it just says "do not use windows 10 and if you do use some earlier version run qubes or tails to boost your privacy". At least, that is my reading of the prose.

presumably because the company that makes Wire is not registered in a [FiveEyes] jurisdiction

Possibly that is the case, sure... but the datacenter is AWS, and the wireapp servers contain lots of metadata, so any subpoena from the USA should still be able to be served, I thought. Is that incorrect? (Ditto for Germany/EU because of the partial location there.) To me, the main reason that a piece of software either has, or fails to have, a court-proceeding they can point to is strictly correlated with size of the userbase; signalapp only has a few million endusers so they only have one courtcase, wireapp has around one-tenth the userbase so they do not have one yet.

Until they do, we won't have proof-is-in-the-pudding kind of demonstration of what metadata is being retained, was my point. Court-cases are not a definitive exposition because they tend to be very situational-specific, but they DO help show in a clearcut fashion how well or poorly that specific situation went for the software. I apply the same kind of logic to VPN providers with no-logs policies, and webmail providers, and so on: when they have a third-party audit that is helpful, but a court-case is often even more-helpful (because unexpected / adversarial rather than scheduled / on-the-payroll).