“Trust” as in: trust it enough to run it on your machine.

(And assuming that you can’t understand code yourself)

  • Septimaeus@infosec.pub
    link
    fedilink
    arrow-up
    15
    arrow-down
    2
    ·
    11 days ago

    Depends heavily on application (access required, sensitivity of data handled, etc) and nature of disagreement as it pertains to trustworthiness.

    Example A: I use Lemmy even though I disagree politically with the original devs because the design appears sound and it doesn’t require access to sensitive data.

    Example B: I won’t use anything from the Proton Foundation because the founders’ personal comportment and political leanings have led me to suspect that they intend to sell user data.

    • Midnight Wolf@lemmy.world
      link
      fedilink
      English
      arrow-up
      9
      ·
      11 days ago

      While I am… suspicious of what the CEO (?) has spouted recently, I am unaware of how that connects to user data. Can you ELI5/summarize/point me in a direction?

      • Septimaeus@infosec.pub
        link
        fedilink
        arrow-up
        5
        arrow-down
        1
        ·
        11 days ago

        That was largely gut-level analysis for my personal decision-making but here are a few of the things I considered:

        1. Value proposition in the context of acquisition, featuring a heavily-marketed privacy brand and a base of privacy-conscious users (harder to profile, more expensive data)
        2. Obfuscation of funding sources via ‘venture philanthropy’ non-profit (a la OpenAI) housing closed-doors for-profit operations
        3. Rapid expansion to full-coverage consumer productivity cloud platform alternatives (vpn, mail, drive, calendar, wallet, passwords, etc)
        4. Weird pattern of being blocked then let through without future contest by numerous data-hungry entities including thiel, and generally just allowed in a few too many privacy-unfriendly places for my taste
        5. And the usual reservations re: privatized privacy and commercial OSS

        Again sorry that’s all hand-wavy. Probably shouldn’t have thrown shade without something more concrete.

      • blurb@sh.itjust.works
        link
        fedilink
        arrow-up
        4
        ·
        11 days ago

        What makes you say that? Any e-mail provider can intercept and read any e-mail they want to. This explanation by cock.li is pretty good on this issue:

        How can I trust you? You can’t. Cock.li doesn’t read or scan your e-mail content in any way, but it’s possible for any e-mail provider to read your e-mail, so you’ll just have to take our word for it. No “encrypted e-mail” provider is preventing this: even if they encrypt incoming mail before storing it, the provider still receives the e-mail in plaintext first, meaning you’re only protected if you assume no one was reading or copying the e-mail as it came in. When possible, you should use X.509 or GPG with your mail correspondents to encrypt your message content and prevent it from ever being handled in plaintext on our servers. You should also download and delete your mail from our servers regularly, which alone is almost as good as encrypting your mail.

      • Septimaeus@infosec.pub
        link
        fedilink
        arrow-up
        2
        ·
        11 days ago

        Yes and most vulnerabilities related to the mail service are, I imagine, related to interop requirements of legacy protocol/clients. I haven’t audited their e2ee but I expect it’s on par with other e2ee cloud providers, and IIRC they passed SOC ii.

        My distrust pertains mostly to their operations during a future exit scenario/acquisition when users are, presumably, more heavily invested in the various offerings of their extended productivity suite.