XMPP Council - 2023-06-30


  1. MattJ

    I just submitted a protoxep so hopefully next week's meeting won't be so uneventful: https://github.com/xsf/xeps/pull/1287

  2. MattJ

    There's a rendered version at https://matthewwild.co.uk/uploads/xeps-tmp/xep-reporting-account-affiliations.html

  3. Kev

    MattJ: If that hasn't appeared by, Tuesday evening, please poke and I'll try to do it.

  4. MattJ

    Shall do

  5. lissine

    > I just submitted a protoxep so hopefully next week's meeting won't be so uneventful: https://github.com/xsf/xeps/pull/1287 If a user with member affiliation invites a new user to create an account on the server, what affiliation should the new user have?

  6. MattJ

    That's up to the deployment. In Snikket they will have a lower affiliation by default.

  7. Ge0rG

    I've also thought about an additional level in between, as invited is clearly less evil than IBR, but only if you can punish the inviter for the invitee's actions, and if the inviter isn't IBR themselves

  8. msavoritias

    cant you already trace who invited who?

  9. MattJ

    Yes, Prosody supports that

  10. pep.

    riseup keeps this kind of information but for a limited amount of time for privacy, and not an exact date either. It removes the marker about a quarter after account creation

  11. pep.

    (who invited who)

  12. moparisthebest

    MattJ: hmm can be used to mass scan for whether accounts exist right? At minimum that should be mentioned in security considerations, it'd be even better if there was a recommendation to avoid this, but that seems hard

  13. Zash

    How would that work?

  14. Zash

    How would it be easier than it already is?

  15. moparisthebest

    The only thing that enables it now is public OMEMO nodes right?

  16. larma

    > How would that work? I guess you typically don't want to query this out of the blue. By removing the query (4.2) functionality and only have the embedding (4.3) functionality, you're already good to go. You also don't lose anything, you just might be sending more things around then needed.

  17. moparisthebest

    Yes it's only a problem with the query

  18. Zash

    Weren't there words about restricting access and embedding to trusted servers or did I imagine that?

  19. larma

    Zash, that's a MAY

  20. moparisthebest

    > A server may exercise discretion over when it includes affiliation information. For example, it MAY choose to only reveal this information when sending stanzas to trusted servers, or withold it when sending stanzas to untrusted servers (the definition of trusted servers is beyond this specification - it may be implementation-specific or based on a protocol such as XEP-0267: Server Buddies).

  21. moparisthebest

    And it's in business rules, not security considerations

  22. Zash

    So a server policy decision, rather than a protocol decision. Seems fine with me.

  23. moparisthebest

    At the very minimum security considerations should mention "account scraping/harvesting"

  24. larma

    I also think that there is no need to have general query, just make it such that query only works if the querying entity was receiver of a stanza from the queried entity before (we do have all kind of ways to figure that out in practice)

  25. Zash

    As you note, this is already lost, while on the other hand I haven't heard of anyone observing such scraping.

  26. larma

    I don't think "we currently have issues that account scraping is possible under certain conditions" be a reason to not try to make account scraping hard

  27. larma

    I don't think "we currently have issues that account scraping is possible under certain conditions" should be a reason to not try to make account scraping hard

  28. MattJ

    I would like to keep the query protocol defined, but I'm happy to tighten up the wording about when it should be permitted

  29. larma

    MattJ, do you think there are valid usecases of the query protocol that couldn't be covered by the embedding protocol?

  30. moparisthebest

    > I don't think "we currently have issues that account scraping is possible under certain conditions" should be a reason to not try to make account scraping hard 💯 we need to fix the current places where account scraping can happen, not open up new ones

  31. MattJ

    larma: yes. For example, not all stanzas have embedded info. Also you may want to make this information accessible to non-recipients, including the server admins.

  32. larma

    1. Only IQs can't have embedded info and i wouldn't know where this would be relevant for IQs. 2. If server admins learn the JID of a sender of a stanza without being the recipient, they should be able to learn the embedded info of that stanza the same way.

  33. larma

    I mean, I'm not entirely against the query, as long as we make it clear that it can only be queried by entities that are somehow authorized (for example by having received a stanza from that entity)

  34. MattJ

    1. Publishing to a comment node of a pubsub blog. 2. Admin receives a report about a JID on their server and wants to find out the status of that JID.

  35. moparisthebest

    > 2. Admin receives a report about a JID on their server and wants to find out the status of that JID. They can just look in mam no?

  36. MattJ

    My current implementation only adds it to (some) presence, so no

  37. MattJ

    I don't think I want to add it to every stanza ever

  38. MattJ

    As I said, I'm happy to tighten up the wording about queries

  39. larma

    I don't think it's unreasonable to add it to: - presence that is a subscription request - messages to entities without subscription

  40. MattJ

    Yeah, I'm doing the former. Also directed presence (MUC joins).

  41. MattJ

    The latter does mean the MUC distributes it if it doesn't filter it. I haven't decided how much of a problem that is, or what alternatives there may be.

  42. larma

    Don't add it to type=groupchat then?

  43. MattJ

    Presence

  44. MattJ

    I'm not adding it to any messages currently

  45. larma

    huh?

  46. larma

    (also we shouldn't be having this discussion in council@)

  47. MattJ

    I mean, I'm adding the info to directed presence, which includes MUC join presence (which does not have type=groupchat)

  48. MattJ

    Maybe the confusion was my use of "the latter", meaning the "directed presence" statement in my previous message, not the latter option in your message

  49. MattJ

    And sure, we can take this wherever

  50. larma

    ah, understood