XSF Discussion - 2023-02-11


  1. tmolitor

    how to proceed regarding pr 1248? https://github.com/xsf/xeps/pull/1248

  2. tmolitor

    afaic council did not vote on that because of the pending SASL2 merge, but it seems it is not yet merged into the inbox, too, right?

  3. pep.

    Is there any document explaining why it's not recommended to reuse the same resource anymore (it isn't, right?) And/or why server devs would like this to be controlled by the server

  4. singpolyma

    I don't think not recommended is it so much as not common

  5. flow

    best practice is to use a randomized (or server assigned) resource, but then re-use that resource for subsequent reconnects, as it, for example, improves the chances that you get stanzas that where addressed to this resource prior the reconnect

  6. pep.

    singpolyma: and yet it was extremely common in the past no? But there's been a change in the last few years

  7. singpolyma

    Manually assigned resources are fine, but users don't really want to make up unique names for their devices usually

  8. pep.

    flow: makes sense

  9. pep.

    When do you know you can drop the resource? After SM timeout?

  10. flow

    pep., why drop the resource at all?

  11. pep.

    Ah wait

  12. pep.

    Ok I misread

  13. pep.

    And yeah I remember we do store the generated resource

  14. flow

    to answer my question: one could argue that a malicious actor may learn your resource, so you may still want to rotate it once in a while

  15. Zash

    Is it best practice if all current clients pick something "Client.HCcg" and then use that forever?

  16. MattJ

    If someone knows (or can guess) your resource then they can tell when you are online, which is considered a presence leak and something we have always tried to protect against

  17. MattJ

    Then there are conflict issues, which are thankfully less common these days

  18. MattJ

    But previously it was super common for people to have two clients kicking each other off in a loop

  19. singpolyma

    How do they guess your presence using only your resource?

  20. Zash

    singpolyma, `<presence type=probe to=fulljid>`

  21. MattJ

    Just iq or anything

  22. tmolitor

    does the server answer the probe on behalf of the client or the client itself?

  23. singpolyma

    Zash: and the server won't block that?

  24. MattJ

    I actually can't recall what full JID probes do, but an iq ping works just as well

  25. singpolyma

    MattJ: shouldn't inbound iq from non roster usually get a generic error that doesn't confirm or deny presence?

  26. MattJ

    Who should send that error?

  27. singpolyma

    I guess maybe not always

  28. singpolyma

    The client

  29. MattJ

    Timing makes it trivial to detect then

  30. singpolyma

    🤔

  31. MattJ

    And timing aside, the client would have to be sure to send the exact same error that the server would send if the resource was offline

  32. flow

    + sometimes there may be good reasons an entity without presence subscription or in your roster send you an IQ

  33. singpolyma

    flow: but then you should know this good reason to allow it

  34. MattJ

    Sure, though usually the client should be able to determine that

  35. flow

    singpolyma, maybe. but it's easy to get this wrong

  36. flow

    how many implementations do consider roster/subscription state when doing message delivery receipts?

  37. MattJ

    This is a good question for someone to explore 🙂

  38. flow goes on an explores his bed instead :)