❌ Software Removal | Signal

[ghost]

Problem with Signal

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

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

Playstore history

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

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

bad players involved with OWS Signal

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

Prostitution ring diagram showing privacy abuses:

(PDF)

[ThatLurker]

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?

[ThatLurker]

At least before final verdict we should get an input on the issues listed from someone at Open Whisper Systems.

[ghost]

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

Why not use the apk on their website?

[ghost]

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.

[Mikaela]

The removal of Signal would but Riot.im and Ricochet as top recommendations.

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)?

[ghost]

@Mikaela

Would it be time to think about XMPP (#60 & #141)?

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.

[ghost]

Another possibility is to buy a SIM card in countries that don't require ID registration (e.g. in the Czech Republic)

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.

[ghost]

@Shifterovich

Another possibility is to buy a SIM card in countries that don't require ID registration (e.g. in the Czech Republic)

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.

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.

[ghost]

@infosec-handbook

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.

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.

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.

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.

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.

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

So, there is no Google-free world.

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.

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.

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

Installing apks from websites comes with security risks. I see no problems in warning users about this.

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:

acquisition mechanism	high-level risk assessment	impact	countermeasure
Google Playstore	Privacy-abusing PRISM corporation forces creation of sensitive info (a phone number and IMEI#), then collects it centrally in aggregation with other sensitive info for the purpose of monatizing it; study also shows high rate of malware	mass surveillance - all users compromised globally	none
website APK download	An adversary could MitM the distro	targeted attack - impacts a very small minority of advanced users, and only if exploited	HTTPS padlock check and/or hash verification
F-Droid	The only noteworthy risk is if an advanced user opts to use the website instead of the app	targeted attack - impacts a very small minority of advanced users, and only if exploited	HTTPS padlock check and/or hash verification; Or use the F-Droid app

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.

Point 4: I suggest that most users never access the support page of Signal.

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.

Besides, I opened the link several times in the Tor Browser and never saw any warnings, or captchas.

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.

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

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.

In summary, there is no perfect messenger, and there is very likely no completely Google-free messenger.

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.

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.

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.

[ghost]

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?

Looks like Jami is not even listed as an IM tool. It should be.

[ghost]

@libBletchley

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.

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

[ghost]

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.

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.

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.

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.

Besides, your remaining main point is that Signal doesn't aggressively promote the direct APK download

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.

In my opinion, it is really hard to seriously explain people why they should avoid Signal due to this.

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.

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?

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.

• Signal's false credibility will be realized and normalized.
• Credibility of privacytools.io will go up. Instead of just being a crowd follower, the research-driven endorsements will show that being popular is insufficient for PTIO endorsement. The endorsement must demonstrate merit.
• It will be clear why OWS lost PTIO endorsement. It will also therefore be clear how they can reacquire PTIO endorsement. If OWS fixes the problems mentioned, then PTIO will have improved the privacy of an IM tool simply by endorsing the most privacy-respecting tools.

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.

[ghost]

@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:

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.

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.

In my opinion, it is really hard to seriously explain people why they should avoid Signal due to this.

You don't need to. You say "PTIO does not endorse Signal. Use Jami."

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.

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.

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.

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.

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.

Benefits to dropping Signal

Again and again, where is a list of drawbacks of Jami or a list of benefits of Signal resp.?

Credibility of privacytools.io will go up.

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?

[E3V3A]

Have you guys actually contacted Signal devs about:

1. The lack of a direct APK download issue?
2. The AWS issue?
3. Give them some feedback what they can do, for PTIO to be satisfied (without being irrational)?

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?

[E3V3A]

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.

• Given how they emply a bot to automatically close (even serious) issues, is plain horrifying!
• Given how poorly they handled my previous concerns, leaving gaping attack vectors open for use.
• They're still allowing you to use MMS FFS!!
• It has since become a populistic shit-attractor trying to be just like WhatsApp (but without the knowledge that everything you do is insecure).

[ghost]

As mentioned by others and us, it would be really nice to 1) define requirements for software/services recommended on privacytools.io before continuing

That is not what this thread is for. Do that here please.

2. not only focus on drawbacks presented by one single account but also look at benefits

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.

3. also consider valid points of Signal (e.g. that they can't offer support for every platform on earth).

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:

• threatened legal action under trademark law (claiming that "LibreSignal" would be confused with "Signal")
• condemned the use of their network by the tools of other people's tools
  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.

And again, you tell us your personal situation, and suggest that this is valid for all people on earth.

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.

That is exactly the problem. In two months, the next person shows up, and tells us "Jami has problem x, drop it.

Actually that's a different problem. This is why it's important to do a bit of analysis before haphazardly recommending whatever is popular.

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.

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.

As mentioned before, you still try to represent every interested user coming to privacytools.io.

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.

1. They must know that F-Droid exists,

PTIO has a duty to make that happen.

2. they must willingly download the F-Droid apk

PTIO has a duty to inspire them.

3. they must disable a security feature of Android and understand why it is there

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.

4. they must install and configure F-Droid

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.

then, they get a much smaller amount of apps

Rightly so. This is inherent in leaving a catalog full of dodgy apps.

and may have to install just another store like Aurora/Yalp to download/update their now missing apps again.

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.

Furthermore, just installing another store doesn't change anything regarding communication with Google servers.

F-droid doesn't communicate with Playstore and does not require it. F-Droid is actually what liberates users from Google.

Again and again, where is a list of drawbacks of Jami or a list of benefits of Signal resp.?

You tell me. If you can see that something is missing in the discussion, why haven't you contributed it?

[ghost]

Have you guys actually contacted Signal devs about:

The lack of a direct APK download issue?
The AWS issue?
Give them some feedback what they can do, for PTIO to be satisfied (without being irrational)?

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.

[ghost]

@libBletchley

I've not contacted [Signal] about those particular issues.
[privacytools.io] is not a one-person project. It is not the burden of [me] to do all the work.

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.

[ghost]

You don't look at benefits

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.

and you don't verify your points by asking Signal/using Signal yourself.

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.

Anyway, we already wrote several times that your lists aren't the full truth,

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.

It is perfectly understandable that a company can't support any forks but you just add this to your "drawbacks" list.

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

Then, you recommend Jami via F-Droid for "novice users" while writing in the same issue that F-Droid is for "advanced users".

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.

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.

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.

F-Droid (as mentioned above too) contains a much smaller amount of apps.

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.

I don't have the time to repeatedly edit my posts/add new ones to discuss the same points over and over

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.

[five-c-d]

what happened to Riot recently

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

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

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

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

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

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

PTIO recommends replacing Windows with GNU/Linux

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

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

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

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

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

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

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

[smaragdus]

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.

[blacklight447]

What are you hoping to accomplish by commenting that you are not agreeing with the community consensus on a closed issue?

[smaragdus]

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,

[blacklight447]

@smaragdus which is exactly what the community agreed on: that signal provides privacy.

[smaragdus]

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

[dawidpotocki]

The only chat protocol I consider secure is [Tox](https://tox.chat/). Tox desktop clients ([qTox](https://github.com/qTox/qTox), [Isotoxin](https://github.com/isotoxin/isotoxin), [Toxygen](https://github.com/toxygen-project/toxygen), the latter two seem to be abandoned) are fine but the mobile ones ([Antox](https://github.com/Antox/Antox), [TRIfA](https://github.com/zoff99/ToxAndroidRefImpl)) 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](https://xmpp.org/software/clients.html) or [Telegram](https://telegram.org/) than [Signal](https://signal.org/).

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.

while there is no mention of the very few really privacy-friendly browsers- [Pale Moon](https://www.palemoon.org/)>

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? jasperla/openbsd-wip#86

[blacklight447]

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.

[dijit]

@smaragdus which is exactly what the community agreed on: that signal provides privacy.

The author of this thread has good points to the contrary that are worth considering.

[Lunarequest]

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

[t1011]

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.

[Herohtar]

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.

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.

[smaragdus]

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.

[smaragdus]

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

[Lunarequest]

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

[smaragdus]

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.

[Lunarequest]

Unfortunately it appears a large amount of racist Alt-right groups have infiltrated GitHub

[dijit]

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.

[ph00lt0]

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.

[freddy-m]

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

[lrq3000]

I find it fun to read that people recommend Matrix instead. The sign up process of matrix also requires Google's reCAPTCHA.

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.

[lrq3000]

Some updates on the issue of requiring a phone number for registration in Signal:

Currently only devices with a PSTN number are supported. Embedded devices like door stations, webcams, etc. 1 should be able to communicate with Signal users, too. I suggest to implement UID support for devices without a PSTN number.

maybe with an email or just an user name .

As replied by Open Whisper System many times, it’s on DOTO list.

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.

[lrq3000]

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

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.

[ph00lt0]

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

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.

[lrq3000]

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.