-
Chan Shen
https://infosec-handbook.eu/blog/xmpp-aitm/
-
Chan Shen
Did XSF members try to fix these issues ???
-
jonas’
Chan Shen, you can use end-to-end encryption (e.g. OMEMO) to avoid the admin reading your messages.
-
jonas’
many servers support the SCRAM authentication, which avoids cleartext passwords (ejabberd disables it by default for reasons™ I think)
-
jonas’
test 1/2 show just data which exists in all server-based communication systems
-
Chan Shen
> jonas’ wrote: > Chan Shen, you can use end-to-end encryption (e.g. OMEMO) to avoid the admin reading your messages. It doesn't fix all of these issues
-
jonas’
(established connections alongside with state and public data)
-
jonas’
all over all, this article documents a lot of things which are kind of obvious when you look at the design decisions of XMPP (and many other protocols). it is a server-based federated chat protocol, which means that things like "injecting (unauthenticated) messages on the server side" is just how things work; if authentication of messages is needed, E2EE (such as OMEMO) needs to be employed to thwart that.
-
jonas’
likewise, the server is used to share data between clients on the same account (such as the roster), which implicitly gives the server some power over the roster…
-
jonas’
(and other such data)
-
Chan Shen
> jonas’ wrote: > all over all, this article documents a lot of things which are kind of obvious when you look at the design decisions of XMPP (and many other protocols). it is a server-based federated chat protocol, which means that things like "injecting (unauthenticated) messages on the server side" is just how things work; if authentication of messages is needed, E2EE (such as OMEMO) needs to be employed to thwart that. > likewise, the server is used to share data between clients on the same account (such as the roster), which implicitly gives the server some power over the roster… > (and other such data) How about matrix ???
-
jonas’
I am no Matrix expert.
-
jonas’
but I am sure if you ask their marketing, they’ll tell you it’s all fine there.
-
jonas’
I am certain that you can see for instance client connections with public IPs on a matrix server though, that’s just how it works.
-
jonas’
no idea how their contact list stuff works, so I can’t comment on that. I’d be surprised if it was considerably different from what XMPP has in that regard though.
-
Chan Shen
> jonas’ wrote: > I am certain that you can see for instance client connections with public IPs on a matrix server though, that’s just how it works. https://serpentsec.1337.cx/matrix
-
xutaxkamay
on a privacy side i think we could get rid off metadata by suppressing the servers and using peer to peer which i believe is possible in xmpp (correct me if i'm wrong) but i guess all parties must be connected in order to talk to each others and need their ip addresses, routers could still theorically get infos but if the communication is encrypted it should be fine
-
jonas’
server-less messaging is only specified for LAN use cases
-
jonas’
not for WAN
-
jonas’
(it relies on mdns, which is not routed)✎ -
jonas’
(it relies on mdns, which is not generally routed) ✏
-
xutaxkamay
wouldn't it work with something like i2p?
-
jonas’
and you cannot have multi-user chats in the specs as written
-
xutaxkamay
i see
-
jonas’
I have no idea how i2p works and how XMPP plays into that
-
jonas’
(and I don’t know of any spec)
-
jonas’
(when I say "it doesn’t work" or "does not exist", I talk about specs as written)
-
xutaxkamay
yeah right
-
jonas’
but if you drop the servers from the scheme, it’s not really XMPP anymore. you can go with briar or tox or whatever then :)
-
jonas’
XMPP is a federated, not a peer-to-peer system, by design and choice
-
Zash
s2s is p2p, after a fashion
-
jonas’
if every individual runs a server, yes
-
Zash
that's what p2p is. everyone running servers. have fun with those trade-offs on mobile
-
xutaxkamay
i see, it is possible somehow to prove that we don't collect any meta data except hashed password and email on a server?
-
jonas’
xutaxkamay, no, because that’s not true
-
xutaxkamay
well i guess giving ssh access
-
Zash
... and email?
-
xutaxkamay
but probably not a good idea
-
xutaxkamay
ops
-
jonas’
how would you prove that the ssh access is really accessing the server, and not a chroot/jail which just *looks* like the server with all the important data stripped out? :)
-
xutaxkamay
i meant address
-
Zash
what the federated client-server model gives you is choice. choice in who you trust to run your server and who has access to your metadata.
-
xutaxkamay
there is things, i guess but yep technically you could do anything
-
xutaxkamay
i see, well i guess the best is to run your own server in that case then
-
jonas’
xutaxkamay, well, a server will generally also store an archive of messages, the roster, things published via PEP, ..., so "hash of password + address" does not quite cover it, at all.
-
Zash
it can also remain online while you're out of range of wifi or cell networks, which simplifies things.
-
xutaxkamay
> jonas’ wrote: > xutaxkamay, well, a server will generally also store an archive of messages, the roster, things published via PEP, ..., so "hash of password + address" does not quite cover it, at all. if the config is done correctly it should be okay, but yeah i was just saying self-host at home only for your only user and join others servers with it and theorically customize the server so it leaks less as possible informations but it does take indeed time
-
ralphm
I may be (too) late yoday
-
ralphm
Today, too
-
dwd
You can minimize collectable metadata by never talking to anyone. Doesn't seem ideal to me, though.
-
Zash
Arrange a face-to-face meeting in the woods. Leave your phones at home.
-
dwd
What if someone is watching?
-
Zash
Deeper into the woods!
-
Zash
Make sure the foliage gives enough coverage to hide you from the satellites!
-
dwd
But how do we arrange the meeting securely without someone else hearing?
-
dwd
I mean, obviously we arrange a meeting in the woods to arrange a meeting in the woods, but that has some obvious flaws.
-
Zash
It's meetings in the woods all the way back!
-
moparisthebest
DWRoX - Deep Woods Rendezvous over XMPP is the clear solution here
-
dwd
Do we have Board members here? arc / MattJ / ralphm ?
-
MattJ
Here
-
dwd
Two member does not a Board make.
-
ralphm
Sorry guys. Also arc has connection issues with his server. I think it is a DNS server not responding.
-
şişio
Are messages deleted from the server after a certain day
-
Zash
şişio, up to each server✎ -
Zash
şişio, up to each server admin to decide ✏
-
şişio
> Zash wrote: > şişio, up to each server admin to decide How?
-
şişio
Does it change from server to server
-
ralphm
Yes, local policy
-
MattJ
I want it to be user policy, but I (and nobody else) has written the XEP yet...
-
mdosch
That would be great.
-
şişio
> ralphm wrote: > Yes, local policy 👍
-
Menel
Instead of mam"=yes/no/contacts that would be good indeed.
-
MattJ
Yes, I want to deprecate that configuration in favour of retention configuration
-
MattJ
(within bounds set by the server operator)
-
Zash
I also want this instead of persistent=yes|no for MUC
-
MattJ
That one I think can just go entirely, to be replaced by operator config. If the owner wants a MUC destroyed sooner, they can do so. Likely there is an upper bound that an operator would want for an empty room, might as well just use that as the TTL
-
Zash
Even simpler!