❌ Software Removal | Signal #779
Labels
No Label
🔍🤖 Search Engines
approved
dependencies
duplicate
feedback wanted
high priority
I2P
iOS
low priority
OS
Self-contained networks
Social media
stale
streaming
todo
Tor
WIP
wontfix
XMPP
[m]
₿ cryptocurrency
ℹ️ help wanted
↔️ file sharing
⚙️ web extensions
✨ enhancement
❌ software removal
💬 discussion
🤖 Android
🐛 bug
💢 conflicting
📝 correction
🆘 critical
📧 email
🔒 file encryption
📁 file storage
🦊 Firefox
💻 hardware
🌐 hosting
🏠 housekeeping
🔐 password managers
🧰 productivity tools
🔎 research required
🌐 Social News Aggregators
🆕 software suggestion
👥 team chat
🔒 VPN
🌐 website issue
🚫 Windows
👁️ browsers
🖊️ digital notebooks
🗄️ DNS
🗨️ instant messaging (im)
🇦🇶 translations
No Milestone
No Assignees
1 Participants
No due date set.
Dependencies
No dependencies set.
Reference: privacyguides/privacytools.io#779
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem with Signal
Signal has copious privacy issues making it unfit for privacytools.io endorsement.
(see also F-Droid: The privacy-friendly alternative to Google Play Store)
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
Prostitution ring diagram showing privacy abuses:
(PDF)
The removal of Signal would but Riot.im and Ricochet as top recommendations.
Do you want to explain the use of Riot or Ricochet to someone who uses Whatsapp and are both of them as easy to use as Whatsapp?
At least before final verdict we should get an input on the issues listed from someone at Open Whisper Systems.
Why not use the apk on their website?
You can, and it's better than Playstore but it doesn't completely avoid feeding Google. See 2.i and 3.v.
And Riot.im/Matrix.org appear to be using Cloudflare (https://github.com/privacytoolsIO/privacytools.io/issues/374) and the problems with in general haven't been reported as fixed yet (https://github.com/privacytoolsIO/privacytools.io/pull/562#issuecomment-464569232).
Ricochet's situation seems uncertain to me at a quick glance, there is https://github.com/privacytoolsIO/privacytools.io/issues/474 arguing it's unmaintained and pointing to https://github.com/privacytoolsIO/privacytools.io/issues/746 in the latest comment.
Would it be time to think about XMPP (https://github.com/privacytoolsIO/privacytools.io/issues/60 & https://github.com/privacytoolsIO/privacytools.io/issues/141)?
@Mikaela
When it comes to user experience, no, absolutely not. There are dozens of XEPs needed for a WhatsApp-like client that are only supported by several client implementations. Then, modern encryption (OMEMO, which is still experimental) is only supported by a small number of clients. Finally, you need an XMPP server that must also support several XEPs. There is no simple way for users to find the right client AND server when they decide to switch to XMPP.
Another drawback of all of these systems (Matrix, XMPP etc) is that contact/account management is done by the server, while messengers like Signal/Briar implement client-side account/contact management.
Server-side management implies that the server knows much more about registered accounts like group memberships, contact lists, devices, reading status, and even passwords (as mentioned in https://infosec-handbook.eu/blog/xmpp-aitm/). In my opinion, this isn't privacy-friendly at all.
Besides, some of the @libBletchley's statements above aren't completely right. For instance, we showed that users can simply register a random phone number from "Free SMS receive" websites and lock down the re-registration afterwards. Another possibility is to buy a SIM card in countries that don't require ID registration (e.g. in the Czech Republic). Doing so, invalidates the whole point 1.
Point 2 is mainly about "Google is everywhere". This very likely affects many other messengers as they contain code provided by Google. Moreover, most modern smartphones run Android (Google), and even custom ROMs (LineageOS, /e/) heavily rely on Google's code. So, there is no Google-free world. (Keep in mind that there are dozens of protocols and technologies on the internet like JSON, HTTP/2, Content Security Policy, Certificate Transparency etc.)
Point 3 repeatedly complains about the same problem: Some users can't directly access the apk download link as it relies on JavaScript since the link is generated using JSON, and scripting. Installing apks from websites comes with security risks. I see no problems in warning users about this.
Point 4: I suggest that most users never access the support page of Signal. Besides, I opened the link several times in the Tor Browser and never saw any warnings, or captchas.
Point 5: As mentioned in other issues, many websites run on Amazon AWS (like Signal, GitHub, several XMPP/Mastodon servers etc). If we decide to remove Signal due to this, privacytools.io should also close its GitHub account …
In summary, there is no perfect messenger, and there is very likely no completely Google-free messenger. Discouraging users from using services since the developer buys from Amazon, drinks Coca-Cola, or runs Windows 10 isn't about the actual service but about political beliefs.
While this is a great approach for anonymity, note that the SIM cards that you can buy in stores in CZ are temporary (usually 2 years I think). Still quite good though and they're cheap too.
@Shifterovich
When I brought a sim card from a green region to a red region in this map, the phone could not connect to a tower using that sim. There may be some loopholes where it works, but this will only get worse as they close the loopholes. This whole scenario is already well beyond the PTIO target audience. That is, casual users are not going to leave the country for a GSM chip just to register for a messenger service particularly when it's a service with many other compromises.
@infosec-handbook
This doesn't follow. The circumvention doesn't run contrary to anything that I've said. And in fact I've already addressed this in 1.iii.
Actually that only addresses 1.i and it's rendered moot by 1.iii. Furthermore, I've tested this and it doesn't work. See my reply to @Shifterovich.
Everything in part 2 is about the project website and not in the slightest about the application code. The website needlessly pushes visitors into Google's walled-garden of privacy abuse. Users are forced to interact with Google before they even get a copy of the app. Some will not even manage to get the app because of the Google barrier to entry (2.e).
Jami's f-droid download page is Google-free, and the F-Droid app also gives novice users a Google-free means to acquire the APK.
You claim redundancy, but then you only address 3.v. W.r.t. redundancy, all the part 3 points are unique and collectively support the part 3 thesis that the "APK download is implemented in a privacy-hostile manner".
Every possible mechanism has security risks. The problem with OWS is they not only offer the most risky of all options (Google Playstore) and they push users into that privacy-compromised situation with no warnings at all. And then OWS hides their less risky mechanism and puts a very loud warning banner on it to deceive users. OWS then bluntly refuses to use F-Droid despite years of criticism from experts. This is not just a security issue - it's a trust issue.
Let's be clear about the magnitude of risk:
OWS is knowingly and willfully pushing users into the most risky of all possibilities and claiming it's the "safest". It's malicious, it's intellectual dishonesty, and it shows OWS cannot be trusted. By endorsing Signal, privacytool.io loses credibility.
Some users quite rightly refuse to visit CloudFlare sites, so their lack of access is actually due to forcing users into CloudFlare's privacy-abusing walled-garden.
CF has taken actions to mitigate CAPTCHAs presented to Tor Browser. This is actually detrimental to privacy. Hiding the presence of CF enables the privacy-abuses that occur in the browsing session surreptitiously.
This is a bandwagon fallacy. And it's a bandwagon that goes against the PTIO mission. PTIO should condemn AWS instances, including Signal, GitHub, and any particular Mastodon instance known to use it.
Perfection is not the PTIO mission. The PTIO mission is to assess and endorse the lesser of evils. Signal fails to make that cut. Signal deliberately forces users direct exposure to Google surveillance among the other privacy abuses mentioned.
This is a false dichotomy. The core of this bug report is focused on user privacy through direct use of the endorsed services. Looking also at the financing of privacy abusers is secondary, and it's certainly not in contention with direct privacy abuses. Users seeking to protect their own personal privacy are also opposed to large scale investments that will manifest in future privacy abuses. The PTIO target audience does not want to support their mass surveillance adversaries. And it's less about the developer's personal choice and more about everyone's forced patronization as a result. I.e. it's not that the developer chooses to drink Coca-Cola but more like he is forcing everyone else to drink Coca-Cola.
Looks like Jami is not even listed as an IM tool. It should be.
@libBletchley
We own several Czech (green) SIM cards and use them like every other SIM card in red countries like Germany, Austria, Hungary etc. – every day. Last year, we also registered Austrian (red since 2019) SIM cards with Signal and can use them as any other SIM card.
Additionally, we mentioned the possibility to register a random phone number from the internet that can be locked down by setting up a registration lock PIN.
Besides, your remaining main point is that Signal doesn't aggressively promote the direct APK download, or APK download via F-Droid. In my opinion, it is really hard to seriously explain people why they should avoid Signal due to this. "Yes, they offer state-of-the-art encryption, avoid metadata where possible, but you can't access the download link if you use NoScript/uMatrix in your web browser."
How many people block JS in their web browser, especially on their smartphone? How many people use F-Droid? And are these people really "novice users" as mentioned by you? What about iOS users who can't use F-Droid? What about the real "novice users" who don't know how to install F-Droid and stick with Google's Playstore?
Anyway, one basic problem remains:
Every other day, someone opens an issue to suggest the removal of software. Sometimes, these people suggest a replacement they prefer, another time, the discussions come to nothing. Sometimes, there are questionable reasons for the removal, another time, the reasons are totally valid.
However, there are no defined requirements for recommendations on privacytools.io. We tell users that specific software is "good" (due to what?), and after some months, we replace the recommendation due to the opinion of less than 10 people on GitHub. In my opinion, this process is non-transparent and often only rely on people who were "in the right spot at the right time".
It's hit and miss. My green-region chip doesn't work in red regions. Not to mention it's already quite loony to expect the PTIO target audience to buy a GSM phone and then buy chips for it in another country. It's a nonstarter because their mailing address is not anonymous, the payment method is not anonymous, and if they physically travel to Czech and pay cash they'd be hard-pressed to find a shop without video surveillance. Then once they get the chip they can only use it away from home (due to GSM tracking) and also due to GSM tracking they have to find an CCTV-free place to activate the chip, use it, and then remove the chip. It's completely absurd to propose this as a precursor to establishing an anonymous Signal account.
According to signal docs, users must "retain control of this phone number" and use the reg. lock PIN to prevent compromise. That's an /and/ not an /or/. And again we're still outside the scope of what the PTIO target audience will bother with. Anyone who uses the free-for-all pinger numbers knows they fail 95% of the time. After a number is used to register 6 or so accounts, Twitter, Google, Facebook, etc, blacklists the number. The websites offering pinger numbers sell the use of virgin numbers for a premium and then after those numbers have been spent on the full quota of twitter, google, facebook, and linkedin accounts, etc, then they are opened up to the public who then tries to use them only to find the confirmation code never arrives. Sometimes they work in corner cases for unpopular services, but usually the numbers quickly end up on a list. I've seen these numbers fail even for 2fa at a small hole-in-the-wall university because the school outsourced to an organization that was good at maintaining the blacklists. So what you're suggesting is a non-starter not just because chance of success is low, but also because anyone who has used those services already knows they only work in obscure niche situations and would not even likely attempt it with Signal. And then the users who don't have experience with the SMS pingers are also the ones unlikely to go through the hoops you're suggesting.
I don't even try anymore, generally. If a service demands a phone number, I walk. I have a link farm of pinger number sites from doing this chase in the past and I still personally find it's not worth my time. PTIO should not even be suggesting users waste their time with this - it's demoralizing to PTIO users.
That's a bit twisted. The problem is the aggressive push into the privacy abusing walled-garden of Google Playstore. Signal needs to stop overselling the mass surveillance option, and stop hiding the APK. And even then it would only be viable for users advanced enough to handle an APK. Jami is in F-Droid, which is easy enough for novices to use.
You don't need to. You say "PTIO does not endorse Signal. Use Jami." Anyone who wants to know the rationale can come here and see ~50+ reasons not to trust Signal+Google+Amazon+CloudFlare.
It's the job of OWS to market Signal, and so far they've failed to demonstrate that they are suitable for PTIO endorsement.
These are exactly the users who need to be guided away from Playstore and over to the F-Droid repo. Keeping them jailed in the Playstore disservices those users. If they come to privacytools.io, they're looking to change that. This is what PRISM-Break does in the "App Store" section. And it's what PTIO should be doing. F-Droid is a fool-proof procedure. Users are told they must allow installations from unknown sources, and then they are automatically taken directly to the config screen where they flip a switch that originally has them isolated on Playstore.
It's unclear what you're trying to say about iOS and how Signal comes out ahead there. Signal and Jami are both available on iOS, which is inherently jailed AFAIK. Both are taking users to iTunes store. Are you saying there's a better alternative to iTunes suitable for novices? Does Signal have a hidden page for that too?
Benefits to dropping Signal
PTIO can actually improve users' options by delisting Signal.
Regardless of whether OWS reacts, it currently disservices users for PTIO to be needlessly directing users into the privacy-hostile walled-garden of Google Playstore via OWS, whilst subjecting users to Amazon and potentially CloudFlare as well. This is not what PTIO visitors signed up for.
@libBletchley
As mentioned by others and us, it would be really nice to 1) define requirements for software/services recommended on privacytools.io before continuing, 2) not only focus on drawbacks presented by one single account but also look at benefits, and 3) also consider valid points of Signal (e.g. that they can't offer support for every platform on earth).
Regarding your latest list of points against Signal:
And again, you tell us your personal situation, and suggest that this is valid for all people on earth. How is successfully using five SIM cards from the Czech Republic in five different devices/four different countries a "hit and miss"? I get the impression that you either never owned a SIM card from there or just repeat yourself to tell us that we must quickly remove Signal.
Then, you continue to cite Signal docs and assume that something you experienced in a different situation is also true for Signal. You obviously never tried this before.
That is exactly the problem. In two months, the next person shows up, and tells us "Jami has problem x, drop it. Choose XMPP-based messengers." Then, the whole process of subjectively choosing the next candidate restarts, and then we say "PTIO does not endorse Jami. Use Conversations/Dino/etc."
Where is a list of benefits/drawbacks of Jami? Why is Jami as good as Signal? Why is it better than Matrix-/XMPP-based messengers? Why don't we recommended messengers like Briar? Hopefully you get that just saying "We must quickly drop Signal, and just add my favorite messenger" doesn't work.
As mentioned before, you still try to represent every interested user coming to privacytools.io. Furthermore, there is no "black and white", no "good and bad". Using Playstore and/or F-Droid isn't about religious beliefs, and we are likely not in the position to tell users that they must use F-Droid.
A "fool-proof procedure"? 1) They must know that F-Droid exists, 2) they must willingly download the F-Droid apk, 3) they must disable a security feature of Android and understand why it is there, 4) they must install and configure F-Droid … then, they get a much smaller amount of apps, and may have to install just another store like Aurora/Yalp to download/update their now missing apps again. Furthermore, just installing another store doesn't change anything regarding communication with Google servers. We just looked at /e/ operating system and another blog analyzed LineageOS. Even if you get rid off many Google components, there is still communication with Google servers. Installing F-Droid is a drop in the bucket, and F-Droid also has drawbacks.
Again and again, where is a list of drawbacks of Jami or a list of benefits of Signal resp.?
Yes, of course. "privacytools.io just dropped Signal due to statements presented by a single person without ever considering any benefits of Signal or drawbacks of Jami."
Besides, privacytools.io is still on GitHub that is hosted on AWS, but we tell users that Signal is bad since it is on AWS … and then, there is PRISM Break. After years, they started to recommend Signal. Are you also there, @libBletchley, to tell PRISM Break that they must remove Signal to endorse an experimental messenger that doesn't offer the same features and has drawbacks never mentioned by you?
Have you guys actually contacted Signal devs about:
Until there actually is a de-facto replacement for Signal that is compatible with or without Gplay-store, I think we really need to try to convince them to shape up their privacy issues where warranted, and accept that we're not an ideal world, while a shitload of people are already using Signal, even though most of them don't even know why.
In that regard. Why don't you post a better solution to Signal devs about how they could replace the phone number and still keep shit simple enough for people to actually use. At least Signal is keeping all their shit up-to-date, which is far better than most other alternatives.
I think the [signal] issue is that updates, and new installs should remain transparent to the user and at one point they decided that using the phone number was smart. Well, it's not as we have seen...
So a possible solution would perhaps be by using a combination of (1) the phone's IMEI and (2) the phones serial number. That way it would be unknown to most potential attackers, while leaving the phone number out of the equation.
Perhaps @greyson-signal (or someone from your team) would care to comment?
Actually, I just changed my mind.
Please Remove Signal!
As I haven't browsed their issues for quite a long time, I took another look.
That is not what this thread is for. Do that here please.
I'm not in control of the focus. Endorsements are a function of both the benefits and the dirt. Each contributor can freely contribute to either. You are free to focus on the benefits if you want.
It's bizarre that you mention it because I didn't bring it up and it's a shortcoming of Signal. When a standard protocol is used on a decentralized network of free software devices and it naturally gains the momentum of diversity and it's a selling point. While Signal, Wire, Jami, and Telegram all support the same basic platforms, I'm not sure what the value is in that discussion. XMPP trumps in that discussion because users are not just limited to ~4 or 5 apps, but rather old pre-existing apps that users are familiar with have developed plugins. IRSSI users need not install yet another tool that forces them to use a GUI that enslaves them to the look and feel the developers impose. There are irssi plugins for things like XMPP, Omemo, OTR, Mastodon, GNU Social, Twitter, etc.
Signal is open enough that someone could create plugins for different existing tools, but you can't take credit until it's done. And in fact a non-OWS developer did create a free software client for Signal and OWS took a hostile posture and attacked him for it. OWS:
In fact, this hostility toward other developers is noteworthy enough to add to the OP. So platform support is actually artificially limited by the same control freak who refuses to use f-droid.
Actually it's the other way around. You've proposed something that's only viable for people who live just inside the border of a red region adjacent to a green region, as if that's worth consideration to all people on earth. It was actually me who pointed out why that fails.
Actually that's a different problem. This is why it's important to do a bit of analysis before haphazardly recommending whatever is popular.
This is not a one-person project. It is not the burden of one person to do all the work.
Signal is not the sole endorsement in any category, so it can be dropped without leaving an empty section. Expecting there to be 3 endorsements in every category is ridiculous. There is no inherent need to replace Signal's screen space with another tool. It just happens that Jami does not suffer from any of the 50+ privacy issues that Signal has and is more privacy-focused and freedom-focused. So Jami happens to be a good candidate but in the absence of Jami, Signal should still be condemned in the current state of it.
I don't "represent" PTIO target audience. Indeed try to cater for that audience and we all have a duty to do so, but I do not consider myself part of that demographic.
PTIO has a duty to make that happen.
PTIO has a duty to inspire them.
The process holds the users hands, so it's easy enough to do and as far as the rationale goes the user only has to understand it to the extent that they care. If they're triggered by their visit to PTIO, then they already have an interest in escaping Google's walled-garden. Understanding it is as optional as understanding the other security features and options of the device.
The installation is no different than any other app, and no, they need not configure it. That's optional and the default config will suffice until they need to add another 3rd party repo.
Rightly so. This is inherent in leaving a catalog full of dodgy apps.
No, that's not how it works. F-droid does not remove existing apps. The user is in control of what they want to remove.
F-droid doesn't communicate with Playstore and does not require it. F-Droid is actually what liberates users from Google.
You tell me. If you can see that something is missing in the discussion, why haven't you contributed it?
I've not contacted them about those particular issues. But I've read a lot of their threads and it's clear that they are not open to making significant change based on user feedback. OWS has been criticized by many people for years over Playstore vs. F-Droid and they will not bend to persistent pressure from their own users. I'm not sure how OWS monatizes the stats they're collecting via Playstore but it's very clear how attached they are to them. OWS even threatened legal action against someone else who wrote an f-droid distributed free software app. They are highly motivated to push people into Playstore.
The APK hiding is obviously deliberate. When you see their relentless Playstore advocacy to the point of deception (claiming it's the "safest" option), it's clear they won't budge on a mere request.
Nothing PTIO does is in stone (although some people here would like it to be). When the endorsement is lifted, if OWS notices they can react by taking actions to win back endorsement. And that's how PTIO can actually improve privacy.
The best play here is to drop Signal endorsement and work on increasing PTIO credibility by dropping a few other junk endorsements as well. Dropping Signal may improve Signal. At the same time, a project like Jami could use PTIO endorsement. And if that project gets the momentum it has earned it can improve merely by getting more attention and support.
@libBletchley
So, you write a lengthy list of Signal's "privacy abusements" that you edit nearly every day to convince the small set of people that read this issue. You don't look at benefits and you don't verify your points by asking Signal/using Signal yourself. As it seems, you also deliberately don't link any statements of Signal, or decide that understandable reasons for not doing something aren't worth to be mentioned in this issue.
For instance, there is a post by Marlinspike stating that they don't want messengers named Signal (or LibreSignal) because users of these messengers contact Signal's support in case of any problems. It is perfectly understandable that a company can't support any forks but you just add this to your "drawbacks" list.
Anyway, we already wrote several times that your lists aren't the full truth, but you repeat your points over and over again to define what is best for the target audience of privacytools.io (that you don't represent as stated by you).
Then, you recommend Jami via F-Droid for "novice users" while writing in the same issue that F-Droid is for "advanced users". You never talk about any drawbacks of F-Droid/Jami or benefits of Signal but require others to do so since your only goal is the removal of Signal.
Finally, you tell privacytools.io that they must convert Playstore users to F-Droid users to become "liberated from Google". We already wrote that just installing F-Droid doesn't change anything. Users have to root their device to remove all Google apps or install an ungoogled ROM. Even if they do so, there is still Google code left that communicates with Google servers. Additionally, F-Droid (as mentioned above too) contains a much smaller amount of apps. If you require apps that aren't in any F-Droid repo, you likely need Playstore/Aurora/Yalp to get apks from Google.
The original statement remains a biased list of arbitrary reasons to get Signal removed that aren't fully true and don't consider valid points why something isn't as puristic as wished by the OP.
I don't have the time to repeatedly edit my posts/add new ones to discuss the same points over and over again as this comes to nothing.
The PTIO mission is this:
"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."
In this context, a "benefit" would be something that helps people avoid mass surveillance. In light of all the mass surveillance Signal subjects users to I don't see the point of wasting time on that effort - but you are certainly free to. It's quite bizarre that as a die-hard loyal Signal advocate you've not attempted to make a case for how Signal helps people avoid global mass surveillance.
Asking a biased party to verify a fact that's detrimental to them is the least competent way to verify a fact. All the facts I've exposed are verifiable without asking OWS anything. And even facts about OWS's position on something are already verifiable from existing public threads. If you need help verifying something in particular because a source needs to be cited feel free to call it out.
All facts presented remain unchallenged so far. If you think a statement of fact is false, feel free to call it out. If you think a relevant fact was overlooked, it's your duty (not mine) to point it out so the "full truth" is exposed. I'm not a mind reader.
Naming a non-OWS project "LibreSignal" in no way imposes an obligation of support on OWS. It's a bogus corporate PR excuse used to block a name that naturally suggests to the public that "Signal" on its own is not "Libre" (which is bad for the corporate bottom line).
I never said F-Droid is "for advanced users" as if to imply that it's not also for novice users. F-Droid is for both novice users and advanced users. You're probably confused by the row in the table saying advanced users are vulnerable to targeted attack, but the context is that the website is used for the APK instead of the app. This is a use-case that most commonly facilitates side-loading, and side-loading is an advanced user activity. F-Droid users need not side-load.
That is not true. F-Droid is usable without Playstore (you've been told this before). Even someone who buys a phone that excludes Playstore (and therefore not licensed to have Playstore) can use F-Droid. Users do not need to "root their device to remove all Google apps or install an ungoogled ROM" to get that benefit.
You keep recycling defeated arguments without adding anything to the discussion. Go back and re-read my response to that.
Moreover, Android users who do not have Playstore have access to zero apps in the Playstore repository. F-Droid caters for users who prefer quality and security over quantity, and this value choice is more aligned with PTIO users.
Rightly so. We don't have the time to read again recycled defeated claims. You're wasting a lot of other people's energy when you restate something that was already defeated without addressing the elements that countered the claim.
https://updates.signal.org/android/Signal-website-release-4.35.3.apk
Just added 1.vii:
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.
Consider the pre-Microsoft days of LinkedIn which did not require phone registration. Those users were grandfathered. They cling to their accounts because they lucked out and escaped that particular privacy abuse. But what many fail to realize is that the mere existence of their account serves as bait for exploiting the privacy of prospective new members who want to reach out to old friends. If Alice wants to get back in touch with Bob, she may be forced to get a phone number and then supply it to Microsoft, who then exploits this effect. So the proper ethical move is to stop being the pawn that gives them power and close the account even if it's grandfathered.
W.r.t. Open Whisper Systems, they refuse to cooperate with a federated network while at the same time forcing phone registration. Those two issues paired together creates the
1.viiviral privacy abuse issue.hey guys, i just read this article:
but i've never used keybase, so what are your opinion about that project and app?
Has it been wetted?
https://github.com/privacytoolsIO/privacytools.io/issues/740#issuecomment-460076395
I've also noticed that Keybase holds meetings and seminars on CloudFlare property. It might be interesting to know if that relationship extends beyond sharing meeting rooms.
The keybase discussion isn't relevant to this issue.
On Thu., 28 Mar. 2019, 07:58 libBletchley, notifications@github.com wrote:
Wire project is open to the idea of federating and even offering XMPP interoperability:
While the problems raised here are valid and certainly concerning, shorley the main signal developers should be given a chance to address these concerns.
@zero77
If you dig into the history of bug reports and forums for Signal, some of these issues have a long history and OWS would not budge on any of them given copious public pressure. And the list is huge. So delaying the correction on PTIO only does harm, as users are getting bad guidance every day that Signal gets the unmerited endorsement.
In the unlikely case that OWS makes a miraculous 180 degree turn, PTIO can always endorse them again.
@libBletchley
I cannot comment on all of the issues you raised but, yes, the use of a phone number has been brought up countless times with no progress.
Although, i am yet to see an up to date explanation as to why OWS haven't progressed with these issues shorley, they should at least be given the opportunity to provide one.
Signal can use Google reCAPTCHA on users registering on Signal:
02b0800b22thanks for the tip @zexi3453. I've added section 2.iii to highlight some of the problems with Google's reCAPTCHA. This change means Signal is no longer free software because users must trust and execute non-free j/s. IMO Signal should be removed from the fsf directory.
This is true, the complaint has been raised countless times, and it is also true, that changing to inscrutable cryptohashes as identifiers, or changing to spammer-heaven emails as identifiers, or whatever, has never happened. But that is because those are the Wrong Approaches if you want a dead-simple messenger aimed at the masses, that will NOT become overrun with spam as it gets increasingly popular.
This is a hard problem in other words. Pointing out that phone-nums can be a privacy-risk, is not a "solution" it is just a complaint. An actual honest-to-gosh solution, would have no downsides in terms of usability, nor in terms of spam-resistance, nor ideally in terms of hijack-resistance either. Signalapp's reliance on phone-nums is a compromise, with tradeoffs firmly in mind.
The recent addition of the reCaptcha thing is, reading the tea-leaves, also directly related to spam prevention (or maybe to draconian governments that have nationalized the telco-system and are doing DoS against signalapp by pre-emptively registering all phone-nums in country-code +NN to deny their citizens that capability). It only applies to a limited subset of registrations, and I've never even heard of anybody seeing it. More details here, https://community.signalusers.org/t/use-something-else-instead-of-google-recaptcha-for-registration/6289
As for the merit of the overall complaint...
If you cannot deal with those pragmatic design-decisions, either because of ethical allergies to Ma Bell or The Goog or the Empire of Bezos, or possibly because you are up against nation-state level adversaries capable of bribing AWS sysadmins or pwn'ing google backend datasets, then absolutely you should not be using signalapp -- or any consumer electronics AT ALL. None of those devices will save you from the NSA rootkit'ing your handset, and similarly, none of those devices will only connect to backend systems with zero taint of large corporations anywheres.
But the goal of privacyToolsIO seems to be educating people about how to incrementally improve their privacy, which means it does not say "you have to buy Librem5 and you have to run Qubes on OpenBSD and you have to hand-manage your own air-gapped offline keypair generation system" or anything like that. Instead it recommends stuff that installs on common laptop OSes + apps that install on common smartphones the usual way + services that work with normal enduser-devices on the normal corporate-run internet.
Signalapp is therefore an extremely good fit for the privacyToolsIO goals, because it works on common consumer laptops & phones via the typical internet infrastructure.
Unlike the demand to remove signalapp entirely from https://www.privacytools.io/software/voip/ and also from https://www.privacytools.io/software/im/
...the suggestion that one or both of those places should link to https://signal.org/android/apk/#target in addition to the more usual https://signal.org/download URL, might have merit? It depends on what the maintainers of the privacyToolsIO listings think is wise for the audience they serve.
[LaterEdit: I was confused, looks like the direct link to the APK is mentioned in the voip and in the im listings -- "Advanced users with special needs can download the Signal APK directly. Most users should not do this under normal circumstances" -- starting from sometime back in 2017 according to archive.org copies of privacyToolsIO, but down in the 'RelatedInfo' portion rather than in the more prominent click-here-we-recommend-signalapp portion. So the suggestion that it BE listed, is already implemented. There is still a valid discussion about whether to hyperlink to https://signal.org/android/apk#target rather than to the top of the page which encourages playStore, and an orthogonal discussion about whether to mention the APK-direct-download in the green-highlighted portion versus where it is presently in the IsRelated portion.]
However, do note that the https://signal.org/android/apk/#target is only for android-smartphones, to install signal4ios requires use of iTunes (there is no easy way to sideload on iDevices short of tricksy jailbreaking is my understanding).
So, for people with iPhones and people wanting signal4desktop, I recommend leaving the normal signal.org/download (or the signal.org/install quicklink perhaps) visible. The hard decision would be, whether to link to the direct-download APK, and if so, whether to have it mentioned first and prominently, or mentioned second and peripherally. I would lean towards the former arrangement, signalDotOrgAPK listed first and prominently, and the link which goes to playStore + iTunes + DEB repo + windows + osx, listed second.
Alternatively-alternatively, the privacyToolsIO link could be the no-javascript-required one which goes direct to a versioned APK, per https://github.com/privacytoolsIO/privacytools.io/issues/779#issuecomment-475846949 , but that approach would require regular updating as new APKs were released so it would be a bit more legwork for the website-maintainers (I believe new APKs are pushed every month or thereabouts)
p.s. Thanks for the great website. I will continue to recommend people that are serious about their privacy, look through the privacyToolsIO listings, as their first place to begin. I don't wholeheartedly recommend people just blindly install ALL the tools listed by privacyToolsIO, because I don't think that is the point. The point is to consider these tools, and then select which ones best match the enduser's individualized circumstances. Most of those folks will want signalapp, and the privacy-oriented things it has to offer, so it would be a shame to de-list it
spam avoidance is solved without privacy abuse
It's only a hard problem for email and public broadcast services like blogs and forums. In the context of a centralized IM/voice service offered by a corporate supplier it's a problem in terms of maximizing profit. Privacy-respecting competitors like Jami and Wire don't have a spam problem, and yet they've not forced users to make such unacceptable compromises to privacy. OWS and Telegram are focused on easy spam-control on their end to the extent that they've required users to give up on privacy.
trading privacy for spam avoidance would be a bad trade
This discussion is hypothetical. Apart from the fact that we don't need to trade privacy for spam avoidance in this case, in the hypothetical case where the values are at odds PTIO users favor privacy. The trade-off may be okay for those with a great intolerance for spam but wholly unacceptable for those who hold privacy above spam avoidance.
I would gladly accept the risk of occasionally accidentally accepting an invite from a spammer who then needs to be blocked in order to not have to buy a phone, buy phone service registered to a national id, disclose of the number, and then become subject to ~4-5 new walled-gardens that finance half a dozen privacy abusing corporations:
It's a lousy and needless trade. We don't have to give up privacy to avoid spam and even if we did PTIO goals are clear:
"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."
Note that spam avoidance is not included in that mission objective. The trade-off you're advocating undermines PTIO goals.
It's a complaint that is specific to Signal and Telegram which competing systems avoid. The competing systems demonstrate solutions.
CAPTCHA
The first mistake is to use Google's reCAPTCHA, the most intrusive and detrimental of all varieties of CAPTCHA. It reflects yet another flippant decision by OWS to support adversaries of the privacytools.io community who come here precisely to avoid those walled-gardens. The next mistake is to subject users to non-free software while rendering the possibility of text-based tools useless.
It's a very poor choice for privacyToolsIO users because competing systems have more platform diversity (no network protectionism coupled w/hostility toward 3rd party devs) without the privacy abuses.
obtaining Signal
These issues have been laid out and indeed there is no suitable option for obtaining Signal because the least privacy-abusive option still exposes users to privacy issues and is likely outside the scope of PTIO audience expertise anyway.
Does PTIO have to monitor the Signal project and edit the version with every release? Signal has proven to be such a poor choice it doesn't merit that kind of effort, which also brings the shortcoming of a much more complex statement of endorsement.
endorsement
The effect of the de-listing steers users clear of a bad option and guides them to privacy-focused options. They're likely already aware of Signal due to its unmerited popularity. PTIO has a duty to correct that and spotlight tools that are aligned with PTIO values.
I'm not sure how I feel about this so I'm just going to respond to as many points as I feel qualified to answer with my own opinion.
The reason I have a hard time agreeing that we should stop recommending Signal is because they do an excellent job at keeping your messages private, which is a very important thing to many people. Privacy is not necessarily anonymity and not recommending tools because they don't keep you completely anonymous online is gatekeeping, and it might not even be a concern for some people. This is why I think identifying threat models (https://github.com/privacytoolsIO/guides.privacytools.io/issues/5) is something we need to really focus on getting users to understand. That could even tie into #729: documenting shortcomings along with benefits of each platform. These two things are important considerations but IMO they are not dealbreakers if you're looking for ultra-secure communication and anonymity isn't a factor for you.
I also think we might be missing the point that Signal is largely an SMS replacement. People are more than happy to give out their phone numbers for SMS, but SMS isn't encrypted at all. If people want to keep the contents of their messages private, shouldn't the use of Signal be encouraged? I even think on Android you can use the Signal app as your SMS app as well, so Signal is becoming more of an open-source iMessage alternative (from a security perspective at least) than anything else, which I think is a good thing.
This is true, and we should probably link to the APK page by default. We could even link to
https://signal.org/android/apk/#apk-dangerso it scrolls you down automatically.This is true, but as long as the code is open, which theirs is, it doesn't seem like an issue to me. Wire does the same thing for example.
This is probably the main issue I have. There are no good alternatives to mobile messaging at the moment. Signal covers a different use-case than these other options.
This needs to happen, I feel like a lot of removal or addition requests could be easily closed if we had a clear set of requirements we want from our recommendations.
There are definitely some cons against Signal, and I think those should be clearly listed. But that would require a complete change of essentially all of our pages the way #729 suggests so this isn't some small undertaking. I don't however, think that these issues should result in the removal of the software from the site, as it does a very fine job at
With respect, @libBletchley -- since you clearly do have a strong grasp on the ins and outs of messenger-services and the compromises they make -- you definitely have no idea what you are talking about when it comes to spam in that sector.
Why spam is an existential risk to signal-network
I think the main problem is that you are using "competitors" loosely and including things like Jami aka cx.ring -- which has less than a thousand playStore reviews. Wireapp is MUCH better known, but very much still a niche-competitor at the moment, with 30k reviews on playStore, in roughly the same miniaturized-pony-competition class as wickr with 20k reviews and threema with 55k reviews. The userbase of those walled gardens is just too tiny, there is no network-effect, so of course there is no spam.
The few thousand people on Jami do not spam each other, of course, and real spammers are not messing with THAT small of a slice of humanity! Real spammers have SMTP and Facebook-pages and such, as targets. Should signalapp really succeed someday, and grow to a userbase of hundreds of millions or billions of daily-driver endusers, signalapp will be such a target, also. Signalapp has 300k reviews on playStore, and millions of endusers, putting it in a different category entirely -- it is not a "competitor" of Jami because they are not even in the same universe.
Jami is an alternative to signalapp, in some pedantic theoretical sense, but no, it is not a competitor. The competition is Whatsapp-by-Facebook, they get 300k playStore reviews every 8 hours when I last did the math. To a lesser degree (ten times bigger than signalapp but ten times smaller than whatsapp) it is also valid to see Telegram as a competitor. Definitely not Jami though.
Yes, yes, you have made clear that you have a burning desire to see signalapp de-listed, and replace it with Jami or whatever. I'm not here to convince you otherwise, you are beyond convincing :-) From your username it sounds like you are concerned GCHQ is likely to target you personally, and to me that means you absolutely should not use signalapp, nor anything else that runs on a smartphone, just stop using smartphones entirely. You cannot become 100% anonymous whilst using internet-connected hardware and the software it requires, if you believe that is possible, you are misinformed.
Yeah, I think I am starting to understand here. You don't like signalapp because it is non-federated, and because it uses AWS for webservers, and because it uses playStore for deployment. And you want it to be federated like Jami, and use only 100% certified organic free-range webservers, and stop being listed in playStore so F-Droid will become more popular, and stop using phone-nums because THAT will really stick it to Ma Bell and Jeff Bezos and Google and GCHQ and all those other surveillance-badguys.
What you fail to understand is that the reason signalapp has 300k playStore reviews and Jami has a tiny fraction thereof, is because signalapp made some very hard tradeoffs. It runs on normal androids (not just OpenBSD), it is found in the normal appstore (not just F-Droid), it is hosted on the regular internet (not just as a hidden Tor service), and they tried federation (with LineageOS-fka-CyanogenMod folks) and it slowed down development so much they stopped trying after a couple dozen months. What other actual-competitors have those same tradeoffs? Whatsapp, mostly-telegram, partly-skype... all of which have LARGE userbases!
Are there any end2end encrypted, widely federated, never-touches-Amazon, never-touches-Google, never-touches-telcos messengers? Sure, but how many of them have hundreds of millions of endusers? Zero. Why? Because likely, it cannot be done. Signalapp is competing with WhatsInstaBookMsgrApp, not with Jami. Signalapp's reputation is hard-won and well-deserved. You don't like the design decisions that made signalapp popular and well-vetted, because you have special ethical constraints you apply, or because you have extremely-maximized anonymity requirement that is a dealbreaker for you? Well, okay, don't use it then. But don't try to push your threat-model on everyone else.
What you are advocating is that signalapp stop connecting to any Amazon servers, stop connecting to any google servers ... yet keep running on android which is a google-controlled codebase! ... and stop utilizing anything like a telephone-number. If you need that, REALLY need that, because you are up against adversaries with sufficient power to subpoena records and gag-order the sysadmins of major billion-dollar multinationals, then yup, signalapp is not for you, and neither is any other software. Go full-on old-skool, and fallback on one-time-pads, dead-drops, whispered face-to-ear conversations, and maybe magical amulets.
But you are mostly just here to advocate replacing signalapp with less-well-vetted products that don't offer the same feature-sets nor the same level of reliability/vetting. There are billions of people using the officially-branded Signal Protocol, and signalapp itself is recommended by top-notch cryptographers. I don't see any cryptographers mentioned on the Jami homepage, or any endorsements at all. Who recommends Jami itself specifically, besides yourself? For that matter, what cryptographers recommend wireapp?
Because of the extremely careful server-side metadata-resistance, if signalapp does not PREVENT spam from happening -- not "avoid" spam and not "detect" spam and not "mitigate" spamming but flat out prevent spammers from ever getting a foothold -- then it will be fatal for the entire signal-network. Average endusers will not stand for spam, if there is any significant amount of spam, these average endusers will demand a serious anti-spam solution. Guess who will happily step in to provide that solution, by offering to upload all plaintext message-bodies and associated metadata into the cloud, so it can be scanned and analyzed with best-in-class anti-spam algorithms?
The gmail people, who "happen" to be the same people that control the OS-autoupdates on 99% of android handsets worldwide. If signalapp develops a spam-problem, Google can take the whole Signal Foundation down, and endusers will not be that mad because they will do almost anything to not be spammed. Proof? Look at the market-penetration of gmail, if you don't believe me. Endusers will give up privacy in a heartbeat. The only solution here is for signalapp never to develop a serious spam-problem. Hence, moving away from the phone-num system to the email-based system, in a naive fashion, would be the death-knell of signalapp.
I want properly-anonymized signal-identifiers so bad I can taste it, but no, it is not an easy-peasy-simple-pimple problem, and no, just because you don't see much spam on wireapp with a tenth the userbase or on Jami with a hundredth of the userbase, does not mean ANYTHING. Actual competitors to signalapp, with LARGE userbases where spam can take root, can scan for spammers server-side: whatsapp keeps all metadata (phone-number-based) non-end2end-encrypted, wireapp does the same, telegram does the same plus also stores 90% of the message-bodies server-side, skype is much like that. Even matrixOrg/riotIM store a huge amount of stuff server-side, unless you run your own Synapse homeserver (in which case the storage is server-side but you can control who secures that data-trove).
Signalapp is unique amongst the major messengers, because it is 100% GPLv3/AGPLv3 and it tries very hard to minimize server-side metadata. None of the others do, and by others, I mean actual competitors with similar scale-in-userbase, not niche products. This uniqueness of signalapp has a huge downside: signalapp cannot stop spam server-side, which means, spam has to be prevented from ever getting started. The main thorn in the side of signalapp being discussed here, is the reliance upon phone-nums... which are hard to truly anonymize, and most people do not.
But to lessen that reliance is not simple, we HAVE to make sure the spam-prevention is rock-solid, first, because if spammers even get a toehold, that will quickly become an existential threat to signal-network, all endusers not just those being spammed, because Google will be able to convince signalapp endusers to pwn their own endpoints (voluntarily!).
And less imperative, but just as fatal to the long-term success of signal-network as a mass deployment daily-driver messenger suited to thwarting mass surveillance someday, is usability: phone-nums are "more usable" and the everyday Dave-from-Denmark will absolutely positively be unsatisfied with “ricochet:5092ef327373” or whatnot.
Yes, correct. It is an important consideration, but strongly depends on your threat-model as to whether it is a dealbreaker-consideration. If you are up against GCHQ and the NSA, then anonymity is probably not even a plausible GOAL when using consumer electronics.
Correct, and this SMS-integration is on by default. I turn it off, because I prefer to keep my unencrypted chats firmly compartmentalized away from my encrypted conversations (lest I inadvertently "cross the streams"). Plenty of people install signal4android as this-is-a-better-SMS-app-than-the-stock-SMS-app, however, is my understanding.
Well, kind of... only on signal4android though, because Apple purposely locks down the SMS/MMS features of their iDevices so that only iMessage can access that stuff! :-) Vendor lock-in at its finest methinks. So although signal4android handles SMS/MMS fallback... and unlike iMessage if memory serves, signalapp encrypts those unencrypted-in-transit messages once they are sent-or-received, rather than storing them on the filesystem in the clear... signal4ios cannot truly be an iMessage alternative, because Apple does not allow anything to be an iMessage alternative, on iDevices at least.
Also correct -- signalapp is not really a competitor to RiotIM+Synapse, because one is aimed at being the banquet and one is aimed at being the barbeque, as the Librem5 folks discovered when they tried to make the Fractal variant of RiotIM into a signalapp-equivalent. To my way of thinking RiotIM+Synapse and signalapp+signalServer are complementary technologies, rather than competitors, in much the way that I don't see protonmail and tutanota as "competitors" to signalapp (nor to matrixOrg) -- encrypted webmail solutions are complementary, once again. Protonmail competes with gmail, RiotIM+Synapse competes with slack+skype4biz, and signalapp competes with whatsapp+skype4home.
payload privacy
We can neglect payload privacy because all the competing systems offer this. No payload-disclosing exploits exist on any of the competing platforms (Jami, Telegram, Wire, Tox, Riot.im, Omemo, and Ricochet). The differences between these systems is privacy of the metadata, walled-gardens, and privacy abusing partners.
anonymity
Anonymity is privacy. Specifically, it's privacy of identity. And it's sensitive. It's not okay to expose who is talking to who.
The abuses we're talking about also go well beyond anonymity. Forcing someone to enter the marketplace and buy a phone harms privacy in a number of ways. Even if the purchase is offline, with cash, in a shop without CCTV, most phone makers are lobbying against privacy and many abuse users' privacy through spyware and configuration limitations. So privacy-focused consumers are being forced by OWS to spend their money in a way that is counter to their own privacy interest.
Even the most privacy respecting phone is inherently compromised by conforming to GSM/CDMA specs. And the privacy compromise I've described so far is before we even start talking about phone service, the Signal install process, and the Signal reg. process.
documenting shortcomings
The number of Signal shortcomings and pitfalls more than fills a screen. PTIO would have to spotlight an embarrassingly high number of anti-features on their endorsement, or hide these from the user.
Signal as an SMS replacement
It fails as an SMS replacement because it relies on phone registration. It's not a replacement, it's a supplement. Competing systems do entirely replace SMS because they don't require phone reg.
software freedom and network protectionism
This has been tested. Someone produced a 3rd party app and OWS refused to allow that app on their network. So the software freedom does not exist with OWS Signal. So you're apparently proposing a lower standard -- open source instead of free software. The problem with open source is that the creator still wields all the power and control. Like Facebook they can do what they want after acquiring the power of mass acceptance and resistance is futile.
I've not heard of any cases of Wire bullying 3rd party authors. AFAIK, Wire s/w is truly free s/w. Is there an article to the contrary?
alternatives
You can easily say nothing is good because everything has shortcomings, but nothing is as broken and reckless as Signal with respect to privacy. Jami and Wire are both better options.
TLDR... tap for details... but in short, wireapp is centralized aka non-federated, has a poor track-record related to licensing&trademark disputes, is not sufficiently vetted in terms of crypto, is absolutely awful but not quite DANGEROUS when it comes to metadata-resistance, and (yes this part is good) has libre-licensed server-code
The quote about "wire does the same thing" was referring to "wire is a centralized service". Just like signalapp. And this helps explain why wireapp has more playStore reviews than decentralized Jami: because with network-effect messaging apps, centralized services can add features faster, develop complicated upgrades faster, and so on.
If you want information about Wireapp's corporate ethics, you can dig up their lawsuit against Moxie, when the wireapp folks decided to use Signal Protocol within wireapp... and then suddenly wireapp's encryption was renamed as "Proteus Protocol".
Again, if one platform has millions and the other has thousands, they are not "competitors" in any realworld sense. How many cryptographers have vetted, and then publicly endorsed, Proteus protocol? How many endusers are using Proteus protocol in practice, every day? With crypto, popularity is the ONLY sure way to see whether the codebase has security-holes. I invented my own crypto system just now: it has zero published exploits, just like Jami's crypto-implementation. But I guarantee you that lack of any CVEs, is not because my home-brew crypto is ACTUALLY secure: only realworld vetting gives evidence of THAT. Absence of evidence, is not evidence of absence.
You think wireapp has better metadata-resistance than signalapp? https://en.wikipedia.org/wiki/Wire_(software)#Metadata versus https://en.wikipedia.org/wiki/Signal_(software)#Metadata seems like night versus day, to me. Wireapp has roughly the same metadata-storage as Whatsapp (and considerably worse than RiotIM+Synapse as long as you run your own homeserver), though Wireapp sysadmins do not have the same inherent motive to abuse such data as Facebook does. https://en.wikipedia.org/wiki/Reception_and_criticism_of_WhatsApp_security_and_privacy_features
The codebase of wireapp is libre, correct, that is my understanding as well. So at least we don't disagree about everything under the sun ;-)
You seem to misunderstand the meaning of the four freedoms.
This is wrong. GPLv3 gives you the freedom to run the codebase, for any purpose. It does not give you the “freedom” to demand that the people who gave you that GPLv3 codebase, and thereby gave you the liberty to run the code for any purpose, must supply YOU with free-as-in-beer server bandwidth FOREVER. No, that is a gigantic misinterpretation of what freedom is. Here are the four freedoms == https://en.wikipedia.org/wiki/Free_software#Definition
Popularity as a basis for judgment has been tried and it failed.
Yes, I know that the spam game changes as the scale of the system changes. PTIO is not here to give sympathy to large scale projects that have bigger problems. It's making a recommendation for the best tool today given today's systems. If a small system grows to be large and one day begins to abuse users' privacy in attempt to manage the growth, PTIO can and should revise the endorsement accordingly.
free software delisting
Actually that was the first time I mentioned delisting Signal from the FSF Directory, which is a different list than the PTIO list, with a different objective.
This is a straw man. I never advocated for the impossible. I've always advocated for the lesser of relative evils and the best tool for the job given the mission statement of PTIO.
I've listed the problems that shows Signal to be a poor choice. All this emotional bending you're trying to do here is irrelevant. The Playstore problems are about playstore, not F-Droid. F-Droid just happens to be a superior distribution mechanism that Jami uses. I might actually prefer to see a new repo emerge that rivals F-Droid. The bottom line is that OWS has made poor choices and there are better options on the table.
another band-wagon
Is this another band-wagon attempt? I see nothing in the mission statement of PTIO that implies large projects need sympathy points. PTIO is making decisions w.r.t. privacy a single user benefits from. If a large management burden causes privacy to be tossed out, PTIO cares about the privacy loss not the management problem that caused it.
the "I found an imperfection so let's disregard all security" paradigm
You're trying that broken security logic that says "because some aspect of a security system has an imperfection, we therefore must abandon the whole system". Amateurs and journalists take that stance but it is naïve. That was tried when PGP had some recent vulnerabilities in some mail clients which caused a ridiculous overreaction similar to yours. Obviously it's sensible to avoid vulnerabilities to the extent practical. Trading a system with imperfections for something worse is a poor choice and it's not what PTIO should advocate.
I personally use a desktop for IM/voice, so I'm quite removed from google. I need to talk to those who use iphones and androids, so platform diversity is a sensible compromise. But there's no reason to force users to share information with and financially support Amazon and Google. Some users will choose to share with google but there's a problem with endorsing a tool that does not liberate other users from google. A google fan should be able to talk to someone who entirely opts out of privacy abuses. OWS uses network protectionism which blocks users who prefer to be liberated from privacy abusers from connecting with others.
mass surveillance =/= targeted surveillance
You're conflating mass surveillance with targeted surveillance. The PTIO mission is to avoid mass surveillance, and it's mass surveillance that phone networks support.
Again, the PTIO threat model is mass surveillance. You can see from this post that it's mass surveillance that's in my threat model, while OWS Signal is subjecting users to mass surveillance in a naïve attempt at avoiding targeted surveillance.
privacy trumps spam avoidance
That is their decision to make. When PTIO gives up privacy, it's a disservice. Users can do what they want but PTIO's duty is to endorse privacy-respecting tools regardless of whether a user wants privacy or not.
4 software freedoms
I know the 4 freedoms quite well. You seem not to, as 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. OWS is a good example of how the free software label can be abused for marketing purposes without actually empowering the users.
It's not wrong. Everything in that quote was accurately stated. For some reason you interpreted what I said as being non-compliant with the freedoms, but I never claimed a GPL violation in the part that you quoted. Go back and re-read what you replied to.
You can also license a work as free software (GPLv3) but then never distribute it. While it is technically free software, it fails to empower the public.
I do indeed claim non-free software elsewhere, however, because the Google reCAPTCHA is implemented with non-free javascript that Signal forces users to execute.
Wire metadata
I'm familiar with Wire's metadata leak, just as I am with OWS tracking the identities of each user. Wire users can be anonymously associated while OWS users are not anonymous in the first place and associated within OWS even if the OWS data is not disclosed as plaintext. Given the huge list of privacy abuses, Signal is far less aligned with PTIO's mission statement than Wire overall. Jami is more aligned with PTIO's mission than both Signal and Wire.
"Popularity" is necessary for proper crypto, because only projects that have enough popularity get security audits. Projects that are unpopular amongst serious cryptographers -- whether that unpopularity is "merited" or just bad luck -- are NOT WELL VETTED. Apologies for the shouting, but it seems needful.
You are flat out saying, with no varnish and no nuance whatsoever, that "all these alternatives to signalapp -- none of which use Signal(TM) Protocol -- are just as good at payload privacy" aka have the same quality of crypto. That is utter nonsense. I think you know it is nonsense, you obviously know a lot about messengers, and care a lot about privacy. Cryptosystems must be vetted, and that only begins with the server-side codebase being libre when we are talking messengers.
additional points:
I was accusing YOU of doing that, actually :-) See next two points
If you want domain-fronting, how else do you suggest it be accomplished? Of course, that has worked out less well than could be hoped. https://signal.org/blog/looking-back-on-the-front But even if you don't care about people in draconian countries with nationalized telco systems in the short term, how do you plan to thwart mass surveillance in the long run, if you don't let the masses download from the most popular appstore onto the most popular smartphone platform??
Google runs both those things, and as you have pointed out, google is in deep. But as several others, not just moi, have pointed out to you: F-Droid is not a "solution" to the playStore because you are still running on android and it still phones home to google, unless you REALLY rip out the innards and install a hyper-specialized max-privacy-no-matter-the-loss-of-convenience heavily customized ROM (i.e. not the privacyToolsIO target-audience).
Then what are you doing comparing them to signalapp favorably? Apparently we are talking past each other, but in a lot of the fundamentals we seem to agree. Just, not in how to apply those fundamentals, when it comes to picking winners&losers on the privacyToolsIO listings!
I cannot even fathom how you came to this understanding :-) The whole point of signalapp is to eventually thwart mass surveillance, of the masses, which means becoming popular and ubiquitous. Hence, the compromise to be in playStore, because that is where the masses get their apps nowadays. Hence, the compromise to use phone-nums, because that improves usability (which masses require or they use Something Else), plus acts as a strong proven-in-practice check on spam with billion-enduser messengers.
You think Snowden is endorsing signalapp, because he was hoodwinked? Or because he truly believes Signal Foundation is in favor of mass surveillance, rather than the nemesis of the mass surveillance apparatus? I am at a loss for words. Signalapp has never been about preventing TAO, it is impossible for a mere app to even do that, end2end crypto is utterly useless if the endpoint-devices are compromised! I just, this is so backwards of an understanding of what signalapp is doing, it is hard to know where to begin.
Um, yes. We agree on something again ;-) But you have a very odd definition of 'privacy', of the word 'respecting', and maybe also of 'tools' methinks (our disagreement about what industry we are even discussing and who is versus who is not competitive therein). Yeah, I agree that privacy is crucial, and that surveillance-even-to-beat-spammers is unacceptable. But as other have pointed out, you strongly equate privacy with modicum-of-anonymity, 100% anonymity being nigh-impossible, when anonymity is only a portion of privacy broadly construed. Moreover, depending on one's individualized threat-model, what matters is normally who can de-anonymize you.
(NSA? Facebook? Verizon? local cops? head of the municipal political party? sysadmin at the local ISP? corporate competitor? border guards? mall cops? nosy neighbor? unfriendly coworker? these are very different threats and dealt with using very different tactics.)
You also seemingly equate "privacy" with "does not run on any servers owned by corporations that do not share my values" which is getting pretty far away from PRIVACY of what is communicated (encrypted payload) and with whom (metadata payload). You recommend wireapp, yet they have awful metadata-handling, and poorly-vetted crypto. You want signalapp delisted from the FSF, delisted from privacyToolsIO, and so on -- despite the best-in-class metadata-resistance and the best-on-the-planet crypto-vetting.
Are there "better" messengers if you cannot stomach a phone-num as identifier? Yes, to some degree... on paper... but only if you are willing to lose the crypto-vetting advantages and the usability advantages: with messengers, what matters is who you can message, more than anything else. Bob Metcalfe from the 1970s, this is ancient knowledge.
Emphasis added. But like I said above: what matters, is WHO you can message, i.e. "popularity" of the messenger. Even for yourself that is a primary consideration. And why you are here trying to get signalapp delisted, since it does not satisfy you, and get Jami listed, since it does satisfy you. I think the keyword there, in your demand above, is "should" ...as in, you believe any messaging system ought to be designed with your desires and circumstances in mind.
The GPL was specifically written to benefit everybody, all of humanity, including people you dislike ethically. But the GPL was very specifically written not to put burden on the person-or-corporation that was releasing the GPL'd codebase: "AS-IS" means no liability. GPL is friendly to corporations, and to commercialization. https://en.wikipedia.org/wiki/GNU_General_Public_License#Terms_and_conditions
Yes, that was my interpretation. When you say, in effect, "oh we want to use your GPL'd signal4android but only if YOU pay for the server bandwidth on signal4server nodes so WE can chat with our hardforks" then yeah, you have lost sight of the big picture, to me.
Freedom to use/study/modify/redistribute, nowhere at any point has ever included "freedom" to force the original author of the codebase to host a server for you. Run your own server if you like, the codebase is AGPLv3, but don't demand somebody pay your hosting fees, that is not what free-as-in-freedom is all about. If that is not what you are saying, then accept my apologies, I will re-read... but you seem pretty clearly to be saying, exactly that.
They have a google tracker. And you know they have a google tracker. Same as wireapp, which has the same google tracker, as I noted immediately above, so you know that as well. Maybe those projects are just "accidentally" including the Google Firebase Analytics module... it is quite difficult to kick out, you have to manually exclude the analytics-stuff. Which signalapp has done, but Jami and Wireapp as yet have not. Signalapp inadvertently included the tracker -- albeit disabled and not actually active -- in the 4.33.5 release, but still, quickly corrected the mistake in time for the next stable-channel release.
This almost feels as if you're intentionally misinterpeting what I replied.
Anonymity is privacy yes, but privacy is not necessarily a key part of privacy to many people, it depends on your objectives. Like I said, different people have different threat models and pretending that everyone needs to conform to a very narrow form of "privacy" is ridiculous.
It again, depends on your privacy objectives. Like @five-c-d said, "It is an important consideration, but strongly depends on your threat-model as to whether it is a dealbreaker-consideration."
Many people including myself don't need complete anonymity online, but are pursuing better ways to keep their personal information such as instant messages private from third-parties, advertisers, and large corporations. Moving to Signal from an app like Google Hangouts for example would be a great move to many.
The issues you're outlining here have nothing to do with Signal as a product, but the fact that you need to own a mobile device to use it? By that criteria should we not make any recommendations for mobile device users? Should we not recommend people use NetGuard or Blokada on Android because the second they touch a phone all hope of privacy is lost?
This is just semantics. I didn't say it was the perfect SMS successor by any means, but many people use Signal, at least on Android, as a drop-in SMS replacement that requires essentially no additional configuration much like SMS doesn't. If your contact uses Signal and you do too, then you're encrypted. If your contact doesn't use Signal then it will fall back to the same SMS you would've used anyways if you didn't have Signal.
No, this isn't a good solution for sensitive communications, but for many consumers the convenience of this method outweighs the downside of having to use SMS with some encryption holdouts. Signal functioning in this method is a stepping stone between SMS and encrypted communications.
I was primarily commenting on the lack of federation, and I could have been more clear about that.
The other point you made does seem to fall short however. Yes, a third party client was developed and removed, but it was ostensibly removed because it had Signal in the name, and I have no reason to believe otherwise. Signal is presumably a trademark of OWS and depending on jurisdiction they may have had to enforce that in order to retain their trademark, but I can't really comment on that or know for sure. Has some third party client been taken down that doesn't use Signal in the name?
Them taking LibreSignal down would be the same as if someone developed a version of Firefox without Pocket or whatever weird things Mozilla is now including, and calling it Firefox 2.0. Of course Mozilla would take that project down. Trademark enforcement has nothing to do with FOSS.
I was pointing out that Wire is also not federated, and is in fact a completely closed communication system that is controlled by the Wire developers. Never was I commenting on third-party clients.
Yes I know, it was a straw man, and the straw man was compelled by your use of that broken logic (apart from the straw man also being broken logic).
The absurd "playstore is necessary for /avoiding/ mass surveillance" claim
It's the other way around. It's pushing users to a single large centralized repository that makes it easy for repressive governments to compromise the distribution. Big players like Yahoo, Google, Microsoft, Apple all have big business in every country and can and will dance to maximize profits.
You also fail seem to be unaware of PRISM, and how the relationship between fortune 500 companies and the US government operate. When Playstore data is centrally located along with a shit ton of other data on a person, it's a mass surveillance wet dream because it's trivial and convenient in many ways for the government to get the data outside of the legal system.
The "F-Droid doesn't entirely avoid all of Google, so throw it out" claim
Google is an adversary of privacy who collects and exploits data in large variety of ways. To say that you might as well give Google everything because there is some data sharing that is hard to stop is patently stupid. Even if we neglect the users who circumvent phoning home, the phoning home does not collect all the same data that Playstore does. And even if it were to hypothetically, it would still be foolish to do that disclosure which would then nullify the value in circumventing the home phoning mechanism.
Are you infosec-handbook back with another userid? Read my replies - this has already been addressed and you've added nothing new.
Wire
That was already answered. To be brief, I'm not repeating myself. Reply to my answer if you want to advance on that point.
using mass surveillance to "thwart mass surveillance"
OWS would like you to think that, but obviously subjecting users to Google surveillance is a profoundly foolish way to "thwart mass surveillance".
Centralization in a corporate walled-garden is conducive to mass surveillance.
the "users are too stupid to handle usernames" argument
This is a profoundly absurd attempt to justify phone registration. I do not believe the PTIO audience is incapable of other ways of identifying users.
Snowden
Snowden as well as Bruce Schneier are competent but not infallible. I've seen bad advice come from
both of them. Your appeal to authority shows your desperation in your highly motivated loyalty to OWS. We can speculate all day about Snowden's endorsement that you can trust anything in general from OWS. Snowden's statement is not a specific endorsement of Signal and he did not compare Signal and choose a lesser of evils. We don't know the context of the statement, but the kind of statement he made is likely after being asked about OWS, and not framed in a way that asks him to compare a number of tools the way PTIO is. We don't know when the comment was made; maybe phone registration wasn't in force when he made the comment. Snowden probably didn't read moxie's responses to F-Droid requests either.
OWS trustworthiness
The claim that OWS is naturally trustworthy doesn't stand up to what we know from this thread. It's evident from OWS shenanigans to push users into Playstore while discouraging and hiding the APK download and the fact that OWS admitted that it was to obtain stats makes it clear they are not trustworthy. They are a corporation behaving like a typical corporation. Their refusal to federate is while at the same time requiring phone reg on their own network is another clear indicator that corporate greed is above what's best for user privacy.
TAO is Signal's excuse for subjecting users to mass surveillance
You're not in touch with the discussion. It's not me who claimed Signalapp prevents TAO or that it needs to. I've repeatedly stated this is about mass surveillance. When you claimed this before, I referred you to https://github.com/privacytoolsIO/privacytools.io/issues/779#issuecomment-471975275. Please read that so you can stop recycling this claim. It's OWS who uses TAO-avoidance as an excuse to downplay the APK download, while subjecting users of the mass surveillance of Playstore.
avoiding phone reg. is not for "modicum-of-anonymity"
Phone registration abuses privacy in copious many ways. To suggest that avoiding phone registration only gives you "modicum-of-anonymity" indicates how far you are from understanding the privacy of it. I cannot deliver a whole book of knowledge to you in this thread.
return of the "disregard security because there's an imperfection" argument
This is that broken argument that if you cannot have absolute security then don't even bother. It's absurd. I shouldn't have to address this.
The threat model is mass surveillance, so what matters is not how anonymity from targeted attack. If you do the phone reg. process, you've tossed any possibility of anonymity out the window and failed to mitigate mass surveillance.
the "we should support corporate privacy abusers" attempt
Supporting a corporate privacy abuser inherently supports mass surveillance. It's directly contrary to the PTIO mission.
Popularity is not a privacy feature
No, popularity does not matter in the context of the PTIO mission. Go re-read the mission statement. PTIO aside, as far as what matters to individual users, it matters if they can reach their contacts, not necessarily the whole world or a popular majority thereof. Just their own contacts need to be reachable. It's not PTIO's mission to get everyone on the same platform; it's to point out the tool that minimizes mass surveillance. Signal is not that tool.
the "give up on avoiding adversaries because they're everywhere" argument
It's a red herring. Please don't clusterfuck this thread with such nonsense. There are both ethical and unethical ISPs. If you follow the supply chain of the ethical ones, it often leads to an unethical one. I personally ensure that I don't needlessly feed unethical suppliers. That means I will not needlessly buy a phone or service from an unethical supplier. OWS creates the need for consumers to support privacy abusers.
the "I can't avoid Amazon completely so I might as well go whole-hog" argument
This is more of the same poor reasoning, where you suggest it's okay to needlessly support privacy abuse in one context because supporting the same bad actor is inevitable in another context involving different information.
network protectionism
The difference here is that I'm advocating for the users, and you're advocating for a single corporation. OWS blocked a tool that gave users more freedom and privacy. In the unrelated case of Wireapp suing Moxie, you'd have to say more to actually make a down-to-earth case for how this relates to PTIO's endorsement for their users.
Freedom and platform diversity
Not exactly. You're wasting time with irrelevant claims, but briefly I'll say there is value to having the freedom to modify code and redistribute it in part so that platforms can gain support without OWS control. The network protectionism ruins that.
This is a straw man. The rationale for acceptance into official Debian repos is quality assurance, which has a very indirect privacy influence. Official Debian packages are entirely supplemental to the upstream repositories and users have choice. The QA benefit was worth mentioning in the OP but like a lot of your comments it's not worth the energy you're putting into it.
GPL purpose
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, and an effort to do so risks creating unwanted side-effects. FSF takes a live and let live stance that assumes most GPL developers are inherently good and won't game the system (and rightly so). When an owner of a work goes out of their way to legally undermine people from actually making practical use of the freedoms we can highlight that and move on. It's not legally actionable but it's morally condemnable.
network protectionism - the "LibreSignal creates more burden than Signal" claim
Actually the big picture is lost on your part. When a user has a choice between Signal and LibreSignal their network consumption is the same either way. OWS has a right to control their network and bully users of it, but to claim their network is in some way more burdened by someone connecting with LibreSignal than by that same user's use of Signal is unsubstantiated.
This is more of the corporate PR BS spin we've already seen from OWS. It'll work in court but it doesn't fool the public. This does not obviate the point above, and also misses the fact that OWS actually refuses to connect to another network to allow users of other implementations to host their own server and actually communicate with others.
Firebase
If you've already read my comment, then why are you making an already defeated point? I've already done the exodus analysis on the F-Droid distributed version of Jami and the Firebase tracker isn't there.
importance of anonymity
The threat model is mass surveillance, which obviously makes anonymity very relevant.
Actually it's disregarding anonymity that narrows the privacy focus. And it's more narrow than the objective to avoid mass surveillance.
There's no question that anonymity is a factor in the mass surveillance threat model. It's also wrong to say that some people can disregard it because such a stance neglects the deeper benefits of anonymity. E.g. someone may not care that they are identified if their payload is well secured. But if a bug or flaw were to expose the payload, anonymity suddenly becomes much more useful than such a user would have anticipated.
anonymity w.r.t. security in depth
The centerpiece of this discussion is the security in depth principle. It's a bad idea to rely on just one mechanism for protection. Redundancy is proper security. You are proposing needlessly throwing out anonymity when some users have a strict need for it and all other users still benefit from the security in depth of anonymity.
Another way to express this:
anonymity w.r.t. the principle of least privilege
The principle of least privilege is the idea that one should not by default give more privilege than necessary. Even if something is not apparently or superficially sensitive, it's backwards to expose it and look for justification to secure it. Competent security policies default to protecting access or information and only remove protection when there is reasonable justification for doing so. There is no reason for IM client users to share needlessly their identity with someone in the role of OWS, particularly when the information being asked does not necessarily exist.
When you give up anonymity the things you mention here are affected. Advertisers are very clever and have mastered exploiting metadata. It's not just the payload that is sensitive.
It's not good enough. It's replacing one walled-garden with five. We can do better.
forced use of another surveillance system matters
OWS Signal requires participation in a system of mass surveillance. Of course this is a factor. It's a show-stopping factor in light of systems that don't impose this.
A mobile device is not just a phone and users of one may or may not have a GSM chip in the device. Those that do have conceded to a lot of abuses but even for them sharing their phone number is still yet another needless abuse.
Of course not. You can see that kind of thinking throughout @five-c-d's posts. There is no way to use NetGuard without an Android, so it only helps to endorse it. But Signal is not limited to mobile devices which means the endorsement would be reckless to disregard the non-mobile use-cases in play, particularly when competing options have solved that problem.
SMS replacement
I didn't realize you were talking about the e2e crypto over SMS. That's indeed a good point. The problem now is that Signal is being endorsed as an instant messager. In that generalized category Signal is a privacy disaster. But if there were a specific SMS category, Signal may be a lesser of evils in that narrow context.
Perhaps it makes sense to endorse it purely as an SMS tool. But that would need to be carefully written because a lot of normies would mentally equate SMS with IM.
Signal trademark
The trademark is where OWS obtained legal power to bully. But it's not a trivial trademark case because the mark used was not simply "Signal", which means OWS would have to convince a court that unwitting users would actually confuse LibreSignal with an OWS product due to the substring "Signal". It also was not sufficient for the project to change the name. OWS strong-armed F-Droid into removing it because the app connected to the OWS network. Since a LibreSignal rebranding would still not withstand the network protectionism anyway, the project died.
For that analogy to be accurate the modified version would have to be "LibreFirefox", and Mozilla would have to convince a court that users would likely confuse LibreFirefox with Mozilla Firefox. BTW, there actually is a "Librefox". So in that case using an unmistakable "fox" with "libre" as a prefix is not an issue. OWS would have an uphill battle if LibreSignal did not have to also contend with network protectionism.
Trademark enforcement coupled with network protectionism is the legal force by which software freedom is curtailed.
Signal engages in network protectionism; Wire does not
Wire is centralized on AWS just like Signal, but the difference is that Wire is not using network protectionism to thwart development of 3rd party apps. Wire is even open to the idea of XMPP interoperability. So while federating is the best, centralization without network protectionism is still better than what OWS is doing.
For the unwary reader, who might believe "network protectionism" actually has some literal-definition-of-evil meaning, what @libBletchley is specifically complaining about is the trademarked term Signal, and the bandwidth-costs of the official Signal Server. Any trademark owner including Signal Foundation that wishes to avoid genericide must protect the mark (or lose it forever). Any non-profit entity that does not wish to become ThePirateBay must control who can stream how much multimedia through the server-bandwidth paid for by Signal Foundation.
Plus, as explained above, signal-network is extra-vulnerable to spammers because of the lack of server-side metadata -- contrast with wireapp and riotIM and whatsapp which scarf that up -- so letting ANY spammers gain a toehold inside signal-network is an existential risk. Such as would be guaranteed to happen if LibreSignal decided to allow anybody with an SMTP address to signup, and then blindly gateway'd the encrypted payloads to other signal-network endusers. https://lwn.net/Articles/687294/
No, the key(heh!) difference between wireapp and signalapp is that one has tenfold more field-vetting of the codebase, as well as -- to me more far more crucial -- roughly a thousand-fold better vetting of the crypto-system. Plus of course, the active and openly-acknowledged collection of metadata by wireapp, and the possibly-disabled tracker in the APK ... I haven't checked the manifest myself however.
These serious differences are why signalapp has Scheier and Snowden endorsements, one might presume, and why signalapp has more endusers as well perhaps -- good reputation can sometimes boost adoption. For instance, if that reputation leads to signalapp getting listed by privacyToolsIO, ahem. Which you like to call 'argument by popularity and argument from authority' and then go with the 'we can never truly know what plain words mean.'
Deconstructionism is beneath you, and you should not resort to such things. Snowden did not endorse 'everything by OWS' through some sort of mistake, and he did not mince words. Wireapp folks say flat out that they collect metadata, but because they also say they are 'open to the idea' of STOPPING the centralized collection of metadata onto their AWS infrastructure, you give them a pass? You are arguing from emotion.
And from ad hominem, quite a lot of it, even measured as a percentage of your verbiage. Should also be beneath you. Do you think github is like a street protest where whoever screams the loudest into a megaphone "wins" the argument?
And you assume a person who disagrees with you -- not even entirely disagrees just partially disagrees -- probably is some kind of a sockpuppet, or a paid corporate shill, or both? Better stop digging if you want to stop sinking. I will ping @infosec-handbook since you somehow forgot to do that when you attacked them.
We are not the same humans. We have never met. We are not on the same continent I'm pretty positive. I know about their website, because they linked to it (they recommend Jami so they cannot be me!), but also because I've seen it once before. So far as I'm aware though, they've never heard of me. Howdy there @infosec-handbook , sorry for dragging you into this :-)
Can you please confirm that you have no financial interest in OWS, are not receiving any kickbacks from Signal Foundation, were not bribed by Moxie Marlinspike nor Brian Acton nor Edward Snowden nor Bruce Schneier, and have not been xkcd 538'd into saying things you would not voluntarily say of your own free will?
And also, that you are not now, and have never been, the same human as myself?
I hereby solemnly swear and affirm, for my own part, that I am not a shill nor a sockpuppet, in any way, whatsoever, and in particular not of infosec-handbook nor any Signal Foundation slash OWS person. I say these things of my own free will: signalapp is the best-in-class software messenger for metadata-resistance and well-vetted crypto, and anybody who says different, does not know what they are talking about.
You write a lot of words and very little on the case, unlike libBletchley. An aggressive method of conversation does not make you more convincing. Aren't you tired of referring to Snowden? The fact that he farted in the media about what Signal uses doesn't make Signal any safer.
A lot of repetitious emotional drivel came from vendor loyal infosec-handbook and five-c-d. I've picked through the garbage to address things worthy of more thought and energy:
How network protectionism hinders privacy
Suppose you go to a web page and you are blocked with a statement: "You cannot use your browser of choice because we paid money to host this website and we require you to use our proprietary in-house browser". They also say: "our browser is mostly GPL'd so you are technically free to remove the privacy-abusing non-free components from it, but it's against our ToS for you to actually use the modified version to visit our website." So "free software" is used as a marketing prop, not as a means to liberate or empower the users. A webmaster can legally do that and they can try to justify it however they want, but users would be fools to download such a browser and make themselves pawns. A privacy org would be a bigger fool to endorse such a browser, because we expect a privacy org to have better judgement than the users who would opt to download such a browser.
Now let's say your friends are communicating on that website, so it's harder to walk away from. If you want to talk to your friends you must make yourself a pawn and then become the bait that pressures others to use the proprietary platform. This is what I call viral privacy abuse (1.vii).
This is essentially what OWS is doing with their service. Hosting a service isn't free whether it's blogs, file sharing, or communication. All service providers have bills to pay and must be clever in how they solve the challenge of attracting users, and also profiting (in the case of corporate suppliers). Of all the solutions to that problem, the ones that do relatively more harm to privacy than other solutions are unfit for PTIO endorsement.
OWS's anti-federating rationale: the UX
Amid all the junk being posted, this article was useful => https://lwn.net/Articles/687294/ A lot of it is redundant with what already appears in this thread. Exceptionally, the anti-federating rationale is laid out in detail. OWS believes federating slows progress. While that's true to some extent, they heavily exaggerate the rate of progress in the federated model (not that it matters). They acknowledge that using an extensible protocol solves that problem, but OWS doesn't like what it does to the user experience (users of one tool may have a feature that others don't have). Nevermind that each tool maker has a natural incentive to keep up with the extensions or get abandoned. But like Steve Jobs, OWS has become heavily bent on controlling the user experience.
When it comes to PTIO endorsement, PTIO does not have as even part of the objective "help suppliers make money" or "help suppliers control the look and feel". The PTIO objective is purely to avoid mass surveillance. When a service optimizes for profit at the cost of privacy it's very unlikely that they are suitable for PTIO endorsement.
Spam is still not a PTIO problem
When OWS designed a system in such a way that makes it extra-vulnerable to spammers, it's on them to solve their own problem. PTIO's endorsement must be focused on effective privacy from a utilitarian viewpoint, not deontologically-driven excuses. To say vendor X has good reason Y for doing privacy harm is merely an attempt at using sympathy to undermine the PTIO mission.
I've used Wire and Jami and not received a single spam message on them. So even if usability were a factor in the PTIO mission statement, the spam factor would not hinder Wire or Jami endorsements.
metadata exposure comparison
and their associations(edit)There are clearly issues with both services. With OWS, you have to trust that
they do not track the relationships between identified people.they do not log accesses from their identified users. With Wire, it's certain that the relationship data is logged and kept for the life of an account and Amazon has a view of it. Wire users are anonymous but Amazon can likely deanonymize those who use their shop with the same IP address - although it's automatically avoided by Tor users as Wire automatically discovers and uses Tor if it is installed.Which of the two come out ahead on the metadata compromise really depends on the user. Considering OWS has such a long list of other privacy abuses, even if we can say it's favorable on this issue it loses on the 10,000 foot view of everything.
We must disagree about what "the case" is here, I guess. Like @libBletchley though, I very definitely do write a lot of words.
why signalapp is better than wireapp (and jami) for IM-on-smartphones
Here is The Case being made: libBletchley is aggressively arguing that signalapp should be removed (as in completely delisted rather than being demoted to the WorthMentioning section), because it has some stuff tied to google, and runs on AWS webservers, and uses phone-numbers from MaBell, plus also (presumably) is in a FiveEyes country which is used as an exclusion-criteria for the VPN-section of privacyToolsIO (no TunnelBear-of-Canada).
To replace signalapp, libBletchley specifically recommends wireapp, which is currently listed in WorthMentioning with the "experimental" warning-note attached. The wireapp APK includes a google tracker, wireapp servers run on AWS, wireapp uses phone-nums by default but CAN optionally support non-phone-nums, and although the server-nodes are in Switzerland/EU the people running those servers are HQ'd in the USA. Wireapp has worse-vetted crypto than signalapp, Proteus-protocol is nowhere near as used/known/endorsed. Wireapp purposely stores all metadata server-side. Wireapp is not a good choice to green-highlight for IM on mobiles, though it is fine to list in WorthMentioning methinks.
why signalapp is better than wireapp (and jami) for VoIP-on-smartphones
Jami is not even listed in WorthMentioning of the IM listings (despite offering the feature), but it is listed under WorthMentioning for cryptocalls. Wireapp is blue-highlighted for cryptocalls (with a caveat that they retain metadata noted at the bottom), and signalapp is green-highlighted. @libBletchley would like to see signalapp completely delisted here as well, not just demoted to WorthMentioning, on the same basis as mentioned above for IM. And would like to see wireapp promoted to from blue- to green-highlighted, despite the hypocrisy of that stance, as outlined above.
When analyzing cryptocalls, there are several things that matter: is the crypto high-quality and well-vetted? Does it use CBR, rather than VBR which is dangerous against an adversary sophisticated enough to use phonologically-driven algorithms? Is the metadata of who-is-calling-whom, end2end encrypted, or recorded server-side in any way? Does the cryptocall reveal the IP address of the caller to the callee, and vice versa? Does the system utilize TURN/STUN services, run by whom, and are these shielded so that the IP address of the caller and callee are not revealed? What happens to call-logs on the client-side, are they stored encrypted? How are contacts organized, via stock addressbook of the smartphone, or internally? What kind of identifier is used to connect to a contact? Is there a way to verify the cryptokeys with that contact directly, to prevent man-in-the-middle attack-vectors? Does the APK have any trackers in it, that upload metadata to third parties, or for that matter, to first-parties? There are probably more, but I consider those the primary ones.
Signalapp privacy-answers: yes, yes, deleted ASAP, on-by-default but there is a setting to relay-all-calls, yes (shielded nowadays but formerly were not), yes in sqlCipher, uses default smartphone addressbook by default but can be turned off by denying permissions, signal-num which is a telco-num (can be landline/voip/burner/etc -- need not be cellnum), zero trackers and the only metadata which is stored server-side non-end2end-encrypted are date&time you registered + last day/date you connected to signal-server + the telco-num you selected as your signal-num.
There is also the question of usability/functionality: wireapp has an advantage here because it supports confcalls of up to 10 people, whereas signalapp only supports 1-to-1 cryptocalls right now. This is a good reason to blue-highlight wireapp despite their metadata-tracking efforts, methinks: if you need confcalls signalapp is no help to you, and better to select wireapp than whatsapp's 4-way confcalls or skype's 25-way confcalls. Jami also supports confcalls, amongst a theoretically-unlimited-number of participants (good reason to be WorthMentioning), but the downside is that this is only partially implemented: you have to be running jami4windows or jami4linux, there is no confcall support in jami4ios nor jami4android yet, apparently. https://jami.net/features/
If you think I'm the one conversing aggressively, as opposed to libBletchley, then I don't think I can help you see reason :-)
Correct, the endorsement by whistleblowers does not make the crypto secure. But the endorsements by cryptographers, is evidence that the crypto is secure, and the endorsements by whistleblowers and journalists -- like the green-highlighting by privacyToolsIO -- does lend credence to signalapp's reputation as privacy-oriented. Wireapp and Jami do not have green-highlighting by privacyToolsIO, and part of the reason they don't have that, is because they don't have famous cryptographers endorsing their codebases as best-in-class.
Endorsements do matter. Jami is endorsed by the FSF, which to me is a clear-as-a-bell strong indicator the code is libre to the core. But the FSF is not about cryptography, and if you want privacy, the crypto protecting that privacy has to be sound. Where is the evidence that wireapp's crypto is sound? Where is the evidence that Jami's crypto is sound? Does it even have perfect forward secrecy?
Yes, I believe you. They have tenfold (wireapp) to a hundredfold (jami) lower of a userbase than signalapp, which itself is merely in the millions-of-endusers. By contrast, I have been spammed via using signalapp: some dentist sent an SMS spam, and signalapp requires me to have a valid telco-num, so in some sense I blame Moxie for me getting that spam :-) But for a privacy-respecting messenger to have enough endusers to matter when it comes to thwarting mass surveillance, it needs to be used BY the masses, which means billions of humans. If the architecture is wrong then you get spam: SMTP has spam. And if the architecture of that wrong thing is federated, you get a proprietary centralized anti-spam predator swooping in to cannibalize the success: gmail has anti-spam, and running your own SMTP server nowadays is nigh-impossible. https://www.jwz.org/blog/2018/06/starttls-everywhere
But like with your comment about crypto-strength ("No payload-disclosing exploits exist") you are incorrect about how spam-prevention mechanisms work. Absence of exploits in the wild is not evidence that the code has no security-flaws. Absence of spam in the wild is not evidence that the messenging-architecture is spam-resistant. Wireapp has a spam-resistant architecture, because like whatsapp, they store all the metadata server-side. If spam becomes a problem as the wireapp userbase grows, they can scan for it server-side, much like protonmail does with spam-assassin (protonmail does not encrypt subject-lines partly for this reason).
Signalapp has a spam-resistant architecture because the block-button is the first thing that pops up when a new contact messages you, because there is a single master-device required in every sync-set, and because creating a new persona with a new signal-num currently requires ability to receive inbound verification-code via robo-call to a valid unique telco-num. This also has usability benefits: everyday endusers know what a phone-num is, and know how to receive a robo-call, so they automatically grok how to cryptocall via signalapp. Jami has a complex system of identifiers: SIP-based phone-nums as well as Ring.cx accounts and optional Ethereum-based usernames. Is that a spam-resistant architecture? Dunno, but I do know it is probably too complicated for poor Dave-from-Denmark to grok.
nevermind this: side comment about RiotIM
I believe that RiotIM is also working on confcalls, but they are not listed with the experimental-tag in WorthMentioning of the voip section, right now? Might still be too-experimental, from this comment... https://github.com/vector-im/riot-web/issues/6444#issuecomment-381594269 The fallback is to use Jitsi-with-RiotIM for confcalls it seems (and Jitsi is listed in WorthMentioning).
Edit: nevermind... they are working on it, but only the RiotIM client supports confcalls at present, and is basically a fork of the jitsi codebase, if this comment is correct == https://github.com/privacytoolsIO/privacytools.io/pull/562#issuecomment-459584980
#368
For most categories the colorization is purely aesthetic (or something :-) But for the IM category, it seems to be divided up by platform: signalapp is the recommended IM for mobile-device-endusers, Ricochet is the recommended IM for desktop-endusers (signal4desktop is a slave-device which cannot perform cryptocalls yet but it works fine for chat / voiceNotes / photos / videos / hyperlinks / etc). Is the "mobile" intended to be a limitation of signalapp, not a here-is-the-tool-we-recommend-for-this-kind-of-device, kind of thing? If so the word can potentially be removed from the IM-listing ... depending on how non-reverse-tethered slave-devices are treated ... albeit needs to be retained as a limitation in the VoIP-listing of signalapp.
With the VoIP category both signalapp and wireapp are recommended, jami is WorthMentioning, and it is not divided up by platform explicitly (though signalapp says 'mobile' because signal4desktop cannot handle cryptocalls yet).
In any case, I was under the impression that being "listed first" was also supposed to be somehow meaningful, even if the coloration itself was not meaningful. Is that incorrect? (The exception being things like VPNs where listing is alphabetical.)
/Worth mentioning/ is still an endorsement
(scare quotes mine)
When multiple tools satisfy the PTIO mission objective to avoid mass surveillance, it's sensible to list all of them and rank them if there are significant differences in overall privacy. But Signal is unworthy of mention because it actually subjects users to mass surveillance, and is by no stretch of the imagination even close to the options that do not impose ~4 or 5 different walled-gardens on users. If there would an Avoid list for IM tools, OWS Signal would be worthy of that list.
Wire doesn't stand where you claim I say it stands
It's a straw man to claim I'm advocating for Wire as a top endorsement. I never said that. I said that both Wire and Jami are more suitable w.r.t. PTIO's mission. I also condemn privacy abuses on the part of Wire and in fact link to them in the OP to my bug reports against Wire. For you take what I've said about Wire's shortcomings (cleartext metadata, the Swiss-hosting lie, Amazon) and present them whilst using this straw man is intellectual dishonesty. Shame on you.
What's our purpose, if not to correct bad endorsements?
That's what we're here to settle. We are not enslaved by past decisions (be they poor decisions, or [more likely] lesser informed decisions), most particularly when it's absence of a decision.
Doing something right doesn't help when so many things are wrong
If you can't state which of these questions is answered unfavorably w.r.t. a competing tool, it's useless to merely point out that a privacy abusing tool does something well. Do your own homework. If you find something worthy of mention in the lesser of evils comparison, share it with us at that point.
Category matters, but conference participant count probably does not
(esoteric detail about X number in conference call support snipped)
This is mostly a red herring in terms of the thesis of the thread. I say "mostly", because there would be relevance if this feature justified a separate category of tools. I think not.
But as I said earlier (which you missed): OWS Signal may potentially be worthy of endorsement if (and only if) a separate and distinct category existed strictly for SMS tools, because in that case it's a different set of competitors. Competitors exist in that category but those projects are out of maintenance (abandoned), so OWS Signal has a chance to come out ahead.
PTIO credibility currently suffers. This is what we need to fix
So here you've extended your appeal to authority to include PTIO. That's us.
The worst kind of appeal to authority is committed when one cites themselves as the authority. Not only does it create more of a distrust, PTIO currently has a credibility problem that needs to be fixed.
When a tool is wrong for the job, there's no value QA analysis on the code
It's incorrect for you to imply that code with "no security-flaws" is even a thing. Anything more complex than "Hello World" has security flaws. Accept it. Absence of exploits is favorable, but no one in this thread ever claimed that absence of exploits was in any way the highest standard of security.
We've exposed known, documented, unacceptable privacy abuses on the part of OWS Signal in this thread, and you're here to tell everyone to focus on hypotheticals, with off-the-cuff speculation that not enough eyes have seen the Wire or Jami code. When comparing superficially equally suitable products, it's sensible to dig deep on the QA process (code review process and 3rd party audits). But when a product is obviously so flawed to satisfy the use-case (to avoid mass surveillance) because high-level system design (ows_signal.pdf) actually subjects users to walled-gardens of mass surveillance, it's the wrong tool for the job and therefore there's no point in looking further into how well polished the code is. If the code is high quality, it should be cannabalized and used to support a privacy-respecting project. This is why we embrace the 4 software freedoms. When suitable products are being compared with no obvious show-stopping privacy abuses, then feel free to do a refined analysis of code quality.
Signal as an IM/VOIP tool - color is moot
I don't think hardly any of the visitors see any significance with the color. If PTIO assigns an unfitting color it will have minimal impact. But for the sake of correctness, the color of Signal in the IM and VOIP categories is moot because it's clear from this thread that it nees to be removed.
Signal purely as an SMS tool - and appropriate color code
What has not been sufficiently discussed is the possibility of listing Signal strictly in an SMS category. If that happens, then it would make sense to downgrade Signal to the most cautioned color available in light of the findings in this thread.
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?
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.
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:
In 2017, Snowden posted a message on the birdsite saying:
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.
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
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.
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
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.
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!
I think it's time to split content on privacytools.io into two sections:
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.
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.
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?
Thread thesis: remove Signal (nothing more)
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
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
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.
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.
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.
(unrelated reply to @BurungHantu1605 moved here.
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.
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.
Yes, exactly.
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:
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
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.
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.
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.
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.
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.
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.
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.
Yes, that is the correct move given what we know now.
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.
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.
Actually it's failure to stay current with security developments that doesn't actually work.
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?
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.
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.
(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 :-)
Tier2 pages are where the most good can be done, with some terse overall-wizardry-level tables replacing the 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.
Tier3 example numero deux, the VoIP page:
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! ;-)
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.
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.
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.
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.
@Herohtar
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
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.
Design flaws
I've simplified it:
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
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
Wire desktop users are not even asked for a phone number. Mobile users have a choice between phone and email reg.
helping the masses
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
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
Effect of demoting Signal, retaining endorsement
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.
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.
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).
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.
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.
@libBletchley
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.
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.
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)
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.
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.
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).
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)
Phone number issues: https://www.reddit.com/r/signal/comments/bfqdfj/how_is_this_possible_unfortunately_it_is/
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)
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.
@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
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")
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).
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!
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.
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.
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 ;-)
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.
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.
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.
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.
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%.
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.
You don't understand what occurred, methinks.
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:
another participant, who provided the chat records to the Guardian...
[famous participant] did not respond to a request for comment...
The Guardian confirmed the identity of those in the chat
by cross-checking phone numbers attached to the Signal accounts"
That is what I mean by "untrustworthy insider". A person inside the conversation not a person inside OWS :-)
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®istered, 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
That's it. Bit boring indeed. Here's a slightly more interesting Venn diagram:
(edit2) So I've made the Jami diagram more interesting:
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.
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.
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.
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.
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
threetwo routes forward:just removing Signal that I would be happy to do at this point, but there is no concensur for doing it in this issue, at the Matrix room nor in the team.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]".
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 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).
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.
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.
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).
That is also wrong; sealed sender prevents exactly this scenario.
Oh? Link please. I notice you elide any evidence of your accusation.
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).
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.
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.
@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.
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.
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
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.)
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.
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.
That's not what that term even means.
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.
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.
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.
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.
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
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.
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
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
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?
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).
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.
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?
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.
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.
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.
How about we click the close button until something worse happens and it can be easily replaced?
In case there is interest, I became aware that Signal forums had a thread about this thread ending to April 10th.
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.
@five-c-d
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:
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.
@five-c-d
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.
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.
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.
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?
This is not quite true. What the listings say is not so starkly black-n-white:
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.
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).
Seeing major privacy offenders like Brave and Signal in the list of recommendations means that Privacy Tools website has nothing to do with privacy- better no privacy than false privacy.
What are you hoping to accomplish by commenting that you are not agreeing with the community consensus on a closed issue?
In am expressing my opinion, I don't care for community consensus, I care for privacy,
@smaragdus which is exactly what the community agreed on: that signal provides privacy.
@blacklight447-ptio
The only chat protocol I consider secure is Tox. Tox desktop clients (qTox, Isotoxin, Toxygen, the latter two seem to be abandoned) are fine but the mobile ones (Antox, TRIfA) suck so much that they are barely usable on mobile phones.
If I have to make a compromise with privacy I would rather use a XMPP client or Telegram than Signal. I don't need to repeat all the reasons why Signal is hostile to privacy, I would just mention that Google Play Store is a huge privacy calamity and Signal main developer- Moxie Marlinspike (the most hostile to forking person in the open source world that I have ever seen) refuses to offer Signal via free and open source stores like F-Droid (issue). Also, In contrast with Telegram Desktop (C++) Signal Desktop is pure junk (JavaScript + Electron). A further reading why Signal cannot be trusted. Also, locking issues is common practice for Signal developers.
Privacy Tools recommends Brave, which is another privacy disaster (the same applies to Firefox) while there is no mention of the very few really privacy-friendly browsers- Pale Moon, Basilisk and Iridium (the latter being the only de-Googled Chromium clone while Bromite being its Android counterpart).
These two examples- Signal and Brave, show that Privacy Tools cannot be taken seriously as privacy and security adviser. I do not know who stays behind Privacy Tools but I can imagine only two reasons why the website recommends privacy disasters like Brave, Firefox and Signal- either the people behind Privacy Tools website are totally incompetent about privacy or they are being paid by Brave, Firefox and Signal.
Telegram does not even have good E2EE and you are saying that it is
better than Signal? Also source code of Android app is always released
after some time, which makes it pain for Telegram-FOSS builds in
F-Droid. Server of Telegram is nonfree, while Signal's is on GitHub.
Oh, is this that browser that was serving infected execs for like half a
year?
https://forum.palemoon.org/viewtopic.php?f=17&t=22526
Or that which fscked with OpenBSD developers?
https://github.com/jasperla/openbsd-wip/issues/86
First of all, privacytools.io is a community project, the only reason the there are a few people with commit access is to prevent vandalism. All content is on the site by community consensus.
Second of all, we are actually in the process of removing brave. (Not though, because it would be privacy unfriendly)
Second of all we have decided not to list palemoon and basilisk because they have severe security problems, which you can read in #375 #856 and #375.
If you disagree with the listings, you are free to open up an issue for each item with a concrete set of proper arguments. And if you don't like that, you can always fork ptio and make your own website. However, privacytools.io is and always will be a project which listens to community consensus to decide what the best possible listing would be, I hope you have respect for our choice to follow this model.
The author of this thread has good points to the contrary that are worth considering.
As of the time of writing. the github repo for the server component of Signal has remained untouched for almost a year. The version of the server can be veritably proven to be not the version running on the server, This is due to the fact the source code in the repo has data leaks that are not present in the current version of Signals server. Along with this signal recently released a tls proxy for those in countries like Iran. shortly after its release a issue was found showing that a government or any malicious entity could bypass and the proxy and track the users.
when this was reported to the signal team via the github. their reaction was to remove the issues section completely(as of writing still missing) and proceeded to ban the users that found this issue from the signal forums. we can not endorse signal due to their practices that quite frankly endanger lives. For more information on the tls-proxy issue you can read this [issue[(https://github.com/net4people/bbs/issues/60) on the Net4People BBS repo
It seems that PrivasyTools disregard for the arguments of contributors over the years regarding the unsafe use of Signal has reached an apogee. Remove it at last.
This is false. They removed the issue section because they had no intention of using it and politely requested that discussion of the proxy be continued on the Signal Community forum. One user was auto-silenced (not banned) on the forum due to Discourse's spam prevention settings, which was promptly reversed by the mods as soon as they realized what happened.
Signal is a government op
This was obvious from the very beginning for those who have eyes to see and brains to think.
PrivacyTools? No, thanks.
@LongJohn-Silver
All about Signal has always been murky and suspicious to me, from the leading developer (whose name I don't even want to mention) to the distribution model. Proving such stuff like the one mentioned above is from hard to impossible for obvious reasons. The problem with metadata is very grave (Michael Hayden Gleefully Admits: We Kill People Based On Metadata) as is the problem with the currently available chat programs- almost all are either insecure or underdeveloped, or perform miserably, or all of that together. As far as I know setting up your own Matrix server is only theoretically possible and the Matrix desktop clients are very poor. About Session- Session Desktop is forked from Signal Desktop, which is JavaScript/Electron which means firm no to me.
About Signal- I got even more suspicious when Snowden started recommending it enthusiastically, but when creatures like Musk recommend it it becomes more than obvious that it shouldn't be used.
I would not recommend session due to some heavy al-right ties the current developers of session have. You can see more about this here https://twitter.com/WPalant/status/1281540005190672384
Your argument is absolutely ridiculous. Unfortunately dumb SJWs and useful idiots have heavily infiltrated GitHub.
Unfortunately it appears a large amount of racist Alt-right groups have infiltrated GitHub
It's not useful to flame each other.
I don't know anything about session, but if it's a FOSS technology then nothing prevents your or I from adopting it independent of undesirables.
In fact, that would be the only way to save its reputation from extremists.
Regardless. It is a tangent and not related to the removal of signal. Which I support for the reasons mentioned above.
Although I agree that the trend of Signal forcing up more and more Google spyware is worrying, I find it fun to read that people recommend Matrix instead. The sign up process of matrix also requires Google's reCAPTCHA. Session is indeed a great alternative, but yet no support for calls. I guess that for calls, there is a need for good servers... ...from the big boys.
I also wonder why it would be problematic that Signal has enabled other companies to adopt E2EE, I believe this has greatly improved privacy and security of the masses.
Luckily Signal will remove the phone number dependency, so we can take that from the list.
All in all, Signal is for most people (which is the targeted audience of PTIO) a huge improvement over other chat apps. I see no reason to delist it.
At the moment, we will not be delisting Signal. However, if you want some legitimate criticism of Signal, see this video: Signal's Terrible MobileCoin Betrayal
Ah indeed, in the past there wasn't a reCAPTCHA but now there is one. However, I think that using the desktop app there is no reCAPTCHA as far as I know. And in-browser it's possible to use Tor Browser which nullifies risks with reCAPTCHA, which is not possible with the Signal app.
Some updates on the issue of requiring a phone number for registration in Signal:
Source: https://community.signalusers.org/t/registration-without-a-phone-number/2222/2
Another interesting discussion at the pros and cons of using email addresses for registration: https://community.signalusers.org/t/registering-with-an-email-address/919/103
From what I gather, it seems Signal is not going to support other form of registration anytime soon, as they want to bar spammers and bots from joining the network from the get go, they chose a strategy of gatekeeping.
I wasn't aware of MobileCoin. This is very concerning. MobileCoin is a fork of Monero, but with the decentralized consensus algorithm being stripped out in favor of a centralized one. This cryptocurrency has all the marks of a scam: centralized (only nodes approved by the parent company can become validators), fully pre-mined, unknown circulating supply and shady allocation (15% already allocated to private investors, public investors can't get more than 5K euros annually, and for the rest we don't know). MobileCoin has been integrated into signal. Signal's co-founder Moxie is also trying to blur lines about his involvement in MobileCoin.
Beyond the very unadvisable MobileCoin, Signal failed to update the server's source code during the last year, and they never explained why despite inquiries.
All these issues seriously raise the question of whether Signal can still be trusted.
I would suggest to re-open this issue to discuss the opportunity of a removal.
@lrq3000 also on desktop (web) there is. I am not sure if I agree with the statement about Tor. We don't really know what patterns google tracks with Recaptcha. Personally I wouldn't be surprised if the behavior leads to unique fingerprints (or at least put's you in some cohort). In addition we have seen fingerprintJS's findings a few weeks back. Let's agree that using ReCaptcha generally is a very bad decision from both Matrix and Signal. Both do however provide a lot more privacy as other providers. Signal still is a great improvement for most people. Privacy should be approachable for the masses. If we didn't have Signal we would still be needing WhatsApp or texting to contact our relatives.
Yes I agree, it would be better without Google services at all. I don't think the pattern of clicks on the reCaptcha is sufficient to track a user across different Tor circuits when the user reconnects later, but it still is a data leak. Unfortunately it's understandable there is a gatekeeping against bots, and unfortunately reCaptcha is the most reliable of all captcha systems. I have worked myself on an alternative, it's no easy task, always a cat and mouse game, so unless Element/Matrix decides to verify the user's "humanity" by another mean, which likely would involve more intrusive methods such as providing a phone number or an ID, I guess this is the least of evils.
Also worth noting is that if the matrix server is self hosted, then the captcha can be disabled. This is impractical for Signal since it's a centralized system, self-hosting means that you would be gated from interacting with the main network.