Hi Sam, * Sam Whited <[email protected]> [2017-10-11 22:44]: > I'd like to suggest (again) that we obsolete XHTML-IM. If the easy way > to implement a spec is insecure, you can be sure users will do that. We > can't guarantee security in a spec, but we can certainly make something > that's harder than XHTML-IM to implement incorrectly, which would be a > huge gain.
I'm -1 to obsolete XHTML-IM without having a sane replacement on the table. The web as an application platform is a monster that's almost impossible to deploy securely. I'm sure you'll find XSS vulnerabilities in most web-based XMPP clients, with or without XHTML-IM support. Fixing this one hole will not make the ignorant developers smarter automatically, thus preventing further XSS. What I would like to see before changing my mind is an actual (rough) idea of a new formatting specification that will be easy to do right, on the web. The more features we add, the more ways there will be for evil HTML to slip through the filters, or the bigger the developers' inclination to just drop-in some library that automagically converts the input into HTML, opening a wide attack vector once again. I don't want to end up reinventing XHTML-IM with all the features it has now, in a different format, and ending up in the same security nightmare we are in at the moment, except that we'll have killed off most of the currently existing implementations of XMPP with markup. My primary use case of XHTML-IM is syntax-colored code, so what I wish for is: - pre-formatted text - different foreground colors - bold, italics, underline What I'd like to get rid of: - background colors (UX nightmare) - full foreground color flexibility (I'd love to have a limited color palette like XEP-0392, so we can have different colors that are all well-readable, on dark and on light background) - absolute font sizes (relative sizes are okayish, from a usability point of view) What I also like is the explicit separation between the rich message and the compat message. I'm aware that there are security implications, but if we can solve those for LMC, we shouldn't have a problem with XHTML-IM(2.0). One possible solution would be a pop-up on the rich message, showing the plaintext body. Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || ++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
