Modern XMPP project discussion - 2021-04-13

VoIP is not stable, mobile client is not stable. compare to xmpp long history, matrix is still on working at stability

im using matrix as team tools, it work well with text message, but it fail at VoIP sometime,(nat maybe cause some issue, but we are using vpn(wireguard) and share same Net layer ipv6(native support), and sometime VoIP work).

hello according to https://www.privacy-handbuch.de/handbuch_62.htm is xmpp not the privacys best solution... meta-data, group-members and so on are stored unencrypted on the server and can be fetched by almos anybody... this is NOT GOOD.

is there a possibility to change this by a XEP?

Hi jakob@schuerz.at

I haven't read the article (my German is not good), but I can guess at what it is saying

It misses the point of a federated architecture. Does it propose something that is better than XMPP at the problems it identifies?

OK, it looks like it prefers Signal and Threema 🙂

Is it by chance a translation of InfoSec-Handbook?

Very likely (the authors of the Admin-in-the-Middle article)

heh

Both Signal and Threema are centralized platforms controlled by a single organization. Despite what their advertising, both have access to info such as your IP address (and in Signal's case, your phone number)

They are secure if you trust those organizations. XMPP is mostly the same, if you trust your server operator. The point of XMPP is that you can choose your server operator - there are many

that page is not wrong, but I don’t see how xmpp is any different than the other messengers listed (except Tox)

That's the thing, pointing at XMPP doing "bad" things while ignoring issues with other networks

I can accept that signal is slightly better in that regard, but having the social graph use the phonebook is a big no

(but I would really like a server that essentially allows for e.g. the roster to be stored encrypted, with a key derived somewhen during auth, although there are many quirks to work out)

Do I need to complete that project?

(Zash, yes, plz)

no. this is only a synopsis for the different solutions.

it lists the good and the bad points for all the messengers.

and unencrypted metadata, group-members and so on are not very good for privacy in xmpp.

signal is better in this point, bad very bad in other points...

and closing the eyes on xmpp-problems because signal is bäh bad centralized is not my intention. i ask for the possibility to change xmpp with a xep to store metadata, groupmemberships and so on encrypted on the server.

i'm not able to write a xep... i'm only a user of xmpp.

(And a server-admin)

do not point to the dust in the eye of other... resolve the own problems, and make xmpp excellent. ;-)

I'd like to see solutions to fix this. In the meantime saying that Signal doesn't have this issue is a lie. Even if they did multicast or the like for groupchats, they'd still be able to correlate pretty easily

Fixing this is not so easy, be it XMPP or else

The issue is that in the end, unless going the onion or full p2p route, a malicious server admin will always have access to metadata, that’s a fact. The levels of metadata can be varied, and of course it is better if any at-rest data is encrypted, but that’s not the end of the world either if it isn’t

(and living as if a government agency was out to get you on unlimited budget is not healthy, even though it can save your life if justified)

The onion route doesn't protect from the government that's got capture points everywhere

XMPP is not the right protocol to implement encrypted meta data

Well I disagree with this

There's a difference between "a state actor can" and "a state actor does"

I disagree with saying "We're doomed anyway so let's just give up"

That is not my point, I am saying that acting as if it was a critical issue that needs immediate work by everybody is not helping anyone

Yes I believe it is an issue, and I believe the situation can be improved, and should be

But this takes time, and work

What mathieui said

I was replying to Ge0rG really

I'm of the opinion that there isn't very much we can actually do

Most things we can add to take XMPP in that direction also have downsides (sometimes severe) for the general or other specific use-cases

I'm sorry you think this. tbh I'd rather end it here than give up on this :/

If even Signal can barely manage it, what concrete things do you think we can do?

For example, Signal's "sealed sender" stuff is great marketing, but the reality is that they run the service that provides the sender seal, they just don't talk about that

But then they can run around pretending they don't have metadata, when they have easy access to it (either intentional, or via a compromise)

Do we want to spend effort implementing stuff like that in XMPP?

What riseup does regarding encrypted mailboxes (email) is actually something we can do

or do we want to take it more into the domain of Jami and Briar, trust no servers?

It's not for MUC but it's a start in that direction

P2P doesn't fit every single use-case either

Signal privacy-protecting methods is mostly "trust us we have several servers for all services and do not correlate anything"

It's even worse for metadata

Decentralize all the things, don't use untrusted nodes. Or trust nobody and pay the price (is it Briar that doesn't run on iOS at all?)

And to be clear, I didn't say there is nothing we can do, but I said there is not much we can do

We can encrypt some stuff at rest on the server side, that will come at a cost of course, but I'd like to see some experimentation there

But this is also a kind of fake solution, any compromise just has to wait for you to log in

and these days everyone is logged in most of the time

So do you trust your server or don't you?

MattJ, well, at least that means "forgotten IM account on some srver that just got breached" does not leak info about you

Yes, it has some benefits

and "servers got seized by law enforcement"

but yes, it does not help the compromized scenario

MattJ, sure once you login you lose the guarantees. But at least you're sure that the feds getting your server's drives won't allow them to get your data

Isn't that what full disk encryption is for?

Well even if the admins gave up their passwords

They wouldn't have access to your data

admins generally are required to comply

Most compromises of communication servers that I've seen involved compromising a running host

Rather than grabbing drives

That's yet another scenario

I think that's rather last decade

and afaik (e.g. in france) it would be illegal to force admins to install malware to spy on users, while they can ask for at-rest data

Surely if you want to protect against everything.. we'll never get there

But people *do* want to protect against everything :)

Yes, and that is why people with "everything" in their threat model are a pain

Yeah well people got to stop dreaming

I'm not going to stop fighting but I'm no lunatic (I hope)

I'm all for concrete and well-discussed improvements (or even better, real experiments/implementations)

Wouldn't it be easy™ to store roster names encrypted on the server as a start?

No

you still need to establish encryption schemes and whatnot

Of course you need, but what else?

Heh

It might be possible to have encrypted rosters, but certain things would not work.

"Of course you need to do this hard thing, but apart from that, what else?" :)

> No Thanks for the detailed answer ;)

To encrypt you need a key, which comes from where?

I believe Zash has done quite a bit of work on that part so I will trust the "it is not easy"

Okay, but what are the major blocker?

MattJ: derive it from the login?

what is the key, how is it generated, how is it stored, how do we make it generic with all the different auth methods supported by the server

I did this. Crypto key derived from password in way that is only possible during login.

Which requires specific login mechanisms, and ensures you can never change them

what do we do with the use cases requiring access to the roster

> Which requires specific login mechanisms, and ensures you can never change them KEK? :D

Keys encrypting keys encrypting keys encrypting keys ad absurdum yes

😀

but you still need an in-band mechanism to add a different meta-key by confirming the first one or something

Not saying it's easy but it sounds like the easiest of all metadata stored on the server, no? ✏

So we can encrypt the roster and nobody will know who your contacts are. But the message archive is okay...? :)

MattJ, you need a public/private key scheme!

Joy of joys

MattJ: sure you still have MAM, hopefully with e2ee

zapb, that does not protect any metadata

But the JIDs of everyone you communicated with are listed there

Not saying it solves all problems / removes all metadata

Which is probably way more interesting than who is on your roster

Archive can be appended to using asymetric encryption. Source: Built a PoC.

realistically, doing server-side metadata encryption with no explicit client support is a pretty but complicated crutch, imo

You'd have to go through all the data stored and consider whether what read/write requirements there are.

Nobody is talking about an approach without client support or what do you mean?

I think many people would even be fine with some client support

Finally gives people a reason to stop supporting Pidgin from 2006

Get Conversations to implement it and everyone will follow.

zapb, I believe Zash’s experiments were without client support, doing it with client support will necessarily fragment the ecosystem further

mathieui: doesn't this feature only affect your clients?

zapb, it means once you use a client supporting it you are effectively locked in and cannot go back to a client with no support

it is… bad

Just like with OMEMO, sorta.

but worse

Nah, not worse

You can always extract your data and start again

OMEMO... that state is in everyone else's clients

> zapb, it means once you use a client supporting it you are effectively locked in and cannot go back to a client with no support > it is… bad At the moment it's not possible to switch clients at all without losing all data

is it? what ✏

And no client dev really cares ;)

Talking about history, OMEMO keys etc.

cares about?

Because I can tell you many client devs have had s@#t for not supporting C features (among others)

Making it possible to move data from one client to another ✏