XSF Discussion - 2023-08-23


  1. matthias

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

  2. matthias

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

  3. moparisthebest

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

  4. moparisthebest

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

  5. matthias

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

  6. matthias

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

  7. moparisthebest

    those people should be more careful

  8. moparisthebest

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

  9. moparisthebest

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

  10. rdzior4

    Hi!!!

  11. matthias

    > 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.

  12. MSavoritias fae.ve

    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

  13. MattJ

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

  14. MattJ

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

  15. MattJ

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

  16. MSavoritias fae.ve

    yep true

  17. Fishbowler

    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.

  18. Fishbowler

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

  19. Fishbowler

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

  20. Menel

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

  21. Menel

    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?

  22. MSavoritias fae.ve

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

  23. MSavoritias fae.ve

    i mean it already is not imo

  24. matthias

    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?

  25. matthias

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

  26. Fishbowler

    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.

  27. matthias

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

  28. Trung

    Can you upload via tor?

  29. Menel

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

  30. Menel

    (one could too)

  31. Menel

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

  32. Menel

    It doesn't matter from what ip it is done

  33. MattJ

    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

  34. Trung

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

  35. jonas’

    threat models!

  36. Trung

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

  37. jonas’

    certainly works

  38. Trung

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

  39. matthias

    MattJ: true, I forgot that :)

  40. matthias

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

  41. matthias

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

  42. Menel

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

  43. Menel

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

  44. Menel

    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

  45. Menel

    *24h

  46. matthias

    Thanks for your thoughts to all

  47. pep.

    "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 :)

  48. pep.

    "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

  49. pep.

    (And servers proxying, as was mentioned above)

  50. pep.

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

  51. MSavoritias fae.ve

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

  52. MSavoritias fae.ve

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

  53. MSavoritias fae.ve

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

  54. pep.

    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 :)

  55. pep.

    (/s)

  56. Trung

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

  57. Trung

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

  58. MSavoritias fae.ve

    i never open terminals so you lost me there

  59. pep.

    Trung, seriously that's your take on this?

  60. pep.

    I find this naïve

  61. Trung

    pretty much

  62. Trung

    what else are there ?

  63. MSavoritias fae.ve

    eh we are in the xsf room.

  64. MSavoritias fae.ve

    so i guess making xmpp more private :)

  65. pep.

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

  66. pep.

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

  67. MSavoritias fae.ve

    this yeah ^

  68. Trung

    =]]]]

  69. Zash

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

  70. pep.

    Well server proxying is one idea

  71. pep.

    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.

  72. Zash

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

  73. pep.

    Yeah maybe

  74. pep.

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

  75. Zash

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

  76. Zash

    But it would be good to develop something specific to XMPP

  77. Zash

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

  78. pep.

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

  79. Menel

    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?

  80. pep.

    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

  81. Zash

    Out with Tor, in with Oblivious HTTP?

  82. pep.

    :D

  83. Menel

    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.

  84. qy

    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?

    👍 1
  85. qy

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

  86. pep.

    Zash, thanks for the RFC, TIL.

  87. MSavoritias fae.ve

    > 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

  88. opal

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

  89. opal

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

  90. opal

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

  91. Menel

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

  92. MSavoritias fae.ve

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

  93. opal

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

  94. opal

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

  95. MSavoritias fae.ve

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

  96. MSavoritias fae.ve

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

  97. opal

    the "problem" is base64 inflation

  98. opal

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

  99. pep.

    What does this have to do with anything

  100. opal

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

  101. pep.

    I think we've very far away from privacy

  102. opal

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

  103. pep.

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

  104. opal

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

  105. pep.

    Yes

  106. opal

    ok we're on the same page, have fun

  107. pep.

    ?!

  108. qy

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

  109. pep.

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

  110. qy

    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?

  111. qy

    Clients dont need to change anything

  112. qy

    Covers any link sent, not just http upload

  113. pep.

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

  114. qy

    Do you forsee that being problematic?

  115. pep.

    Always?

  116. qy

    I guess the IRC in me is showing...

  117. pep.

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

  118. qy

    Heh, oh yes

  119. opal

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

  120. opal

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

  121. opal

    either the message is sent or it isnt

  122. singpolyma

    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)

  123. singpolyma

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

  124. singpolyma

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

  125. jonas’

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

  126. jonas’

    I'm doing that all the time

  127. Zash

    Confusing it with the subset done in XEP-0065 ?

  128. singpolyma

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

  129. jonas’

    then they're not socks proxies :>

  130. singpolyma

    indeed they are not

  131. singpolyma

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

  132. Zash

    Mostly custom auth

  133. moparisthebest

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

  134. pep.

    Tor isn't a 100% solution though

  135. pep.

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

  136. moparisthebest

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

  137. moparisthebest

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

  138. pep.

    It's not, but it's close

  139. pep.

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

  140. pep.

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

  141. pep.

    Not helpful.

  142. Zash

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

  143. moparisthebest

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

    💯️ 1
  144. pep.

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

  145. Zash

    Cloudflare is your Tor now!

  146. MSavoritias fae.ve

    > 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.

  147. singpolyma

    what kind of basic stuff?

  148. MSavoritias fae.ve

    like why cant i have different profile picture per group?

  149. MSavoritias fae.ve

    its trivial to dox people even behind tor with this

  150. pep.

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

  151. MSavoritias fae.ve

    ^

  152. pep.

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

  153. singpolyma

    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

  154. moparisthebest

    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

  155. singpolyma

    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

  156. MSavoritias fae.ve

    probably. i am talking about current xmpp

  157. MSavoritias fae.ve

    apps i mean

  158. moparisthebest

    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

  159. moparisthebest

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

  160. opal

    > 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

  161. moparisthebest

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

  162. moparisthebest

    >> 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

  163. opal

    >nothing lol you havent went far down that path yet

  164. Zash

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

  165. opal

    shit exists already its just deployment thats the issue

  166. moparisthebest

    Such as?

  167. moparisthebest

    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

  168. opal

    im not talking about reinventions of tor

  169. moparisthebest

    Can you say what you are talking about

  170. singpolyma

    > 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

  171. singpolyma

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

  172. opal

    >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

  173. moparisthebest

    > 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

  174. moparisthebest

    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...

  175. MSavoritias fae.ve

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

  176. pep.

    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

  177. moparisthebest

    > 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)

  178. singpolyma

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

  179. pep.

    Ah that's ibb?

  180. singpolyma

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

  181. singpolyma

    Yes, ibb is lots of back and forth

  182. MSavoritias fae.ve

    moparisthebest, is that EXI?

  183. singpolyma

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

  184. moparisthebest

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

  185. singpolyma

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

  186. moparisthebest

    I mean it won't help us send binary streams

  187. moparisthebest

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

  188. MSavoritias fae.ve

    EXI is not mentioned anywhere in 231 /thinking

  189. moparisthebest

    (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)

  190. MSavoritias fae.ve

    damn :/

  191. moparisthebest

    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

  192. singpolyma

    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

  193. MSavoritias fae.ve

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

  194. Zash

    Not aware of FOSS EXI implementations.

  195. MSavoritias fae.ve

    i remember the xep with limits a few ago

  196. MSavoritias fae.ve

    but it wasnt about specific i thing

  197. MSavoritias fae.ve

    think*

  198. moparisthebest

    > 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

  199. jonas’

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

  200. singpolyma

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

  201. jonas’

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

  202. moparisthebest

    262_144 bytes

  203. jonas’

    (a.k.a. 256 kiB)

  204. pep.

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

  205. pep.

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

  206. singpolyma

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

  207. singpolyma

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

  208. singpolyma

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

  209. Guus

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

  210. moparisthebest

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

  211. Guus

    > 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.

  212. Guus

    >> 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.

  213. Guus

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

  214. Guus

    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 😉

  215. moparisthebest

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

  216. Guus

    Sure

  217. moparisthebest

    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

  218. Zash

    Probably easier to bring back compression.

  219. Guus

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

  220. Guus

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

  221. moparisthebest

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

  222. Guus

    So I figured: why not?

  223. Guus

    Afk wife is making me do the dishes.

  224. opal

    > 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

  225. opal

    or at leasted trusted host for an xmpp component