XSF Discussion - 2022-01-28

Is the roster defined in core?

The other RFC

https://xmpp.org/rfcs/rfc6121.html#roster

I was remembering talking about encrypted rosters with someone a couple months back and they said it wouldn't be possible because the server has to decide who's authorized to messages to an account on it – but I just realized JIDs in rosters could easily be hashed and still be used for that check. This way, server compromises wouldn't expose users' social graphs in the network. ✏

Ah, that would break rosters for new devices…

> because the server has to decide who's authorized to messages to an account on it

what? servers don't allow or disallow messages based on rosters

at least, good servers

There were ideas by someone (waqas? me? someone else) about ways store things on the server in some form so that the administrator could not tell anything from it.

you can do client-side only rosters already, no spec changes needed, messaging still works

Personally I feel like, if you want this, are you really sure you want XMPP and servers at all then?

what's the point though? assuming an evil server, they still have 100% of people you communicate with ?

moparisthebest, but then the evil untrustworthy server of doooooom will still see who you send messages to!!!!!!

we've talked about a way where your server only knows the remote server of your contact, not the actual person there, but that's really only helpful when 2 people are using different large servers, so not all that often...

I'm not assuming an evil server, I'm assuming a good server being raided and forensically analyzed.

full disk encryption

^

Aye, and I can set up swatd. But even case-opened sensors are easy to bypass.

so they don't have your roster just everyone you every communicate with post-raid ? meh

assuming no logs that is

What actually happens: Your phone gets SWAT'd and you had all your conspiracies in plain text there.

moparisthebest, you can assume good operators/server being taken down. That's often an option critics overlook

FDE doesn't help much here either

Most phones come with encryption of this data if I'm not mistaken. Also they're right at hand so switching them off when a raid occurs is trivial. For a server in a diferent country that's completely unrealistic. ✏

most phones come with trivial visit-a-webpage root vulns too so none of that mattercs

If suddenly police gets access to the encryption key because operators are legally forced to. At least admins wouldn't get access to user storage unless somebody changes the software at this point, obviously

But canary and all that

Or we could focus on how useful it is to _trust the server_

Trust in the server, the server is good!

moparisthebest, just because one avanue of attack is possible doesn't mean you shouldn't protect against others? If you take that root, all security is pointless because perfect security is impossible…

pep., are you saying admins would be forced to turn over the server to police but police wouldn't change the software to log the info they want ? that seems... crazy

Not saying that

I'm saying even if they would, birds would be singing

phryk, you still haven't said what you are trying to protect against, or why you think not storing your roster on the server helps

But that's not a use-case to overlook anyway

this whole "canary" concept seems highly questionable to me

You can trust the operators and not trust the cops

you shouldn't trust anyone

(s/cops/governments, or..)

*but* your server needs basic routing information to get your message from A to B, nothing can be done about this

You have to trust people at some point, you just have to choose who

not even signal handwavy but muh SGX helps

SGX lol

So trusting Intel is fine but trusting my operator isn't? ✏

Let's all just go read 'Reflections on trusting trust' again until we realize it's all doomed and we can go do fun things instead

moparisthebest, following scenario: cops raid the provider, leave the server running (i.e. full-disk encryption not being worth much since the key is in memory) and extract data for it. logs i can deactivate, but the rosters are extremely valuable metadata.

pep., did you read my message wrong? I specifically said SGX *does not* help, despite signal's claimns otherwise :P

Ok then

Didn't signal have a canary and then they removed it but people kept using and recommending it?

><

Zash, Given I've spent the last month and a half writing a filter in Metre to strip e2ee, I'm thinking how useful it'd be to have server-side OMEMO now. All the benefits of OMEMO (for the other people that might need it), all the convenience and UX of not having it for me when my server it just over there _points toward the garage_

dwd, so police just extract data once and don't change the server to logging?

dwd, YESSSS!

moparisthebest, How do the police get my server without asking me very nicely and having a warrant?

They can probably accuse you of terrorism and get away with it, and you'll get your server back.. never

idk I thought we were talking about secret warrants served to providers

pep., in that case FDE saves you

Not legal advice: Put your server in a drawer. I read somewhere that it takes an extra-specific warrant to go into drawers.

> moparisthebest, How do the police get my server without asking me very nicely and having a warrant? Immenent danger?

Something smelled like weed?

moparisthebest, Sure, if you don't run your own server your threat model might be different.

Or you at some point in the last 90 year violated someones copyright?

Daniel, None of that would give them access to my server.

It's not like we didn't have proof by now that cops aren't here to protect the people but governments in place

right, I'm wondering what specific scenario encrypted and/or client-side roster protects a user against, anything I can come up with seems contrived and unlikely

moparisthebest, yes, i am assuming that i can either destroy the DNS entries (at least temporarily) myself and get the word out about a compromise or have somebody else do it for me.

Riseup had a nice page detailing their use-case, trying to find it again

riseup's usecase was "we are lazy, just use signal" iirc

Daniel, Or at least, none of that would give access to my server but not my phone.

moparisthebest, no?

I do like server side omemo though (for people how run their own)

luckily as the user of an xmpp client, you don't need to use the roster at all

so this problem is already solved, right phryk ?

And I'm super glad I don't have plain text logs of the shit people send over my (public) server

Server-side OMEMO↔OX translation?

Daniel, Right. E2ee protects providers very well, which is why WhatsApp do it.

moparisthebest, can you give me a source on that?

phryk, sure, open a client, don't add anyone to your contact list, done ?

Zash, Well, it's all heavywieght TLS from your phone to you anyway, right?

and yes, if users can opt into that and then be sure the server doesn't store their roster, then that already solves the problem.

dwd, I'm curious though if they'd risk decrypting it server-side, or is your current work not related?

Otherwise they couldn't claim plausible deniability

moparisthebest, wow, how perfectly usable. :F

phryk, why isn't it ?

dwd: ChaCha!

you can message whoever you want at any time without adding them to your roster/contact list

because then they don't have a contact list which is an essential feature?

it's completely optional

you can have the contact list on the client side

ignore presence

most clients already do this

pep., It's a very long story, but the decryption is for the purposes of increasing security.

.. figure out how the heck to get omemo key shuffling to work again?

pep., TL;DR: Different people and organisations have different threat models.

Zash, is that a specific XEP? ✏

phryk, no

at least in gajim+dino+conversations if you start a conversation with someone, it'll stay there, even if you don't add them to your roster

what are you missing exactly ?

phryk, you are aware that almost everything apart from XMPP Core is optional, right?

Yes.

You don't need rosters or presence to send messages

But I haven't ever seen any client making this optional.

I've never seen a client where it *was not* optional ?

phryk, Oh, I have. But then, I've seen some weird clients.

at least gajim, dino, conversations make it completely optional

"the decryption is for the purposes of increasing security." ah right :D

moparisthebest, Well, most clients use the roster, even if most don't mandate it.

Even if it were true, it's really fishy

right, but none of these 3 *force* you to add people to a roster to chat with them, or keep the conversation open

moparisthebest, one of us is consistently having a severe misunderstanding.

moparisthebest, wrong? I think Conversations forces you to add somebody in the roster to open a chat with them

I've been annoyed by that in the past

pep.: yes and no. If you unload mod_roster it will still work fine

If you managed to open the tab another way then it's all good ✏

So it needs to be added locally?

if i add someone to my contact list in dino, gajim et al – they go into the server-side roster, right? There's no setting in the client that lets me disable synchronizing my local contact list with the server roster, right?

(namely biboumi users. I don't want them in my roster)

If you somehow manage to invoke xmpp:someone-not@your-roster.example then you can still send messages

(or myself)

Or it's just that there's no UI for it, and yeah you need to workaround no UI

Daniel, so clients will (more or less) work fine if the roster is disabled on the server-side?

phryk, so don't add them to your contact list? just start a conversation with them without doing that instead

> Daniel, so clients will (more or less) work fine if the roster is disabled on the server-side? Yes

moparisthebest, having a contact list is stil not optional.

Quicksy.im almost didn't have one

Daniel, Okay, that's all the info I needed. Then I can probably implement an ad-hoc or something command that let's users temporarily activate the roster for example for multi-client contact sync and turn it off and wipe the data from the server afterwards.

So that'd put users into control of how much of their data they are okay with being persistently on the server. And being able to prefer either comfort or security.

phryk, sorry why is it not optional ?

moparisthebest, because otherwise UX is dogshit? o_O

phryk, I think we are talking past each other, you are saying "users need it for good UX so it's not optional" and I'm saying "it's optional because they don't have to use it" ?

users also need MAM for good UX and that involves you keeping all their messages + contacts on the server too so ¯\_(ツ)_/¯

OMEMO'd messages aren't on there in plaintext. And I have the extended mod_e2e_policy module for that.

OMEMO'd messages sender/reciever are there in plaintext, ie, everything that'd be in your roster

But yes, I should make sure that MAM is kept short and wiped. IIRC that's a Prosody setting that my setup already has…

So MAM is transient data, meaning that at least *less* of the social graph would be exposed.

And I should now really get to work. :F

But one last question: Zash, you mentioned OMEMO key shuffling issues when deactivating the roster – is this also an issue when a user is only using one device/client to access the server or a multi-client problem?

PEP depends on presence for signaling that that you wish to receive various kinds of data, including some OMEMO stuff, which you would probably have to poll for then.

Ah, so that would necessitate client modifications, am I understanding that right?

Adding a new device / OMEMO identity might need some trickery to ensure the news goes to "contacts" who need to know

Excuse my word orders, am sleepy.

Ye, but that sounds like it should also be covered by temporary activation of the roster when adding a new device and subsequently deactivating it again and wiping it after things are done. :)

No problem, get some sleep. :)

"temporary activation of the roster" makes no sense to me

Oh. My understanding was that I could normally have the roster for a user deactivated, then activate it so the original client then syncs its contacts etc. up to the server and the server syncing them to all other clients logged into that account. ✏

rosters are distributed data structures that live on both your and your contacts servers and is kept in sync by stuff

I meant like, when opening a chat, poll for devices at that time instead of relying on notifications about new devices

or when receiving a message with some new device tag, if that is a thing that exists

not an OMEMO expert 🤷️

Okay, seems I need to read more specs to reason better about this.^^

could always go back to OTR :P

then you don't need roster, carbons, mam, *or* a good user experience

Maybe we could use a blockchain?

I mean, i've no idea what for, but imagine the VC funding we'd get.

XSFCoin when ?

I tried to propose Conversations rolling out ConCoin but no one jumped on the idea :'(

Good name, though.

Not Coinversations?

Nah. *Con* Coin is the most honest name for a cryptocurrency I've ever heard.

Clearly honesty is what sank the idea

ok but when are we going to start minting NFTs of the jabber trademark ?

I was going to comment on the sorry state of affairs of pubs being locked down, forcing us to have conversations like these ... only to realize that most of us live in countries where lockdowns have already been lifted.

At least the club I want to go to is still closed :<

No raves for me T_T

Lockdowns? We just had stern recommendations.

why go to a pub when you can drink at home and chat on XMPP though...

I did drink .. julmust

TIL