Closed ghost closed 5 years ago
ThatLurker
commented
5 years ago 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
commented
5 years ago At least before final verdict we should get an input on the issues listed from someone at Open Whisper Systems.
ghost
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago @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
commented
5 years ago 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
commented
5 years ago @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
commented
5 years ago @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
commented
5 years ago 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
commented
5 years ago @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
commented
5 years ago 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?
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.
ghost
commented
5 years ago @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
commented
5 years ago 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?
E3V3A
commented
5 years ago Actually, I just changed my mind.
As I haven't browsed their issues for quite a long time, I took another look.
ghost
commented
5 years ago 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:
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
commented
5 years ago 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
commented
5 years ago @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
commented
5 years ago 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.
E3V3A
commented
5 years ago ghost
commented
5 years ago Just added 1.vii:
The privacy abuse is viral. When a user opts to sacrifice their own privacy by registering a phone number, they become bait by which their friends are pressured to make the same compromise in order to stay in touch.
Consider the pre-Microsoft days of LinkedIn which did not require phone registration. Those users were grandfathered. They cling to their accounts because they lucked out and escaped that particular privacy abuse. But what many fail to realize is that the mere existence of their account serves as bait for exploiting the privacy of prospective new members who want to reach out to old friends. If Alice wants to get back in touch with Bob, she may be forced to get a phone number and then supply it to Microsoft, who then exploits this effect. So the proper ethical move is to stop being the pawn that gives them power and close the account even if it's grandfathered.
W.r.t. Open Whisper Systems, they refuse to cooperate with a federated network while at the same time forcing phone registration. Those two issues paired together creates the 1.vii viral privacy abuse issue.
E3V3A
commented
5 years ago hey guys, i just read this article:
Mikaela
commented
5 years ago but i've never used keybase, so what are your opinion about that project and app?
https://github.com/privacytoolsIO/privacytools.io/issues/740#issuecomment-460076395
ghost
commented
5 years ago I've also noticed that Keybase holds meetings and seminars on CloudFlare property. It might be interesting to know if that relationship extends beyond sharing meeting rooms.
dalanmiller
commented
5 years ago The keybase discussion isn't relevant to this issue.
On Thu., 28 Mar. 2019, 07:58 libBletchley, notifications@github.com wrote:
I've also noticed that Keybase holds meetings and seminars on CloudFlare property. It might be interesting to know if that relationship extends beyond sharing meeting rooms.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/privacytoolsIO/privacytools.io/issues/779#issuecomment-477344797, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0sNpOpPtsrYqYsMkIO4d-9jrVS-tZvks5va9tmgaJpZM4bnR9t .
ghost
commented
5 years ago Wire project is open to the idea of federating and even offering XMPP interoperability:
zero77
commented
5 years ago While the problems raised here are valid and certainly concerning, shorley the main signal developers should be given a chance to address these concerns.
ghost
commented
5 years ago @zero77 If you dig into the history of bug reports and forums for Signal, some of these issues have a long history and OWS would not budge on any of them given copious public pressure. And the list is huge. So delaying the correction on PTIO only does harm, as users are getting bad guidance every day that Signal gets the unmerited endorsement.
In the unlikely case that OWS makes a miraculous 180 degree turn, PTIO can always endorse them again.
zero77
commented
5 years ago @libBletchley I cannot comment on all of the issues you raised but, yes, the use of a phone number has been brought up countless times with no progress.
Although, i am yet to see an up to date explanation as to why OWS haven't progressed with these issues shorley, they should at least be given the opportunity to provide one.
ghost
commented
5 years ago Signal can use Google reCAPTCHA on users registering on Signal: https://github.com/signalapp/Signal-Android/commit/02b0800b22e2faaa1f659d34ac3bb2f44eda3631
ghost
commented
5 years ago thanks for the tip @zexi3453. I've added section 2.iii to highlight some of the problems with Google's reCAPTCHA. This change means Signal is no longer free software because users must trust and execute non-free j/s. IMO Signal should be removed from the fsf directory.
five-c-d
commented
5 years ago "use of a phone number has been brought up countless times with no progress"
This is true, the complaint has been raised countless times, and it is also true, that changing to inscrutable cryptohashes as identifiers, or changing to spammer-heaven emails as identifiers, or whatever, has never happened. But that is because those are the Wrong Approaches if you want a dead-simple messenger aimed at the masses, that will NOT become overrun with spam as it gets increasingly popular.
This is a hard problem in other words. Pointing out that phone-nums can be a privacy-risk, is not a "solution" it is just a complaint. An actual honest-to-gosh solution, would have no downsides in terms of usability, nor in terms of spam-resistance, nor ideally in terms of hijack-resistance either. Signalapp's reliance on phone-nums is a compromise, with tradeoffs firmly in mind.
The recent addition of the reCaptcha thing is, reading the tea-leaves, also directly related to spam prevention (or maybe to draconian governments that have nationalized the telco-system and are doing DoS against signalapp by pre-emptively registering all phone-nums in country-code +NN to deny their citizens that capability). It only applies to a limited subset of registrations, and I've never even heard of anybody seeing it. More details here, https://community.signalusers.org/t/use-something-else-instead-of-google-recaptcha-for-registration/6289
* yes, signalapp uses normal phone-nums and that means the big four telcos might indirectly collect data about signalapp endusers, rather than inventing their own identifier-system, * yes, signalapp uses the normal android infrastructure and that means google might indirectly be able to collect metadata about signalapp endusers, rather than inventing their own smartphone ecosystem, * yes, signalapp runs from Amazon-and-Google server infrastructure rather than building their own high-availability cloud services from scratch. * that said, *no*, the four defined freedoms absolutely do not give the recipient the "freedom to demand gratis server-bandwidth provided forever" from the Signal Foundation, nor the "freedom to violate trademark law and dilute the reputation of the legal owner" either. If you cannot deal with those pragmatic design-decisions, either because of ethical allergies to Ma Bell or The Goog or the Empire of Bezos, or possibly because you are up against nation-state level adversaries capable of bribing AWS sysadmins or pwn'ing google backend datasets, then absolutely you should not be using signalapp -- or *any* consumer electronics AT ALL. None of those devices will save you from the NSA rootkit'ing your handset, and similarly, none of those devices will only connect to backend systems with zero taint of large corporations anywheres. But the goal of privacyToolsIO seems to be educating people about how to incrementally improve their privacy, which means it does **not** say "you have to buy Librem5 and you have to run Qubes on OpenBSD and you have to hand-manage your own air-gapped offline keypair generation system" or anything like that. Instead it recommends stuff that installs on common laptop OSes + apps that install on common smartphones the usual way + services that work with normal enduser-devices on the normal corporate-run internet.
Signalapp is therefore an extremely good fit for the privacyToolsIO goals, because it works on common consumer laptops & phones via the typical internet infrastructure.
users are getting bad guidance every day that Signal gets the unmerited endorsement
Unlike the demand to remove signalapp entirely from https://www.privacytools.io/software/voip/ and also from https://www.privacytools.io/software/im/
At a minimum the link on privacytools.io should be to the [direct-download] APK ...
...the suggestion that one or both of those places should link to https://signal.org/android/apk/#target in addition to the more usual https://signal.org/download URL, might have merit? It depends on what the maintainers of the privacyToolsIO listings think is wise for the audience they serve.
[LaterEdit: I was confused, looks like the direct link to the APK is mentioned in the voip and in the im listings -- "Advanced users with special needs can download the Signal APK directly. Most users should not do this under normal circumstances" -- starting from sometime back in 2017 according to archive.org copies of privacyToolsIO, but down in the 'RelatedInfo' portion rather than in the more prominent click-here-we-recommend-signalapp portion. So the suggestion that it BE listed, is already implemented. There is still a valid discussion about whether to hyperlink to https://signal.org/android/apk#target rather than to the top of the page which encourages playStore, and an orthogonal discussion about whether to mention the APK-direct-download in the green-highlighted portion versus where it is presently in the IsRelated portion.]
However, do note that the https://signal.org/android/apk/#target is only for android-smartphones, to install signal4ios requires use of iTunes (there is no easy way to sideload on iDevices short of tricksy jailbreaking is my understanding).
So, for people with iPhones and people wanting signal4desktop, I recommend leaving the normal signal.org/download (or the signal.org/install quicklink perhaps) visible. The hard decision would be, whether to link to the direct-download APK, and if so, whether to have it mentioned first and prominently, or mentioned second and peripherally. I would lean towards the former arrangement, signalDotOrgAPK listed first and prominently, and the link which goes to playStore + iTunes + DEB repo + windows + osx, listed second.
Alternatively-alternatively, the privacyToolsIO link could be the no-javascript-required one which goes direct to a versioned APK, per https://github.com/privacytoolsIO/privacytools.io/issues/779#issuecomment-475846949 , but that approach would require regular updating as new APKs were released so it would be a bit more legwork for the website-maintainers (I believe new APKs are pushed every month or thereabouts)
p.s. Thanks for the great website. I will continue to recommend people that are serious about their privacy, look through the privacyToolsIO listings, as their first place to begin. I don't wholeheartedly recommend people just blindly install ALL the tools listed by privacyToolsIO, because I don't think that is the point. The point is to consider these tools, and then select which ones best match the enduser's individualized circumstances. Most of those folks will want signalapp, and the privacy-oriented things it has to offer, so it would be a shame to de-list it
ghost
commented
5 years ago ..NOT become overrun with spam as it gets increasingly popular...This is a hard problem in other words.
It's only a hard problem for email and public broadcast services like blogs and forums. In the context of a centralized IM/voice service offered by a corporate supplier it's a problem in terms of maximizing profit. Privacy-respecting competitors like Jami and Wire don't have a spam problem, and yet they've not forced users to make such unacceptable compromises to privacy. OWS and Telegram are focused on easy spam-control on their end to the extent that they've required users to give up on privacy.
This discussion is hypothetical. Apart from the fact that we don't need to trade privacy for spam avoidance in this case, in the hypothetical case where the values are at odds PTIO users favor privacy. The trade-off may be okay for those with a great intolerance for spam but wholly unacceptable for those who hold privacy above spam avoidance.
I would gladly accept the risk of occasionally accidentally accepting an invite from a spammer who then needs to be blocked in order to not have to buy a phone, buy phone service registered to a national id, disclose of the number, and then become subject to ~4-5 new walled-gardens that finance half a dozen privacy abusing corporations:
| 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 |
| yes | user tracking in many different ways via playstore and captcha | OWS feeds this notorious privacy abuser and PRISM corp | |
| CloudFlare | yes | sees all web traffic to OWS support site and blocks Tor users | OWS feeds this notorious abuser of privacy and net neutrality. |
| 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; many European carriers require gov. id |
It's a lousy and needless trade. We don't have to give up privacy to avoid spam and even if we did PTIO goals are clear:
"You are being watched. Private and state-sponsored organizations are monitoring and recording your online activities. privacytools.io provides knowledge and tools to protect your privacy against global mass surveillance."
Note that spam avoidance is not included in that mission objective. The trade-off you're advocating undermines PTIO goals.
Pointing out that phone-nums can be a privacy-risk, is not a "solution" it is just a complaint.
It's a complaint that is specific to Signal and Telegram which competing systems avoid. The competing systems demonstrate solutions.
The recent addition of the reCaptcha thing is, reading the tea-leaves, also directly related to spam prevention (or maybe to draconian governments that have nationalized the telco-system and are doing DoS against signalapp by pre-emptively registering all phone-nums in country-code +NN to deny their citizens that capability).
The first mistake is to use Google's reCAPTCHA, the most intrusive and detrimental of all varieties of CAPTCHA. It reflects yet another flippant decision by OWS to support adversaries of the privacytools.io community who come here precisely to avoid those walled-gardens. The next mistake is to subject users to non-free software while rendering the possibility of text-based tools useless.
Signalapp is therefore an extremely good fit for the privacyToolsIO goals, because it works on common consumer laptops & phones via the typical internet infrastructure.
It's a very poor choice for privacyToolsIO users because competing systems have more platform diversity (no network protectionism coupled w/hostility toward 3rd party devs) without the privacy abuses.
...the suggestion that one or both of those places should link to https://signal.org/android/apk/#target in addition to the more usual https://signal.org/download URL, might have merit? It depends on what the maintainers of the privacyToolsIO listings think is wise for the audience they serve. However, do note that the https://signal.org/android/apk/#target is only for android-smartphones, to install signal4ios requires use of iTunes (there is no easy way to sideload on iDevices short of tricksy jailbreaking is my understanding).
These issues have been laid out and indeed there is no suitable option for obtaining Signal because the least privacy-abusive option still exposes users to privacy issues and is likely outside the scope of PTIO audience expertise anyway.
privacyToolsIO link could be the no-javascript-required one which goes direct to a versioned APK,
Does PTIO have to monitor the Signal project and edit the version with every release? Signal has proven to be such a poor choice it doesn't merit that kind of effort, which also brings the shortcoming of a much more complex statement of endorsement.
Most of those folks will want signalapp, and the privacy-oriented things it has to offer, so it would be a shame to de-list it
The effect of the de-listing steers users clear of a bad option and guides them to privacy-focused options. They're likely already aware of Signal due to its unmerited popularity. PTIO has a duty to correct that and spotlight tools that are aligned with PTIO values.
jonaharagon
commented
5 years ago I'm not sure how I feel about this so I'm just going to respond to as many points as I feel qualified to answer with my own opinion.
- Users are forced to supply a phone number to Signal (#432).
- Users are forced to feed Google.
The reason I have a hard time agreeing that we should stop recommending Signal is because they do an excellent job at keeping your messages private, which is a very important thing to many people. Privacy is not necessarily anonymity and not recommending tools because they don't keep you completely anonymous online is gatekeeping, and it might not even be a concern for some people. This is why I think identifying threat models (https://github.com/privacytoolsIO/guides.privacytools.io/issues/5) is something we need to really focus on getting users to understand. That could even tie into #729: documenting shortcomings along with benefits of each platform. These two things are important considerations but IMO they are not dealbreakers if you're looking for ultra-secure communication and anonymity isn't a factor for you.
I also think we might be missing the point that Signal is largely an SMS replacement. People are more than happy to give out their phone numbers for SMS, but SMS isn't encrypted at all. If people want to keep the contents of their messages private, shouldn't the use of Signal be encouraged? I even think on Android you can use the Signal app as your SMS app as well, so Signal is becoming more of an open-source iMessage alternative (from a security perspective at least) than anything else, which I think is a good thing.
- APK download is implemented in a privacy-hostile manner
This is true, and we should probably link to the APK page by default. We could even link to https://signal.org/android/apk/#apk-danger so it scrolls you down automatically.
- Network protectionism: the Signal network is a closed walled-garden in itself.
This is true, but as long as the code is open, which theirs is, it doesn't seem like an issue to me. Wire does the same thing for example.
The removal of Signal would but Riot.im and Ricochet as top recommendations.
This is probably the main issue I have. There are no good alternatives to mobile messaging at the moment. Signal covers a different use-case than these other options.
As mentioned by others and us, it would be really nice to 1) define requirements for software/services recommended on privacytools.io before continuing
This needs to happen, I feel like a lot of removal or addition requests could be easily closed if we had a clear set of requirements we want from our recommendations.
There are definitely some cons against Signal, and I think those should be clearly listed. But that would require a complete change of essentially all of our pages the way #729 suggests so this isn't some small undertaking. I don't however, think that these issues should result in the removal of the software from the site, as it does a very fine job at
five-c-d
commented
5 years ago Privacy-respecting competitors don't have a spam problem either
With respect, @libBletchley -- since you clearly do have a strong grasp on the ins and outs of messenger-services and the compromises they make -- you definitely have no idea what you are talking about when it comes to spam in that sector.
I think the main problem is that you are using "competitors" loosely and including things like Jami aka cx.ring -- which has less than a thousand playStore reviews. Wireapp is MUCH better known, but very much still a niche-competitor at the moment, with 30k reviews on playStore, in roughly the same miniaturized-pony-competition class as wickr with 20k reviews and threema with 55k reviews. The userbase of those walled gardens is just too tiny, there is no network-effect, so of *course* there is no spam. The few thousand people on Jami do not spam each other, of course, and real spammers are not messing with THAT small of a slice of humanity! Real spammers have SMTP and Facebook-pages and such, as targets. Should signalapp really succeed someday, and grow to a userbase of hundreds of millions or billions of daily-driver endusers, *signalapp* will be such a target, also. Signalapp has 300k reviews on playStore, and millions of endusers, putting it in a different category entirely -- it is not a "competitor" of Jami because they are not even in the same universe. Jami is an *alternative* to signalapp, in some pedantic theoretical sense, but no, it is not a competitor. The **competition** is Whatsapp-by-Facebook, they get 300k playStore reviews *every 8 hours* when I last did the math. To a lesser degree (ten times bigger than signalapp but ten times smaller than whatsapp) it is also valid to see Telegram as a competitor. Definitely not Jami though. > IMO Signal should be removed from the fsf directory [not just privacyToolsIO listings] Yes, yes, you have made clear that you have a burning desire to see signalapp de-listed, and replace it with Jami or whatever. I'm not here to convince you otherwise, you are beyond convincing :-) From your username it sounds like you are concerned GCHQ is likely to target you personally, and to me that means you absolutely should not use signalapp, nor anything else that runs on a smartphone, just stop using smartphones entirely. You **cannot** become 100% anonymous whilst using internet-connected hardware and the software it requires, if you believe that is possible, you are misinformed. > [people reading privacyToolsIO are] likely already aware of Signal due to its unmerited popularity. Yeah, I think I am starting to understand here. You don't like signalapp because it is non-federated, and because it uses AWS for webservers, and because it uses playStore for deployment. And you want it to be federated like Jami, and use only 100% certified organic free-range webservers, and stop being listed in playStore so F-Droid will become more popular, and stop using phone-nums because THAT will really stick it to Ma Bell and Jeff Bezos and Google and GCHQ and all those other surveillance-badguys. What you fail to understand is that the reason signalapp *has* 300k playStore reviews and Jami has a tiny fraction thereof, is ***because*** signalapp made some very hard tradeoffs. It runs on normal androids (not just OpenBSD), it is found in the normal appstore (not just F-Droid), it is hosted on the regular internet (not just as a hidden Tor service), and they tried federation (with LineageOS-fka-CyanogenMod folks) and it slowed down development so much they stopped trying after a couple dozen months. What other actual-competitors have those same tradeoffs? Whatsapp, mostly-telegram, partly-skype... all of which have LARGE userbases! Are there any end2end encrypted, widely federated, never-touches-Amazon, never-touches-Google, never-touches-telcos messengers? Sure, but how many of them have hundreds of millions of endusers? Zero. *Why?* Because likely, it cannot be done. Signalapp is competing with WhatsInstaBookMsgrApp, not with Jami. Signalapp's reputation is hard-won and well-deserved. You don't like the design decisions that *made* signalapp popular and well-vetted, because you have special ethical constraints you apply, or because you have extremely-maximized anonymity requirement that is a dealbreaker for you? Well, okay, don't use it then. But don't try to push your threat-model on everyone else. What you are advocating is that signalapp stop connecting to any Amazon servers, stop connecting to any google servers ... yet keep running on android which is a google-controlled codebase! ... and stop utilizing anything like a telephone-number. If you need that, REALLY need that, because you are up against adversaries with sufficient power to subpoena records and gag-order the sysadmins of major billion-dollar multinationals, then yup, signalapp is not for you, and neither is any other software. Go full-on old-skool, and fallback on one-time-pads, dead-drops, whispered face-to-ear conversations, and maybe magical amulets. But you are mostly just here to advocate replacing signalapp with less-well-vetted products that don't offer the same feature-sets nor the same level of reliability/vetting. There are billions of people using the officially-branded Signal Protocol, and signalapp itself is recommended by top-notch cryptographers. I don't see *any* cryptographers mentioned on the Jami homepage, or any endorsements at all. Who recommends Jami itself specifically, besides yourself? For that matter, what cryptographers recommend wireapp? Because of the extremely careful server-side metadata-resistance, if signalapp does not *PREVENT* spam from happening -- not "avoid" spam and not "detect" spam and not "mitigate" spamming but flat out prevent spammers from ever getting a foothold -- then it will be fatal for the entire signal-network. Average endusers will not stand for spam, if there is any significant amount of spam, these average endusers will demand a serious anti-spam solution. Guess who will happily step in to provide that solution, by offering to upload all plaintext message-bodies and associated metadata into the cloud, so it can be scanned and analyzed with best-in-class anti-spam algorithms? The gmail people, who "happen" to be the same people that control the OS-autoupdates on 99% of android handsets worldwide. If signalapp develops a spam-problem, Google can take the whole Signal Foundation down, and *endusers will not be that mad* because they will do almost anything to not be spammed. Proof? Look at the market-penetration of gmail, if you don't believe me. Endusers will give up privacy in a heartbeat. The only solution here is for signalapp ***never*** to develop a serious spam-problem. Hence, moving away from the phone-num system to the email-based system, in a naive fashion, would be the death-knell of signalapp. I want properly-anonymized signal-identifiers so bad I can taste it, but no, it is not an easy-peasy-simple-pimple problem, and no, just because you don't see much spam on wireapp with a tenth the userbase or on Jami with a hundredth of the userbase, does not mean ANYTHING. Actual competitors to signalapp, with LARGE userbases where spam can take root, can scan for spammers server-side: whatsapp keeps all metadata (phone-number-based) non-end2end-encrypted, wireapp does the same, telegram does the same plus also stores 90% of the message-bodies server-side, skype is much like that. Even matrixOrg/riotIM store a huge amount of stuff server-side, unless you run your own Synapse homeserver (in which case the storage is server-side but you can control who secures that data-trove). Signalapp is unique amongst the major messengers, because it is 100% GPLv3/AGPLv3 *and* it tries very hard to minimize server-side metadata. None of the others do, and by others, I mean *actual competitors* with similar scale-in-userbase, not niche products. This uniqueness of signalapp has a huge downside: signalapp **cannot** stop spam server-side, which means, spam has to be prevented from *ever* getting started. The main thorn in the side of signalapp being discussed here, is the reliance upon phone-nums... which are hard to truly anonymize, and most people do not. But to lessen that reliance is not simple, we HAVE to make sure the spam-prevention is rock-solid, first, because if spammers even get a toehold, that will quickly become an existential threat to signal-network, all endusers not just those being spammed, because Google will be able to convince signalapp endusers to pwn their own endpoints (voluntarily!).
And less imperative, but just as fatal to the long-term success of signal-network as a mass deployment daily-driver messenger suited to thwarting mass surveillance someday, is usability: phone-nums are "more usable" and the everyday Dave-from-Denmark will absolutely positively be unsatisfied with “ricochet:5092ef327373” or whatnot.
Privacy is not necessarily anonymity
Yes, correct. It is an important consideration, but strongly depends on your threat-model as to whether it is a dealbreaker-consideration. If you are up against GCHQ and the NSA, then anonymity is probably not even a plausible GOAL when using consumer electronics.
on Android you can use the Signal app as your SMS app as well,
Correct, and this SMS-integration is on by default. I turn it off, because I prefer to keep my unencrypted chats firmly compartmentalized away from my encrypted conversations (lest I inadvertently "cross the streams"). Plenty of people install signal4android as this-is-a-better-SMS-app-than-the-stock-SMS-app, however, is my understanding.
so Signal is becoming more of an open-source iMessage alternative
Well, kind of... only on signal4android though, because Apple purposely locks down the SMS/MMS features of their iDevices so that only iMessage can access that stuff! :-) Vendor lock-in at its finest methinks. So although signal4android handles SMS/MMS fallback... and unlike iMessage if memory serves, signalapp encrypts those unencrypted-in-transit messages once they are sent-or-received, rather than storing them on the filesystem in the clear... signal4ios cannot truly be an iMessage alternative, because Apple does not allow anything to be an iMessage alternative, on iDevices at least.
Signal covers a different use-case than these other options [riot + ricochet]
Also correct -- signalapp is not really a competitor to RiotIM+Synapse, because one is aimed at being the banquet and one is aimed at being the barbeque, as the Librem5 folks discovered when they tried to make the Fractal variant of RiotIM into a signalapp-equivalent. To my way of thinking RiotIM+Synapse and signalapp+signalServer are complementary technologies, rather than competitors, in much the way that I don't see protonmail and tutanota as "competitors" to signalapp (nor to matrixOrg) -- encrypted webmail solutions are complementary, once again. Protonmail competes with gmail, RiotIM+Synapse competes with slack+skype4biz, and signalapp competes with whatsapp+skype4home.
ghost
commented
5 years ago The reason I have a hard time agreeing that we should stop recommending Signal is because they do an excellent job at keeping your messages private, which is a very important thing to many people. ... If people want to keep the contents of their messages private, shouldn't the use of Signal be encouraged?
We can neglect payload privacy because all the competing systems offer this. No payload-disclosing exploits exist on any of the competing platforms (Jami, Telegram, Wire, Tox, Riot.im, Omemo, and Ricochet). The differences between these systems is privacy of the metadata, walled-gardens, and privacy abusing partners.
Privacy is not necessarily anonymity and not recommending tools because they don't keep you completely anonymous online is gatekeeping, and it might not even be a concern for some people.
Anonymity is privacy. Specifically, it's privacy of identity. And it's sensitive. It's not okay to expose who is talking to who.
The abuses we're talking about also go well beyond anonymity. Forcing someone to enter the marketplace and buy a phone harms privacy in a number of ways. Even if the purchase is offline, with cash, in a shop without CCTV, most phone makers are lobbying against privacy and many abuse users' privacy through spyware and configuration limitations. So privacy-focused consumers are being forced by OWS to spend their money in a way that is counter to their own privacy interest. Even the most privacy respecting phone is inherently compromised by conforming to GSM/CDMA specs. And the privacy compromise I've described so far is before we even start talking about phone service, the Signal install process, and the Signal reg. process.
That could even tie into #729: documenting shortcomings along with benefits of each platform
The number of Signal shortcomings and pitfalls more than fills a screen. PTIO would have to spotlight an embarrassingly high number of anti-features on their endorsement, or hide these from the user.
I also think we might be missing the point that Signal is largely an SMS replacement.
It fails as an SMS replacement because it relies on phone registration. It's not a replacement, it's a supplement. Competing systems do entirely replace SMS because they don't require phone reg.
This is true, but as long as the code is open, which theirs is, it doesn't seem like an issue to me.
This has been tested. Someone produced a 3rd party app and OWS refused to allow that app on their network. So the software freedom does not exist with OWS Signal. So you're apparently proposing a lower standard -- open source instead of free software. The problem with open source is that the creator still wields all the power and control. Like Facebook they can do what they want after acquiring the power of mass acceptance and resistance is futile.
Wire does the same thing for example.
I've not heard of any cases of Wire bullying 3rd party authors. AFAIK, Wire s/w is truly free s/w. Is there an article to the contrary?
This is probably the main issue I have. There are no good alternatives to mobile messaging at the moment. Signal covers a different use-case than these other options.
You can easily say nothing is good because everything has shortcomings, but nothing is as broken and reckless as Signal with respect to privacy. Jami and Wire are both better options.
five-c-d
commented
5 years ago The quote about "wire does the same thing" was referring to "wire is a centralized service". Just like signalapp. And this helps explain why wireapp has more playStore reviews than decentralized Jami: because with network-effect messaging apps, centralized services can add features faster, develop complicated upgrades faster, and so on. If you want information about Wireapp's corporate ethics, you can dig up their lawsuit against Moxie, when the wireapp folks decided to use Signal Protocol within wireapp... and then suddenly wireapp's encryption was renamed as "Proteus Protocol". > No payload-disclosing exploits exist on any of the competing platforms Again, if one platform has millions and the other has thousands, they are not "competitors" in any realworld sense. How many cryptographers have vetted, and then publicly endorsed, Proteus protocol? How many endusers are using Proteus protocol in practice, every day? With crypto, popularity is the ONLY sure way to see whether the codebase has security-holes. I invented my own crypto system just now: it has zero published exploits, just like Jami's crypto-implementation. But I guarantee you that lack of any CVEs, is **not** because my home-brew crypto is ACTUALLY secure: only realworld vetting gives evidence of THAT. Absence of evidence, is not evidence of absence. > ...The differences between these systems is privacy of the metadata... nothing is as broken and reckless as Signal with respect to privacy. Jami and Wire are both better You think ***wireapp*** has better metadata-resistance than signalapp? https://en.wikipedia.org/wiki/Wire_(software)#Metadata versus https://en.wikipedia.org/wiki/Signal_(software)#Metadata seems like night versus day, to me. Wireapp has roughly the same metadata-storage as Whatsapp (and considerably worse than RiotIM+Synapse as long as you run your own homeserver), though Wireapp sysadmins do not have the same inherent motive to abuse such data as Facebook does. https://en.wikipedia.org/wiki/Reception_and_criticism_of_WhatsApp_security_and_privacy_features The codebase of wireapp is libre, correct, that is my understanding as well. So at least we don't disagree about *everything* under the sun ;-)
Someone produced a 3rd party app [called LibreSignal] and OWS refused to allow that app on their network [i.e. to connect to servers paid for and run by OWS]. So the software freedom does not exist with OWS Signal
You seem to misunderstand the meaning of the four freedoms.
[OWS / SignalFoundation] capitalized on the marketing benefit of free software licensing [the 100% GPLv3/AGPLv3 codebase of signalapp] but implement a policy [non-federation plus unofficial-clients-mostly-prohibited] that prevents the freedoms of free software from actually having a practical usable effect.
This is wrong. GPLv3 gives you the freedom to run the codebase, for any purpose. It does not give you the “freedom” to demand that the people who gave you that GPLv3 codebase, and thereby gave you the liberty to run the code for any purpose, must supply YOU with free-as-in-beer server bandwidth FOREVER. No, that is a gigantic misinterpretation of what freedom is. Here are the four freedoms == https://en.wikipedia.org/wiki/Free_software#Definition
ghost
commented
5 years ago you definitely have no idea what you are talking about when it comes to spam in that sector... Signalapp has 300k reviews on playStore,
Popularity as a basis for judgment has been tried and it failed.
Yes, I know that the spam game changes as the scale of the system changes. PTIO is not here to give sympathy to large scale projects that have bigger problems. It's making a recommendation for the best tool today given today's systems. If a small system grows to be large and one day begins to abuse users' privacy in attempt to manage the growth, PTIO can and should revise the endorsement accordingly.
IMO Signal should be removed from the fsf directory [not just privacyToolsIO listings]
Yes, yes, you have made clear that you have a burning desire to see signalapp de-listed, and replace it with Jami or whatever.
Actually that was the first time I mentioned delisting Signal from the FSF Directory, which is a different list than the PTIO list, with a different objective.
You cannot become 100% anonymous whilst using internet-connected hardware and the software it requires, if you believe that is possible, you are misinformed.
This is a straw man. I never advocated for the impossible. I've always advocated for the lesser of relative evils and the best tool for the job given the mission statement of PTIO.
Yeah, I think I am starting to understand here. You don't like signalapp because it is non-federated, and because it uses AWS for webservers, and because it uses playStore for deployment. And you want it to be federated like Jami, and use only 100% certified organic free-range webservers, and stop being listed in playStore so F-Droid will become more popular, and stop using phone-nums because THAT will really stick it to Ma Bell and Jeff Bezos and Google and GCHQ and all those other surveillance-badguys.
I've listed the problems that shows Signal to be a poor choice. All this emotional bending you're trying to do here is irrelevant. The Playstore problems are about playstore, not F-Droid. F-Droid just happens to be a superior distribution mechanism that Jami uses. I might actually prefer to see a new repo emerge that rivals F-Droid. The bottom line is that OWS has made poor choices and there are better options on the table.
Are there any end2end encrypted, widely federated, never-touches-Amazon, never-touches-Google, never-touches-telcos messengers? Sure, but how many of them have hundreds of millions of endusers?
Is this another band-wagon attempt? I see nothing in the mission statement of PTIO that implies large projects need sympathy points. PTIO is making decisions w.r.t. privacy a single user benefits from. If a large management burden causes privacy to be tossed out, PTIO cares about the privacy loss not the management problem that caused it.
What you are advocating is that signalapp stop connecting to any Amazon servers, stop connecting to any google servers ... yet keep running on android which is a google-controlled codebase!
You're trying that broken security logic that says "because some aspect of a security system has an imperfection, we therefore must abandon the whole system". Amateurs and journalists take that stance but it is naïve. That was tried when PGP had some recent vulnerabilities in some mail clients which caused a ridiculous overreaction similar to yours. Obviously it's sensible to avoid vulnerabilities to the extent practical. Trading a system with imperfections for something worse is a poor choice and it's not what PTIO should advocate.
I personally use a desktop for IM/voice, so I'm quite removed from google. I need to talk to those who use iphones and androids, so platform diversity is a sensible compromise. But there's no reason to force users to share information with and financially support Amazon and Google. Some users will choose to share with google but there's a problem with endorsing a tool that does not liberate other users from google. A google fan should be able to talk to someone who entirely opts out of privacy abuses. OWS uses network protectionism which blocks users who prefer to be liberated from privacy abusers from connecting with others.
and stop utilizing anything like a telephone-number. If you need that, REALLY need that, because you are up against adversaries with sufficient power to subpoena records and gag-order the sysadmins of major billion-dollar multinationals, then yup, signalapp is not for you,
You're conflating mass surveillance with targeted surveillance. The PTIO mission is to avoid mass surveillance, and it's mass surveillance that phone networks support.
But don't try to push your threat-model on everyone else.
Again, the PTIO threat model is mass surveillance. You can see from this post that it's mass surveillance that's in my threat model, while OWS Signal is subjecting users to mass surveillance in a naïve attempt at avoiding targeted surveillance.
Endusers will give up privacy in a heartbeat.
That is their decision to make. When PTIO gives up privacy, it's a disservice. Users can do what they want but PTIO's duty is to endorse privacy-respecting tools regardless of whether a user wants privacy or not.
Someone produced a 3rd party app [called LibreSignal] and OWS refused to allow that app on their network [i.e. to connect to servers paid for and run by OWS]. So the software freedom does not exist with OWS Signal
You seem to misunderstand the meaning of the four freedoms.
I know the 4 freedoms quite well. You seem not to, as you apparently don't realize the purpose and big-picture motivation behind them, and the ultimate utilitarian benefit that manifests from the 4 freedoms when there are no shenanigans to pervert software freedom. With only a shallow superficial understanding of the 4 freedoms you're vulnerable to allowing misplacement of power in a way that undermines those who the 4 freedoms were designed to benefit. OWS is a good example of how the free software label can be abused for marketing purposes without actually empowering the users.
[OWS / SignalFoundation] capitalized on the marketing benefit of free software licensing [the 100% GPLv3/AGPLv3 codebase of signalapp] but implement a policy [non-federation plus unofficial-clients-mostly-prohibited] that prevents the freedoms of free software from actually having a practical usable effect.
This is wrong. GPLv3 gives you the freedom to run the codebase, for any purpose. It does not give you the “freedom” to demand that the people who gave you that GPLv3 codebase, and thereby gave you the liberty to run the code for any purpose, must supply YOU with free-as-in-beer server bandwidth FOREVER. No, that is a gigantic misinterpretation of what freedom is. Here are the four freedoms == https://en.wikipedia.org/wiki/Free_software#Definition
It's not wrong. Everything in that quote was accurately stated. For some reason you interpreted what I said as being non-compliant with the freedoms, but I never claimed a GPL violation in the part that you quoted. Go back and re-read what you replied to.
You can also license a work as free software (GPLv3) but then never distribute it. While it is technically free software, it fails to empower the public.
I do indeed claim non-free software elsewhere, however, because the Google reCAPTCHA is implemented with non-free javascript that Signal forces users to execute.
...The differences between these systems is privacy of the metadata... nothing is as broken and reckless as Signal with respect to privacy. Jami and Wire are both better
You think wireapp has better metadata-resistance than signalapp? https://en.wikipedia.org/wiki/Wire_(software)#Metadata versus https://en.wikipedia.org/wiki/Signal_(software)#Metadata seems like night versus day, to me.
I'm familiar with Wire's metadata leak, just as I am with OWS tracking the identities of each user. Wire users can be anonymously associated while OWS users are not anonymous in the first place and associated within OWS even if the OWS data is not disclosed as plaintext. Given the huge list of privacy abuses, Signal is far less aligned with PTIO's mission statement than Wire overall. Jami is more aligned with PTIO's mission than both Signal and Wire.
five-c-d
commented
5 years ago "Popularity" is necessary for proper crypto, because only projects that have enough popularity get security audits. Projects that are unpopular amongst serious cryptographers -- whether that unpopularity is "merited" or just bad luck -- are NOT WELL VETTED. Apologies for the shouting, but it seems needful.
You are flat out saying, with no varnish and no nuance whatsoever, that "all these alternatives to signalapp -- none of which use Signal(TM) Protocol -- are just as good at payload privacy" aka have the same quality of crypto. That is utter nonsense. I think you know it is nonsense, you obviously know a lot about messengers, and care a lot about privacy. Cryptosystems must be vetted, and that only begins with the server-side codebase being libre when we are talking messengers.
> You're trying that broken security logic that says "because some aspect of a security system has an imperfection, we therefore must abandon the whole system" I was accusing YOU of doing that, actually :-) See next two points > there's no reason to force users to share information with and financially support Amazon and Google If you want domain-fronting, how else do you suggest it be accomplished? Of course, that has worked out less well than could be hoped. https://signal.org/blog/looking-back-on-the-front But even if you don't care about people in draconian countries with nationalized telco systems in the short term, how do you plan to thwart mass surveillance in the long run, if you don't let the masses download from the most popular appstore onto the most popular smartphone platform?? Google runs both those things, and as you have pointed out, google is in deep. But as several others, not just moi, have pointed out to you: F-Droid is not a "solution" to the playStore because you are still running on android and it still phones home to google, unless you REALLY rip out the innards and install a hyper-specialized max-privacy-no-matter-the-loss-of-convenience heavily customized ROM (i.e. *not* the privacyToolsIO target-audience). > I'm familiar with Wire's metadata leak Then what are you doing comparing them to signalapp *favorably*? Apparently we are talking past each other, but in a lot of the fundamentals we seem to agree. Just, not in how to apply those fundamentals, when it comes to picking winners&losers on the privacyToolsIO listings! > Signal is subjecting users to *mass surveillance* > in a naïve attempt at avoiding *targeted* surveillance. I cannot even fathom how you came to this understanding :-) The whole point of signalapp is to eventually thwart mass surveillance, **of the masses**, which means becoming popular and ubiquitous. Hence, the compromise to be in playStore, because that is where the masses get their apps nowadays. Hence, the compromise to use phone-nums, because that improves usability (which masses *require* or they use Something Else), plus acts as a strong proven-in-practice check on spam with billion-enduser messengers. You think Snowden is endorsing signalapp, because he was hoodwinked? Or because he truly believes Signal Foundation is ***in favor of*** mass surveillance, rather than the nemesis of the mass surveillance apparatus? I am at a loss for words. Signalapp has never been about preventing TAO, it is impossible for a mere app to even *do* that, end2end crypto is **utterly useless** if the endpoint-devices are compromised! I just, this is so backwards of an understanding of what signalapp is doing, it is hard to know where to begin. > PTIO's duty is to endorse privacy-respecting tools Um, yes. We agree on something again ;-) But you have a very odd definition of 'privacy', of the word 'respecting', and maybe also of 'tools' methinks (our disagreement about what *industry* we are even discussing and who is versus who is not competitive therein). Yeah, I agree that privacy is crucial, and that surveillance-even-to-beat-spammers is unacceptable. But as other have pointed out, you strongly equate privacy with modicum-of-anonymity, 100% anonymity being nigh-impossible, when anonymity is only a portion of privacy broadly construed. Moreover, depending on one's individualized threat-model, what matters is normally *who* can de-anonymize you. (NSA? Facebook? Verizon? local cops? head of the municipal political party? sysadmin at the local ISP? corporate competitor? border guards? mall cops? nosy neighbor? unfriendly coworker? these are **very different threats** and dealt with using very different tactics.) You *also* seemingly equate "privacy" with "does not run on any servers owned by corporations that do not share my values" which is getting pretty far away from PRIVACY of what is communicated (encrypted payload) and with whom (metadata payload). You recommend wireapp, yet they have awful metadata-handling, and poorly-vetted crypto. You want signalapp delisted from the FSF, delisted from privacyToolsIO, and so on -- despite the best-in-class metadata-resistance and the best-on-the-planet crypto-vetting. Are there "better" messengers if you cannot stomach a phone-num as identifier? Yes, to some degree... on paper... but only if you are willing to lose the crypto-vetting advantages and the usability advantages: with messengers, what matters is who you can message, more than anything else. Bob Metcalfe from the 1970s, this is ancient knowledge. > there's a problem with endorsing a tool [by listing it on privacyToolsIO] that does not liberate other users [i.e. people who refuse to own smartphones at all and do everything from linux-on-the-desktop] from google. A google fan [i.e. anybody with a smartphone] **should** be able to talk to someone who entirely opts out [and never connects to a google server nor an amazon server nor owns any phone-number whatsoever] Emphasis added. But like I said above: what matters, is WHO you can message, i.e. "popularity" of the messenger. Even for yourself that is a primary consideration. And why you are here trying to get signalapp delisted, since it does not satisfy you, and get Jami listed, since it does satisfy you. I think the keyword there, in your demand above, is "should" ...as in, you believe any messaging system ought to be designed with your desires and circumstances in mind. * You want the ability to register for signalapp, without owning a phone, because you won't financially support any telco carrier/operator. (But where do you get your internet-connectivity from if not a corporate-run capitalist backbone provider? Are all internet providers ethical?) * You want the ability to send messages and attachments without Amazon AWS nor Google FCM ever touching your system. (But yet you comment here on AWS-hosted github, owned by Microsoft? And yet, going even further, you *recommend* wireapp which includes Firebase Analytics *enabled* **plus** stores all that metadata server-side?) * You don't like OWS because they refused to let LibreSignal use the Signal server bandwidth and the Signal trademark, and therefore they are evil, according to your -- misguided I believe -- spin on the 4 freedoms. (But yet you do like and recommend Wireapp which sued Moxie for extortion when they make a poor knockoff of his crypto?) * You want the ability to install signal4desktop onto the esoteric PC platform of your choice, presumably (and here signalapp does have some lack... such as TailsOS support... but failure to be in the official debian-hosted-repo is *not* one of the downsides, the signalOrg-repo is more than sufficient for linux-on-the-desktop folks to get things done, and pretending where the repo is located is some kind of **privacy** problem would be flat out disingenous. It is a platform-annoyance.) > undermines those who the 4 freedoms were designed to benefit The GPL was specifically written to benefit *everybody*, all of humanity, including people you dislike ethically. But the GPL was very specifically written *not* to put burden on the person-or-corporation that was releasing the GPL'd codebase: "AS-IS" means no liability. GPL is friendly to corporations, and to commercialization. https://en.wikipedia.org/wiki/GNU_General_Public_License#Terms_and_conditions
you interpreted what I said as being non-compliant with the freedoms
Yes, that was my interpretation. When you say, in effect, "oh we want to use your GPL'd signal4android but only if YOU pay for the server bandwidth on signal4server nodes so WE can chat with our hardforks" then yeah, you have lost sight of the big picture, to me.
Freedom to use/study/modify/redistribute, nowhere at any point has ever included "freedom" to force the original author of the codebase to host a server for you. Run your own server if you like, the codebase is AGPLv3, but don't demand somebody pay your hosting fees, that is not what free-as-in-freedom is all about. If that is not what you are saying, then accept my apologies, I will re-read... but you seem pretty clearly to be saying, exactly that.
Jami is more aligned
They have a google tracker. And you know they have a google tracker. Same as wireapp, which has the same google tracker, as I noted immediately above, so you know that as well. Maybe those projects are just "accidentally" including the Google Firebase Analytics module... it is quite difficult to kick out, you have to manually exclude the analytics-stuff. Which signalapp has done, but Jami and Wireapp as yet have not. Signalapp inadvertently included the tracker -- albeit disabled and not actually active -- in the 4.33.5 release, but still, quickly corrected the mistake in time for the next stable-channel release.
jonaharagon
commented
5 years ago This almost feels as if you're intentionally misinterpeting what I replied.
Privacy is not necessarily anonymity and not recommending tools because they don't keep you completely anonymous online is gatekeeping, and it might not even be a concern for some people.
Anonymity is privacy. Specifically, it's privacy of identity. And it's sensitive. It's not okay to expose who is talking to who.
Anonymity is privacy yes, but privacy is not necessarily a key part of privacy to many people, it depends on your objectives. Like I said, different people have different threat models and pretending that everyone needs to conform to a very narrow form of "privacy" is ridiculous.
It again, depends on your privacy objectives. Like @five-c-d said, "It is an important consideration, but strongly depends on your threat-model as to whether it is a dealbreaker-consideration."
Many people including myself don't need complete anonymity online, but are pursuing better ways to keep their personal information such as instant messages private from third-parties, advertisers, and large corporations. Moving to Signal from an app like Google Hangouts for example would be a great move to many.
[...] Forcing someone to enter the marketplace and buy a phone harms privacy in a number of ways. Even if the purchase is offline, with cash, in a shop without CCTV, most phone makers are lobbying against privacy and many abuse users' privacy through spyware and configuration limitations. So privacy-focused consumers are being forced by OWS to spend their money in a way that is counter to their own privacy interest. [...]
The issues you're outlining here have nothing to do with Signal as a product, but the fact that you need to own a mobile device to use it? By that criteria should we not make any recommendations for mobile device users? Should we not recommend people use NetGuard or Blokada on Android because the second they touch a phone all hope of privacy is lost?
I also think we might be missing the point that Signal is largely an SMS replacement.
It fails as an SMS replacement because it relies on phone registration. It's not a replacement, it's a supplement. Competing systems do entirely replace SMS because they don't require phone reg.
This is just semantics. I didn't say it was the perfect SMS successor by any means, but many people use Signal, at least on Android, as a drop-in SMS replacement that requires essentially no additional configuration much like SMS doesn't. If your contact uses Signal and you do too, then you're encrypted. If your contact doesn't use Signal then it will fall back to the same SMS you would've used anyways if you didn't have Signal.
No, this isn't a good solution for sensitive communications, but for many consumers the convenience of this method outweighs the downside of having to use SMS with some encryption holdouts. Signal functioning in this method is a stepping stone between SMS and encrypted communications.
This is true, but as long as the code is open, which theirs is, it doesn't seem like an issue to me.
This has been tested. Someone produced a 3rd party app and OWS refused to allow that app on their network. So the software freedom does not exist with OWS Signal. So you're apparently proposing a lower standard -- open source instead of free software. The problem with open source is that the creator still wields all the power and control. Like Facebook they can do what they want after acquiring the power of mass acceptance and resistance is futile.
I was primarily commenting on the lack of federation, and I could have been more clear about that.
The other point you made does seem to fall short however. Yes, a third party client was developed and removed, but it was ostensibly removed because it had Signal in the name, and I have no reason to believe otherwise. Signal is presumably a trademark of OWS and depending on jurisdiction they may have had to enforce that in order to retain their trademark, but I can't really comment on that or know for sure. Has some third party client been taken down that doesn't use Signal in the name?
Them taking LibreSignal down would be the same as if someone developed a version of Firefox without Pocket or whatever weird things Mozilla is now including, and calling it Firefox 2.0. Of course Mozilla would take that project down. Trademark enforcement has nothing to do with FOSS.
Wire does the same thing for example.
I've not heard of any cases of Wire bullying 3rd party authors. AFAIK, Wire s/w is truly free s/w. Is there an article to the contrary?
I was pointing out that Wire is also not federated, and is in fact a completely closed communication system that is controlled by the Wire developers. Never was I commenting on third-party clients.
ghost
commented
5 years ago You're trying that broken security logic that says "because some aspect of a security system has an imperfection, we therefore must abandon the whole system"
I was accusing YOU of doing that, actually :-) See next two points
Yes I know, it was a straw man, and the straw man was compelled by your use of that broken logic (apart from the straw man also being broken logic).
But even if you don't care about people in draconian countries with nationalized telco systems in the short term, how do you plan to thwart mass surveillance in the long run, if you don't let the masses download from the most popular appstore onto the most popular smartphone platform??
It's the other way around. It's pushing users to a single large centralized repository that makes it easy for repressive governments to compromise the distribution. Big players like Yahoo, Google, Microsoft, Apple all have big business in every country and can and will dance to maximize profits.
You also fail seem to be unaware of PRISM, and how the relationship between fortune 500 companies and the US government operate. When Playstore data is centrally located along with a shit ton of other data on a person, it's a mass surveillance wet dream because it's trivial and convenient in many ways for the government to get the data outside of the legal system.
F-Droid is not a "solution" to the playStore because you are still running on android and it still phones home to google,
Google is an adversary of privacy who collects and exploits data in large variety of ways. To say that you might as well give Google everything because there is some data sharing that is hard to stop is patently stupid. Even if we neglect the users who circumvent phoning home, the phoning home does not collect all the same data that Playstore does. And even if it were to hypothetically, it would still be foolish to do that disclosure which would then nullify the value in circumventing the home phoning mechanism.
unless you REALLY rip out the innards and install a hyper-specialized max-privacy-no-matter-the-loss-of-convenience heavily customized ROM (i.e. not the privacyToolsIO target-audience).
Are you infosec-handbook back with another userid? Read my replies - this has already been addressed and you've added nothing new.
I'm familiar with Wire's metadata leak
Then what are you doing comparing them to signalapp favorably?
That was already answered. To be brief, I'm not repeating myself. Reply to my answer if you want to advance on that point.
The whole point of signalapp is to eventually thwart mass surveillance,
OWS would like you to think that, but obviously subjecting users to Google surveillance is a profoundly foolish way to "thwart mass surveillance".
of the masses, which means becoming popular and ubiquitous. Hence, the compromise to be in playStore, because that is where the masses get their apps nowadays.
Centralization in a corporate walled-garden is conducive to mass surveillance.
Hence, the compromise to use phone-nums, because that improves usability (which masses require or they use Something Else), plus acts as a strong proven-in-practice check on spam with billion-enduser messengers.
This is a profoundly absurd attempt to justify phone registration. I do not believe the PTIO audience is incapable of other ways of identifying users.
You think Snowden is endorsing signalapp, because he was hoodwinked? Or because he truly believes Signal Foundation is in favor of mass surveillance, rather than the nemesis of the mass surveillance apparatus? I am at a loss for words.
Snowden as well as Bruce Schneier are competent but not infallible. I've seen bad advice come from both of them. Your appeal to authority shows your desperation in your highly motivated loyalty to OWS. We can speculate all day about Snowden's endorsement that you can trust anything in general from OWS. Snowden's statement is not a specific endorsement of Signal and he did not compare Signal and choose a lesser of evils. We don't know the context of the statement, but the kind of statement he made is likely after being asked about OWS, and not framed in a way that asks him to compare a number of tools the way PTIO is. We don't know when the comment was made; maybe phone registration wasn't in force when he made the comment. Snowden probably didn't read moxie's responses to F-Droid requests either.
The claim that OWS is naturally trustworthy doesn't stand up to what we know from this thread. It's evident from OWS shenanigans to push users into Playstore while discouraging and hiding the APK download and the fact that OWS admitted that it was to obtain stats makes it clear they are not trustworthy. They are a corporation behaving like a typical corporation. Their refusal to federate is while at the same time requiring phone reg on their own network is another clear indicator that corporate greed is above what's best for user privacy.
Signalapp has never been about preventing TAO, it is impossible for a mere app to even do that, end2end crypto is utterly useless if the endpoint-devices are compromised! I just, this is so backwards of an understanding of what signalapp is doing, it is hard to know where to begin.
You're not in touch with the discussion. It's not me who claimed Signalapp prevents TAO or that it needs to. I've repeatedly stated this is about mass surveillance. When you claimed this before, I referred you to https://github.com/privacytoolsIO/privacytools.io/issues/779#issuecomment-471975275. Please read that so you can stop recycling this claim. It's OWS who uses TAO-avoidance as an excuse to downplay the APK download, while subjecting users of the mass surveillance of Playstore.
But as other have pointed out, you strongly equate privacy with modicum-of-anonymity,
Phone registration abuses privacy in copious many ways. To suggest that avoiding phone registration only gives you "modicum-of-anonymity" indicates how far you are from understanding the privacy of it. I cannot deliver a whole book of knowledge to you in this thread.
100% anonymity being nigh-impossible, when anonymity is only a portion of privacy broadly construed.
This is that broken argument that if you cannot have absolute security then don't even bother. It's absurd. I shouldn't have to address this.
Moreover, depending on one's individualized threat-model, what matters is normally who can de-anonymize you.
The threat model is mass surveillance, so what matters is not how anonymity from targeted attack. If you do the phone reg. process, you've tossed any possibility of anonymity out the window and failed to mitigate mass surveillance.
You also seemingly equate "privacy" with "does not run on any servers owned by corporations that do not share my values" which is getting pretty far away from PRIVACY of what is communicated (encrypted payload) and with whom (metadata payload).
Supporting a corporate privacy abuser inherently supports mass surveillance. It's directly contrary to the PTIO mission.
Emphasis added. But like I said above: what matters, is WHO you can message, i.e. "popularity" of the messenger.
No, popularity does not matter in the context of the PTIO mission. Go re-read the mission statement. PTIO aside, as far as what matters to individual users, it matters if they can reach their contacts, not necessarily the whole world or a popular majority thereof. Just their own contacts need to be reachable. It's not PTIO's mission to get everyone on the same platform; it's to point out the tool that minimizes mass surveillance. Signal is not that tool.
You want the ability to register for signalapp, without owning a phone, because you won't financially support any telco carrier/operator. (But where do you get your internet-connectivity from if not a corporate-run capitalist backbone provider? Are all internet providers ethical?)
It's a red herring. Please don't clusterfuck this thread with such nonsense. There are both ethical and unethical ISPs. If you follow the supply chain of the ethical ones, it often leads to an unethical one. I personally ensure that I don't needlessly feed unethical suppliers. That means I will not needlessly buy a phone or service from an unethical supplier. OWS creates the need for consumers to support privacy abusers.
You want the ability to send messages and attachments without Amazon AWS nor Google FCM ever touching your system. (But yet you comment here on AWS-hosted github, owned by Microsoft? And yet, going even further, you recommend wireapp which includes Firebase Analytics enabled plus stores all that metadata server-side?)
This is more of the same poor reasoning, where you suggest it's okay to needlessly support privacy abuse in one context because supporting the same bad actor is inevitable in another context involving different information.
You don't like OWS because they refused to let LibreSignal use the Signal server bandwidth and the Signal trademark, and therefore they are evil, according to your -- misguided I believe -- spin on the 4 freedoms. (But yet you do like and recommend Wireapp which sued Moxie for extortion when they make a poor knockoff of his crypto?)
The difference here is that I'm advocating for the users, and you're advocating for a single corporation. OWS blocked a tool that gave users more freedom and privacy. In the unrelated case of Wireapp suing Moxie, you'd have to say more to actually make a down-to-earth case for how this relates to PTIO's endorsement for their users.
You want the ability to install signal4desktop onto the esoteric PC platform of your choice,
Not exactly. You're wasting time with irrelevant claims, but briefly I'll say there is value to having the freedom to modify code and redistribute it in part so that platforms can gain support without OWS control. The network protectionism ruins that.
but failure to be in the official debian-hosted-repo is not one of the downsides, the signalOrg-repo is more than sufficient for linux-on-the-desktop folks to get things done, and pretending where the repo is located is some kind of privacy problem would be flat out disingenous. It is a platform-annoyance.)
This is a straw man. The rationale for acceptance into official Debian repos is quality assurance, which has a very indirect privacy influence. Official Debian packages are entirely supplemental to the upstream repositories and users have choice. The QA benefit was worth mentioning in the OP but like a lot of your comments it's not worth the energy you're putting into it.
The GPL was specifically written to benefit everybody, all of humanity, including people you dislike ethically. But the GPL was very specifically written not to put burden on the person-or-corporation that was releasing the GPL'd codebase:
The software freedoms are declared for the purpose of shifting the power structure to be favorable to the user. The process of codifying the 4 principles into the GPL is imperfect. It's impossible to codify it in a way that catches all possible shenanigans that game the GPL label while shifting power back to the corporation, and an effort to do so risks creating unwanted side-effects. FSF takes a live and let live stance that assumes most GPL developers are inherently good and won't game the system (and rightly so). When an owner of a work goes out of their way to legally undermine people from actually making practical use of the freedoms we can highlight that and move on. It's not legally actionable but it's morally condemnable.
Yes, that was my interpretation. When you say, in effect, "oh we want to use your GPL'd signal4android but only if YOU pay for the server bandwidth on signal4server nodes so WE can chat with our hardforks" then yeah, you have lost sight of the big picture, to me.
Actually the big picture is lost on your part. When a user has a choice between Signal and LibreSignal their network consumption is the same either way. OWS has a right to control their network and bully users of it, but to claim their network is in some way more burdened by someone connecting with LibreSignal than by that same user's use of Signal is unsubstantiated.
Freedom to use/study/modify/redistribute, nowhere at any point has ever included "freedom" to force the original author of the codebase to host a server for you.
This is more of the corporate PR BS spin we've already seen from OWS. It'll work in court but it doesn't fool the public. This does not obviate the point above, and also misses the fact that OWS actually refuses to connect to another network to allow users of other implementations to host their own server and actually communicate with others.
Jami is more aligned They have a google tracker. And you know they have a google tracker.
If you've already read my comment, then why are you making an already defeated point? I've already done the exodus analysis on the F-Droid distributed version of Jami and the Firebase tracker isn't there.
ghost
commented
5 years ago Anonymity is privacy yes, but privacy is not necessarily a key part of privacy to many people, it depends on your objectives. Like I said, different people have different threat models and
The threat model is mass surveillance, which obviously makes anonymity very relevant.
pretending that everyone needs to conform to a very narrow form of "privacy" is ridiculous.
Actually it's disregarding anonymity that narrows the privacy focus. And it's more narrow than the objective to avoid mass surveillance.
It again, depends on your privacy objectives. Like @five-c-d said, "It is an important consideration, but strongly depends on your threat-model as to whether it is a dealbreaker-consideration."
There's no question that anonymity is a factor in the mass surveillance threat model. It's also wrong to say that some people can disregard it because such a stance neglects the deeper benefits of anonymity. E.g. someone may not care that they are identified if their payload is well secured. But if a bug or flaw were to expose the payload, anonymity suddenly becomes much more useful than such a user would have anticipated.
The centerpiece of this discussion is the security in depth principle. It's a bad idea to rely on just one mechanism for protection. Redundancy is proper security. You are proposing needlessly throwing out anonymity when some users have a strict need for it and all other users still benefit from the security in depth of anonymity.
Another way to express this:
The principle of least privilege is the idea that one should not by default give more privilege than necessary. Even if something is not apparently or superficially sensitive, it's backwards to expose it and look for justification to secure it. Competent security policies default to protecting access or information and only remove protection when there is reasonable justification for doing so. There is no reason for IM client users to share needlessly their identity with someone in the role of OWS, particularly when the information being asked does not necessarily exist.
Many people including myself don't need complete anonymity online, but are pursuing better ways to keep their personal information such as instant messages private from third-parties, advertisers, and large corporations.
When you give up anonymity the things you mention here are affected. Advertisers are very clever and have mastered exploiting metadata. It's not just the payload that is sensitive.
Moving to Signal from an app like Google Hangouts for example would be a great move to many.
It's not good enough. It's replacing one walled-garden with five. We can do better.
The issues you're outlining here have nothing to do with Signal as a product, but the fact that you need to own a mobile device to use it?
OWS Signal requires participation in a system of mass surveillance. Of course this is a factor. It's a show-stopping factor in light of systems that don't impose this.
By that criteria should we not make any recommendations for mobile device users?
A mobile device is not just a phone and users of one may or may not have a GSM chip in the device. Those that do have conceded to a lot of abuses but even for them sharing their phone number is still yet another needless abuse.
Should we not recommend people use NetGuard or Blokada on Android because the second they touch a phone all hope of privacy is lost?
Of course not. You can see that kind of thinking throughout @five-c-d's posts. There is no way to use NetGuard without an Android, so it only helps to endorse it. But Signal is not limited to mobile devices which means the endorsement would be reckless to disregard the non-mobile use-cases in play, particularly when competing options have solved that problem.
This is just semantics. I didn't say it was the perfect SMS successor by any means, but many people use Signal, at least on Android, as a drop-in SMS replacement that requires essentially no additional configuration much like SMS doesn't.
I didn't realize you were talking about the e2e crypto over SMS. That's indeed a good point. The problem now is that Signal is being endorsed as an instant messager. In that generalized category Signal is a privacy disaster. But if there were a specific SMS category, Signal may be a lesser of evils in that narrow context.
Perhaps it makes sense to endorse it purely as an SMS tool. But that would need to be carefully written because a lot of normies would mentally equate SMS with IM.
The other point you made does seem to fall short however. Yes, a third party client was developed and removed, but it was ostensibly removed because it had Signal in the name, and I have no reason to believe otherwise. Signal is presumably a trademark of OWS and depending on jurisdiction they may have had to enforce that in order to retain their trademark, but I can't really comment on that or know for sure. Has some third party client been taken down that doesn't use Signal in the name?
The trademark is where OWS obtained legal power to bully. But it's not a trivial trademark case because the mark used was not simply "Signal", which means OWS would have to convince a court that unwitting users would actually confuse LibreSignal with an OWS product due to the substring "Signal". It also was not sufficient for the project to change the name. OWS strong-armed F-Droid into removing it because the app connected to the OWS network. Since a LibreSignal rebranding would still not withstand the network protectionism anyway, the project died.
Them taking LibreSignal down would be the same as if someone developed a version of Firefox without Pocket or whatever weird things Mozilla is now including, and calling it Firefox 2.0.
For that analogy to be accurate the modified version would have to be "LibreFirefox", and Mozilla would have to convince a court that users would likely confuse LibreFirefox with Mozilla Firefox. BTW, there actually is a "Librefox". So in that case using an unmistakable "fox" with "libre" as a prefix is not an issue. OWS would have an uphill battle if LibreSignal did not have to also contend with network protectionism.
Trademark enforcement has nothing to do with FOSS.
Trademark enforcement coupled with network protectionism is the legal force by which software freedom is curtailed.
I've not heard of any cases of Wire bullying 3rd party authors. AFAIK, Wire s/w is truly free s/w. Is there an article to the contrary?
I was pointing out that Wire is also not federated, and is in fact a completely closed communication system that is controlled by the Wire developers. Never was I commenting on third-party clients.
Wire is centralized on AWS just like Signal, but the difference is that Wire is not using network protectionism to thwart development of 3rd party apps. Wire is even open to the idea of XMPP interoperability. So while federating is the best, centralization without network protectionism is still better than what OWS is doing.
five-c-d
commented
5 years ago the difference is that Wire is not using network protectionism
For the unwary reader, who might believe "network protectionism" actually has some literal-definition-of-evil meaning, what @libBletchley is specifically complaining about is the trademarked term Signal, and the bandwidth-costs of the official Signal Server. Any trademark owner including Signal Foundation that wishes to avoid genericide must protect the mark (or lose it forever). Any non-profit entity that does not wish to become ThePirateBay must control who can stream how much multimedia through the server-bandwidth paid for by Signal Foundation.
Plus, as explained above, signal-network is extra-vulnerable to spammers because of the lack of server-side metadata -- contrast with wireapp and riotIM and whatsapp which scarf that up -- so letting ANY spammers gain a toehold inside signal-network is an existential risk. Such as would be guaranteed to happen if LibreSignal decided to allow anybody with an SMTP address to signup, and then blindly gateway'd the encrypted payloads to other signal-network endusers. https://lwn.net/Articles/687294/
No, the key(heh!) difference between wireapp and signalapp is that one has tenfold more field-vetting of the codebase, as well as -- to me more far more crucial -- roughly a thousand-fold better vetting of the crypto-system. Plus of course, the active and openly-acknowledged collection of metadata by wireapp, and the possibly-disabled tracker in the APK ... I haven't checked the manifest myself however.
These serious differences are why signalapp has Scheier and Snowden endorsements, one might presume, and why signalapp has more endusers as well perhaps -- good reputation can sometimes boost adoption. For instance, if that reputation leads to signalapp getting listed by privacyToolsIO, ahem. Which you like to call 'argument by popularity and argument from authority' and then go with the 'we can never truly know what plain words mean.'
Deconstructionism is beneath you, and you should not resort to such things. Snowden did not endorse 'everything by OWS' through some sort of mistake, and he did not mince words. Wireapp folks say flat out that they collect metadata, but because they also say they are 'open to the idea' of STOPPING the centralized collection of metadata onto their AWS infrastructure, you give them a pass? You are arguing from emotion.
broken absurd unaware patently stupid profoundly foolish stupid profoundly absurd desperation probably didn't read shenanigans hiding greed excuse not in touch how far you are from understanding broken absurd Go re-read give up Please don't clusterfuck this thread with such nonsense might as well go whole-hog more of the same poor reasoning supporting the same bad actor You're wasting time like a lot of your comments it's not worth the energy shenanigans game the system control bully misses the fact why are you making an already defeated point?
And from ad hominem, quite a lot of it, even measured as a percentage of your verbiage. Should also be beneath you. Do you think github is like a street protest where whoever screams the loudest into a megaphone "wins" the argument?
Are you infosec-handbook back with another userid? ... your highly motivated loyalty to OWS ... I'm advocating for the users, and you're advocating for a single corporation ... corporate PR BS spin
And you assume a person who disagrees with you -- not even entirely disagrees just partially disagrees -- probably is some kind of a sockpuppet, or a paid corporate shill, or both? Better stop digging if you want to stop sinking. I will ping @infosec-handbook since you somehow forgot to do that when you attacked them.
We are not the same humans. We have never met. We are not on the same continent I'm pretty positive. I know about their website, because they linked to it (they recommend Jami so they cannot be me!), but also because I've seen it once before. So far as I'm aware though, they've never heard of me. Howdy there @infosec-handbook , sorry for dragging you into this :-)
Can you please confirm that you have no financial interest in OWS, are not receiving any kickbacks from Signal Foundation, were not bribed by Moxie Marlinspike nor Brian Acton nor Edward Snowden nor Bruce Schneier, and have not been xkcd 538'd into saying things you would not voluntarily say of your own free will?
And also, that you are not now, and have never been, the same human as myself?
I hereby solemnly swear and affirm, for my own part, that I am not a shill nor a sockpuppet, in any way, whatsoever, and in particular not of infosec-handbook nor any Signal Foundation slash OWS person. I say these things of my own free will: signalapp is the best-in-class software messenger for metadata-resistance and well-vetted crypto, and anybody who says different, does not know what they are talking about.
t1011
commented
5 years ago the difference is that Wire is not using network protectionism
For the unwary reader, who might believe "network protectionism" actually has some literal-definition-of-evil meaning, what @libBletchley is specifically complaining about is the trademarked term Signal, and the bandwidth-costs of the official Signal Server. Any trademark owner including Signal Foundation that wishes to avoid genericide must protect the mark (or lose it forever). Any non-profit entity that does not wish to become ThePirateBay must control who can stream how much multimedia through the server-bandwidth paid for by Signal Foundation.
Plus, as explained above, signal-network is extra-vulnerable to spammers because of the lack of server-side metadata -- contrast with wireapp and riotIM and whatsapp which scarf that up -- so letting ANY spammers gain a toehold inside signal-network is an existential risk. Such as would be guaranteed to happen if LibreSignal decided to allow anybody with an SMTP address to signup, and then blindly gateway'd the encrypted payloads to other signal-network endusers. https://lwn.net/Articles/687294/
No, the key(heh!) difference between wireapp and signalapp is that one has tenfold more field-vetting of the codebase, as well as -- to me more far more crucial -- roughly a thousand-fold better vetting of the crypto-system. Plus of course, the active and openly-acknowledged collection of metadata by wireapp, and the possibly-disabled tracker in the APK ... I haven't checked the manifest myself however.
These serious differences are why signalapp has Scheier and Snowden endorsements, one might presume, and why signalapp has more endusers as well perhaps -- good reputation can sometimes boost adoption. For instance, if that reputation leads to signalapp getting listed by privacyToolsIO, ahem. Which you like to call 'argument by popularity and argument from authority' and then go with the 'we can never truly know what plain words mean.'
Deconstructionism is beneath you, and you should not resort to such things. Snowden did not endorse 'everything by OWS' through some sort of mistake, and he did not mince words. Wireapp folks say flat out that they collect metadata, but because they also say they are 'open to the idea' of STOPPING the centralized collection of metadata onto their AWS infrastructure, you give them a pass? You are arguing from emotion.
broken absurd unaware patently stupid profoundly foolish stupid profoundly absurd desperation probably didn't read shenanigans hiding greed excuse not in touch how far you are from understanding broken absurd Go re-read give up Please don't clusterfuck this thread with such nonsense might as well go whole-hog more of the same poor reasoning supporting the same bad actor You're wasting time like a lot of your comments it's not worth the energy shenanigans game the system control bully misses the fact why are you making an already defeated point?
And from ad hominem, quite a lot of it, even measured as a percentage of your verbiage. Should also be beneath you. Do you think github is like a street protest where whoever screams the loudest into a megaphone "wins" the argument?
Are you infosec-handbook back with another userid? ... your highly motivated loyalty to OWS ... I'm advocating for the users, and you're advocating for a single corporation ... corporate PR BS spin
And you assume a person who disagrees with you -- not even entirely disagrees just partially disagrees -- probably is some kind of a sockpuppet, or a paid corporate shill, or both? Better stop digging if you want to stop sinking. I will ping @infosec-handbook since you somehow forgot to do that when you attacked them.
We are not the same humans. We have never met. We are not on the same continent I'm pretty positive. I know about their website, because they linked to it (they recommend Jami so they cannot be me!), but also because I've seen it once before. So far as I'm aware though, they've never heard of me. Howdy there @infosec-handbook , sorry for dragging you into this :-)
* Can you please confirm that you have no financial interest in OWS, are not receiving any kickbacks from Signal Foundation, were not bribed by Moxie Marlinspike nor Brian Acton nor Edward Snowden nor Bruce Schneier, and have not been xkcd 538'd into saying things you would not voluntarily say of your own free will? * And also, that you are not now, and have never been, the same human as myself?I hereby solemnly swear and affirm, for my own part, that I am not a shill nor a sockpuppet, in any way, whatsoever, and in particular not of infosec-handbook nor any Signal Foundation slash OWS person. I say these things of my own free will: signalapp is the best-in-class software messenger for metadata-resistance and well-vetted crypto, and anybody who says different, does not know what they are talking about.
You write a lot of words and very little on the case, unlike libBletchley. An aggressive method of conversation does not make you more convincing. Aren't you tired of referring to Snowden? The fact that he farted in the media about what Signal uses doesn't make Signal any safer.
ghost
commented
5 years ago A lot of repetitious emotional drivel came from vendor loyal infosec-handbook and five-c-d. I've picked through the garbage to address things worthy of more thought and energy:
Suppose you go to a web page and you are blocked with a statement: "You cannot use your browser of choice because we paid money to host this website and we require you to use our proprietary in-house browser". They also say: "our browser is mostly GPL'd so you are technically free to remove the privacy-abusing non-free components from it, but it's against our ToS for you to actually use the modified version to visit our website." So "free software" is used as a marketing prop, not as a means to liberate or empower the users. A webmaster can legally do that and they can try to justify it however they want, but users would be fools to download such a browser and make themselves pawns. A privacy org would be a bigger fool to endorse such a browser, because we expect a privacy org to have better judgement than the users who would opt to download such a browser.
Now let's say your friends are communicating on that website, so it's harder to walk away from. If you want to talk to your friends you must make yourself a pawn and then become the bait that pressures others to use the proprietary platform. This is what I call viral privacy abuse (1.vii).
This is essentially what OWS is doing with their service. Hosting a service isn't free whether it's blogs, file sharing, or communication. All service providers have bills to pay and must be clever in how they solve the challenge of attracting users, and also profiting (in the case of corporate suppliers). Of all the solutions to that problem, the ones that do relatively more harm to privacy than other solutions are unfit for PTIO endorsement.
Amid all the junk being posted, this article was useful => https://lwn.net/Articles/687294/ A lot of it is redundant with what already appears in this thread. Exceptionally, the anti-federating rationale is laid out in detail. OWS believes federating slows progress. While that's true to some extent, they heavily exaggerate the rate of progress in the federated model (not that it matters). They acknowledge that using an extensible protocol solves that problem, but OWS doesn't like what it does to the user experience (users of one tool may have a feature that others don't have). Nevermind that each tool maker has a natural incentive to keep up with the extensions or get abandoned. But like Steve Jobs, OWS has become heavily bent on controlling the user experience.
When it comes to PTIO endorsement, PTIO does not have as even part of the objective "help suppliers make money" or "help suppliers control the look and feel". The PTIO objective is purely to avoid mass surveillance. When a service optimizes for profit at the cost of privacy it's very unlikely that they are suitable for PTIO endorsement.
signal-network is extra-vulnerable to spammers
When OWS designed a system in such a way that makes it extra-vulnerable to spammers, it's on them to solve their own problem. PTIO's endorsement must be focused on effective privacy from a utilitarian viewpoint, not deontologically-driven excuses. To say vendor X has good reason Y for doing privacy harm is merely an attempt at using sympathy to undermine the PTIO mission.
I've used Wire and Jami and not received a single spam message on them. So even if usability were a factor in the PTIO mission statement, the spam factor would not hinder Wire or Jami endorsements.
| network | who sees the metadata | what the metadata reveals | persistence |
|---|---|---|---|
| OWS | OWS (Amazon can't see the OWS userid's due to encryption, but would see the IP addresses of those using OWS) | identified users |
persistence is short enough that conversation syncing is problematic |
| Wire | Wire and Amazon (due to being plaintext data at rest) | anonymous users and their associations | lives until the account is deleted |
There are clearly issues with both services. With OWS, you have to trust that they do not track the relationships between identified people. they do not log accesses from their identified users. With Wire, it's certain that the relationship data is logged and kept for the life of an account and Amazon has a view of it. Wire users are anonymous but Amazon can likely deanonymize those who use their shop with the same IP address - although it's automatically avoided by Tor users as Wire automatically discovers and uses Tor if it is installed.
Which of the two come out ahead on the metadata compromise really depends on the user. Considering OWS has such a long list of other privacy abuses, even if we can say it's favorable on this issue it loses on the 10,000 foot view of everything.
five-c-d
commented
5 years ago You write a lot of words and very little on the case, unlike libBletchley.
We must disagree about what "the case" is here, I guess. Like @libBletchley though, I very definitely do write a lot of words.
Here is The Case being made: libBletchley is aggressively arguing that signalapp should be removed (as in completely delisted rather than being demoted to the WorthMentioning section), because it has some stuff tied to google, and runs on AWS webservers, and uses phone-numbers from MaBell, plus also (presumably) is in a FiveEyes country which is used as an exclusion-criteria for the VPN-section of privacyToolsIO (no TunnelBear-of-Canada). To replace signalapp, libBletchley specifically recommends wireapp, which is currently listed in WorthMentioning with the "experimental" warning-note attached. The wireapp APK includes a google tracker, wireapp servers run on AWS, wireapp uses phone-nums by default but CAN optionally support non-phone-nums, and although the server-nodes are in Switzerland/EU the people running those servers are HQ'd in the USA. Wireapp has worse-vetted crypto than signalapp, Proteus-protocol is nowhere near as used/known/endorsed. Wireapp purposely stores all metadata server-side. Wireapp is not a good choice to green-highlight for IM on mobiles, though it is fine to list in WorthMentioning methinks.
Jami is not even listed in WorthMentioning of the IM listings (despite offering the feature), but it is listed under WorthMentioning for cryptocalls. Wireapp is blue-highlighted for cryptocalls (with a caveat that they retain metadata noted at the bottom), and signalapp is green-highlighted. @libBletchley would like to see signalapp completely delisted here as well, not just demoted to WorthMentioning, on the same basis as mentioned above for IM. And would like to see wireapp promoted to from blue- to green-highlighted, despite the hypocrisy of that stance, as outlined above. When analyzing cryptocalls, there are several things that matter: is the crypto high-quality and well-vetted? Does it use CBR, rather than VBR which is dangerous against an adversary sophisticated enough to use phonologically-driven algorithms? Is the metadata of who-is-calling-whom, end2end encrypted, or recorded server-side in any way? Does the cryptocall reveal the IP address of the caller to the callee, and vice versa? Does the system utilize TURN/STUN services, run by whom, and are these shielded so that the IP address of the caller and callee are not revealed? What happens to call-logs on the client-side, are they stored encrypted? How are contacts organized, via stock addressbook of the smartphone, or internally? What kind of identifier is used to connect to a contact? Is there a way to verify the cryptokeys with that contact directly, to prevent man-in-the-middle attack-vectors? Does the APK have any trackers in it, that upload metadata to third parties, or for that matter, to first-parties? There are probably more, but I consider those the primary ones. Signalapp privacy-answers: yes, yes, deleted ASAP, on-by-default but there is a setting to relay-all-calls, yes (shielded nowadays but formerly were not), yes in sqlCipher, uses default smartphone addressbook by default but can be turned off by denying permissions, signal-num which is a telco-num (can be landline/voip/burner/etc -- need not be cellnum), zero trackers and the only metadata which is stored server-side non-end2end-encrypted are date&time you registered + last day/date you connected to signal-server + the telco-num you selected as your signal-num. There is also the question of usability/functionality: wireapp has an advantage here because it supports confcalls of up to 10 people, whereas signalapp only supports 1-to-1 cryptocalls right now. This is a good reason to blue-highlight wireapp despite their metadata-tracking efforts, methinks: if you need confcalls signalapp is no help to you, and better to select wireapp than whatsapp's 4-way confcalls or skype's 25-way confcalls. Jami also supports confcalls, amongst a theoretically-unlimited-number of participants (good reason to be WorthMentioning), but the downside is that this is only partially implemented: you have to be running jami4windows or jami4linux, there is no confcall support in jami4ios nor jami4android yet, apparently. https://jami.net/features/
An aggressive method of conversation does not make you more convincing.
If you think I'm the one conversing aggressively, as opposed to libBletchley, then I don't think I can help you see reason :-)
Aren't you tired of referring to Snowden? The fact that he farted in the media about what Signal uses doesn't make Signal any safer.
Correct, the endorsement by whistleblowers does not make the crypto secure. But the endorsements by cryptographers, is evidence that the crypto is secure, and the endorsements by whistleblowers and journalists -- like the green-highlighting by privacyToolsIO -- does lend credence to signalapp's reputation as privacy-oriented. Wireapp and Jami do not have green-highlighting by privacyToolsIO, and part of the reason they don't have that, is because they don't have famous cryptographers endorsing their codebases as best-in-class.
Endorsements do matter. Jami is endorsed by the FSF, which to me is a clear-as-a-bell strong indicator the code is libre to the core. But the FSF is not about cryptography, and if you want privacy, the crypto protecting that privacy has to be sound. Where is the evidence that wireapp's crypto is sound? Where is the evidence that Jami's crypto is sound? Does it even have perfect forward secrecy?
I've used Wire and Jami and not received a single spam message on them
Yes, I believe you. They have tenfold (wireapp) to a hundredfold (jami) lower of a userbase than signalapp, which itself is merely in the millions-of-endusers. By contrast, I have been spammed via using signalapp: some dentist sent an SMS spam, and signalapp requires me to have a valid telco-num, so in some sense I blame Moxie for me getting that spam :-) But for a privacy-respecting messenger to have enough endusers to matter when it comes to thwarting mass surveillance, it needs to be used BY the masses, which means billions of humans. If the architecture is wrong then you get spam: SMTP has spam. And if the architecture of that wrong thing is federated, you get a proprietary centralized anti-spam predator swooping in to cannibalize the success: gmail has anti-spam, and running your own SMTP server nowadays is nigh-impossible. https://www.jwz.org/blog/2018/06/starttls-everywhere
But like with your comment about crypto-strength ("No payload-disclosing exploits exist") you are incorrect about how spam-prevention mechanisms work. Absence of exploits in the wild is not evidence that the code has no security-flaws. Absence of spam in the wild is not evidence that the messenging-architecture is spam-resistant. Wireapp has a spam-resistant architecture, because like whatsapp, they store all the metadata server-side. If spam becomes a problem as the wireapp userbase grows, they can scan for it server-side, much like protonmail does with spam-assassin (protonmail does not encrypt subject-lines partly for this reason).
Signalapp has a spam-resistant architecture because the block-button is the first thing that pops up when a new contact messages you, because there is a single master-device required in every sync-set, and because creating a new persona with a new signal-num currently requires ability to receive inbound verification-code via robo-call to a valid unique telco-num. This also has usability benefits: everyday endusers know what a phone-num is, and know how to receive a robo-call, so they automatically grok how to cryptocall via signalapp. Jami has a complex system of identifiers: SIP-based phone-nums as well as Ring.cx accounts and optional Ethereum-based usernames. Is that a spam-resistant architecture? Dunno, but I do know it is probably too complicated for poor Dave-from-Denmark to grok.
I believe that RiotIM is also working on confcalls, but they are *not* listed with the experimental-tag in WorthMentioning of the voip section, right now? Might still be too-experimental, from this comment... https://github.com/vector-im/riot-web/issues/6444#issuecomment-381594269 The fallback is to use Jitsi-with-RiotIM for confcalls it seems (and Jitsi *is* listed in WorthMentioning). Edit: nevermind... they *are* working on it, but only the RiotIM client supports confcalls at present, and is basically a fork of the jitsi codebase, if this comment is correct == https://github.com/privacytoolsIO/privacytools.io/pull/562#issuecomment-459584980
jonaharagon
commented
5 years ago Wireapp and Jami do not have green-highlighting by privacyToolsIO
five-c-d
commented
5 years ago For most categories the colorization is purely aesthetic (or something :-) But for the IM category, it seems to be divided up by platform: signalapp is the recommended IM for mobile-device-endusers, Ricochet is the recommended IM for desktop-endusers (signal4desktop is a slave-device which cannot perform cryptocalls yet but it works fine for chat / voiceNotes / photos / videos / hyperlinks / etc). Is the "mobile" intended to be a limitation of signalapp, not a here-is-the-tool-we-recommend-for-this-kind-of-device, kind of thing? If so the word can potentially be removed from the IM-listing ... depending on how non-reverse-tethered slave-devices are treated ... albeit needs to be retained as a limitation in the VoIP-listing of signalapp.
With the VoIP category both signalapp and wireapp are recommended, jami is WorthMentioning, and it is not divided up by platform explicitly (though signalapp says 'mobile' because signal4desktop cannot handle cryptocalls yet).
In any case, I was under the impression that being "listed first" was also supposed to be somehow meaningful, even if the coloration itself was not meaningful. Is that incorrect? (The exception being things like VPNs where listing is alphabetical.)
ghost
commented
5 years ago Here is The Case being made: libBletchley is "aggressively" arguing that signalapp should be removed (as in completely delisted rather than being demoted to the WorthMentioning section)...would like to see wireapp promoted to from blue- to green-highlighted, despite the hypocrisy of that stance, as outlined above.
(scare quotes mine)
When multiple tools satisfy the PTIO mission objective to avoid mass surveillance, it's sensible to list all of them and rank them if there are significant differences in overall privacy. But Signal is unworthy of mention because it actually subjects users to mass surveillance, and is by no stretch of the imagination even close to the options that do not impose ~4 or 5 different walled-gardens on users. If there would an Avoid list for IM tools, OWS Signal would be worthy of that list.
To replace signalapp, libBletchley specifically recommends wireapp, which is currently listed in WorthMentioning with the "experimental" warning-note attached.
It's a straw man to claim I'm advocating for Wire as a top endorsement. I never said that. I said that both Wire and Jami are more suitable w.r.t. PTIO's mission. I also condemn privacy abuses on the part of Wire and in fact link to them in the OP to my bug reports against Wire. For you take what I've said about Wire's shortcomings (cleartext metadata, the Swiss-hosting lie, Amazon) and present them whilst using this straw man is intellectual dishonesty. Shame on you.
Jami is not even listed in WorthMentioning of the IM listings (despite offering the feature), but it is listed under WorthMentioning for cryptocalls. ... signalapp is green-highlighted.
That's what we're here to settle. We are not enslaved by past decisions (be they poor decisions, or [more likely] lesser informed decisions), most particularly when it's absence of a decision.
When analyzing cryptocalls, there are several things that matter: is the crypto high-quality and well-vetted? Does it use CBR, rather than VBR which is dangerous against an adversary sophisticated enough to use phonologically-driven algorithms? Is the metadata of who-is-calling-whom, end2end encrypted, or recorded server-side in any way? Does the cryptocall reveal the IP address of the caller to the callee, and vice versa? Does the system utilize TURN/STUN services, run by whom, and are these shielded so that the IP address of the caller and callee are not revealed? What happens to call-logs on the client-side, are they stored encrypted? How are contacts organized, via stock addressbook of the smartphone, or internally? What kind of identifier is used to connect to a contact? Is there a way to verify the cryptokeys with that contact directly, to prevent man-in-the-middle attack-vectors? Does the APK have any trackers in it, that upload metadata to third parties, or for that matter, to first-parties? There are probably more, but I consider those the primary ones.
If you can't state which of these questions is answered unfavorably w.r.t. a competing tool, it's useless to merely point out that a privacy abusing tool does something well. Do your own homework. If you find something worthy of mention in the lesser of evils comparison, share it with us at that point.
There is also the question of usability/functionality:
(esoteric detail about X number in conference call support snipped)
This is mostly a red herring in terms of the thesis of the thread. I say "mostly", because there would be relevance if this feature justified a separate category of tools. I think not.
But as I said earlier (which you missed): OWS Signal may potentially be worthy of endorsement if (and only if) a separate and distinct category existed strictly for SMS tools, because in that case it's a different set of competitors. Competitors exist in that category but those projects are out of maintenance (abandoned), so OWS Signal has a chance to come out ahead.
like the green-highlighting by privacyToolsIO -- does lend credence to signalapp's reputation as privacy-oriented. Wireapp and Jami do not have green-highlighting by privacyToolsIO,
So here you've extended your appeal to authority to include PTIO. That's us. The worst kind of appeal to authority is committed when one cites themselves as the authority. Not only does it create more of a distrust, PTIO currently has a credibility problem that needs to be fixed.
But like with your comment about crypto-strength ("No payload-disclosing exploits exist") you are incorrect about how spam-prevention mechanisms work. Absence of exploits in the wild is not evidence that the code has no security-flaws.
It's incorrect for you to imply that code with "no security-flaws" is even a thing. Anything more complex than "Hello World" has security flaws. Accept it. Absence of exploits is favorable, but no one in this thread ever claimed that absence of exploits was in any way the highest standard of security.
We've exposed known, documented, unacceptable privacy abuses on the part of OWS Signal in this thread, and you're here to tell everyone to focus on hypotheticals, with off-the-cuff speculation that not enough eyes have seen the Wire or Jami code. When comparing superficially equally suitable products, it's sensible to dig deep on the QA process (code review process and 3rd party audits). But when a product is obviously so flawed to satisfy the use-case (to avoid mass surveillance) because high-level system design (ows_signal.pdf) actually subjects users to walled-gardens of mass surveillance, it's the wrong tool for the job and therefore there's no point in looking further into how well polished the code is. If the code is high quality, it should be cannabalized and used to support a privacy-respecting project. This is why we embrace the 4 software freedoms. When suitable products are being compared with no obvious show-stopping privacy abuses, then feel free to do a refined analysis of code quality.
ghost
commented
5 years ago Wireapp and Jami do not have green-highlighting by privacyToolsIO
368
I don't think hardly any of the visitors see any significance with the color. If PTIO assigns an unfitting color it will have minimal impact. But for the sake of correctness, the color of Signal in the IM and VOIP categories is moot because it's clear from this thread that it nees to be removed.
What has not been sufficiently discussed is the possibility of listing Signal strictly in an SMS category. If that happens, then it would make sense to downgrade Signal to the most cautioned color available in light of the findings in this thread.
Problem with Signal
Signal has copious privacy issues making it unfit for privacytools.io endorsement.
Playstore history
The Signal-Playstore discussion (quite rightly) never dies. Threads keep popping up over the years and moving, but one thing that never changes is the project's unwillingness to deviate (in short, they want their stats). The most recent discussion lives here if anyone wants to follow it.
Perhaps it's worth mentioning that Google can possibly exceptionally be avoided entirely if a user downloads the source code and compiles it from scratch. I've not verified that, but it's somewhat moot anyway since privacytools.io target users would not be doing that.
bad players involved with OWS Signal
Prostitution ring diagram showing privacy abuses:
(PDF)