XSF Discussion - 2021-07-28


  1. goffi

    Hi > phryk a écrit : > The concept for an XMPP messenger I came up with some time last year was using python + kivy so I can do responsive design from the ground up and do desktop + android + iOS (+ pinephone or whatever) – basically one client to rule them all. :P Libervia Desktop is doing exactly that.

  2. jonas’

    "split ability inspired from Blender"

  3. jonas’ tries to imagine his mother using blender

  4. goffi

    jonas’: you don't need to use it, it working without it.

  5. emus

    There have been questions raised if the XMPP Office Hours has been recorded, here we go: https://youtu.be/e1-hpsQ9OZE

  6. phryk

    roster encryption was a feature someone is working on, right? i seem to vaguely remember something about this, but can't find any info…

  7. jonas’

    I think people were talking about it, but nobody is actively working on it AFAIK

  8. Ge0rG

    Zash made a prototype of sorts

  9. Zash

    Not covering rosters

  10. phryk

    Not sure if I'm 100% on the terminology here anyways – rosters are/include the contact list, right?

  11. flow

    eventually I don't think that encrypted rosters are feasible

  12. MattJ

    phryk, correct

  13. flow

    you'll loose some functionality that may be considered crucial

  14. Kev

    You could encrypt the roster, but the effect would be largely pointless.

  15. phryk

    Why?

  16. Kev

    Because the server that holds the roster is the server that will route your presence information and messages to/from your contracts.

  17. flow

    phryk, the server may need to make a decission based on someone being in your roster (contact list) or not

  18. Kev

    So even if you encrypted the roster, and moved presence fan-out to the client, the server would still route the presences.

  19. phryk

    Oh, damn. :<

  20. phryk

    Any other recommendations to protect the social graph of people in case of compromise?

  21. Kev

    It *does* mean that technically at-rest data wouldn’t contain your contacts, I suppose, which isn’t nothing, but is probably not the attack vector anyone cares about when talking about encrypted rosters.

  22. Kev

    You can’t really (with XMPP or otherwise), all you can do is move around which the systems that matter if they’re compromised are.

  23. flow

    phryk, the best answer I have are is that we should make self-hosting very easy and reliable, so that there are as many as possible small self-hosted services

  24. flow

    but then again, many small services also make it easier to determine who is communicating with whom (in the absence of countermeasures like tor)

  25. phryk

    So only a P2P solution can effectively protect the social graph of users?

  26. Kev

    No, even a P2P solution can’t.

  27. flow

    define P2P solution

  28. Kev

    Indeed, a P2P solution is, in some ways, *more* vulnerable to such things.

  29. phryk

    Well, mostly contact list completely client-side.

  30. Zash

    P2P makes everyone a server

  31. phryk

    Mhh true, because every user has to harden their own device…

  32. Kev

    Not just that.

  33. Kev

    If you’re observing traffic between an XMPP user’s device and their server, who are they talking to?

  34. phryk

    You need surveillance around the server to make any guesses to that, i think.

  35. Kev

    No clue. If you’re observing traffic for a “P2P client”’s device, you see where that traffic is going.

  36. Kev

    And observing network traffic is a more likely attack than compromising a server (although both are possible).

  37. phryk

    That's also mitigatable by tor, tho.

  38. MattJ

    phryk, surveillance of the network around the client and/or server is significantly easier than surveillance *on* the server (which requires compromise of the server)

  39. Kev

    Except when the surveilance authority is running your tor exit points.

  40. phryk

    Point.

  41. Kev

    So I assert that this is a problem you cannot solve, you can just move around your pain point

  42. MattJ

    This is basically what Snowden revealed in 2013 (that mass surveillance of internet traffic is a real thing)

  43. phryk

    Yeah, I'm trying to do my best due dilligance to protect people from that. :P

  44. Kev

    (And I’m not saying that moving around the pain point is necessarily without merit. Just that you can’t solve it)

  45. phryk

    Mhh, I could at least allow for obfuscating social graphs by allowing users to create multiple accounts, tho… But that would kind of defeat the whole invite-only and limited user number thing I'm going for…

  46. Zash

    There may be things to encrypt to protect from a casual nosy admin, but it that worth the effort?

  47. phryk

    Guess I'll just need to teach my users about identity compartmentalization.

  48. Link Mauve

    phryk, even then, you still have other metadata which can somewhat easily be used to correlate these identities.

  49. Link Mauve

    Such as the times you log in and log off.

  50. Link Mauve

    If these two accounts always log in at the exact same time every day, a surveillance entity can assume they are controlled by the same person.

  51. phryk

    Yeah, was talking with somebody about that yesterday. And thought maybe having the server always claim everyone is online is a good solution. The server itself will still know when users are actually online and with MAM even E2EE works when users are actually offline, no?

  52. phryk

    (if the contacting knows the pubkey from previous communication)

  53. phryk

    (if the contacting user/client knows the pubkey from previous communication)

  54. Link Mauve

    phryk, even just the amount of data being transferred makes it easy to distinguish between a client connecting, a client operating normally, and a client being disconnected.

  55. flow

    phryk, most (all I know) E2EE schemes do not require MAM

  56. Link Mauve

    Solving the surveillance problem is, well, hard.

  57. phryk

    Heh, ain't that the truth. :P

  58. flow

    phryk, but with double-ratchet mechanisms, like OMEMO, it is beneficial if the client logs in once in a while to advance the ratchet

  59. phryk

    Oh right, the "ratchet" part means new temporary keys are derived from the keypair – do I remember that right?

  60. Link Mauve

    phryk, your idea is to fake a client being always connected on your users’ accounts?

  61. phryk

    Yeah, in hindsight, I don't think this will do anything. ^^;

  62. phryk

    Well, it'd lessen infoleak towards people in users' rosters…

  63. phryk

    But not do anything from the perspective of someone surveilling network activity.

  64. Link Mauve

    Not even that, because it would then be very easy for your users’ contacts to figure out this fake client never answers, and thus only consider them online if they have a second resource connected.

  65. phryk

    Well, I'd say save the last connected esource name and remove the fake client once a client actually connects – so it just looks like they moved from one client to another – or as if nothing happened. but still not worth the trouble, I'd say.^

  66. phryk

    ^^;

  67. phryk

    I'm gonna go get some grocery shopping done real quick.

  68. phryk

    (oh no, now the cops now to breach this place when i go out)

  69. southerntofu

    phryk, for tor-routed P2P messaging that's precisely what briar.im is doing, would be very interesting to get XMPP interop :)

  70. southerntofu

    Link Mauve, if clients are broadcast as permanently online (reducing presence spam) and sessions are tor-routed, then network analysis becomes harder (though not entirely impossible)

  71. southerntofu

    i'm curious about a presence-less XMPP.. would it break things in fact? (or reduced preesnce, as handled by server not client)

  72. MattJ

    Start of the day: discussion about how we should encrypt rosters, end of the day: discussion about how we should move presence handling entirely to the server

  73. MattJ

    Conflict

  74. southerntofu

    MattJ, why conflict? in my view it's part of the same threat model

  75. southerntofu

    eg. leak less info about the client to other servers, and store less info about the client on the home server

  76. Zash

    Something something hold two conflicting ideas in your head at the same time, and accept both as true.

  77. MattJ

    The server needs to know who to send presence to/who should be allowed to view your presence

  78. MattJ

    That's the roster

  79. Sam

    Presenceless would require the server to cache/update CAPS hashes, which would be interesting.

  80. southerntofu

    emus, Sam, about XMPP office hours recording, should we maybe setup a peertube instance?

  81. Zash

    Oh, yes, replace presence with caps update notifications! Such a win!

  82. Sam

    southerntofu: if you're volunteering to maintain it and pay for storage space and CPU time, then sure, I'd love that :)

  83. Sam

    And to upload the videos and make sure the descriptions match or auto-sync with YouTube or whatever.

  84. southerntofu

    from experience resource usage is rather low (unless you do tons of transcoding) maybe joinjabber.org has resources for that!

  85. southerntofu

    we have ~200MB RAM usage (2GB total) and 4vCPUs mostly running idle

  86. Sam

    Zash: right; if you get rid of presences you either go back to disco spam, or the server has to handle all that. I'm assuming you'd still send presence, just not as often because caps likely won't change. So more or less just initial "online" presence and caps per session

  87. southerntofu

    Sam, is this what CAPS is about? https://xmpp.org/extensions/xep-0127.html

  88. southerntofu

    i'll do further reading before i comment further on that issue :)

  89. Sam

    southerntofu: sorry, I meant entity caps https://xmpp.org/extensions/xep-0115.html

  90. Sam

    It never occured to me that those names are confusing.

  91. Zash

    But then how relevant are even caps given MAM and Carbons and stuff?

  92. southerntofu

    Sam, for video upload it should be straightforward to make a peertube->youtube importer (maybe it already exists!) but the other way around i strongly disrecommend as Youtube doesn't guarantee when/if the videos will be available to parse/download

  93. southerntofu

    as the indieweb saying goes "Publish on your Own Site, Syndicate Elsewhere" (POSSE)

  94. Sam

    Sure, other way is fine, as long as we can upload to one place and have it wind up in both

  95. southerntofu

    Sam, i've never used youtube account, but if you give me an API key i'm 99% confident i can roll up a peertube RSS -> youtube upload bot pipeline

  96. Sam

    Zash: how do MAM/Carbons make caps irrelevant?

  97. southerntofu

    Zash, i'm not entirely sure that's why i was asking, i'll do more reading and come back to you! my understanding of XMPP prootcol is still <25% :)

  98. Sam

    southerntofu: if you actually want to host a peertube instance and the XSF wants to use it (I assume they do, emus on the comms team and I have talked about this a lot) I'd be absolutely thrilled to give you a youtube key and we can figure out how to sync them and make it an official channel! (again, assuming the XSF wants to do that)

  99. MattJ

    Caps are useful to discover the features supported by the recipient of your traffic. In a world where everything you send is replicated to every device of the recipient (including future devices that haven't been seen yet), it makes no sense.

  100. Zash

    Sam: You don't know if the receiver supports anything, a client you never got the caps from could read messages from MAM later. Etc.

  101. Sam

    oh, are we assuming the latest caps is stored in MAM somewhere? I'm thinking if we want to know if jingle is in disco#info for example, I don't see how MAM/Carbons helps us with that.

  102. Zash

    Huh

  103. MattJ

    No

  104. MattJ

    Jingle is a great example though

  105. mathieui

    southerntofu: I asked the question previously for peertube, the answer is that if anyone is willing to do the work to setup sync it will be very welcomed

  106. MattJ

    When it was first designed, it used an iq, directly between two resources. You could use disco to figure out which device(s) of your contact you send the call to.

  107. Zash

    But now the recipient is the account, not the resource, so maybe we should start broadcasting caps of accounts instead.

  108. MattJ

    Now the preferred solution is to initiate Jingle via a message, which gets forked to all devices (ignored by those that don't support it), push notified if relevant, and stored in MAM for offline clients to show a missed call was received, etc.

  109. moparisthebest

    in fact it probably should just assume jingle support and send calls anyway, so if your one client that can do calling logs on later today, you'll see a missed call ?

  110. MattJ

    ^

  111. Sam

    Sure, but how do we know that *any* client supports jingle calling ot show the icon in the first place?

  112. moparisthebest

    you shouldn't care, just show it

  113. Sam

    Or mark it as un-greyed-out or whatever our UI is. I wouldn't want to just always pretend the call is working even if there's no support/hope of it being picked up.

  114. Sam

    That seems like a terrible UX. <Why has my friend literally never answered any of my calls no matter how many times I try? Guess they're mad at me and don't want to talk.>

  115. MattJ

    We currently don't, we could hack a solution for that indeed (currently Conversations requires it to be seen in disco at least once, then it's permanently displayed for that contact)

  116. moparisthebest

    is it terrible UX though? how is it different from you calling a friend on a land line and they are on vacation or no longer have that phone or whatever

  117. Zash

    All this is terrible!

  118. Sam

    It is different, but also even if it weren't I hope we can provide a better experience than a landline. The landline doesn't have an icon that says "your friend is definitely here", we do so we should probably not make it look like something will work that has no chance of working.

  119. moparisthebest

    "online" doesn't mean they are there and will ever look at messages either

  120. Sam

    But the UX is veering off course. I'm just saying that we still need to be able to check disco#info, which means a way to cache them and know which ones we have/have not fetched is still useful.

  121. moparisthebest

    or... stop doing disco all together

  122. Zash

    Uh, too much text, not enough ice cream to follow this discussion anymore.

  123. moparisthebest

    since it was designed for a world where you dial up to the internet for a few hours with your 1 client every night

  124. Sam

    That's fine, but I thought the statement was "right now Carbons/MAM makes caps useless", and I'm disputing that. Sure, in the future we could replace disco with something entirely different.

  125. southerntofu

    MattJ, about presence vs encrypted roster, i'm talking about a model where presence would be the same for all users, so you would in fact leak whether an account actually exists, but not more information (is it online? etc).. the only issue i would see would be spam management because eg. mod_firewall rules have to be applied at some point, but maybe the server could append incoming useful (not presence) to the user-encrypted mailbox up to a certain storage quota (think 100MB) then start droppping stuff, then firewall rules would be applied on user mailbox decryption (during login process, where box private key is derived from user password)

  126. southerntofu

    that's *sort of* what riseup.net is doing for email

  127. Zash

    Should we move the whole model to one with persistent resources that have caps+disco#info stored on the server?

  128. MattJ

    That's basically happening with push registrations (currently in a hacky non-standard way)

  129. southerntofu

    and the fact they can't have user-encrypted boxes in case of server compromised (therefore potentially leaking roster + metadata history despite mod_e2ee being enforced) is precisely why they're dropping XMPP support

  130. Zash

    And OMEMO devices

  131. moparisthebest

    southerntofu, the reason they conflict is, for server to do anything presence-wise it has to have access to your roster, and if your roster is encrypted, it doesn't have that access...

  132. southerntofu

    and i heard at least one other "big" hosting coop is dropping XMPP hosting for the same reason

  133. southerntofu

    moparisthebest, why would it need to do anything presence-wise except responding to pings?

  134. moparisthebest

    you said the server would make presence be the same for all users ?

  135. southerntofu

    Zash, i think the permanent subscription model is one of the attractive things about matrix for end-users

  136. Zash

    What

  137. southerntofu

    moparisthebest, yes, hypothetically. pretend every one is online or offline all the time

  138. moparisthebest

    southerntofu, and expose that to everyone all the time? for that to be "safe" you'd have to also pretend all accounts exist

  139. moparisthebest

    but it still wouldn't be safe due to disco/caps etc, you'd be able to identify users and such

  140. southerntofu

    Zash, room subscriptions are permannet in matrix world (which has downsides), no such thing as MAM etc

  141. southerntofu

    (eg. you never miss messages if you were offline)

  142. Zash

    What

  143. southerntofu

    if your client is offlinethe server is still receiving messages for you, leading to higher resource usage (especially since accounts who haven't logged in in 6 months are still subscribed to the rooms), but you receive all messages when you reconnect, not just those stored in a size-limited archive

  144. Zash

    "no such thing as MAM" I think you mean the whole thing is one single MAM thing

  145. southerntofu

    moparisthebest, hiding what accounts actually exist COULD be even better (though i think it's nice to have an error when you do a typo on an account name ;)) but i do consider whether a nick exists or not to be a lower-danger leak than presence information

  146. southerntofu

    Zash, ah yes, that's one way to put it :D

  147. emus

    southerntofu: Im fine to have peertube as an alternative, but I think we are low on ressources, so someone would need to volunteer

  148. Sam

    Hmm, I've been working on my little experimental TUI client more lately and now I wonder if I should get rid of presence all together. I still don't love not having it, but honestly I've been proven wrong about how much I needed it since using Conversations so maybe it really doesn't matter and I was just being conservative about change

  149. Sam

    or get rid of visible presence, I mean. In light of this discussion.

  150. southerntofu

    moparisthebest, but if you have critiques about other venues of cross-account tracking, consider me very interested to know and potentially mitigate

  151. southerntofu

    Sam, it's becoming an increasing UX pattern to either not show whether the contact is online, or not make it an important information (eg. don't hide offline contacts, but maybe order convos by date of last message?)

  152. Zash

    Going back to the SMS experience...

  153. Zash

    Meanwhile the Slack & clones crowd do want presence.

  154. moparisthebest

    southerntofu: XMPP core already hides presence from your non contacts so what are you after?

  155. southerntofu

    emus, i can't give any guarantees about reliability but i'm happy to write a recipe to set it up on joinjabber.org and see how it goes?!

  156. Zash

    Your boss wants to know if you'll reply when they ask you questions.

  157. southerntofu

    emus, Sam do you have a handy subdomain to CNAME to emma.joinjabber.org ?

  158. southerntofu

    moparisthebest, presence is broadcast to contacts and chatrooms, that's already a huge leak that can be used to correlate different accounts based on when thye are available

  159. Sam

    southerntofu: An XSF one? No, we'd probably want to set it up on some other random domain until we can get XSF approval to make it an "official" peertube instance on the domain or whatever

  160. southerntofu

    Zash, i agree presence and such (message receipts, "composing" notices) can be useful in some contexts, what i'm interested in is developing a use case of XMPP as a privacy-friendly platform where a single switch in client/server config can harden things considerably by turning off a lot of features

  161. moparisthebest

    southerntofu: you probably shouldn't add attackers as contacts? Ie don't press the "share my presence with this person" button on people who you don't want to have it?

  162. southerntofu

    moparisthebest, you never know! and to my knowledge my presence leaks to all persons in public MUCs, right? which is why i run poezio 24/7 on a VM :)

  163. moparisthebest

    The muc is a different story but there are easier solutions there

  164. southerntofu

    Sam, what about.. video.joinjabber.org? tube.joinjabber.org? media.joinjabber.org?

  165. moparisthebest

    southerntofu: such as https://modules.prosody.im/mod_minimix.html

  166. Zash

    MIX when?

  167. southerntofu

    moparisthebest, that osunds good indeed, except for the "known issues" :D

  168. Sam

    southerntofu: those sound good to me; if this is *just* for the XSF we can add a subdomain later if whomever controls the domain approves and update it to use that, or if joinjabber just wants to host peertube and the XSF just has a channel and links to video.joinjabber.org/xsf or whatever that seems fine too

  169. moparisthebest

    Mix never seems like

  170. southerntofu

    > video.joinjabber.org/xsf <-- yes something like this i believe :)

  171. southerntofu

    Sam, do you have the sources of videos from youtube i can download as a tarball from somewhere? how much space is that? we have about 24GB free on joinjabber.org

  172. emus

    > southerntofu escribió: > emus, Sam do you have a handy subdomain to CNAME to emma.joinjabber.org ? why emma?

  173. emus

    video.joinjabber.org/xsf thats better maybe

  174. Sam

    southerntofu: I don't have them all in one tarball, but I can send you some links. Reach out to my JID and I'll put together a list right now.

  175. southerntofu

    emus, a tribute to Emma Goldman, a popular hero of american history, or a humble figure of workers struggle against State, capitalism and patriarchy if you prefer this interpretation

  176. Sam

    (let's move the peertube discussion to the joinjabber room since you're asking about it there anyways; thanks for offering to do this!)

  177. southerntofu

    happy to help any way i can, always a shame to see federated protocols rely on centralized services to spread the word :)

  178. emus

    southerntofu: I think we should not our peertube with political substatements which are not related

  179. southerntofu

    emus, that is your personal opinion, and mine is wildly different (because i see a relation between technic and politic), i cannot speak in the name of the joinjabber.org collective but our goals stated are very political (empower users against Nation States and corporations interests).. we would probably be happy to host try and host less-political content because that would be aligned with our political values of decentralization, but if you are unhappy to cohabitate with a political collective then for sure you are welcome to host it yourself

  180. southerntofu

    emus, i will write ansible recipes anyway so setup should be in fact very simple

  181. emus

    I'm pretty sure that will then not run under the name of XSF, but feel free to share the videos

  182. southerntofu

    i don't intend to usurp the name of XSF as i'm not even a member of that collective, but i'm happy to provide hosting space for a XSF account if it can help with your lack of resources and bureaucratic process, because in this instance our goals are aligned: spreading information about inteesting developments in the Jabber/XMPP ecosystem

  183. southerntofu

    with the caveat that we have very limited resources ourselves (provided by fosshost) and can't provide any guarantees about uptime and such, so it's more meant as a proof of concept while you can deploy your own :)

  184. southerntofu

    (of course if what i'm proposing is in fact not a service done to the community and creates problem, just tell me and i just won't do it)

  185. emus

    Yes, that is great. However, I cannot do it myself, I think thats the bigger hurdle currently.

  186. Sam

    Back to where we started: "we can have peertube if someone wants to host it or register it somewhere and maintain syncing between it and youtube" :)

  187. Sam

    (and apparently the XSF needs an actual youtube account if we want to do that because API keys are associated with a personal account, not with the org account, so maybe we're even further from it)

  188. wuuko

    Test

  189. chronosx88

    Test passed

  190. bung9

    Test

  191. wuuko

    Blabber.im server unreachable

  192. wuuko

    Blabber.im server unreachable

  193. wuuko

    Test

  194. wuuko

    Blabber.im server unreachable

  195. wuuko

    How about you?

  196. wuuko

    > I wrote: > Test > Blabber.im server unreachable Not server room

  197. me9

    Why do you test and ask here?

  198. wuuko

    This is the only place I can talk.

  199. Zash

    Blabber.im shut down some weeks ago.

  200. wuuko

    Not I say room

  201. wuuko

    No I say room

  202. me9

    > Zash wrote: > Blabber.im shut down some weeks ago. More like months.

  203. me9

    There was no clear reasoning, the client still continues, the serevr wpn't come back. Any.other questions?

  204. me9

    ** There was no clear reasoning, the client still continues, the server won't come back. Any other questions?

  205. Zash

    My sense of time was less than accurate even before the pandemic. Is it April 2020 yet?

  206. wuuko

    I can't text other rooms, even if it's a new account.

  207. wuuko

    This message is coming in late, too.

  208. me9

    > Zash wrote: > My sense of time was less than accurate even before the pandemic. Is it April 2020 yet? Hmmmmmmmm.

  209. me9

    Btw, it seems it's problems with jabber.fr.

  210. wuuko

    Yes

  211. Zash

    This kind of report is probably more on-topic in xmpp:operators@muc.xmpp.org?join

  212. Zash

    And then I find the webpage I was looking for: https://xmpp.org/community/channels/operators

  213. me9

    Yes!

  214. wuuko

    Now jabber.fr has got some problem

  215. wgreenhouse

    > My sense of time was less than accurate even before the pandemic. Is it April 2020 yet? Zash: to paraphrase William Gibson, April 2020 is already here, just unevenly distributed.