XSF Discussion - 2019-09-21


  1. flow

    MattJ, May I suggest to remove the "Servers MUST NOT include the <stanza-id/> element in messages addressed to JIDs that do not have permissions to access the archive" from xep313. It appears to provide very little, I'd even say nothing because the id-String shouldn't reveal anything, for a lot of complexity in the MAM archive service implementation

  2. lovetox

    it does reveal something

  3. lovetox

    on ejabberd for example the exact timestamp of the message

  4. MattJ

    I think it would have to be tied with a requirement that ids do not leak any info

  5. lovetox

    yeah and this would be bad

  6. MattJ

    I'm not sure timestamp counts as a problem

  7. MattJ

    But if it was combined with a counter it would

  8. MattJ

    And timestamps are not unique on their own

  9. flow

    lovetox, well that would violate a MUST frmo xep359

  10. flow

    also I am not sure if timestamps are a problem

  11. lovetox

    its very useful that ejabberd uses timestamps as messages

  12. lovetox

    its very useful that ejabberd uses timestamps as ids

  13. lovetox

    as it allows to determine a order

  14. lovetox

    even if impl cannot rely on it because other servers dont do that

  15. MattJ

    Tell me you don't depend on that :)

  16. flow

    furthermore, we could at least relax the requirement in xep313, e.g. by making it conditional

  17. lovetox

    of course i dont, as not all servers do that

  18. lovetox

    when i remember correctly the only argument against a orderable id was

  19. lovetox

    clusters may be more complex to implement that

  20. flow

    but I would simply remove that requirement from xep313, which also would make the xep less complex, which is always good

  21. pep.

    > MattJ> I think it would have to be tied with a requirement that ids do not leak any info Isn't that the case already?

  22. pep.

    For 0359 stuff

  23. pep.

    Hmm, it says "unique and stable" and recommends UUID..

  24. pep.

    I think that's good enough

  25. lovetox

    i see xep 0398 is under specified

  26. lovetox

    it says "Upon receiving a vCard publication request with a valid photo attached"

  27. lovetox

    so no photo element is invalid in this case?

  28. lovetox

    means every client out there now has to publish empty photo elements in there vcard for avatar conversion to work?

  29. lovetox

    is this intended? why not just interpret no photoelement as <photo/>

  30. lovetox

    or did the XEP author foget about the "Delete a photo" usecase

  31. lovetox

    and this sentence reflects only setting a avatar other than none

  32. lovetox

    ^ Daniel

  33. Daniel

    yes the XEP doesn’t cover deletion

  34. Daniel

    yet

  35. flow

    pep., see also the security section of xep359

  36. pep.

    Right, so that's settled then

  37. flow

    MattJ, xep359 already has that requirement that IDs do not leak inve, hence i was supprised to find that section in xep313

  38. MattJ

    pep.: "unique and stable" is not enough

  39. MattJ

    We've already seen security issues from far simpler and more obvious problems, it's not enough to say that a sentence in a separate document covers us

  40. pep.

    MattJ, see what was said above

  41. pep.

    0359 mandates more than that

  42. pep.

    - the IDs defined in this extension MUST be unique and stable within the scope of the generating XMPP entity - Entities observing the value MUST NOT be able to infer any information from it - The value of 'id' MUST be considered a non-secret value.

  43. pep.

    (obviously, "MUST NOT be able to infer any information from it" is only practical to some extent, but that wouldn't be an issue for MAM would it)

  44. Ge0rG

    I suggest to introduce a new stanza element, <mam-id>, that is not leaking any information.

  45. Ge0rG

    With a "MUST NOT be equal to any of the other id elements or attributes of the message" requirement.

  46. MattJ

    Can't tell if sarcasm

  47. Zash

    In https://xmpp.org/extensions/xep-0398.html#presence it's implied but not explicitly stated that the server should leave empty <photo/> elements alone. Why is that? (poke Daniel)

  48. Daniel

    Iirc to give clients the option to join w/o avater

  49. Daniel

    Not that it really makes sense. But I think that was the intention behind it

  50. Zash

    Some clarification there would be good I think

  51. Daniel

    Quick update on the IM regulation. I just (accidentally) talked to someone who was on the SPD's (major party in Germany) digital working group thing. And it was her that Katharina barley asked in 2018 about IM regulation. And she contacted the CCC who was like "mhh we don't really know". And now it's apparently dead because according to her the SPD is not in a functional state right now

  52. Daniel

    Cc Ge0rG

  53. pep.

    What was that article then a week ago? :/

  54. Daniel

    dunno. i mean it did not have any sources. maybe it was old sources

  55. Daniel

    or just made up

  56. pep.

    k

  57. Daniel

    also she asked for me contact information and i wrote down my website and my email address and then she asked for my phone number because she doesn’t write email; and under pressure I couldn’t remember it (why do people think that 10 random numbers are a good ID) - i gues s i need a business card

  58. pep.

    "why do people think that 10 random numbers are a good ID" haha, I agree, and that's not even because of the infamous Zooko.

  59. Ge0rG

    Daniel: did you take her phone number at least?

  60. Daniel

    Ge0rG, no. it felt more like a "don’t call us we call you" situation

  61. Ge0rG

    Daniel: that's a bit sad.

  62. Daniel

    last time i tried to talk to a politician she offered to take a selfie with me

  63. pep.

    "PR, PR, PR"?

  64. Ge0rG

    Daniel: looks like you learned the hard way how modern politics work...

  65. fippo

    daniel: maybe she wanted the phone number to contact you via signal? :-p