❌ Software Removal | Signal
Problem with Signal
Signal has copious privacy issues making it unfit for privacytools.io endorsement.
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:
The text was updated successfully, but these errors were encountered:
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 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.
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.
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.
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.
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:
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.
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.
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).
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.
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.
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
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)
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.
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.
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.
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.
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.
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:
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.