XSF Discussion - 2024-08-08

does anyone know https://wiki.xmpp.org/web/GideonW_Application_2024 ? gonna be hard to vote for him given that info...

anyone care to proof-read this for me ? https://www.moparisthebest.com/against-silos-signal/ maybe Seve or emus since you are good with words? :D also maybe newsletter stuff

I think you should remove the comma after "software" and add a colon after "own server": s/You can choose your own server, both software, and host, or host it yourself/You can choose your own server: both software and host, or host it yourself/

I think that's right, thanks !

that's a different blog post :D

> _Nothing_ is a competitor to XMPP. I thought Matrix was a competitor 😁 ✏

fix pushed, thanks again

The version of BouncyCastle Conversations used needed *to be* updated,

Moreover, you can rephrase this to "the version of BouncyCastle used by Conversations" ✏

how about that ?

It sounds more natural s/The version of BouncyCastle Conversations used/The version of BouncyCastle used by Conversations/ But as you like

Or you can s/The version of BouncyCastle Conversations used/The version of BouncyCastle *that* Conversations used/ ✏

I pushed a change already, maybe need F5 refresh: > The version of the BouncyCastle library used by Conversations needed to be updated ?

It's good now 👌

thanks for the help!

You're welcome!

moparisthebest: I find it a bit disingenuous at best to say that signal is in it for the VC money

mathieui: what would you call it: > Signal is now developed by Signal Messenger LLC, a software company founded by Moxie Marlinspike and Brian Acton in 2018, which is wholly owned by a tax-exempt nonprofit corporation called the Signal Technology Foundation, also created by them in 2018. The Foundation was funded with an initial loan of $50 million from Acton

moparisthebest: line breaks in your text are somewhat broken. It appears to affect only text that is a hyperlink.

https://en.wikipedia.org/wiki/Brian_Acton > By the end of 2018, the loan had increased to $105,000,400, due to be repaid on February 28, 2068. Damn

https://igniterealtime.org/httpfileupload/3QWzXj6EzZvW6HNJNakdmd9tNyE/SLTlY8u1R8W1Mfs2MHtW2A.jpg

Huh Guus that looks harder to fix i didn't want to touch CSS 💀

I share that sentiment.

It does look bad though I'll see if I can do anything tommorow :'(

Hello everyone 😊

> anyone care to proof-read this for me ? https://www.moparisthebest.com/against-silos-signal/ maybe Seve or emus since you are good with words? :D > also maybe newsletter stuff I couldn't tell if this was Newsletter stuff but I hope you don't mind me just making it Lemmy stuff 😊

https://lemmy.sdf.org/post/20634613

Will delete it asap if you ask me to

moparisthebest: clicking on the title "moparisthebest.com" of your website sends one to a dead link: https://www.moparisthebest.com/example-site/ at least on mobile

When I click on the header I get redirected to `moparisthebest.com` which works for me (Destkop Firefox)

moparisthebest, I liked it! Short and sweet! 😀 Good points

> When I click on the header I get redirected to `moparisthebest.com` which works for me (Destkop Firefox) Maybe a problem with the mobile theme? I tried it with Firefox mobile

I tooted it on Mastodon, and it started a little thread there: https://toot.si/@hook/112925304702816838

moparisthebest, thanks for your blog post! IMHO, you are missing an aspect: The relative irrelevance of e2ee depending on adversary. State level actors very often target devices/clients, not servers. That was, TTBOMK, the case in the attack of MBS against Jeff B. and also the German "Bundestrojaner" works this way. I.e. e2ee is good and important, reducing meta data on servers, too, but all that Signal hype gives a false sense of security. ✏

moparisthebest: thanks for writing https://www.moparisthebest.com/against-silos-signal/

Also, Matrix seems conspicuously absent from the list of competitors 🙂

> does anyone know https://wiki.xmpp.org/web/GideonW_Application_2024 ? gonna be hard to vote for him given that info... I do know them, yes. I think they might not be done filling in the details there ↺

>> _Nothing_ is a competitor to XMPP. > I thought Matrix was a competitor 😁 Ah, lissine already mentioned it. ↺

> moparisthebest: thanks for writing https://www.moparisthebest.com/against-silos-signal/ Got it, so now I have to add Bitcoin and 4 pin digit to my XMPP client to make it as good as Signal if I understand it right ? ↺

debacle: that's right, we need more tinfoilchat for that

moparisthebest, what I think is missing from your article is a clearly-defined threat model: otherwise, multiple people can have different threat models and not agree on what facts matter more

(also, the first paragraph just feels like useless accusations, which might not help if you want people to listen to the rest of it, but it’s your choice I guess)

I don’t know why you don’t mention “Invisible Salamanders” at all, I don’t think it applies to any of my use-cases for XMPP, but you can’t just brush it off as “illegitimate” without some justification on why it wouldn’t apply to the use-case considered by the original blog post

betarays, the author of the blog post mentioning invisible salamanders already says that it doesn't apply themselves

where exactly?

wait I take that back, it's not in the text (any more?), I'm confused

I could've sworn there was a part about how that doesn't apply because we generate a new key for each message

so yeah you're right, should probably mention that

it mentions that it could be exploited in abuse reporting scenarios, but doesn’t say anything else about the abuse reporting mechanisms in XMPP

yeah both remarks in that section don't apply to OMEMO, the nonce reuse thing doesn't apply either because we don't reuse keys in the first place

The nonce part does say > so if you’re using the same key for multiple messages

still, it would probably be a good thing to move to newer versions of OMEMO with Stanza Content Encryption for most clients

it is true that Signal sends less metadata without that

(also the MUC protocol lets servers have a lot of metadata as well, I don’t know if there’s a XEP for more client-based groups or something similar planned)

There is a protocol for client based multi-delivery but hasn't seen a lot of use

do you know where I could find this?

https://xmpp.org/extensions/xep-0033.html ? (the type=cc/bcc variants)

thanks

Yeah, that one with to or cc or both depending on needs

I wrote a module for it once. I wanted to make it discover support on other servers so it could delay forking to the receiving side.

> The nonce part does say >> so if you’re using the same key for multiple messages >If you want to rekey after your collision probability exceeds 2^{-32} (for a random nonce between 0 and 2^{96}), you simply need to re-key after 2^{32} messages. I think OMEMO is fine ↺

>> moparisthebest: thanks for writing https://www.moparisthebest.com/against-silos-signal/ > Got it, so now I have to add Bitcoin and 4 pin digit to my XMPP client to make it as good as Signal if I understand it right ? edhelas: well Bitcoin would be a great feature as it's not a shitcoin 😁 the pin isn't the problem, the "uploading private data encrypted by a 4 digit PIN which is easily bruteforceable" is the problem ↺

I could rant for days about how signal and matrix and WhatsApp are bad, or address how every point in that other blog post is wrong, but I tried to keep this short, concise, to the point, and with the least amount of snark possible. Which took all my resolve. 💀🥲

Without acknowledging or defining possible use-cases or threat models it feels a bit like bad faith honestly

you can very well agree to have a different use-case and thus XMPP being better for this one use-case and not others, or argue that XMPP is good for the proposed use-case with arguments about this use-case, but it seems to be missing the point that was done in the original article

betarays: I think the original article is missing the point as I said in mine, there are precisely 0 threat models where this is not the deciding factor: > It doesn't actually matter how cryptographically secure your end-to-end encryption is when 1 entity controls all ends, and can instantly update them whenever they want.

If your threat model is a nation state targeting you, or a abusive stalker, or anything I can imagine this is the same. The protections you think you have now can be removed at any time without your knowledge or permission, which makes it useless.

thanks for this input, I'll update my blog with a note about this

I don't know about the scare quotes around security researcher. Doesn't seem necessary

here’s one: you care about the government asking Signal to give them all the data they have on you: since they only keep end-to-end encrypted messages temporarily and store no metadata except for your last login, you’re mostly safe

> here’s one: you care about the government asking Signal to give them all the data they have on you: since they only keep end-to-end encrypted messages temporarily and store no metadata except for your last login, you’re mostly safe on XMPP, if the server gives away the data, they have your keys, your profile picture, a lot of metadata about members-only MUCs, etc.

> I don't know about the scare quotes around security researcher. Doesn't seem necessary agreed

> > here’s one: you care about the government asking Signal to give them all the data they have on you: since they only keep end-to-end encrypted messages temporarily and store no metadata except for your last login, you’re mostly safe > on XMPP, if the server gives away the data, they have your keys, your profile picture, a lot of metadata about members-only MUCs, etc. now, to be fair, there are other options that are better than Signal at metadata resistance, such as Briar

(as far as I know)

> I don't know about the scare quotes around security researcher. Doesn't seem necessary SavagePeanut: I see no evidence they are one, I mentioned how a real security researcher would act at the bottom... ↺

Soatok has their justifications here. I still disagree with "There must never be a “transmit plaintext” option." but this seems non negotionable to them https://soatok.blog/2024/07/31/what-does-it-mean-to-be-a-signal-competitor/

betarays: see you made the same mistake they did. You think signal has less metadata than XMPP now, maybe they do, maybe they don't. It doesn't matter because they could push an update in 2 minutes changing all of that. That's my *entire point*.

well, in my threat model, you trust Signal to have a secure app, but not that they won’t hand over your data

I've explained why signal is no competitor to XMPP and why they wouldn't want to be.

and if you don’t define a threat model, you can just go on about many issues, which sometimes can’t all be fixed at once

I don't think Signal can push an update to one person via apple store or play store

nothing would prevent the developer of your XMPP client from adding a backdoor as well

They'd have to twist the arm of fdroid to push a bad update. Entirely possible it would go by the review process unnoticed but not without leaving a trail

> well, in my threat model, you trust Signal to have a secure app, but not that they won’t hand over your data I don't understand. You think they will hand over data given a court order (I agree, they will) but not modify their app to record more data for a specific person on a court order? Or because their owners change? Or really any reason? What justification do you have for this? ↺

I don’t think a court order would just be able to ask for a backdoor on the whole app

because then they would hand over everyone’s data

> nothing would prevent the developer of your XMPP client from adding a backdoor as well Sure, but then I can change my XMPP client. You can't change your signal client. I thought I covered all this in the post, what isn't clear? ↺

and also, you still have forward-secrecy

> because then they would hand over everyone’s data if username == betarays upload_data() ;p ↺

> and also, you still have forward-secrecy If you delete your history ↺

>> because then they would hand over everyone’s data > if username == betarays > upload_data() > > ;p More likely they'd just update the one phone ↺

> > nothing would prevent the developer of your XMPP client from adding a backdoor as well > Sure, but then I can change my XMPP client. You can't change your signal client. > > I thought I covered all this in the post, what isn't clear? You can have a threat model where such changes would only be done in a public way, and then you could switch off Signal

> I don't think Signal can push an update to one person via apple store or play store ^ ↺

> anyone care to proof-read this for me ? https://www.moparisthebest.com/against-silos-signal/ maybe Seve or emus since you are good with words? :D if you can do revisions, i would: 1) Silos shouldn't be capitalized 2) explain silos are centralized, 1-entity controlled messaging platforms like signal, whatsapp, wire, etc 3) change shitcoin to altcoin or something like 1-entity controlled blockchain and coin 4) maybe link to references saying this is a well-hashed discussion from 2016 about centralization vs federation (https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom/, https://blog.jabberhead.tk/2019/12/29/re-the-ecosystem-is-moving/, https://snikket.org/blog/products-vs-protocols/) and others if you can find them 5) re-emphasize freedom vs centralized control, maybe highlight longevity of xmpp vs every other centralized platform out there

>> Sure, but then I can change my XMPP client. You can't change your signal client. >> >> I thought I covered all this in the post, what isn't clear? > You can have a threat model where such changes would only be done in a public way, and then you could switch off Signal I'm not sure what you mean? ↺

i'd finish it with "patches welcome"

>> I don't think Signal can push an update to one person via apple store or play store > ^ Google and Apple can and also respond to court orders ↺

but, that's just me

deimosBSD: I like it thanks!

> >> Sure, but then I can change my XMPP client. You can't change your signal client. > >> > >> I thought I covered all this in the post, what isn't clear? > > You can have a threat model where such changes would only be done in a public way, and then you could switch off Signal > I'm not sure what you mean? Well, I outlined an example of a threat model, where your data can be handed over by court order, but Signal remains trustworthy otherwise, which doesn’t seem outlandish, and you are giving attacks on something that is not valid in this threat model

now of course if the threat model itself wasn’t realistic, this would be an issue, but I don’t think it really is

not that your threat model is bad, they’re just different priorities

I can accept that people have different threat models

>> I'm not sure what you mean? > Well, I outlined an example of a threat model, where your data can be handed over by court order, but Signal remains trustworthy otherwise, which doesn’t seem outlandish, and you are giving attacks on something that is not valid in this threat model Ok, I mean I think that's a strange threat model but it's still not better than what you get with XMPP, it's at best the same. ↺

most of me says to ignore this soatek post, because they want attention and would love a fight, because it means attention

> most of me says to ignore this soatek post, because they want attention and would love a fight, because it means attention That's why I waited so long but got tired of seeing people post it everywhere and thinking there were actual problems :'( ↺

> >> I'm not sure what you mean? > > Well, I outlined an example of a threat model, where your data can be handed over by court order, but Signal remains trustworthy otherwise, which doesn’t seem outlandish, and you are giving attacks on something that is not valid in this threat model > Ok, I mean I think that's a strange threat model but it's still not better than what you get with XMPP, it's at best the same. As I said earlier, XMPP servers have access to more metadata on users and groups.

They don't actually.

is your profile picture available to your server?

does your server have access to a list of groups you’re in, with their title and pictures, with a list of participants in these groups?

> most of me says to ignore this soatek post, because they want attention and would love a fight, because it means attention Yeah, because of "There must never be a “transmit plaintext” option." they will never not be dismissive ↺

Is signal actually not looking at all the metadata they pinky promise not to look at ? 🙃

That's not a guarantee.

> Is signal actually not looking at all the metadata they pinky promise not to look at ? 🙃 they don’t have access to it, profiles are sent end-to-end encrypted

> > most of me says to ignore this soatek post, because they want attention and would love a fight, because it means attention > Yeah, because of "There must never be a “transmit plaintext” option." they will never not be dismissive a client could be made that doesn’t have an unencrypted option, hypothetically

No it can't because the protocol says MUST

>> Is signal actually not looking at all the metadata they pinky promise not to look at ? 🙃 > they don’t have access to it, profiles are sent end-to-end encrypted Maybe, how do you know? Did you check the code running on your phone? What about now? What about in 3 minutes? ↺

That's my entire point after all

> No it can't because the protocol says MUST There are even servers that don't allow plaintext. There is no protocol police ↺

another idea for a post in obtuse response to soatek is to simply write about the strength of freedom and federation vs centralization with respect to chat services ✏

> >> Is signal actually not looking at all the metadata they pinky promise not to look at ? 🙃 > > they don’t have access to it, profiles are sent end-to-end encrypted > Maybe, how do you know? Did you check the code running on your phone? What about now? What about in 3 minutes? And, again, there are threat models where you don’t care about this: did you read Conversation’s source code? Every update? Are you sure the code is doing what you think it is? Did you build it yourself?

This might be a bit old .. so it probably went under everyone's radar so far .. but

Apparently not enough people are reading the source code because there was a non-updated dependency with a vulnerability in it

I use gentoo, bootstrapped from assembly, and read all the patches before compiling my next update

"It seems unlikely to us that Apple has granted Cellebrite a license to redistribute and incorporate Apple DLLs in its own product, so this might present a legal risk for Cellebrite and its users."

From: https://signal.org/blog/cellebrite-vulnerabilities/

No matter how: Signal ( and any other siloed solution ) can't scape from that ..

Vulnerability is a strong word for a denial of service bug, but certainly not ideal.

yes, it might not be very dangerous, but the point stands

betarays: well if you insist on that threat model, the nicest thing I can say is I don't entertain silly threat models... e2e is all about not needing to trust anyone, so it's invalid to say "I use signal because it has the best e2e" and simultaneously "I trust them"

You need to have some level of trust somewhere, otherwise you end up with unrealistic solutions. My point was that if you don’t define a threat model, you end up using arguments for XMPP just because they exist, and not because they apply to someone’s use-case.

To be fair, that person also had no threat model at all

They linked to their other blog on what they think it means to be a signal competitor

betarays: there's other metadata that signal has (or can trivially infer) such as who is contacting who and when, with phone numbers, and no amount of vague handwaving can prevent this. Even if they cannot, at a specific time, access messages and profile data unless they start to be an active threat (by pushing malicious updates, bruteforcing PINs, etc)

The whole point was, it has probably a better e2ee implementation, that's all

> betarays: there's other metadata that signal has (or can trivially infer) such as who is contacting who and when, with phone numbers, and no amount of vague handwaving can prevent this. Even if they cannot, at a specific time, access messages and profile data unless they start to be an active threat (by pushing malicious updates, bruteforcing PINs, etc) if they actively listen, yes, but they still don’t have group/user names/pictures, and who is in what group

I do trust the crypto, and the reliability here is much better than OMEMO or matrix E2EE from experience, though most of the time it just says "xxxx's security number has changed"

Which is a problem in itself

betarays: who is in what group is easy to infer if there is activity

> betarays: who is in what group is easy to infer if there is activity yes, but there can be multiple groups with the same people in it

The message fanout is still easy to inspect

in any case, in both offline and online comprise cases, Signal does better

though on online it’s mostly about unused groups or pictures and names

They can try to argue that instead of claiming Conversations rolls its own PGP implementation

well, there seems to be two parts to the blog post: something about the XMPP ecosystem more generally, and some part about Conversations specifically

Just not a great look to link to code claiming it does something when you haven't read it

>> they don’t have access to it, profiles are sent end-to-end encrypted > Maybe, how do you know? Did you check the code running on your phone? What about now? What about in 3 minutes? Sounds like an argument to avoid single dev OS too. ;) ↺

I don’t think the blog post was meant to be in-depth, just some quick thing citing a few issues that make XMPP not as good as Signal in this specific use-case, so that people would stop sending messages about XMPP and OMEMO and how it’s better than Signal (I think the author is mostly annoyed about receiving messages about this all the time since the post about Telegram)

> well, there seems to be two parts to the blog post: something about the XMPP ecosystem more generally, and some part about Conversations specifically And neither matter, which is why I didn't go in depth and explain why each was wrong. ↺

> It doesn't actually matter how cryptographically secure your end-to-end encryption is when 1 entity controls all ends, and can instantly update them whenever they want. ^ all that matters regardless of threat model. The end.

now we can fix whatever is valid, ask for correction on anything that is factually wrong, maybe do some post about why XMPP is better in some use-cases, but I think what this person wants out of a messaging app is made clear, and XMPP may not be right for it now

> > It doesn't actually matter how cryptographically secure your end-to-end encryption is when 1 entity controls all ends, and can instantly update them whenever they want. > ^ all that matters regardless of threat model. The end. I think I’ve given one that isn’t that unreasonable, even though it may not fit with what you care about

But I feel like going in circles now, so maybe it’s best to stop here

I mean, many XMPP clients still *default* to unencrypted messages, which is a much more important concern than "Signal could add a backdoor"

If that's your threat model then E2EE should be very intentional. You should definitely be verifying your sessions.

No one even mentioned backdoor btw, I did however link a few of the anti-user things signal has done over the years. Is "goes away" in your threat model? Because historically that's what happens to 100% of chat apps that aren't XMPP. :)

> If that's your threat model then E2EE should be very intentional. You should definitely be verifying your sessions. Sure, but you can't say the UX for novice users is the best. I've had my family switch back to unencrypted multiple times already (and me too to be honest). > No one even mentioned backdoor btw, I did however link a few of the anti-user things signal has done over the years. Is "goes away" in your threat model? Because historically that's what happens to 100% of chat apps that aren't XMPP. :) Oh, I disagree with many of Signal's decisions, this is why I installed my server in the first place. But I don't have a lot of issues with their security.

And I will keep using XMPP, but I can perfectly understand that someone else's use-case will be different

Still, this should be an opportunity to improve

> I've had my family switch back to unencrypted multiple times already Yeah which is exactly why OMEMO off by default makes sense

It's a lower barrier to entry for the layman

My family is on my server so I'm not even really worried about E2EE for them

>> I've had my family switch back to unencrypted multiple times already > Yeah which is exactly why OMEMO off by default makes sense > > It's a lower barrier to entry for the layman No? In every case encrypted messaging would have worked. It's just that you install a new client and it takes 10 messages to realize you didn't enable encryption (for example)

> My family is on my server so I'm not even really worried about E2EE for them I agree, but it's not every use-case

I've said before, terminating the "E2EE" at the server would make a lot of sense for a lot of cases. Means putting OMEMO into the server, of course, which is challenging on a number of fronts.

> I don’t think the blog post was meant to be in-depth, just some quick thing citing a few issues that make XMPP not as good as Signal in this specific use-case, so that people would stop sending messages about XMPP and OMEMO and how it’s better than Signal (I think the author is mostly annoyed about receiving messages about this all the time since the post about Telegram) I don't know how you can read that blog post and say "quick thing citing a few issues that make XMPP not as good as Signal in this specific use-case". That blog post is nothing short of a breakdown with accusations, swear words, ?! and mild doxxing. The author stated multiple times that they don't even care and just wrote the post because they want "evangelists" to stop asking them about XMPP. The whole purpose of the blog post is more or less officially FUD. ↺

That doesn't make sense to me at all, sorry.

>> I don’t think the blog post was meant to be in-depth, just some quick thing citing a few issues that make XMPP not as good as Signal in this specific use-case, so that people would stop sending messages about XMPP and OMEMO and how it’s better than Signal (I think the author is mostly annoyed about receiving messages about this all the time since the post about Telegram) > I don't know how you can read that blog post and say "quick thing citing a few issues that make XMPP not as good as Signal in this specific use-case". That blog post is nothing short of a breakdown with accusations, swear words, ?! and mild doxxing. The author stated multiple times that they don't even care and just wrote the post because they want "evangelists" to stop asking them about XMPP. The whole purpose of the blog post is more or less officially FUD. They do care about correctness as they've corrected some issues with the original article

I admire the dated edits while keeping the original. Buy if they cared about correctness they wouldn't make claims on code they haven't read

> I admire the dated edits while keeping the original. Buy if they cared about correctness they wouldn't make claims on code they haven't read Which claims are you talking about specifically? ✏

> A few people (or maybe the same person under different alts? Didn’t check, don’t really care) have poin Sure. How can there possibly be more than one person calling you out on your bullshit. Must be sock puppets ✏

Code that implements OpenPGP functions (signing, encryption) Code that calls a separate OpenPGP implementation If they read more than the file name + method name it would be obvious that this is using the same OpenPGP implementation and not rolling its own.

The line they link to is even called "executeApi" 🙄

I personally think the whole thing was done in bad faith, it took every ounce of my being to avoid saying that in the blog post

A cynical person might think they had some financial or other motive to push signal so hard...

> I've said before, terminating the "E2EE" at the server would make a lot of sense for a lot of cases. Means putting OMEMO into the server, of course, which is challenging on a number of fronts. How is that any different from TLS? ↺

> > I admire the dated edits while keeping the original. Buy if they cared about correctness they wouldn't make claims on code they haven't read > Which claims are you talking about specifically? Plus the whole section on GCM vulnerabilities that don't apply to OMEMO. ↺

I think you might be over thinking that. It's not like that person has any relevance whatsoever

> > > I admire the dated edits while keeping the original. Buy if they cared about correctness they wouldn't make claims on code they haven't read > > Which claims are you talking about specifically? > Plus the whole section on GCM vulnerabilities that don't apply to OMEMO. So “Invisible Salamanders”?

The symmetric wear out as well

No, that isn't applicable for other reasons :)

I mean, “you can send 4294967296 messages of 68719476704 bytes each with the same key”, knowing that you don’t reuse the key doesn’t seem particularly bad ✏

> I think you might be over thinking that. It's not like that person has any relevance whatsoever Indeed. This is basically all the psychological phenomenon of https://xkcd.com/386/ ↺

> I mean, “you can send 4294967296 messages of 68719476704 bytes each with the same key”, knowing that you don’t reuse the key doesn’t seem particularly bad maybe it’s just me always trying to read things charitably, but it seems to me like this was more about comparing the older versions with the newer ones than a real “issue”

But is Invisible Salamanders really not applicable here? Wouldn’t it allow someone to send something harmful to an encrypted group without the group admin seeing?

> I mean, “you can send 4294967296 messages of 68719476704 bytes each with the same key”, knowing that you don’t reuse the key doesn’t seem particularly bad The post doesn't say that OMEMO doesn't reuse keys though, it is 100% without a doubt formulated to make it appear as if both vulnerabilities were a problem for OMEMO ↺

This is someone just telling to "fuck off" if they disagree in the comments, so the good faith was lost for me

> > I mean, “you can send 4294967296 messages of 68719476704 bytes each with the same key”, knowing that you don’t reuse the key doesn’t seem particularly bad > The post doesn't say that OMEMO doesn't reuse keys though, it is 100% without a doubt formulated to make it appear as if both vulnerabilities were a problem for OMEMO I think this part was about AES-GCM, not OMEMO

The whole post is an attempt to get xmppeople to stop talking to them. So maybe we should respect their desire

Yes, this feels like someone possibly overreacting because they’re tired of hearing about XMPP all the time

Then they did a very wrong post, not a psychology genius But it's pointless to talk anyway true

I think we should talk about things if some valid criticisms have been brought us, but otherwise leave it be

In https://soatok.blog/2024/07/31/what-does-it-mean-to-be-a-signal-competitor/ I like that the very first criterion already disqualifies Signal itself

or do a thorough debunk if you want

but don’t fall into the same trap of doing emotional accusations, this won’t go well for anyone

> But is Invisible Salamanders really not applicable here? Wouldn’t it allow someone to send something harmful to an encrypted group without the group admin seeing? betarays: sure. But you can also do that in a non-encrypted group. Also it's highly likely the signal server can also do it. ↺

I already did a debunk, their entire premise was flawed, no need to go through them one at a time :P

About going in circles now

This isn’t about servers, this is about clients. I thought you just sent a message to the MUC and the server sent it to everyone in the same way?

I mean, there may be another way to do the same thing, but it’s a valid concern for moderation.

It does, but nothing guarentees it does

Going in circles since the invention of language.

> This isn’t about servers, this is about clients. I thought you just sent a message to the MUC and the server sent it to everyone in the same way? betarays: XMPP messages can have multiple bodies each with their own language tag ↺

> It does, but nothing guarentees it does But then nothing guarantees the admins can even moderate :p

> > This isn’t about servers, this is about clients. I thought you just sent a message to the MUC and the server sent it to everyone in the same way? > betarays: XMPP messages can have multiple bodies each with their own language tag Yes, I’ve heard that, this also seems to be a concern for moderation.

The admins are the adversary under this case anyway

Unless they can all be seen in some way.

> The admins are the adversary under this case anyway I might have misunderstood your first message, but I agree here

I mean, the point is whether you can make the admins not see some abuse

In the case of a hostile user

Now we moved the goallost from a security issue to, they might be a very complicated way theoretically to harass people.

Beside making millions of accounts on servers and do the same easier

And only in private encrypted groups

*goalpost

> Historically, this was exploited in “abuse reporting” scenarios, but as I explained in my Threema disclosures, it can sometimes come up in group messaging scenarios. The article always said that

this is the only case that this seems relevant too

and, since this is about comparing to Signal, all groups are considered to be encrypted

Sure, just seems not a likely problem in an encrypted group. Can't scale that up to a point where you need mods anyway usually

It is just a no issue for the reason I gave above. Harrassing is easier in xmpp

Anyway, their point is valid and it matters to them, but we already know the solution and the attack is unlikely to cause any problems (and doesn't cause leaks) until then

On the other hand, in signal everyone knows everyone's telephone number and can harass on a different level

> On the other hand, in signal everyone knows everyone's telephone number and can harass on a different level I think phone numbers aren’t shared by default now

> Sure, just seems not a likely problem in an encrypted group. Can't scale that up to a point where you need mods anyway usually Right if you need mods in an encrypted group you're doing something wrong

> Anyway, their point is valid and it matters to them, but we already know the solution and the attack is unlikely to cause any problems (and doesn't cause leaks) until then Yes, it’s not like it allows someone to decrypt everything or anything like this. But it does prevent using XMPP in cases where you would expect to have harassment.

> > Sure, just seems not a likely problem in an encrypted group. Can't scale that up to a point where you need mods anyway usually > Right if you need mods in an encrypted group you're doing something wrong The comparison was about moving big groups from Telegram I think, so moderation would make sense from that point of view. And switching to unencrypted messaging doesn’t make much sense if even Telegram could do it.

It makes sense for xmpp, since we have semi-anon, what they don't have. But I have the feeling we're arguing for the sake of it

Telegram can't even do multi-device E2EE

In my opinion unencrypted semi-anon is a valid and good Modus they are lacking

I've never used Telegram but I'm almost positive E2EE for group chats isn't even an option

I mean, I just see that multiple people here are getting very angry at the post because we all rely on different assumptions. And while I agree that the post wasn’t well worded and had some factual errors, there are a few interesting points it makes about a use-case that isn’t currently well-supported by XMPP. So you can’t simply point to XMPP because “Signal bad” when it doesn’t support that use-case, which is the point of the article.

I think you got your opinion transported now

Seems we've got multible people with different opinions on that and it doesn't look like that will change

I just think most of it boils down to "XMPP gives me the freedom to shoot myself in the foot, so it's not good"

I still think it’s an opportunity to improve XMPP, even though that’s not necessarily the case I have for it

Try to promote XMPP instead of “Discord servers” for example, these things are unencrypted anyway

I am very excited to see what Prose is like

> I still think it’s an opportunity to improve XMPP, even though that’s not necessarily the case I have for it I think it's an opportunity to improve signal. They can add federation using XMPP s2s protocol. ↺

Oh wait then they lose that sweet sweet user lock-in, shoot

> > I still think it’s an opportunity to improve XMPP, even though that’s not necessarily the case I have for it > I think it's an opportunity to improve signal. They can add federation using XMPP s2s protocol. You know Signal was created based on the assumption that “federated can’t move fast enough”

> I am very excited to see what Prose is like That looks interesting yes. For now I’ve been doing something with Converse.js and multiple subdomains

Didn't the Signal server have federation? Doesn't it still have, but disabled in production?

Fun fact: signal had federation back in the day. Set it up with CyanogenMod. Then rugpulled users

> > I am very excited to see what Prose is like > That looks interesting yes. For now I’ve been doing something with Converse.js and multiple subdomains It’s not the best right now (I still need to improve querying of available channels), but with `muc_grouped_by_domain` it’s somewhat useable

> Try to promote XMPP instead of “Discord servers” for example, these things are unencrypted anyway We don't have UIs or hosting services meant to compete with that yet, but we could ↺

I've been exploring it

I should probably write a guide about it

It's on my roadmap as well, but everything takes time

Dear all, the XMPP Standards Foundation has decided to sign the Open Letter to the European Commission: https://xmpp.org/2024/08/the-xsf-signs-open-letter-to-the-european-commission/ https://fosstodon.org/@xmpp/112928073351147288 https://x.com/xmpp/status/1821631028303212916

does anyone know how this might affect nlnet? I've not heard of NGI before now but it seems there's some overlap there

Nlnet these days get most of their money from NGI

ah then that does indeed suck

Or in other words since NGI is an EU program that doesn't have the manpower, knowledge or capability to judge what small project deserve money they delegate that out to other organizations. One of those organizations is Nlnet (but there are others)

Nlnet existed and was giving out money before NGI. But that's presumably why they were picked / accepted as such an organization. They already knew how to distribute money

Thanks for the explanations

Other topic: I am try such tweets which represents our core work at XSF: https://fosstodon.org/@xmpp/112928192028172975

NLnet has been around for a long time (essentially came about from closing of one of the first internet companies): https://en.wikipedia.org/wiki/NLnet