• 1 Post
  • 3 Comments
Joined 2 years ago
cake
Cake day: June 8th, 2023

help-circle
  • Just pilling on some concrete examples, awesome-gemini is definitely the best place to start looking. There are both converters for the gemtext format and gateways for the protocols.

    For format conversion tools, awesome-gemini already lists a handful of tools.

    From the gemini side there are some gateways for specific websites operated by various people

    • BBC news gemini://freeshell.de/news/bbc.gmi
    • The Guardian gemini://guardian.shit.cx/world/
    • Lots of others gemini://gemi.dev/cgi-bin/waffle.cgi

    These work pretty well for me. I think there were public gateways to open http pages from gemini, but I can’t recall one from the top of my head.

    Some of the gemini browsers support gemini proxies to access http(s) content. You can run it in your own machine. Duckling is the only one I’m familiar (but see the awesome list for more)

    Conversely, to access gemini pages from a web browser portal.mozz.us hosts a gateway (just place whatever gemini link you want in the box).

    One big privacy caveat of using gemini proxies for this is that while this may improve your privacy with regards to javascript/cookies it will reduced it because it makes your behaviour more identifiable from the point of view of the websites you visit (i.e. your proxy is clearly not a browser making it unusual).


  • Depends on what you mean by “secure”, being very loose with the definitions, we have

    • end to end confidentiality (i.e. only you and the intended destination can see the message contents)
    • privacy (only the destination knows i’m sending messages to them)
    • anonymity (no one can find out who you are, where you live, i.e. metadata/identity/etc)

    My personal preference is Simplex.

    Reasoning for a few:

    • Email: even if you use PGP to encrypt messages the server(s) in the delivery path have access to all metadata (sender, receiver, etc, etc). If no encryption is in use, they see everything. Encryption protocols in e-mail only protect the communication between client and server (or hop by hop for server to server)
    • XMPP: similar reasoning to email. i.e. the server knows what you send to who. I should note that XMPP has more options for confidentiality of message content (PGP, OMEMO, others). So I find it preferable to email - but architecturally not too different.
    • IRC: Again similar reasoning to email - even if your IRC server supports TLS, there is no end to end encryption to protect message contents. There were some solutions for message encryption/signing, but I’ve never seen them in the wild.
    • Signal: Good protocol (privacy, confidentiality, etc). Dependency on phone number is a privacy concern for me. I think there are 3rd party servers/apps without the use of phone numbers.
    • Simplex: Probably the strongest privacy protection you can find, but definitely not easy in terms of usability. The assumption is that we do not trust the intermediate server at all (and expose nothing to it), we just leave our encrypted messages there for the receiver to pick up later. It also does some funny stuff like padding messages with garbage.
    • Matrix: In theory it supports end to end encryption in various scenarios, but my experience with it has been so bad (UX, broken encrypted sessions) I only use it for public groups.

    Some more food for though though; these protocols support both group communication and 1-1 messaging - privacy expectations for these two are very different. For example I don’t care too much about confidentiality in a group chat if there are 3000 people in there. It might be more concerned with concealing my phone/name/metadata.

    In general I consider large group chats “public”, I can try to be anonymous, but have no other expectations. e.g. some people use some protocols over ToR because they do not trust the service (or even the destination) but they try to protect their anonymity.

    On a technical note: I don’t think there is any protocol that supports multi-device without some kind of vulnerability in the past. So I would temper my expectations if using these protocols across devices.

    I’m not familiar with the other ones that were mentioned in comments or in the spreadsheet.



  • This is a really nice summary of the practical issues surrounding this.

    There is one more that I would like to call out: how does this client scanning code end up running in your phone? i.e. who pushes it there and keeps it up to date (and by consequence the database).

    I can think of a few options:

    1. The messaging app owner includes this as part of their code, and for every msg/image/etc checks before send (/receive?)
    2. The phone OS vendor puts it there, bakes it as part of the image store/retrieval API - in a sense it works more on your gallery than your messaging app
    3. The phone vendor puts it there, just like they already do for their branded apps.
    4. Your mobile operator puts it there, just like they already do for their stuff

    Each of these has its own problems/challenges. How to compel them to insert this (ahem “backdoor”), and the different risks with each of them.