rrobin

rrobin, 20 days ago

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.

rrobin, 1 month ago

So lets be clear - there is no way to prevent others from crawling your website if they really want to (AI or non AI).

Sure you can put up a robots.txt or reject certain user agents (if you self host) to try and screen the most common crawlers. But as far as your hosting is concerned the crawler for AI is not too different from e.g. the crawler from google that takes piece of content to show on results. You can put a captcha or equivalent to screen non-humans, but this does not work that well and might also prevent search engines from finding your site (which i don’t know if you want?).

I don’t have a solution for the AI problem, as for the “greed” problem, I think most of us poor folks do one of the following:

• github pages (if you don’t like github then codeberg or one of the other software forges that host pages)
• self host your own http server if its not too much of an hassle
• (make backups, yes always backups)

Now for the AI problem, there are no good solutions, but there are funny ones:

• write stories that seem plausible but hold high jinx in there - if there ever was a good reason for being creative it is "I hope AI crawls my story and the night time news reports that the army is now using trained squirrels as paratroopers"
• double speak - if it works for fictional fascist states it works for AI too - replace all uses of word/expression with another, your readers might be slightly confused but such is life
• turn off your web site at certain times of the day, just show a message showing that it only works outside of US work hours or something

I should point out that none of this will make you famous or raise your SEO rank in search results.

PS: can you share your site, now i’m curious about the stories

rrobin, 1 month ago

There are gemini to http gateways so the content is probably already crawled anyway.

rrobin, 2 months ago

Here is my take as someone who absolutely loves the work simplex did on the SMP protocol, but still does not use SimpleX Chat.

First the trivial stuff:

1. no one else seems to use it
2. UX is not great because of initial exchange

These two are not that unexpected. Any other chat app with E2E security has tricky UX, and SimpleX takes the hard road by not trading off security/privacy for UX. I think this is a plus, but yes it annoys people.

Now for the reasons that really keep me away:

1. the desktop app is way behind the mobile app - and I would really prefer to use a desktop CLI app
2. haskell puts me off a bit - the language is fine I just don’t know how to read it - for more practical issues it did not support older (arm6/7) devices which kept lots of people in older devices away
3. AFAIK no alternative implementations of either the client or the SMP server exist - which is a petty I think the protocol would shine in other contexts (like push notifications)
4. I was going to say that there are not many 3rd party user groups - but I just found out about the directory service (shame on me, maybe? can’t seem to find groups though)
5. protocol features/stabilization is a moving target and most of the fancy new features don’t really interest me (i don’t care much about audio/video)
6. stabilization of code/dependencies would help package the server/client in more linux distros, which I think would help adoption among the tech folk

Finally a couple of points on some of the other comments:

• multi device support - no protocol out there can do multi device properly (not signal, none really) so i’m ok with biting the bullet on this
• VC funding is a drag - but I am still thankful that they clearly specified the chat protocol separate from the message relay, which means that even if the chat app dies, SMP could still be used for other stuff.