February 2024 - Standards

by email＠msavoritias.me

Hey, JoinJabber is interested in possibly hosting an rtbl instance and holding domains accountable to our CoC. With that in mind the XEP-377 seems to be inadequate. Specifically here: https://xmpp.org/extensions/xep-0377.html#payload It mentions only: *urn:xmpp:reporting:spam* Used for reporting a JID that is sending unwanted messages. *urn:xmpp:reporting:abuse* Used for reporting general abuse. That is severely limiting. For example what if somebody sends hate speech? or transphobia? or racism? or moderation is non existent in this server? One solution when i talked about was removing the limitation of being only two and allowing any label basically. Wdyt? MSavoritias

8 months, 4 weeks

3
2
0 0

Small fixes for XEP-0424

by Nicolas Cedilnik

Hi all, I opened a pull request <https://github.com/xsf/xeps/pull/1326> to contribute small fixes to XEP-0424: - Fixes the schema of the |<retracted>| element: * The is no 'from' attribute * There is a mandatory 'id' attribute * 'by' and 'stamp' are not mandatory - Add a fallback 'for' attribute in Example 4. I hope that's useful. Cheers, -- Nicolas

9 months

1
0
0 0

Re: Proposed XMPP Extension: Reporting Account Affiliations

by Matthew Wild

On Sun, 20 Aug 2023 at 09:35, Guus der Kinderen <guus.der.kinderen(a)gmail.com> wrote: > I can't believe this was in August... > I've been toying with an Openfire-based implementation for the Reporting Account Affiliations plugin. The plugin has not seen much real-world use yet (it barely has been smoke tested). So far, I've only implemented the 'reporting' functionality (the Info-request query mechanism, and the embedding things). I have not yet implemented a consumer part (eg: using account info to do something with regards to permissions). For the curious, the code is here: https://github.com/igniterealtime/openfire-accountaff-plugin I'm trying to get my own implementation finally finished and published soon. > When implementing this, I wondered about the following. > > Is embedding worth it? > > A (considerable) benefit of embedding account info in stanzas is that it saves round-trips: whenever an entity wants to know the data, it does not necessarily need to perform a lookup. Are there other benefits that I've not yet identified? Lookups are a pain. Your comment focuses on the time saved, but sending queries and waiting for a response generally consumes resources. The other party might take a long time to response, during which time we have to keep the stanza and associated state on hold. Now consider this multiplied 1000x during someone flooding a MUC room with automated bots, or whatever. I think there are significant benefits in stanzas bearing this information up-front if it is likely to be needed. In some cases I think I would rather fall back to the current behaviour than implement remote lookup. E.g. if I wanted to automatically grant voice to new MUC users with sufficient RAA credentials, I am more likely to just leave users who don't present RAA info without voice than to implement a lookup and complex async join logic. > The round-trip that's saved comes with a caveat: prior to usage, a recipient MUST perform a disco/info query to the originating domain, to see if the provided data can be trusted. This can be optimized (through caching), and the disco/info result can be re-used for all accounts that originate from the domain - but still, it's not quite round-trip free. As you say, I anticipate such lookups only being done infrequently. > Something about adding data to a stanza that is inherently 'unsafe' (something that MUST be verified before use) does not sit well with me. It is invitingly easy for an implementation to skip, or have an issue in that second step, which would lead to misinterpretation of data that has potential to be used for authorization purposes. I think it happens all the time that entities send stuff that cannot be trusted or needs additional verification. Data received from third parties should be untrusted by default, and that's just a general principle of most systems. > I expect that the account information data is rarely used - although I'll readily admit that I've not coded this part yet, and that there might be future use-cases that I'm not thinking of. Assuming that I'm right, then the embedding of data on many stanzas can add considerable overhead: not only in stanza size (which possibly gets persisted in MAM archives - which leads to interesting questions around the validity of this data over time), but also to compute the value at the originating server. The XEP addresses this by providing guides on when to embed data (more on that below), but a significant amount of overhead remains. Is that worth the savings of a round-trip (especially when a verification request might be needed anyway)? I think there are only a very small number of stanza types where this needs to be added, so I'm not too worried about overhead. > The XEP defines three types of stanzas in which to embed account info. I've found implementing this to be a lot harder than anticipated (which very well might be a result of Openfire's API). One thing that I struggled with was to choose when to act on a stanza that was being processed: when processing inbound, client-originating stanzas, I worry about missing stanzas that are generated by the server on the user's behalf. When applying this to outbound stanzas, it's not straight-forward to identify stanzas that originated from local users - and even if you do, something like MUC can have modified the addressing, making identifying the correct local account even harder. The complexity adds up, which leads to implementations that are more error-prone. You're not alone, it's not "hard", but it's not trivial in Prosody either. I'm still working on it. > If I understand the XEP correctly, it specifies that a server must remove account info from client-originating stanzas if the server has support for embedding account info for that particular type of stanza (to avoid spoofing). Given the complexity that I tried to describe above, I believe that this is error-prone. Can we consider mandating that ALL account info from client-originating stanzas is to be removed, if the server has support for any kind of account reporting? Is there any reason to clean up this data in some, but not all client-originating data? Pretty much just to avoid the overhead of scanning all stanzas. As mentioned above, I think RAA info only needs to be embedded in a very small subset of stanzas. Paying the cost on *all* stanzas across a server seems excessive. We have previously discussed this in the past related to the various elements we have now that have a 'by' attribute that ought to be filtered. > Given all of the above, I'm cautiously arguing that all of the 'embedding' should be removed from the XEP. I do not believe that its benefit (preventing a query, sometimes) outweighs the drawbacks (in added complexity and overhead). Removing it might lead to implementations that are easier (faster) to build and are less error-prone. I think it would be easier to remove embedding for the sending side, but conversely it will make the receiving side much more complicated. For that reason I would rather keep it. Of course I reserve the right to change my mind as I continue implementing it.... > As a last remark: the explicit query for information is made against the bare JID of the entity for which information is seeked. XMPP dictates that a server MUST answer such IQ queries on behalf of the user, so this works. I do not like how this implies that another entity is being asked to provide data than the entity that we require to provide the data: the XEP explicitly does not want a client/user to provide this data (that's even defined as 'spoofing'). It wants a server to provide this data. In this light, it would be clearer to address the request to the server JID (without a node-part) instead of an account JID. I see what you're saying. I don't feel strongly, but it doesn't feel right to me. There are a bunch of things that we address to the account if we want to learn about the account. I don't think this is any different. Directing queries to the server JID and putting a username field in the stanza seems worse than what the XEP currently proposes. For example, blocklists will do the right thing with the current approach. I'll continue thinking about some of this stuff as I finish the implementation. Regards, Matthew

9 months

1
0
0 0

Study/Paper about Community Moderation under XMPP

by email＠msavoritias.me

Hey o/ I am currently writing a paper around Community Moderation/Safety in XMPP and what we can do to improve the situation. paper is here -> https://git.sr.ht/~msavoritias/Guile_XMPP/tree/main/item/Documentation/Pape… Its written because I am developing an XMPP library in the same repo and I want to implement good Community Moderation at some point. (Community Moderation in the sense of both server level and group chat level.) The situation currently is less than adequate in xmpp both on protocol and client level. We are lagging behind other communities like activitypub in many ways. And more importantly we are falling short of what should be done beyond what activitypub is doing. The aim is to have some actionable points in the end to move the situation forward. Either with XEPs or suggestions for clients implementations like modernxmpp does. Most likely its going to be both. Would the XSF be willing to fund me to write this paper or help me find funding? MSavoritias

9 months

1
0
0 0

Accepted XEP-xxxx MUC Avatars into historical track

by Daniel Gultsch

Dear Editor, please note that council has accepted the proposed XEP 'MUC Avatars' into the historical track. (A previous submission into standards track has been rejected by the council at that time) https://xmpp.org/extensions/inbox/muc-avatars.html cheers Daniel

9 months

1
0
0 0

Feedback requested: SVCB for XMPP

by Dave Cridland

Hi all, Attached is an *unsubmitted* Internet Draft covering SVCB usage for XMPP. Assuming attachments work on this list! Feedback welcome, I intend to submit this one shortly to the IETF. Dave.

9 months, 1 week

4
7
0 0

Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All

by kevin.smith＠isode.com

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Host Meta 2 - One Method To Rule Them All Abstract: This document defines an XMPP Extension Protocol for extending XEP-0156 by modifying the JSON Web Host Metadata Link format to support discovering all possible XMPP connection methods, for c2s and s2s URL: https://xmpp.org/extensions/inbox/host-meta-2.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

9 months, 1 week

4
5
0 0

Re: Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All

by Travis Burtrum

Hi Fannys! On 12/16/23 04:06, Fannys wrote: > As I said in the @xsf room the problem with this XEP is that the author > is convinced that this is the one answer to everything and assumes a > *lot* of stuff to get there. And besides the title obviously that is > obvious in a few other places. To try to quickly summarize, we need a lot of info to connect to XMPP servers, and need to get it in very specific (secure) ways. I've thought about this a lot over the years, and (very much thanks to your and other's feedback) tried to explain the reason for every decision. I am absolutely not married to one solution, but alternatives need to accomplish the same goals. "I don't like this" isn't helpful without an alternative proposal that can actually be considered. > Specifically: > > > - It calls SRV records as legacy which is a pretty big departure from > the status quo. > > > For the foreseeable future you will need to maintain legacy SRV > records in addition to this file Yes, because this document explicitly deprecates SRV records (while saying they need to be supported for the forseeable future). > - It effectively makes HTTP a hard requirement for all clients and > servers on the network raising complexity significantly. HTTPS already is a hard requirement, with POSH, with HTTP Upload which is currently the only way to share files in MUCs and with multiple clients / offline clients, and, for most servers, the way they get certificates from letsencrypt. HTTPS is also a well established, fully open protocol with many independent implementations exactly like XMPP, I see no reason to avoid it. XMPP relies on many other standards, just as good or bad (depending on your POV), like DNS, IP, TCP, TLS, XML etc etc. > - Recommends that everything runs through port 443 which is in itself > questionable for this. Because it's most likely to work through real-world firewalls in real-world networks, what's questionable about this? > - Also it introduces a hard requirement for a JSON parser in all clients > and servers which is another point that raises complexity. Again, a JSON parser is already a hard requirement due to POSH. I addressed further reasons I thought this was the best choice in the Rationale https://www.moparisthebest.com/xeps/host-meta-2.html#rationale-hm-json , but, this is not an absolute hill for me to die on. If the consensus is that XML is better here, I'm not opposed, but then it should be the XMPP-subset of XML so that we can actually use the same parser, and don't introduce the real security risk of requiring an XML parser that can parse not-XMPP-XML (just one real world example of this vulnerability in the wild is https://prosody.im/security/advisory_20220113/ ). Please note this would introduce the following (imho, downsides): 1. we could not use host-meta.xml as that requires a not-XMPP-subset-XML parser supporting comments etc etc 2. that means an extra https request when trying to fetch host-meta-2 along with legacy methods 3. so it'd require a new document definition, for a quick reference, it would look very similar to HACX https://xmpp.org/extensions/inbox/hacx.html#example-1 > And I think the discussion about these items individually should have > happened before. Especially since from the discussion in @xsf it seems > that some of the alternatives like DNS were rejected on subjective > opinions of the author. I actually discussed this in xsf@ 21 months!!!! (damn I'm slow...) before submitting this ProtoXEP https://logs.xmpp.org/xsf/2022-03-17#2022-03-17-ead56d61d395a6b9 I hopefully explained my rationale re: DNS well https://www.moparisthebest.com/xeps/host-meta-2.html#rationale-dns but please if you disagree and/or have alternatives do share. > My opinion is that HTTP and JSON shouldn't be requirements and i don't > plan to use this XEP anywhere even if it gets voted in. We already have > problems with ports and everything assuming HTTP and I don't want the > problem to be worse. Plus I don't want the complexity at all. So to summarize my current thoughts: * I think HTTPS is likely to be a hard requirement for this, at least I can't think of an alternative that can accomplish the same goals * JSON is *not* a hard requirement, and could be replaced, but has the downsides I layed out above and in the rationale > Fannys I very much appreciate the detailed feedback, thank you!

9 months, 1 week

1
0
0 0

XMPP Council Agenda 2024-02-13

by Daniel Gultsch

Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, February 13 2024 at 16:00 UTC in xmpp:council@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update 4) Items for voting a) xep-template: Require accessibility and privacy sections https://github.com/xsf/xeps/pull/1322 b) Issue Last Call on XEP-0360: Nonzas (are not Stanzas) https://xmpp.org/extensions/xep-0360.html c) Proto XEP: XEP-xxxx: MUC Avatars https://xmpp.org/extensions/inbox/muc-avatars.html 5) Pending votes - Dan on starting Start Last Call on XEP-0392: Consistent Color Generation See the all new spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa… 6) Date of Next 7) AOB 8) Close

9 months, 1 week

1
0
0 0

XEP-0440 and tls-server-end-point

by Simon Josefsson

Hi I was reading XEP-0440 and noticed that since 2022-08 it requires support for tls-server-end-point channel bindings. I believe this is unfortunate because tls-server-end-point channel binding are worse than either of tls-unique or tls-exporter. Mandating support for this weak channel binding will detract from efforts to implement the stronger tls-unique and tls-exporter. When deciding what to prioritize, it may be that someone believes that since XEP-0440 requires tls-server-end-point, it is more important to implement it than spend time getting tls-exporter implemented. That would be a bad outcome. I suggest changing XEP-0440 to require tls-unique when TLS <= 1.2 is used and tls-exporter when TLS >= 1.3 is used. If you have already given up on supporting TLS <= 1.2 I think you should only mandate tls-exporter as this is the best available channel binding available. I believe tls-server-end-point is generally best left unimplemented to guide efforts towards supporting the stronger tls-exporter. /Simon

9 months, 2 weeks

8
11
0 0

2024

2023

Standards February 2024 ----- 2024 ----- November 2024 October 2024 September 2024 August 2024 July 2024 June 2024 May 2024 April 2024 March 2024 February 2024 January 2024 ----- 2023 ----- December 2023

Standards February 2024