Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

❌ Software Removal | Signal #779

Closed
ghost opened this issue Mar 10, 2019 · 95 comments

Comments

Projects
None yet
@ghost
Copy link

commented Mar 10, 2019

Problem with Signal

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

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

Playstore history

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

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

bad players involved with OWS Signal

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

Prostitution ring diagram showing privacy abuses:

(PDF)
ows_signal_design

@pahakalle

This comment has been minimized.

Copy link

commented Mar 10, 2019

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?

@pahakalle

This comment has been minimized.

Copy link

commented Mar 10, 2019

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

@Shifterovich

This comment has been minimized.

Copy link
Member

commented Mar 10, 2019

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

This comment has been minimized.

Copy link
Author

commented Mar 10, 2019

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

This comment has been minimized.

Copy link
Member

commented Mar 11, 2019

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

And Riot.im/Matrix.org appear to be using Cloudflare (#374) and the problems with in general haven't been reported as fixed yet (#562 (comment)).

Ricochet's situation seems uncertain to me at a quick glance, there is #474 arguing it's unmaintained and pointing to #746 in the latest comment.

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

@infosec-handbook

This comment has been minimized.

Copy link
Contributor

commented Mar 11, 2019

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

@Shifterovich

This comment has been minimized.

Copy link
Member

commented Mar 11, 2019

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

This comment has been minimized.

Copy link
Author

commented Mar 12, 2019

@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

This comment has been minimized.

Copy link
Author

commented Mar 12, 2019

@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

This comment has been minimized.

Copy link
Author

commented Mar 12, 2019

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.

@infosec-handbook

This comment has been minimized.

Copy link
Contributor

commented Mar 12, 2019

@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

This comment has been minimized.

Copy link
Author

commented Mar 15, 2019

We own several Czech (green) SIM cards and use them like every other SIM card in red countries like Germany, Austria, Hungary etc. – every day. Last year, we also registered Austrian (red since 2019) SIM cards with Signal and can use them as any other SIM card.

It's hit and miss. My green-region chip doesn't work in red regions. Not to mention it's already quite loony to expect the PTIO target audience to buy a GSM phone and then buy chips for it in another country. It's a nonstarter because their mailing address is not anonymous, the payment method is not anonymous, and if they physically travel to Czech and pay cash they'd be hard-pressed to find a shop without video surveillance. Then once they get the chip they can only use it away from home (due to GSM tracking) and also due to GSM tracking they have to find an CCTV-free place to activate the chip, use it, and then remove the chip. It's completely absurd to propose this as a precursor to establishing an anonymous Signal account.

Additionally, we mentioned the possibility to register a random phone number from the internet that can be locked down by setting up a registration lock PIN.

According to signal docs, users must "retain control of this phone number" and use the reg. lock PIN to prevent compromise. That's an /and/ not an /or/. And again we're still outside the scope of what the PTIO target audience will bother with. Anyone who uses the free-for-all pinger numbers knows they fail 95% of the time. After a number is used to register 6 or so accounts, Twitter, Google, Facebook, etc, blacklists the number. The websites offering pinger numbers sell the use of virgin numbers for a premium and then after those numbers have been spent on the full quota of twitter, google, facebook, and linkedin accounts, etc, then they are opened up to the public who then tries to use them only to find the confirmation code never arrives. Sometimes they work in corner cases for unpopular services, but usually the numbers quickly end up on a list. I've seen these numbers fail even for 2fa at a small hole-in-the-wall university because the school outsourced to an organization that was good at maintaining the blacklists. So what you're suggesting is a non-starter not just because chance of success is low, but also because anyone who has used those services already knows they only work in obscure niche situations and would not even likely attempt it with Signal. And then the users who don't have experience with the SMS pingers are also the ones unlikely to go through the hoops you're suggesting.

I don't even try anymore, generally. If a service demands a phone number, I walk. I have a link farm of pinger number sites from doing this chase in the past and I still personally find it's not worth my time. PTIO should not even be suggesting users waste their time with this - it's demoralizing to PTIO users.

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

That's a bit twisted. The problem is the aggressive push into the privacy abusing walled-garden of Google Playstore. Signal needs to stop overselling the mass surveillance option, and stop hiding the APK. And even then it would only be viable for users advanced enough to handle an APK. Jami is in F-Droid, which is easy enough for novices to use.

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

You don't need to. You say "PTIO does not endorse Signal. Use Jami." Anyone who wants to know the rationale can come here and see ~50+ reasons not to trust Signal+Google+Amazon+CloudFlare.

It's the job of OWS to market Signal, and so far they've failed to demonstrate that they are suitable for PTIO endorsement.

How many people block JS in their web browser, especially on their smartphone? How many people use F-Droid? And are these people really "novice users" as mentioned by you? What about iOS users who can't use F-Droid? What about the real "novice users" who don't know how to install F-Droid and stick with Google's Playstore?

These are exactly the users who need to be guided away from Playstore and over to the F-Droid repo. Keeping them jailed in the Playstore disservices those users. If they come to privacytools.io, they're looking to change that. This is what PRISM-Break does in the "App Store" section. And it's what PTIO should be doing. F-Droid is a fool-proof procedure. Users are told they must allow installations from unknown sources, and then they are automatically taken directly to the config screen where they flip a switch that originally has them isolated on Playstore.

It's unclear what you're trying to say about iOS and how Signal comes out ahead there. Signal and Jami are both available on iOS, which is inherently jailed AFAIK. Both are taking users to iTunes store. Are you saying there's a better alternative to iTunes suitable for novices? Does Signal have a hidden page for that too?

Benefits to dropping Signal

PTIO can actually improve users' options by delisting Signal.

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

Regardless of whether OWS reacts, it currently disservices users for PTIO to be needlessly directing users into the privacy-hostile walled-garden of Google Playstore via OWS, whilst subjecting users to Amazon and potentially CloudFlare as well. This is not what PTIO visitors signed up for.

@infosec-handbook

This comment has been minimized.

Copy link
Contributor

commented Mar 16, 2019

@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

This comment has been minimized.

Copy link

commented Mar 16, 2019

Have you guys actually contacted Signal devs about:

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

Until there actually is a de-facto replacement for Signal that is compatible with or without Gplay-store, I think we really need to try to convince them to shape up their privacy issues where warranted, and accept that we're not an ideal world, while a shitload of people are already using Signal, even though most of them don't even know why.

In that regard. Why don't you post a better solution to Signal devs about how they could replace the phone number and still keep shit simple enough for people to actually use. At least Signal is keeping all their shit up-to-date, which is far better than most other alternatives.

I think the [signal] issue is that updates, and new installs should remain transparent to the user and at one point they decided that using the phone number was smart. Well, it's not as we have seen...

So a possible solution would perhaps be by using a combination of (1) the phone's IMEI and (2) the phones serial number. That way it would be unknown to most potential attackers, while leaving the phone number out of the equation.

Perhaps @greyson-signal (or someone from your team) would care to comment?

@E3V3A

This comment has been minimized.

Copy link

commented Mar 16, 2019

Actually, I just changed my mind.

Please Remove Signal!

As I haven't browsed their issues for quite a long time, I took another look.

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

This comment has been minimized.

Copy link
Author

commented Mar 16, 2019

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.

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

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

It's bizarre that you mention it because I didn't bring it up and it's a shortcoming of Signal. When a standard protocol is used on a decentralized network of free software devices and it naturally gains the momentum of diversity and it's a selling point. While Signal, Wire, Jami, and Telegram all support the same basic platforms, I'm not sure what the value is in that discussion. XMPP trumps in that discussion because users are not just limited to ~4 or 5 apps, but rather old pre-existing apps that users are familiar with have developed plugins. IRSSI users need not install yet another tool that forces them to use a GUI that enslaves them to the look and feel the developers impose. There are irssi plugins for things like XMPP, Omemo, OTR, Mastodon, GNU Social, Twitter, etc.

Signal is open enough that someone could create plugins for different existing tools, but you can't take credit until it's done. And in fact a non-OWS developer did create a free software client for Signal and OWS took a hostile posture and attacked him for it. OWS:

  • threatened legal action under trademark law (claiming that "LibreSignal" would be confused with "Signal")
  • condemned the use of their network by the tools of other people's tools
    In fact, this hostility toward other developers is noteworthy enough to add to the OP. So platform support is actually artificially limited by the same control freak who refuses to use f-droid.

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

Actually it's the other way around. You've proposed something that's only viable for people who live just inside the border of a red region adjacent to a green region, as if that's worth consideration to all people on earth. It was actually me who pointed out why that fails.

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

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

Why is Jami as good as Signal? Why is it better than Matrix-/XMPP-based messengers? Why don't we recommended messengers like Briar? Hopefully you get that just saying "We must quickly drop Signal, and just add my favorite messenger" doesn't work.

This is not a one-person project. It is not the burden of one person to do all the work.

Signal is not the sole endorsement in any category, so it can be dropped without leaving an empty section. Expecting there to be 3 endorsements in every category is ridiculous. There is no inherent need to replace Signal's screen space with another tool. It just happens that Jami does not suffer from any of the 50+ privacy issues that Signal has and is more privacy-focused and freedom-focused. So Jami happens to be a good candidate but in the absence of Jami, Signal should still be condemned in the current state of it.

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

I don't "represent" PTIO target audience. Indeed try to cater for that audience and we all have a duty to do so, but I do not consider myself part of that demographic.

  1. They must know that F-Droid exists,

PTIO has a duty to make that happen.

  1. they must willingly download the F-Droid apk

PTIO has a duty to inspire them.

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

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

This comment has been minimized.

Copy link
Author

commented Mar 16, 2019

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 ghost referenced this issue Mar 16, 2019

Closed

Support Signal messenger #39

@infosec-handbook

This comment has been minimized.

Copy link
Contributor

commented Mar 17, 2019

@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

This comment has been minimized.

Copy link
Author

commented Mar 17, 2019

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.

@quantumpacket

This comment has been minimized.

Copy link

commented Mar 21, 2019

@benfarrel it's point 3 in OP's original post.

@five-c-d

This comment has been minimized.

Copy link

commented Apr 22, 2019

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

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

  1. the reddit-thread describes an endpoint-compromise where one of the participants in the conversation leaked the message-contents and the metadata to the press. Signalapp cannot save you if you trust somebody with secrets, and the person backstabs you. And neither can any of the other chat apps :-)

It is true that signalapp tends to not pretend it can make you pseudonymous, whereas something like Threema -- closed source and thus not in the privacyToolsIO listings -- assigns each person a randomized 5193892429842395 type of threema-identifier seems to be better in that respect. In a sense Threema is better because it is somwhat more plausible to deny that Alice is the human behind 5192892429842395 ... but even then, it is a case of he-said-versus-she-said (Alice saying "that is not my threema identifier" versus the conversation participant Larry who leaked to the press saying "oh yes it is her threema identifier she is lying")

  1. signalapp actually does address deniability at the protocol-level: it is perfectly possible, when Alice with signal-identifier +1-111-111-1111 is actually in a chat with Larry at his +6-666-666-6666 signal-num, for Larry to falsify the transcript by altering his SQLCipher database. It is also possible for Larry to falsify the screenshots without falsifying his signalapp DB, and either technique will dupe some journalists. You can fool some of the people all of the time, and all of the people some of the time, as the old saying goes.

But mathematically speaking, Alice is on solid ground if she wants to say "that is not my signal-num" because in order to register +11111111111 all that is needed is temporary control of the unencrypted SMS-reception of that telco-num. (Signalapp has a registration-lock-PIN to defeat most sorts of SS7 and bribe-the-telco hijacks of Alice's num.) In other words, Alice can plausibly claim "that looks like my telco-num but I don't use that as my signal-num" and back up her story by registering with some secondary-num as her signal-num on her primary handset... might be landline or online-voip-num or whatever... the signal-num need not match up with the simcard-if-any in the android-device Alice is utilizing.

In reality this protocol deniability feature is often not THAT useful, because when one of the conversation-participants is planning to backstab the other, it is usually pretty straightforward to get something 'on the record' which only Alice would know, or otherwise "prove" that signal-num +11111111111 is in fact the same Alice as the person with cell-num +1-111-111-1111. Signalapp is better than most other chat-apps in this respect.

With something like wireapp there is server-side proof that wireapp-identifier "alice@aliceEnterprises.com" was communicating with "larry@evil.inc" on Monday January 1st at 1:11pm ... so although Alice can claim somebody hijacked her work-email, but Larry is saying to the press that oh no it is really her alright, and here is my phone-transcript of chatting with Alice on 1/1, the wireapp server will back me up. And Larry is correct, the wireapp server DOES back him up, even if Alice has deleted her side of the conversation in the meantime. Even if Alice has unregistered her wireapp uid, Larry is still a registered wireapp enduser, and thus I believe the metadata about Larry's conversation with Alice is still stored -- BOTH people have to delete their wireapp identifiers before the server-side metadata is wiped.

If instead of talking about one of the conversation-participants leaking to the press, and you are instead talking about one of the conversation-participants leaking to NSA/GCHQ or CIA/MI6 or at least a powerful law-enforcement group like FBI/EUROPOL, the barrier is much worse, because if the governmental agency has subpoena power over AWS servers and VPN-providers or ISPs on both ends of a chat, they can often using network-layer metadata about what IP sent what size of packet at what time, to put two and two together and show beyond a reasonable doubt that Alice and Larry were communicating.

(This network-layer risk applies to signalapp as well a wireapp ... it is less-applicable to things like Jami. as long as both endusers are exclusively using RingCx hash-identifiers without ethereum-usernames and without SIP-nums associated at any point, but probably the most resistant to such attacks is the now-dormant Ricochet project which uses ricochet:abcd1234123421512 type hash-nums as the sole method of identifiers and Tor as the sole method of transport, if memory serves).

  1. outside the protocol-deniability level, there is the question of shoulder-surfing. From the scant details available, it sounds like this was a conversation-participant purposely leaking. However, it is plausible that what actually happened was a paparazzi-attack-vector: one of the participants was conversing on their endpoint-device, and the press used a combination of a telephoto-lens and a high-resolution digicam to record what was visible on the screen of the device, without the device-owner knowing what happened.

This could happen if the device-owner was in a public place like a restaurant when sending&receiving messages, or this could happen if the device-owner was in their own home but failed to fully close the curtains on their nice big window facing the street. This is also possible with lower-tech shoulder-surfing attacks, where the adversary just stands nearby and peeks over Alice's shoulder whilst she is messaging. No software can truly protect you against this kind of in-person on-the-scene type of attack-vector, because the adversary is breaching physical security rather than breaching the crypto.

Alice is the intended recipient, and Alice's device is the authorized device, but if Alice is using that device from an unsecured location, or if the adversary has found a way to peer into Alice's bedroom with a telephoto-lens setup from the building across the street, signalapp cannot save her. There are some workarounds which Alice might consider utilizing, however, and that signalapp already does support, however.

Addressbook-integration is enabled by default, and Alice can set the names of the people in her contacts-app (the stock one or a more secure and privacy-conscious addressbook app of her choice) to whatever she wishes. Signalapp also supposed the "custom label" field of the addressbook-app, which allows Alice to set the display-phone-num to whatever she wishes, as well. Finally, signalapp will show the signal-avatar of the person Alice is chatting with by default, but if Alice has configured a custom addressbook-avatar for that contact, it will be displayed instead.

This effectively allows Alice to anonymize the titlebar of her sensitive contacts, or of all her contacts, on the primary conversation-list screen when signalapp first opens, and on the chat-history screen. Instead of saying "Larry Leaker, avatar-of-larry's-face.jpg, +6-666-666-6666" at the top of the chat-history with Larry, it would say whatever Alice specified: "Agent L, avatar-of-a-llama.png, +6---__66" for instance is a good choice.

None of this is on by default, because it would make signalapp almost unusably difficult for the everyday enduser, but for endusers at risk of paparazzi with telephoto lens gear or shoulder-surfing thugs or anybody with high-rez spycam gear, it is a helpful feature. Alice can also obscure her chat-messages if she is careful to use asynchronous voice-notes and synchronous cryptocalls audio-only, rather than textual messages and videocalls which might be lip-read by a high-rez spycam conceivably.

None of these measures are any help if the person Alice is communicating with is untrustworthy, however: Alice can set her signal-profile to "Agent A" and set her signal-avatar-pic to "alligator-in-africa.jpg" but Larry can tell the press 'oh yes Alice at AliceEnterprises is really agent-alligator' and give out her signal-num as well. Alice can use a num which is not tied to her identity, but this merely reduces the situation to he-said-she-said...

Alice has to tell Larry 'okay her is my identifier' in order to securely communicate with him, no matter what else she does. Which is true no matter what software app they utilize, of course. If Larry leaks, Alice is in trouble. Signalapp has default settings which might get Alice into trouble... but only if Alice is trusting somebody untrustworthy, in which case, no matter WHAT software Alice is using, she is in trouble!

  1. Although it is on-by-default, to allow things like the setup described above where Alice and Bob are able to use custom-label-fields to obscure their phone-nums on both ends of the conversation from spycams and shoulder-surfing, it actually is possible to setup signalapp without tying into the addressbook-app at all. During installation, you just deny contacts-permission to signal4android or signal4ios, whatever the smartphone you have, and then you get a tabula rasa when you register your signal-num. (Which is typically not linked to your identity if you are going through the hassle of denying addressbook-integration entirely.)

To communicate, one side or the other needs to initiate a chat-session and pump in the signal-num of the other person... this is a one-time-per-contact thing, and I do it like this, it is not too annoying as long as you don't CONSTANTLY find yourself meeting new people all the time. If you are a traveling salesman or something, addressbook-integration is essential and you should get a privacy-respecting addressbook&crm app. But if you have a few dozen contacts that don't rotate their phone-nums all the time, signalapp without any addressbook is pretty straightforward to utilize. They all have to be willing to configure their signal-profile-nickname and ideally some kind of signal-profile-avatar, but for the most part whoever is the most nerdy person can deal with initiating chat-sessions and managing groupchat-memberships and that kind of thing, the others set their own profile-info at install-time and are done messing with anything until they upgrade their handset.

I recommend keeping a "backup copy" of your signalapp contacts either on a piece of paper stored in a secure location, or if you are on signal4android you can export the encrypted-backup-blob and copy the file over to somewhere -- keep the 30-digit restore-passphrase of the backup-blob in a secure location where Eve cannot get it, because the verified-safety-nums are also in the backup-blob and you don't want Eve impersonating you. Stolen or confiscated handsets are not catastrophic so long as you have either the paper-hardcopy of your metadata or the encrypted-backup-blob and the paper-hardcopy of the decrypt-passphrase.

There is no option to set a custom-phone-label within stock signalapp when addressbook-integration is enabled, but it is a two-liner change to the codebase if you want to hand-compile your own APK every few months which disables the phone-num at the top of the titlebar without needing to install and encrypt any privacy-respecting addressbook-app.

  1. At the end of the day, however, signalapp is just an app. It is a piece of software. It runs on your system. You cannot assume that the other person in a chat with you is running the exact same software, exact same OS, and so on. If they have weak opsec, if they are being surveilled with a telephoto lens whilst messaging with you, if they are a leaker or otherwise willing to backstab you, they are untrustworthy and no software can make them trustworthy.

In particular, this is a variant of the most common complaint about signalapp that I hear in the forums, when things like this come up: "...for those... using their real phone number... [name&num] should not appear above texts [in the chat-history] where a recipient you thought you trusted can screenshot..." Or variations on that same theme: signalapp should 100% guarantee that remote devices will delete whatever is sent, signalapp should 100% guarantee that remote devices cannot copy and paste from signalapp into an email client, signalapp should disable the ability to take a screenshot and if Larry tries it should shoot lightning-bolts into his fingertips and then wipe his device for daring to think about leaking Alice's secrets, and so on.

This kind of thing is utterly impossible for any app to accomplish.

I'm not talking hyperbole here, I mean impossible in the literal sense of Not Possible to implement. If you trust the contact not to leak your info to the badguys, and your trust was misplaced and the contact decides to leak your info to the badguys, signalapp cannot save you, and no software can even hypothetically save you. Even if you granted that both ends of the conversation were using DRM-lockdown OSes with remote attestation and mandatory biometric unlocks which provably guarantee that Alice-the-human is chatting with Larry-the-human and both of them are running 100% the right codebase-hashes from the baseband firmware to the OS to the device drivers to the chat-app...

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

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

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

signalapp is better than wireapp, and much better than jami

I'll put it more bluntly this time, to see if I can get through to you, @libBletchley

You don't like telco-firms. You don't own a smartphone. You don't even own a PHONE anymore, or control a telco-num of any kind, because that financially supports telco-firms, and you are boycotting them entirely until they are destroyed by the rise of Jami-fka-RingCx-fka-SFLphone. You think anybody that owns a phone is either a stupid person with a small brain, or an evil person with ulterior motives. You feel superior, because you (nowadays) stick to your principles, no longer trying to acquire quasi-anonymized telco-nums, and you look down your nose at anybody who is unwilling to live their lives on your terms. You don't care than 99% of adults own a phone. They are wrong and you are morally superior.

You run Linux-for-the-desktop, and you approach that in exactly the same fashion: anybody who runs Windows or OSX or iOS or Android or anything but 100% libre OSes, must have a small brain. You don't let yourself think about binary blobs much, or about libreboot ;-) Or maybe you bought a Librem15 which somewhat minimizes those kinds of things. But since you run Debian rather than Trisquel, according to your past statements, I suspect you are just willing to compromise a slight amount. And you have a github-uid, so obviously you are financially supporting microsoft by refusing to boycott their properties, tut tut, what will that do to your uncompromising stances. You think anybody that uses a mainstream operating system (on phones or on laptops or on desktops) is either a stupid person with a small brain, or an evil person with ulterior motives. You feel superior, because you (mostly) stick to your principles, no longer running anything but Debian, and you look down your nose at anybody who is unwilling to live their lives on your terms. You don't care than 99% of adults use a mainstream OS. They are wrong and you are morally superior.

As I keep repeating, if you want to thwart mass surveillance, you have to educate the masses, you have to get the masses to use software that will help thwart mass surveillance, and that means that there will be pragmatic compromises along the way. If you think that Linux-for-the-desktop in the hands of a super-nerd is more secure&private than windows10 in the hands of an everyday enduser, you are 100% correct. If you think that this alone means the everyday enduser has a small brain, you are completely wrong. And if you think that assuming 99% of humanity is 'normies' and telling them to their face they are stupid while you sneer at them, will improve the userbase of Trisquel and Jami, you are in a fantasy-land.

The masses are already in possession of a telco-num. All of them, including you-in-the-past before you decided to go cold turkey and boycott the industry to try and improve privacy and fight mass surveillance. The masses already give out their phone-num to people they communicate with. This is how communication has happened since the early 1900s when telephony was invented. They use their addressbook-app on their smartphone as a way to manage their social-graph. That has been going on for decades and 99.9% of adults do it.

When you give these people signalapp, they can start to have cryptocalls and crypto-texting and NotesToSelf stored in SQLCipher with minimal metadata-leakage, because the server is explicitly designed not to need metadata. But if you want them to actually use it -- aka if you want hundreds of thousands of reviews and tens of millions of downloads like signalapp has achieved in the past nine years -- you have to make it work on platforms they already own (hint: not just work on Linux-for-the-desktop), and you have to make it easy enough for them to remember their identifier (hint: not a RingCx hash-uid nor Ricochet hash-uid), and find their existing contacts (hint: by using EXISTING emails and telco-nums just like signalapp and wireapp do despite the design-compromise that inherently represents).

Ideally, it is best to make it possible for extra-privacy-conscious super-nerds to anonymize their usage of the app. But anonymity is very tough if the adversary is powerful enough. At best you can get only pseudonymity these days; shadow-profiling and network-layer timing analysis and the ever-expanding tracking-industry are too powerful to fully evade whilst communicating with almost anybody

And indeed, if you look up above, you can see that is what is offered by signalapp: the possibility to achieve a modicum of anonymity, and strong metadata-resistance server-side where the opsec-conscious enduser has little power compared to a sophisticated Eve bent on mass surveillance (Eve always tries to pwn the server-cluster because it is the cheapest most effective way to implement mass surveillance).

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

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

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

Is wireapp good crypto? Well, that is hard to say, but it is not awful crypto, despite Moxie's complaining about the wireapp inspired-by codebase. Proteus is not as widely-field-proven and not as well-vetted as signalapp's crypto, which has been on-by-default since 2010 in one form or another, from the very beginning (back in those days signalapp also did not have any metadata-resistance... just like wireapp still has none-to-speak-of). Wireapp also used to be partly proprietary, though nowadays they are not. Signalapp too used to be partly proprietary, and although it was libre-licensed earlier than wireapp, it wasn't by much.

So I don't see a lot of huge differentiation between the two software apps, when it comes to 2019 recommendations: signalapp is better-vetted crypto and about 10x more widely-used (millions of people is "medium-small" in the messenger-industry however), as long as you don't mind the workarounds needed to deal with telco-num identifiers it has best-in-class metadata-resistance. Wireapp is okay crypto, small-but-not-tiny-userbase, terrible on metadata-resistance but that is partly mitigated by the opt-in-email thing. Caveat: however, only as long as you and all your contacts are careful to use Tor+VPNs and avoid the tracking-cookies and hand-compile your own APK without firebaseAnalytics... in which case email-optional is a significant win.

If you are communicating with everyday folks however, the email-thing is going to give you a false sense of security: any Eve sophisticated enough to get five minutes with the server-side metadata will be able to shadow-profile you without any problem whatsoever, and the servers are such juicy targets this is almost impossible to imagine wireHQ folks preventing it. Worse, because wireapp offers a web-client version, Eve just needs to find the weakest link in the groupchat and then get some malware onto any browser they ever use to capture their wireapp credentials and pwn the entire groupchat. Whether this matters depends on the threat-model, aka who the likely adversary is, how sophisticated they are.

Both of these options are 100% libre-licensed, 100% non-federated at the moment (signalapp was federated 2014-2016 and wireapp wants to be federated "someday"), 100% running on AWS, and 100% making compromises in their ancillary support-website-areas because of small teamsizes. Both have not-yet-crystal-clear business-models, though wireapps is pretty obviously going to be some kind of freemium-thing and signalapp's is pretty obviously going to be some kind of donation-and-endowment thing via signal foundation.

Either one of them could someday grow to become the messenger-app which beats out whatsapp-and-skype-and-friends, but neither one of them has done so yet. It is a prediction-problem, as well as a what-to-recommend-today problem: will most endusers be better off with bob@outlook.com as their wireapp-identifier and the downside of server-side metadata? Or will most endusers be better off with +2-222-222-2222 as their signalapp-identifier and the downside of financially supporting the telco industry as a means of spam-prevention within signal-network?

To me the answer it "it depends on whether Bob needs 10-way stream-encrypted confcalls with weak metadata resistance... or N-way purely-client-side-managed pairwise-encrypted groupchats of 50 people... if the former then wireapp, if the latter then signalapp."

But in the long term, signalapp is clearly fighting to thwart mass surveillance, with one cofounder of signal-foundation endorsed repeatedly and in no uncertain terms by Edward Snowden and Bruce Schneier, and the other cofounder of signal-foundation being the facebook billionaire who now advised everybody to Delete Facebook. Will they ever fix the cloudflare screwup, at some point along the way? Will client-side federation ever occur, at some point? Sure, I hope so. I've recommended as much, and I don't have much pull, but it might happen, time will tell.

Wireapp might someday federate, lessen their metadata-resistance weakness (by copying what signalapp does like they did the last time with Proteus most probably), and coming up with a novel way to allow people to register with any valid email address yet somehow prevent spam from consuming the entire wireapp-network AND not stoop to decrypting everything server-side. I'm not very hopeful there because to me wireapp is a typical startup: they are using the freemium endusers as unpaid beta-testers, and they are proprietarizing the key features into their enterprise-grade payware proprietary codebase. If they get popular, just like Telegram they will (my prediction) move to further proprietarize All The Things and thereby monetize the userbase.

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

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

@ghost

This comment has been minimized.

Copy link
Author

commented Apr 22, 2019

the problem was an untrustworthy insider.

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

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

This is not a flaw in how signalapp works,

Actually it is:

  • They've designed the system to collect info that doesn't need to be collected. Unnecessary collection is always vulnerable to exfiltration from outside attacks as well as the insider threat.
  • They've designed a system that doesn't scale without giving up too much security.
  • The system relies on trusting people (insiders). Needless trust is always a bad idea.

I've already exposed the problem here:
#779 (comment)

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

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

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

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

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

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

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

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

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

@five-c-d

This comment has been minimized.

Copy link

commented Apr 22, 2019

You don't understand what occurred, methinks.

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

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

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

  • "chat records obtained by the Guardian reveal [stuff]...
    another participant, who provided the chat records to the Guardian...
    [famous participant] did not respond to a request for comment...
    The Guardian confirmed the identity of those in the chat
    by cross-checking phone numbers attached to the Signal accounts"

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

Google struggles with insiders snooping on emails

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

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

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

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

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

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

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

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

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

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

@ghost

This comment has been minimized.

Copy link
Author

commented Apr 22, 2019

That is what I mean by "untrustworthy insider".

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

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

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

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

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

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

@five-c-d

This comment has been minimized.

Copy link

commented Apr 22, 2019

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

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

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

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

You should not use "untrustworthy insider"

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

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

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

@ghost

This comment has been minimized.

Copy link
Author

commented Apr 22, 2019

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

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

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

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

you don't apply findings carefully and with rigor.

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

@ghost

This comment has been minimized.

Copy link
Author

commented Apr 22, 2019

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

(PDF)
jami

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

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

@five-c-d

This comment has been minimized.

Copy link

commented Apr 22, 2019

because we don't collect phone numbers

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

okay then. and what happened to wireapp, again?

You think that the ethereum blockchain usernames are impervious to law enforcement? You think that the IP address of an everyday enduser, when the Jami APK is auto-updated, will somehow be invisible and undetectable? You think that the playStore version of the Jami APK, which has firebaseAnalytics therein (unlike the fDroid version right which makes it fiiiineeee), will somehow evade any sort of identifiable associations?

You know that Jami is not a silver bullet. There is something about DHT nodes as well, which I don't fully understand... I suspect there are few enough people traversing them, that network-layer monitoring might uniquely identify conversation-participants, in pretty much exactly the way the RIAA/MPAA was able to serve DMCA takedown notices on bittorrent endusers... but that is speculation at this point.

More importantly, you know very well wireapp collects phone-nums, and when they don't collects emails -- nowadays most everday endusers have gmail address which are their legal name. Wireapp prefers to collect both of those, just like Facebook: give us your phone-num so we can keep your facebook-page under your legal name from being hijacked, your privacy is very important to us. Plus uses tracking-cookies at the point of download, and maybe the firebaseAnalytics in the APK as well (unclear whether the tracker is enable or just present-but-disabled).

Yes, I understand your position. You think decentralized messengers are the true solution. And from the lwn link I gave way back up there, you also understand Moxie's position: decentralized messengers are easy pickings for predatory proprietary competitors.

My position is more nuanced: I think both things are correct. But I'm primarily interested in thwarting mass surveillance, and I think the chances of Jami overcoming their incredible deficit in usability and userbase-size and mindshare/vetting is basically zero. I don't mind people using it, but only signalapp and to a lesser extent wireapp (due to less vetting) are feasible options to catch up with the network-effect powering whatsInstaBook.

But my position on wireapp is not nuanced: they store all the metadata-server side. They are not federated now, and as a freemium project which monetizes the userbase by withholding key features, I don't think they ever will be. Where is your diagram for wireapp, listing their political transgressions? It is less boring than your Jami diagram, as you well know :-) If you make a legit wireapp diagram, mirroring the exact structure of your signalapp diagram for ease of comparison, and not pulling any punches, then we will be a lot further along methinks.

Phone numbers do not need to be collected and Jami proves that

I notice you skipped right past wireapp, and onto something else... because the ends justify the means, right? Anything to achieve your endgoal. Whoever screams loudest into the megaphone about the political transgressions will always be the 'winner', eh?

I submit you have not made the case. Jami does not require phone-nums, but Jami does not prove that is a viable approach. Quite the opposite. It has such a vanishingly small userbase, despite being deployed six years before signalapp and five years before whatsapp were even shipped that I disagree it is even something that can be said to work at all. It has such as complicated set of identifiers that I cannot even figure out whether it is spam-resistant at scale. Has anybody vetted the crypto? Oh, but it is the Only Ethical Choice because telco firms are the devil, so that makes up for all the shortcomings? No deal, sorry.

The design of OWS is to start by assuming that everyday endusers will NEVER accept "ricochet:328abae3820283" as their identifier. This is a sound design-decision, because in fact endusers won't accept that :-) You are able to deal with it, I am able to deal with it, but that is because we are wizard-level-three type people willing to using linux-on-the-desktop and eschew even owning a phone-number at all and deal with complex software all day long for a teensy tiny increase in theoretical privacy. As the famous xkcd shows: actual-actual reality, probably nobody cares about those ultra-secure private messages anyways ;-)

I think privacyToolsIO will have the best shot to accomplish the mission to fight mass surveillance, if it concentrates on trying to get people using stock chrome on stock windows and stock whatsInstaBook on stock samsung to start switching over to firefox+3addons on qubes and signalapp on lessGooglyAOSP. This is a huge boost in privacy that will take them from being "the median enduser" to being in the top 10% of all internet citizens in terms of privacy protections.

You want everyday endusers -- so you say at least although I suspect you know perfectly well they won't accept it since your own mom uses wireapp instead of jami -- to be immediately pushed into the top 0.01% where they skip right past firefox-on-qubes and start running hand-compiled UngoogledChromium on Linux-for-the-desktop whilst using Jami with ethereum-blockchain-usernames for all their messenger needs and boycott the telcos completely. As noted up above: my mom ain't gonna do that :-) Not because she is not smart enough, but because those tools you prefer just don't satisfy what she needs. Your mom is not the same as my mom, but if your mom is hand-compiling her own LTS kernel to improve her privacy and refuses to own a telco-num or communicate with anybody who does, well, more power to her. But that is so rare it is almost unheard of.

If she did all that you suggest, my mom and you could chat on Jami, sure... but she would be cut off from all her other contacts, none of whom have any of that stuff. Since she has a desktop PC rather than a laptop, also she would be cut off from the internet any time she was not in her home office! There are a lot of people that are smart enough to want improved privacy, but not if that means constant tool-churn, and DEFINITELY not if that means they can only have a couple thousand fDroid apps and not a couple million playStore apps ... but then, since they cannot own a phone to meet your political demands, they don't even get the fDroid apps do they?

Your position on what is 'ethical' aka politically demanded, is just so unpragmatic I don't even know how to break it to you gently that you are tilting at windmills. Nothing wrong with wanting to change the world for the better. Nothing wrong with boycotting all major corporations in the world, if it makes you feel better. But calling anybody who does not follow your lead, small-brained, is just your hubris talking. And it will not help you change the world the way you are wanting to change things either, it will just hurt your cause by making you look bad (since it is bad behavior).

If you imagine that privacyToolsIO has the vast mindshare to somehow propel Jami to hundreds of millions of endusers, you are once again just flat out impossible-to-put-it-nicely wrong. It's a fine website, it's in the top 100k alexa-ranking in a lot of wealthy countries, but it cannot alter the tide. This is not the year of Linux-on-the-desktop, sorry. And it's not the year that Jami will catch up to wireapp, let alone signalapp. And because decentralized messengers with long hashnums as identifiers tend to be unpopular, the trend of that entire category of messengers -- which never die out completely but never succeed either -- remaining unpopular is likely to continue.

The detailed findings of Signal subjecting users to mass surveillance

Right, because it uses phone-nums, and you hate telcos, and that means only Jami will save us and it must be immediately promoted to top3 and signalapp immediately dropped to the newly-created doghouse. Because you know, if somebody is linked to a bad player, in some tangential fashion -- such as having an apk on the playstore for example -- well that means they are no better than google itself, and privacyToolsIO would not want to align itself with evil google hypercorp now would it?

You are just screaming into the megaphone. Every point you complain about applies to wireapp, with the possible exception of cloudflare (wireapp has a different tracking-analytics thing... with a tracking-cookie to better spy on their webapp-client endusers... so it's hard to call that "better"). But for you wireapp can do no wrong, and if signalapp does the same exact things it is because they are evil.

are well documented and remain uncountered.

I think you confuse "libBletchey refuses to accept their mistakes" with the very different "libBletchey is clearly the 'winner' of the debate". You want a messenger that does not require a phone-handset, and that accepts email-address registration, or better yet, completely anonymous registration, and is 100% libre-licensed. Good. You got one. Go enjoy it.

Oh, you want to boost the userbase of that messenger, so that instead of 607 playStore reviews it can finally crack 1k playStore reviews? Good, go promote it. (And to be clear, I mean, go promote it from notWorthMentioning into the WorthMentioning part of the IM category since I agree that makes sense. But jumping it into the top3 immediately makes zero sense, it is not suitable for everyday endusers.) If you can get it to 30k you will have caught wireapp, and 300k will catch up with signalapp-of-2018. Unless signalapp is growing faster because it has a better reputation and better endorsements and better usability and better crypto and works with OSes and addressbooks that everyday endusers already have by default, Jami might even surpass it someday.

But you don't want Jami to succeed. You want signalapp to fail, because of all the political transgressions you imagine the people at signal foundation and ows must be guilty of. And somehow, fail to check whether any other messengers you promote as better-without-any-qualification-whatsoever, are guilty of? Even when it is pointed out to you, nothing phases you: oh sure jami has trackers but only in the playstore apk and who uses that? Well, almost nobody, you are correct on that point: 50k downloads, but only a 3.9 rating which suggests a good portion uninstalled shortly thereafter.

I'm not interested in seeing whether signalapp can beat jami or wickr or threema or silentPhone, because it has already done so: signalapp has gone from being a niche project to being a well-known name... but only in terms of reputation, not yet in terms of userbase. With luck, it will become either a Minor Messenger with 5% marketshare or a Major Messenger with a billion or more endusers, at which point it will truly become a threat to whatInstaBook and to gmail... until then however, Facebook and Google will continue to dominate (and to a lesser extent Tencent with QQ/WeChat and in certain niches Microsoft with Skype and GroupMe).

I'm not interested in seeing whether wireapp versus signalapp versus riotIM should result in two of them being thrown in the doghouse, because I see them as complementary rather than as competitive in many ways: they compete with skype4biz/Polycom + whatsapp/SMS + slack/IRC, which are fundamentally distinct subsegments within the messenger industry, albeit with overlap. PrivacytoolsIO needs to list them all, ideally with a comparison-chart of pros&cons. You already know that wireapp has 99% the same exact like of 'cons' such as "allows the enduser to register with a telco-num which supports the telephony industry and some of them are large USA corporations which have funded lobbyists that advocate for laws which do bad things once bad politicians pass them" and so on.

@Mikaela

This comment has been minimized.

Copy link
Member

commented Apr 22, 2019

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

I see three two routes forward:

  • #880 for splitting regular and privacy concious recommendations (because WhatsApp is still worse than Signal?) which would place Signal for the regular people.
  • #432 for adding a warning to Signal (like IPFS has in Self-Contained networks?) linking here.
  • just removing Signal that I would be happy to do at this point, but there is no concensur for doing it in this issue, at the Matrix room nor in the team.
@Herohtar

This comment has been minimized.

Copy link

commented Apr 24, 2019

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

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

@ghost

This comment has been minimized.

Copy link
Author

commented Apr 24, 2019

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

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

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

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

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

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

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

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

@3j9fkyahunqoxwqu

This comment has been minimized.

Copy link

commented Apr 25, 2019

Hello

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

@ghost

This comment has been minimized.

Copy link
Author

commented Apr 25, 2019

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

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

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

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

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

@Herohtar

This comment has been minimized.

Copy link

commented Apr 25, 2019

Who is talking to who is leaked to OWS

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

@five-c-d

This comment has been minimized.

Copy link

commented Apr 25, 2019

the false statements they've been caught making

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

whose software can then be replaced with a special version

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

that's a defeated claim

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

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

if your life depends on the anonymity

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

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

sealed sender prevents

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

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

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

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

@ghost

This comment has been minimized.

Copy link
Author

commented Apr 25, 2019

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

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

@five-c-d

This comment has been minimized.

Copy link

commented Apr 25, 2019

OWS can log that if they want

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

@ghost

This comment has been minimized.

Copy link
Author

commented Apr 25, 2019

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

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

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

whose software can then be replaced with a special version

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

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

that's a defeated claim

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

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

@Herohtar

This comment has been minimized.

Copy link

commented Apr 25, 2019

That's security by obscurity.

That's not what that term even means.

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

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

@ghost

This comment has been minimized.

Copy link
Author

commented Apr 25, 2019

That's security by obscurity.

That's not what that term even means.

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

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

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

@Herohtar

This comment has been minimized.

Copy link

commented Apr 25, 2019

That's not how it's been described.

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

@five-c-d

This comment has been minimized.

Copy link

commented Apr 25, 2019

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

From there Google can treat any of their users uniquely if compelled to do so.

And this is applicable to Jami and also to Wireapp, as well, which you know. Every app that offers a playstore variant, could theoretically be targeted. Any app which does not have a playstore variant, is not really suitable for being listed at privacyToolsIO, because it is not something everyday endusers are likely to be comfortable or confident enough to use.

That said: signalapp is specifically built to mitigate that risk, unlike any other messenger app that I'm aware of with the possible exception of BriarMessenger (not listed on privacyToolsIO yet). Signal4android has reproducible builds, and these can be checked against the playstore build, as well as the sideload build. There is a volunteer I know who is doing those exact checks, online in public, and more that I don't know about as well. With time this number will only grow, since signalapp has the userbase to attract such difficult verification and double-checking efforts.

Google can treat any of their users uniquely

How will they accomplish this? Are you asserting that they can bypass the code-signing checks? The APK is signed by Moxie at Signal Foundation, not by Google. (Jami cannot say this on FDroid is my understanding ... the code-signing is done by FDroid people not by Jami.)

It is not impossible to imagine that google might subvert the entire playServices codebase just to get a high-value target. Obviously -- they could do this no matter what the enduser was running, jami or wireapp or whatsapp or the stock sms app -- this is a targeted access operation, purely and clearly an endpoint-attack, which happens to be performed by the OS vendor rather than by an "external" cracker, but is otherwise non-distinct as an attack-vector.

But what if the person in question is running LineageOS sans playServices, and used the sideload APK direct from signal.org? (That is exactly the kind of person who worries about trusting google and yet wants to run signal4android because it has the best-vetted crypto and it has the reproducible builds so the APK can be verified.)

I guess... if they didn't understand how to hit ctrl+u when downloading the APK, and were using their own home IP address without Tor+VPN when they downloaded, theoretically Google might know someone with that laptop, probably installed signalapp, on an unknown device? But like most of your long list of political transgressions, it is a stretch through a long chain of if X then Y which likely means Z and therefore signalapp is evil QED.

All of which applies 100% to your preferred tools, with a vengeance: wireapp actually gives you a tracking-cookie when visiting their download-site, and the same place is where their webapp flavour logins happen. Plus: the wireapp APK has firebaseAnalytics in it, as does jami-from-playstore. Whoops. When you come up with "theoretically google could be forced to crack into the handset of any human running signalapp from playstore" ...sigh.

You act like you are making a huge J'Accuse ... but all that you are doing is pointing out that smartphones are consumer electronics. You own a laptop, presumably with an Intel later than 2007 or an AMD later than 2013 processor. You run debian. If you assume the CPU vendor or the OS vendor is the adversary then is your jami4debian secure? Nope. If you specifically bought a pricey Librem15, or hand-installed libreboot, or something, are you 100% secure against endpoint attacks by powerful sophisticate adversaries? Nope.

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

OWS will follow court orders

There are hundreds of repo-watchers for each flavor of signalapp. The builds are reproducible. The code-signing key-material are on an air-gapped machine. Volunteers are comparing the playstore version to the sideload version on signal.org and there are millions of endusers field-testing the code quality every day.

We have an example of OWS following court orders. Even fighting in court to beat the gag-order. What the record of the court proceedings revealed, when it was unsealed, was: phone-num X is not a signal-num, and we have nothing else about that phone-num. Plus: phone-num Y registered at date/timestamp, and last connected to signal-server sometime on day/date, and is currently a registered signal-num. The last bit the feds could already figure out themselves. Where are the court-cases that demonstrate how much data wireapp

Could a court order delivery of malicious j/s to identified targets and then actually compromise the payload data? This is a risk inherent in having interpreted code downloaded and executed on-the-fly by identified users.

I would also very much like to hear how you imagine this scenario works. As with sealed sender, you just assume the worst is true, and pretend it only applies to signalapp and never to any other messengers, and hurry on past.

What is the exact thing you imagine will occur? Where do you believe the javascript is being served from? What point during usage, will Alice's device be at risk of potentially malicious javascript? Are there any mitigations? Assume she is in a groupchat with 99 members.

Now, do the same comparison, except this time Alice and her groupchat of 99 members are on wireapp. Can any of them be compromised by Google javascript? Can any of them be compromised by wireapp servers, either because the wireapp devs are evil, or because the wireapp servers are pwn'd by an adversary (cracker group or court order), for instance? Does your answer change if zero of the people in Alice's group ever use wire4web and entirely utilize installed flavours?

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

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

example sealed-sender transmission

Signalapp is designed to be end2end crypto. Say that Alice wants to message Bob, and sealed sender is active (it is on-by-default but not always permitted ... this is related to the anti-spam and block-button if memory serves ... sealed sender traffic is above 80% or something like that, maybe higher by now).

  • Alice +1-111-111-1111 composes a message to Bob +2-222-222-2222, hits send
  • the sender-portion is sealed inside a crypto-envelope which only Bob's device can open
  • Alice's device connects to signal-server, using the pinned certs baked into the APK so that Alice is assured she's connecting to the legit server-cluster
  • Alice uploads the payload which says "From: sealed. To: +22222222222"
  • there is a delivery-queue for Bob's device on signal-server, with that signal-num
  • Bob's device checks for messages and downloads the crypto-envelope
  • signal-server deletes the server-side copy, after ACK that the download was ok
  • Bob can decrypt the outer envelope, and then figure out "hey this is from Alice"
  • this is based on the existing long-term encrypted session between Alice and Bob

I dunno if that was all correct, with no omissions and no invalid insertions, but that is basically the process is my understanding.

Now, with timing-analysis, and 100% malicious server-node, and Alice and Bob not being careful about shielding their IP addresses with Tor+VPN perhaps, plus enough days of traffic flow, a sophisticated adversary would be able to connect the dots. Eventually, they would figure out that the IP over here is +2-222-222-2222 and the other IP over there is +1-111-111-1111 ...

now, whether that helps Eve any, depends on whether the IP addresses are geolocatable to anything but the exit-node of an anonymizing network, and whether the telco-nums in question trace back to anything but a simcard purchased with fiat cash (or an online voip num purchased with zCash-filtered-BTC-from-a-mixer).

Maybe the nums were cellnums, and maybe Alice and Bob used their cellnums as their signal-nums ... this is easy and zero-hassle for most endusers, so it is the default. Maybe the IP addresses are their unshielded home ISP dotted-quads, as well -- again, zero hassle, and thus the default. But if so, it would not have mattered whether Alice and Bob were using wireapp (because they would have signed up with their cellnums or with their fname.lname@gmail accounts). And if they are that hassle-averse, Alice and Bob would never use Jami at all (or even have heard of it).

But I think the more telling point is that, if Alice and Bob were that carefree with their personally-identifiable-info, their choice of software would simply not matter, if up against a sophisticated adversary. Weak opsec and humans that leak their own metadata without thinking it through, are never going to be something that software can solve. No matter how well-vetted the crypto, no matter how solid the design, software cannot make Alice and Bob secure if they are behaving insecurely and making it easy for Eve to pwn them.

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

a data replacement that's traceable

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

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

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

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

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

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

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

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

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

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

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

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

@blacklight447-ptio

This comment has been minimized.

Copy link
Member

commented May 13, 2019

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

@Mikaela

This comment has been minimized.

Copy link
Member

commented May 14, 2019

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

@Mikaela Mikaela closed this May 14, 2019

@Mikaela Mikaela added the 👻 label May 20, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.