[Standards] Council Minutes 2020-11-04
https://logs.xmpp.org/council/2020-11-04?p=h#2020-11-04-51d2be3786d1879f 1) Roll Call Present: Jonas, Dave, Daniel, Zash, Georg 2) Agenda Bashing Georg wanted to add his XEP-0401 (Easy User Onboarding) changes, but they don't depend on Council. 3) Editor's Update * LC ended: XEP-0443 (XMPP Compliance Suites 2021) 4a) MR !29 (XEP-0045: specify use of in subject message) - https://gitlab.com/xsf/xeps/-/merge_requests/29 Jonas: +1 Zash: +1 Dave: +1 Daniel: +1 Georg: +1 4b) Proposed XMPP Extension: Pre-Authenticated In-Band Registration - https://xmpp.org/extensions/inbox/ibr-token.html Georg: +1 Daniel: [on-list] Jonas: [on-list] Zash: [on-list] Dave: [on-list] The author, Georg, thanks Dave for his review [1] - Dave still needs to think about this, given Sam's comments [2]; Georg think's Sam made a very generic point that applies to the whole pre-authenticated phase. 4c) Advance XEP-0443 (XMPP Compliance Suites 2021) - https://xmpp.org/extensions/xep-0443.html The author, Georg, notes there was some feedback; Jonas thinks there were comments which should be addressed in some way. The Editor apologises for the automation weirdness that happened with the extra announcement email which appeared yesterday. Jonas doesn't think it makes sense to vote on this until the feedback has been addressed; Georg will endeavour to satisfy all interested parties - would also like to see even more feedback, e.g. are there any XEPs missing or to be removed. 5) Date of Next 2020-11-11 1600 UTC Dave may or may not make it, in between transporting his vintage beer bottle collection between homes. 6a) AOB i: Election Season Jonas notes there are more applications now [3], which is nice. 6b) AOB ii: Compliance Suite 2021 Georg thanks Daniel very much for his A/V additions, and the LC feedback; is looking for specific feedback regarding further XEPs to be added, any to be moved from non-normative to normative, and any that might be removed. MDosch has suggested adding XEP-0425 (Message Moderation) - Georg thinks that it might be a good addition for Advanced IM, though it's still Experimental; Daniel thinks there's a lack of experience with that, not only because it makes use of Fastening - Zash suggests adding it under Future Development. Georg kindly asks Council to review and consider the XEPs touched in the last year for inclusion - Zash requests such a list - Editors will oblige. 6c) AOB iii: XEP-0401 and ibr-token Zash queries the intended relation between these two and XEP-0379 (Pre-Authenticated Roster Subscription) - Georg explains that 0379 is the roster-adding part, ibr-token is the account-creation part, and 0401 connects it all together. Zash notes there is a conflicting overlap with 0401 - Georg had a slight disagreement with 0401's author about its direction, and isn't yet confident how to resolve that; Jonas notes MR !33 [4] - Georg adds that this removes everything IBR related from 0401. Zash may have stated before, but would very much like all of this moved into IBR2 in The Future™ (once SASL2, IBR2, etc2 are in shape) - Georg says this is the intended goal: they will be referenced in 0401 once it's ready; but, until then, the status quo is documented in ibr-token and referenced from 0401. 7) Close Thanks all and everyone. [1] https://mail.jabber.org/pipermail/standards/2020-November/037846.html [2] https://mail.jabber.org/pipermail/standards/2020-November/037852.html [3] https://wiki.xmpp.org/web/Board_and_Council_Elections_2020 [4] https://gitlab.com/xsf/xeps/-/merge_requests/33 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0443 (XMPP Compliance Suites 2021)
Version 0.3.0 of XEP-0443 (XMPP Compliance Suites 2021) has been released. Abstract: This document defines XMPP application categories for different use cases (Core, Web, IM, and Mobile), and specifies the required XEPs that client and server software needs to implement for compliance with the use cases. Changelog: Add more notable XEPs (gl) URL: https://xmpp.org/extensions/xep-0443.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] The Open Graph protocol
On 10.11.20 15:23, Jonas Schäfer wrote: > In this case, please discuss the security implications in regards of > phishing. > With sender-side rich preview, spoofing of such previews becomes trivial. I > imagine a spoofed rich preview to be even more dangerous than the typical href="badsite">goodsite in an HTML email. Absolutely. However this also applies to MUC generated previews as MUC servers in general cannot be considered trustworthy (even though many clients nowadays just do that). Also servers are not able to look into E2EE messages. Also it's not said anywhere that the link preview can be clicked on at all. If you can only click on the actual link in the original message, spoofing what is displayed below is far less of an issue. Also regarding phishing: Nothing keeps me (as a phisher) from actually using the same opengraph tags on the phishing site as on the original site, so even a server generated preview does not protect in any way from that. Marvin ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0438 (Best practices for password hashing and storage)
Version 0.2.0 of XEP-0438 (Best practices for password hashing and storage) has been released. Abstract: This document outlines best practices for handling user passwords on the public Jabber network for both clients and servers. Changelog: Update to match draft-ietf-kitten-password-storage-01. (ssw) URL: https://xmpp.org/extensions/xep-0438.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0045 (Multi-User Chat)
Version 1.34.0 of XEP-0045 (Multi-User Chat) has been released. Abstract: This specification defines an XMPP protocol extension for multi-user text chat, whereby multiple XMPP users can exchange messages in the context of a room or channel, similar to Internet Relay Chat (IRC). In addition to standard chatroom features such as room topics and invitations, the protocol defines a strong room control model, including the ability to kick and ban users, to name room moderators and administrators, to require membership or passwords in order to join the room, etc. Changelog: Specify the use of a delay element in the initial subject message. (jsc) URL: https://xmpp.org/extensions/xep-0045.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XMPP Council Agenda 2020-11-11
Helau everyone, The next XMPP Council Meeting will take place on 2020-11-11 at 16:00Z in xmpp:coun...@muc.xmpp.org?join. Everyone is welcome to join and add to the discussions. This agenda is composed from: - Editor notifications to standards@ - xsf/xeps GitHub PRs marked as Needs Council - xsf/xeps GitLab MRs marked as Needs Council - Suggestions directly sent to me (see below) Agenda as follows: 1) Roll Call 2) Agenda Bashing * Feel free to pre-bash on-list or directly to me if you think something is missing. 3) Editor’s Update Nothing out of the ordinary. 4) Items for voting NOTE: This is the second-to-last Council meeting of this election period. Votes started in this meeting run in danger of expiring at the boundary of Council terms. 4a) Decide on Advancement of XEP-0443: XMPP Compliance Suites 2021 URL: https://xmpp.org/extensions/xep-0443.html Abstract: This document defines XMPP application categories for different use cases (Core, Web, IM, and Mobile), and specifies the required XEPs that client and server software needs to implement for compliance with the use cases. 4b) PR1001: XEP-0393: clarify rules for span directives URL: https://github.com/xsf/xeps/pull/1001 Abstract: Previously I believe the styling of *** in the examples was incorrect. After discussing the matter on the mailing list we came to the conclusion that the actual rules were ambiguous and therefore *** could be styled either way. See-Also: https://mail.jabber.org/pipermail/standards/2020-November/037859.html 5) Pending Votes - Everyone but Georg on ProtoXEP ibr-token 6) Date of Next 7) AOB 8) Close End of Agenda. Note that I am aiming for 30 minutes, but meetings may be extended as necessary if all council members agree. Meetings are normally held every Wednesday at 16:00 UTC in the xmpp:coun...@muc.xmpp.org?join chatroom. Meetings are open, and anyone (XSF Member or not) may attend, though only XMPP Council members may vote. Relevant comments from the floor are welcomed. Using your web browser, you can join anonymously via https://xmpp.org/chat?council Note that conversations in the room are logged publicly at https://logs.xmpp.org/council/ If you have suggestions for an agenda item, you can message me via XMPP or email at this address or at jo...@zombofant.net. I aim to publish the Agenda on the day before the Council meeting before 19:00Z. Thanks everyone, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] The Open Graph protocol
On Dienstag, 10. November 2020 12:10:04 CET Marvin W wrote: > Hi, > > Beside what Jonas said, there is two things I'd like you to consider > when specifying this that seemed to be out of scope or not considered yet: > > ## Support sender-side link generation > According to various security/privacy people, the best way to do these > link previews is to generate them client-side with the sender. By > sending a link the user expresses some amount of trust into it and it is > reasonable to assume they won't be sending links with the intention to > cause harm to their client. However, sending links to cause harms to > others (being it servers or remote clients) is more likely to be in the > intention of some people. > > While I understand the wish to do this server-side in MUCs (i.e. clients > will take some time to support this in sending and you don't want > receiving users to suffer in UX because of that), sender-side link > preview creation should be the default and server-side rather an > optional fallback. > > If link previews are generated by the sender, there is no strict need to > use message attaching (or fastening or whatever is going to be the next > big thing), the link preview details could just be in the message that > has the body with link itself (that said, generating such links might > impose a delay, so some clients will want to use a second message to > announce the link preview nonetheless). So the spec IMO should have this > in mind from the beginning. When using message attaching, this would > probably be straight forward, when using message fastening it's not. In this case, please discuss the security implications in regards of phishing. With sender-side rich preview, spoofing of such previews becomes trivial. I imagine a spoofed rich preview to be even more dangerous than the typical goodsite in an HTML email. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] The Open Graph protocol
Hi, Beside what Jonas said, there is two things I'd like you to consider when specifying this that seemed to be out of scope or not considered yet: ## Support sender-side link generation According to various security/privacy people, the best way to do these link previews is to generate them client-side with the sender. By sending a link the user expresses some amount of trust into it and it is reasonable to assume they won't be sending links with the intention to cause harm to their client. However, sending links to cause harms to others (being it servers or remote clients) is more likely to be in the intention of some people. While I understand the wish to do this server-side in MUCs (i.e. clients will take some time to support this in sending and you don't want receiving users to suffer in UX because of that), sender-side link preview creation should be the default and server-side rather an optional fallback. If link previews are generated by the sender, there is no strict need to use message attaching (or fastening or whatever is going to be the next big thing), the link preview details could just be in the message that has the body with link itself (that said, generating such links might impose a delay, so some clients will want to use a second message to announce the link preview nonetheless). So the spec IMO should have this in mind from the beginning. When using message attaching, this would probably be straight forward, when using message fastening it's not. ## Parsing (multiple) links from a body A message certainly can contain more than one link in its body. And parsing links from a message is a non-trivial task (think of closing parens). Depending on how clients render those link previews, it may be a crucial information where to put it. I think when having the link preview, it should somehow replicate the URL it is referring to and it should be possible to have multiple link previews for different URLs attached to a message. Note that the og:url is referring to a canonical URL, which does not need to be the same as the request URL. Regards, Marvin ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
