Threema, Signal .. etc, What makes different?

Discussion in 'privacy technology' started by Abdallah, May 1, 2018.

  1. Abdallah

    Abdallah Registered Member

    Joined:
    Oct 28, 2013
    Posts:
    124
    Location:
    N/A
    Long time ago I was reading about those E2E encryption apps .. I was confused about "Open Source" term as it is not fully understandable why someone should trust an app only because its source code is open to public and not private...

    Most of users will not review/compile its own app (from that source) and build their own infrastructure (servers and so) needed to be fully confident and sure their is no backdoor or weakeness is their setup..

    So, whats the advantage of using (playstore/appstore) edition of that open source app over using that same of other close source apps ( which may also be vetted by independent teams and using trusted and public encryption protocols )..

    I think there are other things to look at when comparing E2E encryption apps other than open VS close source.

    What do think?
     
  2. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,832
    Location:
    UK
    I think it depends. "Trust" has to be relative and conditional.

    For example, E2E encryption sits in a context of hardware, operating systems, communications, remote servers and applications. In almost all instances, the crypto is not broken, its the context.

    And then, what is this for? So, for example, looking at commercial grade requirements, I would consider closed source/proprietary applications - primarily because I'm already more exposed by other things. Examples, Bitlocker/TPM on Windows. Or Bestcrypt. Or Vmware. Or proprietary drivers.

    Where I want different assurance, and also multi-platform operation, then open source and audited becomes far more important. And although I may not have compiled the app myself, there are indicators that can be got from the credibility of the sources and libraries. You can look at bugs and fixes, and the team. And for example, if it's in the repositories, then it's likely to be better inspected and less likely modified to attack you. Of course, the many-eyes notion has been showed to be unreliable.

    The other aspect being, of course, that your E2E leaves you with the clients being trustworthy or not - which already illustrates your correspondents and operational security, none of this is in isolation. Also, your attitude to metadata leakage.

    I think in the medium term, all successful strong crypto applications will need to be open source and independently audited - that's like an entry criterion. I believe a provider can still make money by providing a reliable and responsive service (a bit like the better VPN providers).

    For some applications, I'd not only compile the app, I'd write it myself based on libraries.
     
  3. RockLobster

    RockLobster Registered Member

    Joined:
    Nov 8, 2007
    Posts:
    1,812
    One thing about open source code, even if you don't understand the code you can go to the git and read the maintainers comments and reasons for their commits and their responses to other peoples questions, requests and comments.
    You can, if you read between the lines get a feel for the attitude of the people who are actually running the project which are often not the same people who started it. Open source projects often get abandoned and then picked up by new people and forked to a new project.
    Do they appear to dismiss valid comments for improving security?
    Do they pay lip service to them by agreeing but never actually implement the improvment?
    Do they make excuses for not using better security or encryption algorithms?
    Do they have lame reasons for adding "features" that put security at risk for very little gain? Especially those that include the internet?
    Do they appear to be implementing new superficial features while neglecting issues or requests about the main purpose of the app, which is to provide secure encryption?
    You can also read the "closed" issues brought to the maintainers attention and then closed by the maintainers. They are often more revealing than the open ones when you can see which issues were closed because the devs fixed them and which were closed because the devs dismissed them.
     
    Last edited: May 1, 2018
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.