XSF Discussion - 2022-05-31

  1. Guus

    Are there any best practices on ensuing that only a recognized (mobile) device is used by a particular end-user? For example, not any other phone than the first one that was used by the client (unless some kind of manual administrative action is performed?

  2. Guus

    Basically, I'm looking for a way to prevent a device other than the one that's either implicitly or explicitly associated with the end-user to be used for the account of that end-user.

  3. Kev

    Do you control the client and server?

  4. Kev

    It's not a best practice, but in that case you could fairly easily use a persistent resource from the client (but would obviously have to then randomise it on the server).

  5. jonas’

    Guus, generate a certificate, use client-certificate authentication.

  6. jonas’

    (and put the key into device storage which cannot be copied (easily) to another device, don't allow sign-up with another key unless administrative action)

  7. Kev

    Or that, depending how much 'administrative action' you want to be required.

  8. Guus

    Kev: as in resource binding? I thought of that, but I worried that this would be pretty easy to mimic - especially since the resource that's used will be used in stanzas that are sent to other users?

  9. Guus

    jonas’ thanks, that's the route that I was dreading :)

  10. Kev

    No, you'd reject the client-provided resource and use a server-provided one.

  11. Guus

    Kev: ah, right - so the client-provided resource would never escape into the wild. That hinges on clients actually accepting a server-provided resource that's different from the one that they provide. I recall that the spec allows for this, but is that used in practice?

  12. Kev


  13. Kev

    Clients that don't cope with server-provided resources are broken.

  14. Kev

    But I did predictate it on you controlling the server and client :)

  15. Guus

    me controlling the server and client does not implicate that they're not broken. :D

  16. Kev


  17. jonas’

    Guus, why dreading? It should be simple and straightforward and it ensures your requirements more or less cryptographically

  18. Guus

    nothing involving client-sided certificates is ever simple, in my experience.

  19. jonas’

    it is if you treat them mostly as a private key

  20. Kev

    jonas’ : It does require that either the admin is generating new certs themselves and injecting them into the devices somehow, or that they are somehow tying up randomly client-generated certs with user credentials. Whereas the resource would allow you to build a system where the admin merely has to approve a new client, knowing for whom it is. I guess it depends on Guus's requirements.

  21. jonas’

    i.e. no CA involved, possibly even ignore expiration (or let them live for 1000 years)

  22. Kev

    But if you're happy to pre-provision the clients with generated certs, it should indeed not be terribly complicated. We've had deployments do similar things in the past.

  23. jonas’

    I'd just generate the key on initial sign up

  24. jonas’

    and use whatever procedure you use to trust the password the user supplies during signup to trust the key

  25. jonas’

    no pre-provisioning or CA involved, that's, indeed, just madneess

  26. jonas’

    no pre-provisioning or CA involved, that's, indeed, just madness

  27. Guus

    jonas’: so, have an initial password-based auth, which somehow provides a cert for the device, which, once registered makes unavailable the password-based auth and will require something like SASL External for that device from then on?

  28. Guus

    I guess that could be sold to the end-user as some kind of 'account activation', which under water registers a cert for the end-user.

  29. jonas’

    what no

  30. jonas’

    just let the app provide the private key instead of the username/password on signup

  31. jonas’

    how does your signup procedure work?

  32. jonas’

    (if you're integrating with an existing username/password based scheme, then yes, your flow sounds sensible)

  33. Guus

    jonas’: yeah, user definitions preexist.

  34. flow

    how does any of that ensure that only a recognized device is used by a particular user? the client cert could be transferred and the resource could also be simply configured by another device, no? I guess you need to have full control over the client software (which is possible on mobile platforms) and use some onbording procedure when the user starts the client for the first time

  35. flow

    fwiw, TLS-PSK (Pre Shared Key) is also a thing, but other than that, I aggree with jonas’ that (TLS) certs become easy if you treat them like "private keys"

  36. flow

    although I am not sure if they provide than any advantage ofer a PSK

  37. jonas’

    Guus, ah then the activation workflow makes sense

  38. moparisthebest

    smells of corporate security to me

  39. moparisthebest

    and by that I mean they'll make it as user-hostile as possible for 0 benefit other than being able to check a box that says "secure"

  40. flow

    dunno, those specialized locked-down clients do not need to be user-hostile, in fact, the could be very user friendly

  41. flow

    wouldn't be surprised if Conversations would bring support for such a setup

  42. jonas’

    I am looking forward to the day we have actual per-device credentials (be it TLS keys, or Device-key-SASL, or whatever)

  43. jonas’

    of course, then without the limitation of one device per user

  44. MattJ

    Working on it :)

  45. Zash

    You can burn a full JID into the cert

  46. jonas’

    (well, actually not "whatever". I strongly think it should be devicekey or TLS keys)

  47. Zash

    Vaguely related, how do I https://datatracker.ietf.org/doc/html/rfc7250 ?

  48. qy

    You know how clients like to skip entire bundles of XEPs to "keep their UI simple"? Maybe it'd be useful to have a standand UI or UI guidelines, so that doesn't have to be the case?

  49. qy looking at conversations and dino particularly

  50. Seve

    https://matrix.org/blog/2022/05/30/welcoming-rocket-chat-to-matrix moparisthebest: already discussed this too?

  51. Zash

    qy, huh?

  52. Zash

    something something https://docs.modernxmpp.org/

  53. qy

    Zash: Gajim's rather feature complete, the other two are not, as i understand it primarily because they're UI-first and want to keep things "simple"/"easy to use" - so if there was a known UI form, that wouldnt be an excuse?

  54. qy

    > Zash wrote: > something something https://docs.modernxmpp.org/ ...oh

  55. qy

    Well, 🚀 modernxmpp

  56. Zash

    Dino has video conferencing, your argument is invalid

  57. qy

    It doesn't have a disco browser :-)

  58. Zash

    Also, diversity and the freedom to try out different things is a strength here. All clients don't have to be the same.

  59. moparisthebest

    what features are you missing? all the stuff that has *terrible* UI like ad-hoc commands? :P

  60. qy

    Zash: But it is the biggest flaw of xmpp

  61. qy

    Well, it doesn't _have_ to have terrible ui if we figure out a nice one!

  62. moparisthebest

    has anyone ever used ad-hoc commands and thought "hmm that was a pleasent experience"

  63. Zash

    That's just, like, your opinion, man

  64. qy


  65. moparisthebest

    usually more like "hmm why did the whole thing freeze" "oh no I clicked back and it crashed" "why didn't anything save"

  66. qy

    moparisthebest: I actually think as theyre done in gajim, pretty nice. I'll agree in profanity, not a great time, but im grateful theyre at least there...

  67. qy

    How else am i meant to configure biboumi :|

  68. qy

    Routinely have to operate 5 different clients to do everything i want smh

  69. moparisthebest

    biboumi should be configurable over a bot-like interface

  70. Zash

    I'm sure the Soprani.ca folks are plenty interested in improving the experience with gateways etc

  71. moparisthebest

    they just went ahead and made everything configurable via talking to a bot, works very well

  72. qy

    Are we just anti adhoc being a thing then?

  73. qy

    What about disco?

  74. wgreenhouse

    ad hoc is useful because you can do input validation, and you can also format the output of commands

  75. Zash

    Who's this "we"?

  76. wgreenhouse

    soprani.ca folks are adding it to their conversations fork, for that reason

  77. wgreenhouse

    > Who's this "we"? modernxmpp and/or the authors of more recent gui clients

  78. qy

    wgreenhouse: I may switch to that fork, unless blabber adopts it too...

  79. wgreenhouse

    > has anyone ever used ad-hoc commands and thought "hmm that was a pleasent experience" moparisthebest: they work great for me in jabber.el :D

  80. qy

    Is it a prompt-based flow in j.el?

  81. moparisthebest

    you can do input validation in a bot too

  82. qy

    moparisthebest: Do you have something against ad-hoc in particular? Or just think it can't be implemented nicely?

  83. qy

    It is a stable xep, isn't it?

  84. moparisthebest

    just that it can't be implemented nicely and serves no purpose that a bot doesn't serve easier, imho

  85. qy

    Feels like IRC logic; everything as chat :p

  86. Zash

    never say never, but it takes effort on both client and server side to get the most out of it

  87. qy yearns for xmpp nickserv

  88. Zash

    I think Gajim did an excellent job, but on the other hand I haven't touched adhoc in months. Configuring Biboumi is mostly a one-time thing.

  89. Zash

    Most available ad-hoc commands are server admin related, for which `prosodyctl shell` is just so much nicer and more powerful.

  90. wgreenhouse

    > Is it a prompt-based flow in j.el? qy: no, it's a new emacs buffer with fields, like M-x customize

  91. qy

    Oh excellent indeed

  92. wgreenhouse

    so you can actually keep chatting with that jid, it doesn't "steal" the buffer

  93. moparisthebest

    ha yes, I last touched biboumi config years ago (using gajim), and haven't needed ad-hoc for prosody in years either for what Zash mentioned

  94. qy

    For weechat i think i'm gonna have to copy profanity's model but make it a bit more prompt-based

  95. moparisthebest

    good luck keeping your infinitly configurable UI code concise and bug free :D

  96. wgreenhouse

    there are beaucoup bugs, just not in ad hoc handling. :P

  97. Sam

    This is something I've been particularly interested in lately. I really thought that dataforms were the main problem and couldn't be used to create a nice UI, and while I still don't love them I have come around on their existance a bit.

  98. Sam

    However, the ad-hoc spec is just *really* hard to understand and implement properly for something that should be simple, so I still suspect that it ends up being horribly buggy not because of UI problems, but because of how it's written and explained.

  99. Zash

    Observation: You don't need dataforms for parameter-less ad-hoc commands.

  100. Sam

    Sure, that's why I thought forms were the problem then I discovered that even for parameterless ones there were lots of bugs and issues for something that should have been trivially simple.

  101. Zash

    Also, I think you could replace dataforms with anything as payload carrier, tho that's probably more interesting for some RPC uses

  102. Sam

    So I'm really not sure about them now. I've come around a little bit, but kind of think the whole thing should be thrown out and re-written. Then again, we haven't had much success with that strategy in the past, even for things that didn't have a huge number of implementations.

  103. Zash

    Overly generic things are tricky.

  104. Zash

    Many things could probably be done with the simpler registration XEP (77?)

  105. Sam

    This is probably the underlying problem ⤴️

  106. wgreenhouse

    registration would make more sense for things like biboumi

  107. wgreenhouse

    since what most people are doing is setting nickserv stuff and maybe changing the hostname to connect to

  108. pep.

    > moparisthebest> has anyone ever used ad-hoc commands and thought "hmm that was a pleasent experience" Actually, yes. Poezio's UI here is ok. I get it's an "advanced feature" (handling generic adhoc forms) and I think that's why it's not in C nor Dino, not because it's "not pretty" or "not easily usable".

  109. qy grumbles about being an advanced user

  110. Sam

    Same with Communiqué, I think, but it was *really* hard to figure out all the weird ad-hoc bugs, and I'm sure it's still probably not compatible with some implementations.

  111. moparisthebest

    so you are writing a service, and debating on how best to let users configure it, your options are: 1. text bot, works with literally everything, including bridges, don't need to test anything else because there aren't differences in implementations 2. ad-hoc commands, works with a couple clients, you have to test them each because they each display things differently and have different bugs, and no other clients care to support them because of all of these problems

  112. moparisthebest

    but hey whatever floats your boat, as an advanced user I'd much rather just use text anyway, ad-hoc commands are more akin to the windows registry :P

  113. wgreenhouse

    ouch. fair enough, though

  114. qy

    ...you're using the windows registry as an example of good, modern design?

  115. moparisthebest

    yes, as good and modern as ad-hoc commands :)

  116. qy

    Have I entered the twilight zone 😧

  117. qy

    Anyway, i agree for now, thats why i was trying to think of how to get more clients to implement ad-hoc commands

  118. qy

    Because if only half the clients implement it, its not worth any of them doing it

  119. moparisthebest

    classic chicken and egg

  120. qy

    But if you premake the egg, who needs a chicken

  121. qy

    Hence, modernxmpp ui and implementation guidelines for ad-hoc commands, so its nice&easy

  122. qy

    > here's a yolk i prepared earlier

  123. pep.

    moparisthebest: bot-as-interface reminds me of your position regarding 393 :p

  124. pep.

    And I completely understand why you like it, and you may understand why I would hate it

  125. moparisthebest

    you might notice a pattern here, 393 and bots are KISS, ad-hoc and choose-your-own-markup are not :D

  126. qy

    moparisthebest: I feel like you would really like IRC

  127. pep.

    moparisthebest: KISS, but for whom :)

  128. pep.

    The receiving client can't have any specific UI for your gateway if the interface is a bot, there's no choice but to make a generic message-sending UI

  129. pep.

    It's simple for client devs, maybe, not for users

  130. moparisthebest

    it's more simple for users

  131. moparisthebest

    "message X and have a conversation" vs "60 minutes of them nodding their heads while attempting to explain what an ad-hoc is"

  132. moparisthebest

    qy, I do like IRC :P just through XMPP

  133. Sam

    I had a nice little library I was working on that let you design ad-hoc command flows and then it would respond to them both with forms and with chat messages (and I think the sopranica folks have something similar). It's not an either/or situation, but I definitely think for normal users a UI would be preferred. Even as someone who doesn't really care one way or another, the UI is way easier in some situations.

  134. moparisthebest

    yea both sounds like a good option if it's easy enough

  135. Sam

    There are situations where you can't have both, of course. Mcabber responds to a few ad-hoc commands to allow you to eg. set its staus from another client. It's quite nice, but obviously if you sent a message to the JID you'd expect it to just be delivered as a normal message

  136. wgreenhouse

    the case where the recipient is also an entity you can message with is an argument for ad hoc. like, biboumi's configuration uses ad hoc in part because the server JID is also what you chat with to send raw IRC commands

  137. wgreenhouse

    maybe 0077 is a way out, if it's simpler to implement

  138. pep.

    I think the fact that it's simpler to implement is a non-argument between all of these options. Yes adhoc takes a bit more to implement but It's not like it (or a -- nonexistent -- different intetface with similar goals) was exceptionally hard to implement either

  139. Sam

    Oh I disagree, ad-hoc was exceptionally hard to implement correctly.

  140. Sam

    The spec is incredibly confusing and often vague.

  141. Zash

    I'm thinking it's okay to reserve it for where the complexity is warranted.

  142. pep.

    Sam: maybe the spec needs improving/redoing, but I don't think that the concept in itself is complex

  143. Zash

    Clarifications of the specs are always welcome

  144. qy

    What part was hard to implement, ooi?

  145. qy

    I haven't tried yet, so curious

  146. lovetox

    If I remember correctly it's a bit confusing with the actions and default actions that are available in each stage

  147. lovetox

    And I think there was clarifications on that part

  148. moparisthebest

    if you all are like me, you read/implement a spec, find it annoying/confusing, vow to write clarifications for the next poor soul...

  149. lovetox

    Othr than that, I would say "exceptional hard" is a hyperbole

  150. moparisthebest

    then a couple months pass and you've memorized all the things you needed to know and forgot what you intended to write down...

  151. jonas’

    Zash, to be fair, '77 has had its fair share of council/standards politics deadlock

  152. jonas’

    there is that edge case I don't dare to remember

  153. Zash

    I've conveniently swapped out all of it to the point I didn't remember the number 🤷️

  154. jonas’


  155. jonas’


  156. jonas’

    I didn't mean '77 actually, I meant '50