On Tue, 6 Jun 2023 at 22:34, Travis Burtrum <[email protected]> wrote:
> > Jun 6, 2023 4:31:54 PM Dave Cridland <[email protected]>: > > > > > On Thu, 4 May 2023 at 15:06, <[email protected]> wrote: > >> Version 0.1.0 of XEP-0481 (Content Types in Messages) has been > >> released. > > > > This is weirdly horrible. > > Me too, but it's not council's job to police the protocol, what gets > widely used is decided by running code and consensus. > Oh, I'm not saying it shouldn't have been published, I don't think this has any potential to damage the interoperability of the network, and it seems free of IPR concerns. It *is* the Council's job to police what gets through to Stable, I think, but that's irrelevant here, and will likely remain so in this case I'd have thought. > > > > * First and foremost, it falls into a general trap that's open to abuse > by malicious actors, by having a message whose content will be interpreted > differently by different clients. This has been used by spammers and as a > malware vector for decades. > > So... Same as xml:lang in the RFC ? I don't like that either. :) > I think worse. xml:lang I'm not keen on for use as a way to send multilingual messages, indeed, but if I send you a message such as: <message> <body>Innocuous message!</body> <content type='text/plain'>Evil annoying spam blockchain AI</content> </message> Then the anti-spam (AI driven using Blockchain of course) might evaluate only the innocuous message and your client might only display the evil annoying spam. The anti-spam can't easily know which your client will display, so it needs to evaluate both, and with something like text/markdown in the mix, it forces the anti-spam to understand all the content-types. (Maybe it does by AI, or blockchain, but still). The same is possible with xml:lang, by sending 'en-gb' and 'en-us' messages, for example, as you note, but those are at least the same basic syntax so a little easier to manage. Critical problem? Not really. But I'd want this pointed out in the Security Considerations. Dave.
_______________________________________________ Standards mailing list -- [email protected] Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s _______________________________________________
