XSF Discussion - 2023-08-23

I think it is problematically that people in anonymous MUCs think they are anonym but they even leak their IP

In general a good way would be that the client is only in contact with its own server I think. Voice over IP excluded..

it's not like if you get an IP you can ID anyone, it doesn't make anything not-anonymous

it might be less than ideal, but it's not a big problem

but you can easily catch IPs of almost all group members 🤔️

think of a group of people in iran sharing thougths which the government does not like..

those people should be more careful

but in a sufficiently large group, you paste an image, you have no idea which IP is which

and chances are if someone pastes a link people will click on it too, so same thing

Hi!!!

> and chances are if someone pastes a link people will click on it too, so same thing You are right but a link is obvious to people. Media shared inside a group is excepted to be save I think.

The problem with this is also that semi anon muc groups are just that. Semi anon. It would be nice to work on a fully anon version but rightnow they only provide privacy under some threat models

"Fully" anonymous groups are not really a thing anywhere (practically)

If the group has a server for distribution, the server can determine the members (it needs to, for message distribution)

If you go serverless (p2p) then ISPs (and group members) can observe IPs

yep true

Agree. For TCP/IP based protocol, hiding your IP address is going to be solved with largely IP-level mitigations rather than something at the application layer.

Conversely, to get this level of intel on XMPP activity for individuals requires monitoring at the application and IP layers.

(albeit, an XMPP server is capable of doing this on an actor's behalf)

And at that level it is already irrelevant if one shares a link or picture

It would cause a lot of traffic, and I wouldn't enable it on my sever, but could the already existing proxy65 be easily adapted to parse all the traffic of pictures to the clients?

and IP is not the biggest privacy concern at that point anyway

i mean it already is not imo

Fully anonymous is difficult, true. But for me it is OK if I trust my server and the muc hosting server. But I can not trust all the other servers which host the media shared in the group you know?

True that it would cause a lot of additional traffic to solve this

With HTTP File Upload, the other servers only get the link rather than the media. Contextual intelligence gathering becomes much more intensive at that point.

Each user uploads his files to his own server. Problem would be solved if uploads go to the muc hosting server only.

Can you upload via tor?

You can. But isn't it the download part the interesting one?

(one could too)

The sever only wants the secret for upload and nothing for download (then the exact path)

It doesn't matter from what ip it is done

matthias [08:50]: > Each user uploads his files to his own server. Problem would be solved if uploads go to the muc hosting server only. That really depends what "problem" you are trying to solve. Because this leaks the user's IP to the MUC service, which doesn't currently see that info

Yeah. `torsocks -i <you-fav-client>`

threat models!

Live in the woods, be connected to nature and cut the cable 🤪

certainly works

Till you realize satelites are above the clouds (the real ones)

MattJ: true, I forgot that :)

This means problem would be solved, if the users server would download the file from the foreign server instead of the client

Whatever... Just think that it was good that users know about this thing

This all sounds as if concerned people just should use tor end the rest doesn't need to care honestly.

> Whatever... Just think that it was good that users know about this thing That yes ↺

My ip isn't even my ip most of the time. It is a shared dslite thing and also changing every 34hx even the ipv6

*24h

Thanks for your thoughts to all

"moparisthebest> Actually directtls probably needs a default port before we can do that... [..] I'd of course suggest 443 but others won't agree :/" If you do this, you increase deployment complexity much :)

"moparisthebest> those people should be more careful" I'd be careful with such a statement. Victim blaming is easy. Currently with XMPP and clients semi-automatically GET-ing links, anyone pasting a link in the channel gets info about most of the participants. That's not something one can be "careful" about. That's up to clients

(And servers proxying, as was mentioned above)

"Menel> This all sounds as if concerned people just should use tor end the rest doesn't need to care honestly." yikes

Yeah tellinp people to install tor to get privacy just says that we dont want to fix our stuff imo

Besides the obvious of we dont care about people that dont know tech

(Hot take: Tor is a hack for the lack of privacy underneath anyway)

Because people who need privacy (that should be all of us anyway, if we collectively want privacy to be a thing) surely know how to use Tor too :)

(/s)

well if you're on Debian, it's there by default. There's no installing anything.

how harder is it to open a terminal and prefix `torsocks` rather than clicking an icon?

i never open terminals so you lost me there

Trung, seriously that's your take on this?

I find this naïve

pretty much

what else are there ?

eh we are in the xsf room.

so i guess making xmpp more private :)

Trung, well not much indeed. That's what we're saying

And telling people to "just be private" isn't gonna cut it

this yeah ^

=]]]]

There's an easy solution: Ban http upload in semi-private group chats.

Well server proxying is one idea

Doesn't work with OMEMO though.. or maybe there could be some kind of iq to request a download instead of a server reading MUC messages, dunno.

Advertise a proxy via XEP-0215 and have clients pick up and use that.

Yeah maybe

Then again I agree some kind of basic thread model needs to be defined to discuss more about this

There's https://www.rfc-editor.org/rfc/rfc7624

But it would be good to develop something specific to XMPP

https://xmpp.org/extensions/xep-0134.html#privacy

> Since the beginning, privacy and security have been important priorities within the Jabber community. That must not change. "words"?

I'm just saying. If you don't want to trust the muc and not the participants, then you need expansive sever support or something tor like anyway. Have xmpp clients to default to tor?

Maybe we can stop about Tor already. It's a great tool but it's not going to fix all the privacy issues of the world

Out with Tor, in with Oblivious HTTP?

:D

Well what's the alternatie? Everything through tor or everything through your server.. Or is there something else. But with tor you even hide from your own sever the ip.

The problem is, you can add all the structure you want, but at the end of the day, people will still sent urls mid-text at worst, so you need a solution that can just handle any link clientside, right?

And tor or some other proxy is all that springs to mind

Zash, thanks for the RFC, TIL.

> Well what's the alternatie? Everything through tor or everything through your server.. Or is there something else. > But with tor you even hide from your own sever the ip. good question. that should be asked too together with defining a threat model

this all seems like an artefact of http file uploads instead of truly-inline file uploads

with xml, binary data is a nightmare, and its already kinda that way with omemo

ascii/utf-8 serialisation formats on the line showing their age

I still wonder.. If I trust my sever... Could I use the already advertised socks5 proxy to get the http file?

> ascii/utf-8 serialisation formats on the line showing their age so what are you proposing?

nothing since thats out of the scope of xmpp to bother with

notice how i stop talking when i have nothing good to say

i would like http upload to be replaced with an xmpp "native" solution that is

but i havent heard of any problems with omemo and xml /shrug

the "problem" is base64 inflation

same thing inherent (probably worse cus more needs escaping) with json

What does this have to do with anything

well, idk if more needs escaping in json than xml, never mind

I think we've very far away from privacy

>what does this have to do with anything check which room youre in again, we're talking about the xmpp protocol

We were talking about privacy and suddently XML is the enemy :)

we were talking about http URLs being a vector for leaking PII to third parties

Yes

ok we're on the same page, have fun

?!

pep.: i think the headline is "BoB bad"

Yes surely BoB is bad, but I doubt that's because of XML.

Server rewites of http uris? Optionally check HEAD first to be sure its a valid link and not garbage, rewrite it to go through a server defined proxy?

Clients dont need to change anything

Covers any link sent, not just http upload

Probably not the best idea as you need to scan for URIs in plaintext

Do you forsee that being problematic?

Always?

I guess the IRC in me is showing...

qy, that's the base of the flam^Wdebate around 0071/0393

Heh, oh yes

> I guess the IRC in me is showing... it was problematic even on irc

neither ircd2 nor ratbox does *anything* related to message texts, not even filter out ctcps

either the message is sent or it isnt

I agree to wanting to push more towards more native file transfer solutions, but this is unlikely to be helpful privacy wise. And as others have stated http download media vs having clickable links is the same thing for privacy (unless your client auto downloads http from strangers, which would be bad of course)

To the can I http via my socks proxy. No, you cannot, because the xmpp socks proxies are very specific

You can jingle via your socks proxy or via your turn server or do IBB all of these fit in this threat model somewhere

huh, why can't you do HTTP via a SOCKS proxy?

I'm doing that all the time

Confusing it with the subset done in XEP-0065 ?

jonas’: you can, but not via the XMPP "socks proxies"

then they're not socks proxies :>

indeed they are not

They just use the same protocol and also do proxying, but in an xmpp specific way

Mostly custom auth

I just don't think there is much value in building a 10% solution when you can just use tor for a 100% solution

Tor isn't a 100% solution though

Here we're just talking about leaking IPs during file transfer but we're missing all the other things that privacy means

"just have the users server fetch the image" isn't even helpful in my ideal future where each user runs their own server

pep.: right I'm just talking about hiding IPs though, Tor is the only 100% solution for that

It's not, but it's close

But depending on your threat model you may not be needing 3 hops between every single of your requests and that'd be ok

Also 3 hops that are likely to be blacklisted everywhere you go

Not helpful.

Matrix-style replication of all media onto every server? Makes sense in some ways, but total storage requirements go up.

Upload to ipfs and have everyone fetch it over the cloudflare node since cloudflare has everyone's IP anyway? 😞

You mean get blocked when trying to get anything from clownflare cause you're using Tor? :)

Cloudflare is your Tor now!

> Here we're just talking about leaking IPs during file transfer but we're missing all the other things that privacy means yep. we dont even have basic stuff never mind IP leaking.

what kind of basic stuff?

like why cant i have different profile picture per group?

its trivial to dox people even behind tor with this

singpolyma, all the "how to have different identities on XMPP"

^

That is often shoved off as "get another account" (and hope clients handle it well and easy)

Get another Jabber ID for sure. Whether that's an "account" or some other thing (burner jid, etc) is an interesting question. Probably need to design the UX first then work backward to the best tech for that

That is the easiest way to do it now, and the least likely to have bugs even if there's another way in the future

Different profile picture per groups is different from different identity I guess because you might want that for style reasons. This we don't need new protocol for though, "just" new implementation

probably. i am talking about current xmpp

apps i mean

Back to file transfers, it would be interesting if all parties (including s2s link) were connected with quic to support a "hey I'm gonna send you a file, ID x" and then the sender could open a uni-directional outgoing stream on their existing connection and send the file

Servers in the middle would just forward the bytes, reciever could accept on their end

> I just don't think there is much value in building a 10% solution when you can just use tor for a 100% solution as a tor user, tor isnt a 100% solution, and we arent there yet with widescale internet routing that can be done anonymously

So kinda proxy65 but no new connections needed, so no one can learn any more IPs or anything than they knew before

>> I just don't think there is much value in building a 10% solution when you can just use tor for a 100% solution > as a tor user, tor isnt a 100% solution, and we arent there yet with widescale internet routing that can be done anonymously Well nothing is going to get closer than Tor to the 100% mark ↺

>nothing lol you havent went far down that path yet

I don't think there's a 100% solution because privacy means different things to different people in different situations.

shit exists already its just deployment thats the issue

Such as?

Just like how many new things spring up that try to reinvent XMPP poorly, many have tried and failed to reinvent Tor in the past too

im not talking about reinventions of tor

Can you say what you are talking about

> Back to file transfers, it would be interesting if all parties (including s2s link) were connected with quic to support a "hey I'm gonna send you a file, ID x" and then the sender could open a uni-directional outgoing stream on their existing connection and send the file Yes, true binary transfer in XMPP is always "out of band" but with this we could get it *almost* in band

but it only works if the whole path is quic otherwise you need to convert somewhere or fail it

>Can you say what you are talking about none of it will help with the topical issue, so no not really the time or place

> but it only works if the whole path is quic otherwise you need to convert somewhere or fail it Right that's the hard part ↺

I'll let other people bikeshed about whether this is "in-band" or not but it would only be going over already established and authenticated connections so...

isnt there a binary xml standard or a way to put binary data in xml?

MSavoritias fae.ve, that's what BoB is, discussed earlier, but it's quite slow because of all the back and forth (iqs) with the server(s) and payload limits

> isnt there a binary xml standard Kinda, won't help with this though > or a way to put binary data in xml? Only one, we use it all the time now, it's just encoding it a base64 (and then it's bloated by % and limited to stanza size when we really want a stream)

pep.: There's no back and forth for BoB

Ah that's ibb?

There's bloat because base64 and size limit so it's not useful for large files

Yes, ibb is lots of back and forth

moparisthebest, is that EXI?

Especially since most people use an extremely small size for ibb as per the xep

MSavoritias fae.ve: the "binary XML" is exi yes

You say EXI doesn't help mostly because it won't solve some of the factor that lead to size limit yeah?

I mean it won't help us send binary streams

Plus it's not really usable on the public federated network but that's a different topic :)

EXI is not mentioned anywhere in 231 /thinking

(it's not usable because you have to negotiate all schemas you are going to use per hop and only closed systems will have that full list)

damn :/

ie currently servers pass stanzas they don't know the schema for all the time, and exi doesn't support that, at least that's my understanding, arc is the (only?) expert here

That's a solveable problem if it would help enough in other ways. But I think I agree size limit is the main issue so it wouldn't be enough

is the size limit of the stanzas documented or is it basically common wisdom?

Not aware of FOSS EXI implementations.

i remember the xep with limits a few ago

but it wasnt about specific i thing

think*

> is the size limit of the stanzas documented or is it basically common wisdom? Finally prosody and ejabberd share a default, so that's the one to use ↺

MSavoritias fae.ve, well the RFC says something of "at least 10 kiB"

Of course when you're gonna base64 you still need some logic around that. I think my limit for BoB right now is 192k

and someone had a path-MTU XEP in the pipeline :)

262_144 bytes

(a.k.a. 256 kiB)

That's probably ok for avatars, not for 100MiB uploaded videos :x

I don't upload files this size but I certainly remember people vehemently arguing about 1MiB limit being nowhere near enough for them :x

For sure. BoB is good for thumbnails, previews, emoji, stickers, stuff like this

Stuff were the experience is ruined by a "do you want to expose ip address" button but also the size is small ✏

> Not aware of FOSS EXI implementations. Openfire has one: https://discourse.igniterealtime.org/t/developing-openfire-efficient-xml-interchange-exi-functionality

> Using EXI format reduces ... the cost of parsing. In what way?

> ie currently servers pass stanzas they don't know the schema for all the time, and exi doesn't support that, at least that's my understanding, arc is the (only?) expert here In my understanding it still passed the 'unrecognised' stanzas, but either not compressed, or after a compression handshake that is not very efficient compared to being able to use a predefined set of schemas.

>> Using EXI format reduces ... the cost of parsing. > In what way? I'm far from an expert, but: it's smaller, but not compressed data, meaning that it can be operated on directly when your app doesn't 'translate back to XML' but speaks EXI directly.

Which I expect can be very applicable to software running on embedded devices, with a predictable data set.

But, one of the reasons that I built that Openfire plugin is that I'd like to test it. I'm waiting for clients to become available 😉

Even embedded devices today are by and large very powerful and have no problem with TLS and XML etc etc

Sure

Basically exi is very complicated and it's not clear to me that it offers any advantages at all over, day, compressing individual stanzas with zstd

Probably easier to bring back compression.

I'm not claiming that this is a silver bullet to anything.

At least in the Java space, a implementation was pretty straightforward.

I'm certainly glad you are doing the harder legwork :)

So I figured: why not?

Afk wife is making me do the dishes.

> I'll let other people bikeshed about whether this is "in-band" or not but it would only be going over already established and authenticated connections so... for purpose of this discussion i'd say same-host is in-band enough

or at leasted trusted host for an xmpp component