jdev - 2025-05-02

moparisthebest, syncing to the server could be optional which would enable different blocklists on different devices

apart from that, what is the privacy problem for you? blocklists are already since years synced to the server by every client

and more than that, every messagers probably does this, thats the first time i heard someone say that they have a problem with the server knowing who they block

> apart from that, what is the privacy problem for you? blocklists are already since years synced to the server by every client Sure, lots of things are sync'd to the server and we need that to decrease not increase. It's "fine" as long as it's made clear to users, but at least consider if you can avoid plaintext. Here can't you only upload one way hashes of the room jid and occupant-id ? ↺

How do you extract your blocking list from a list of hashes?

You'd have to rehash for every occupant and then check against it

Once you've joined a room you can tell who you have blocked in that room

Occupant id is already a hash and server already knows what rooms you're in?

moparisthebest, i make an option to not sync to the server

but i will not inform the user about every bit of data that is sent to its server

we dont do this for bookmarks, mds, user tunes, omemo keys, etc

> Occupant id is already a hash and server already knows what rooms you're in? Again, absolutely massive difference between data a server only has temporarily while being used vs must store forever The second is subject to data leaks from backups, law enforcement requests etc etc, the first is not ↺

lovetox: so what about hashing...

yeah just a hash so the server don't know. the less the server knows the better

Trust the server, the server is good. ;)

It's already a hash

the blocking list for muc users on pubsub exists already ? As a hash ?

No the occupant id is already a hash

it's got roomjid which aren't hash

So we can hash it again but I don't see what that accomplishes

We already store the roomjid on server in bookmarks that's no change

I'd even suggest we could store the list of muted occupants in bookmarks as well as an extension 😉

I believe the point is that while the server knows who is in which rooms, it doesn't need to know who a user wants to ignore/block

yeah there's a big different there……

Some apps will need it to know that in order to prevent push notifications from being generated, but that's a different concern I suppose

If we hash the occupant id again it won't hide this info from the server

Need to encrypt properly if we want that really

or a keyed hash

hash(roomjid+occupantid+supersecretextrarandomvalue)

> So we can hash it again but I don't see what that accomplishes It accomplishes hiding it from your server and backups and law enforcement requests ↺

Are there laws against blocking someone yet?

>> So we can hash it again but I don't see what that accomplishes > It accomplishes hiding it from your server and backups and law enforcement requests Doesn't though. That's my point. The server has the same info the client has in this case so if the client can figure out who a hash is so can the server ↺

under investigation, all details will be examined. you never know.

imagine your mom threatning you to prove to her that dad is not blocking her in the family MUC

that's a nightmare already to deal with let alone man of the law come knocking on the door

Unsubscribe from Elon Musk and go straight to jail.

>> It accomplishes hiding it from your server and backups and law enforcement requests > Doesn't though. That's my point. The server has the same info the client has in this case so if the client can figure out who a hash is so can the server singpolyma: no it doesn't, not stored to disk, only if you are actively joined and it goes out of its way to calculate things ↺

> Are there laws against blocking someone yet? What does that have to do with the price of tea in China? Not hashing means a permanent record of some MUCs you've joined are on the server when otherwise they don't have to be, that's enough ↺

> I'd even suggest we could store the list of muted occupants in bookmarks as well as an extension 😉 Yeah I should use bookmarks why didn't I think of that

> What does that have to do with the price of tea in China? Not hashing means a permanent record of some MUCs you've joined are on the server when otherwise they don't have to be, that's enough Server logs can already show which MUCs you've joined. And if you're worried about a determined investigation seizing the server then they will necessarily go out of their way to calculate things, so an easily derived hash value isn't much protection. ↺

passwords are stored as hash ……

with additional salting

and yes, I am using that to say "I don't know your password"

officer: Is this suspect blocking the drug dealer in this MUC? me: I have no clue officer.

drug dealing is death sentence here btw. things get serious real quick

What does blocking someone (who may coincidentally be a drug dealer) prove? I could be blocking them because they talk nonsense, or even they offer drugs - if anything, it proves I want nothing to do with them

you never know. And truly, I never want to know either.

Never use technology - live in the forest - you never know!

they want to go through everthing on my server. Sure. They want to look at my dickpic on my phone. Sure. But they can't put a bug in my server coz they want to grep data from this suspect for the next 10 years.

the less I know, the better.

Then you should avoid all metadata entirely

So, "you never know" is a defensive choice?

> the less I know, the better. ↑ this is a defensive choice

ignorance is bliss

>> What does that have to do with the price of tea in China? Not hashing means a permanent record of some MUCs you've joined are on the server when otherwise they don't have to be, that's enough > Server logs can already show which MUCs you've joined. And if you're worried about a determined investigation seizing the server then they will necessarily go out of their way to calculate things, so an easily derived hash value isn't much protection. Servers certainly shouldn't have these kind of logs ↺

There is no defense to storing data that doesn't need stored, it doesn't matter how unimportant you think it might be https://www.schneier.com/blog/archives/2016/03/data_is_a_toxic.html

> Then you should avoid all metadata entirely correct, as much as possible, always ↺

i think hashing a block list is https://xkcd.com/538/

if you are living in a corrupt country that has laws to fuck you, no they will not trying to get you on your xmpp blocking list

they usually dont need evidence at all to fuck you, and certainly will not need get data from your server

Especially since the occupant id already tells you nothing unless you join and once you join you can correlate the hashes anyway

What is the use case for this? Is it letting the MUC know who is blocked so that it doesn't send the client messages which are going to be blocked anyway?

> i think hashing a block list is https://xkcd.com/538/ It's not though, also not your call but glad you are privileged enough not to worry about these things so far ↺

No. It's so all your clients can mute the same participants

Just making more work for the future when we remove server's ability to see roster and bookmarks ;)

Though your own server does need to know about the mutes if you rely on push notifications

When designing protocols the question is not "why should this be hidden" it's "why shouldn't it be hidden" and only if you can come up with great reasons for the second do you not do the default which is hide it

I haven't added participant mutes to my push clients yet but that'll be a whole thing I'm sure

moparisthebest: sure but your proposal would not hide it

Encrypting would

Then we need a way to sync a secret around but we might need that anyway

so would hashing with a salt

Sure, same problem with syncing the secret around

yep, so an option would be hashing with an optional user provided salt, because without one is still better than not hashing as it requires an active attacker, and not just pulling from backups

i dont think hashing is any good

it makes everything just more complicated

if you want to solve the problem in a generic way, provide a spec to encrypt pubsub content

also hashing simply doesnt work for anything beyond the occupant id

say i want to store the reason why the block was made ..

Using data stored in bookmarks seems like it might be the best way to handle this instead of as a pubsub thingy in the MUC itself

i will store it in bookmarks

> it makes everything just more complicated What's more complicated ? ↺

> i will store it in bookmarks 👍 ↺

do you have an answer to storing additional data beyond the occupant-id, because if not any discussing about hashes is useless

what more would you like to store

for example the reason

Hash for sure won't work for that, that's even more sensitive to upload plaintext for the server to store though

ok lets tell everyone pubsub is no good anymore, shut it down because all we do is upload plaintext ✏

it's fine, clients can just start encrypting before uploading to it

yes, i agree that would be a generic solution for the problem. I feel positive about implementing it if there ever is a proposal

until then the option in Gajim privacy section "Dont sync with server" will have to do

"blocked because he sold me bad drugs" "blocked because he's anti-abortion in this abortion help channel" you can see how some of block reasons these could be sensitive, maybe just don't have them until they can be protected properly

Omemo encryption for blocking reasons when???

While being mindful of what data the client shares with whom is vital, stringent cryptography requirements for basic everyday use cases does increase the barrier to entry for clients attempting to implement the specs

One of the neat things about XMPP is how easy it is to implement a working client

> Omemo encryption for blocking reasons when??? Can't use OMEMO for something like this. But there are several options for encryption that will work ↺

why not?

because if you want to use it as intended, you can only decrypt data once

oh right

pgp encrypted blocklist when???

although I don't see how you'd trust the server with information on what group chats you join and who you talk to but not with your blocklist

this would work, but there are easier options out there

> pgp encrypted blocklist when??? ❤️ ↺

> pgp encrypted blocklist when??? ❤️ ↺

> although I don't see how you'd trust the server with information on what group chats you join and who you talk to but not with your blocklist right, there are still legacy unencrypted things on the server that need fixed, but that's no reason to keep adding more ↺

They're all optional. You're free to make a single device only hyper locked down app that stores nothing on server

single device as in talking to itself only lol?

the server inevitably knows who you're messaging because how else would it route messages

onion routing over xmpp when??

I have some thoughts for onion routing yeah

Simplex already does that

> They're all optional. You're free to make a single device only hyper locked down app that stores nothing on server Why not multi-device everything nice we have now except server doesn't have to store things plaintext ? ↺

Some people might be interested in making so-called "legacy" clients that don't implement the complex cryptographic functions they would need to understand the encrypted ciphertext that's stored on the server