jonaswdaniel, did you misread that issue? I don’t see edhelas mentioning BOB in the issue, but you’re referencing it. Am I missing something there?
pep.jonasw: I'd like to see solutions like you suggested indeed, instead of deprecating xhtml-im
jonaswvoice yourself on the ML :)
jonaswhas left
pep.Will do
jonaswand thanks
pep.What/how/who would write that reference impl. though? XSF itself doesn't do that kind of stuff right?
zinidreference implementation of what?
Ge0rGhas left
jonaswpep., I wouldn’t say that
jonaswthere are RFCs which contain a reference implementation (e.g. the Opus Codec)
jonaswso I don’t see any strict reason against that
jonaswideally someone from the web development part among the XSF members (looking in the general direction of the movim people) who know JS etc. would take a shot. even more ideally, the XSF would fund a proper audit.
pep.zinid: xhtml-im thread on standards@
zinidah
jonaswalternatively we could take a look at existing web clients wich get this right, but it appears that there are none :)
zinidnot interested :)
jonaswafk for a while
pep.jonasw: right. I would love to see movim implement that at some point
pep.Much better than parsing random /commands and still sending that as text
pep.But I guess that's the extent of what's possible without that xep
Ge0rGhas left
Zashhas left
edhelasI choose to not implement XHTML-IM actually, it's also to keep the UI clean
edhelasand it's heavy to cleanup/process XHTML messages on the volume
pep.Xhtml-im* messages
Ge0rGI'm absolutely in love with poezio's /code plugin.
zinidhttps://xmpp.org/extensions/xep-0223.html -- is it implemented anywhere?
pep.Yep it's really nice. And it doesn't pollute people's screen when they don't do xhtml-im
jonaswGe0rG, /code is annoying in the sense that the sender chooses the colours; they may not fit with the recipients background for examle
uchas joined
edhelaszinid used in Movim for the bookmarks and other things
edhelasGe0rG I'm also handling /code in Movim :)
zinidedhelas: and how to deal with clients who don't support it?
zinidedhelas: the same thing we did with avatars: nothing? :)
edhelaszinid for bookmarks ? well I don't
edhelasMovim is actually not in sync with Conversations regarding bookmarks
zinidand you think it's ok? :)
pep.edhelas: not the same way as poezio does. You leave the /code in your body :/
edhelasbecause I choose to not use the old prive-xml XEP
pep.And it doesn't make sense on any other clieny
pep.Client
edhelaspep. poezio put colors on the code using xhtml-im ?
pep.Yes
edhelasouch
pep.Why?
edhelasthen no, because it will look ugly
pep.Why?
edhelaswell movim has its own color palette and so
edhelasI don't want you to impose your pink and green colors in the Movim UI
pep.Sadness
edhelasalso I can easily colorize the code myself, a simple lib on Movim side can take care of it
jonaswedhelas, allowing XHTML-Im but filtering @style seems like a reasonable thing to do
jonaswyou need to know that it’s code though. XHTML-IM does not allow for a <code/> tag
pep.edhelas: also, you're still polluting the body with /code
edhelasthen XHTML-IM is not a solution for it
jonaswedhelas, itym then XHTML-IM should be extended ;-)
edhelaspep. I agree as well for /code, we also have /me (even if there's a XEP yeah)
jonaswthinks that the handling of /me is fine.
edhelaswhy ?
edhelashaving a proper XML tag would be way better
pep.jonasw: handling of it is fine in implementations, but it come directly from IRC
edhelas<self-quote/>
pep.And I agree with edhelas here
Ge0rGhas left
jonaswyes, it would be better. but it works today, and breaking that would break a lot of clients for little gain
edhelasif you don't like /code I understand, but let's be consistent
jonasw/code is a client-side feature
jonaswthe "/code" is never transmitted
pep.edhelas: history is never really consistent though. :/
pep.Also it's not just about /code
vanitasvitaehas left
edhelasbut in general I'm against clients that are forcing the rendering of content to another client
pep.It's also about all other possibilities that you're missing without xhtml-im. Or that you (somebody) are trying to reproduce badly
edhelasthis also applies to Atom publications in Pubsub, actually Movim is heavily filtering the XHTML tags to remove all the style and customization of the articles
Ge0rGjonasw: I think that XHTML-IM 2.0 colors should be limited in the same way that the Colors XEP works. The sender defines the hue, and the displaying client is responsible for brightness and saturatio
Ge0rG+n
pep.edhelas: you should probably detail this statement, I'm sending you messages forcing you to display them. (Unless you ignore them)
edhelasI'm ignoring xhtml-im
edhelasonly use the body tag
edhelasXMPP is a transport protocol, like HTTP is transporting HTML
pep.Ge0rG: that sounds nice
edhelasthe forating rules of HTML/CSS/JS is another playground
edhelas*formating
edhelasto XMPP can tell me if a message contains code, like HTTP tell me if an answer contains text or images
edhelasbut doesn't tell me how to format thoses
jonaswGe0rG, +1
pep.Well xhtml-im doesn't, you choose
jonaswI thought about that when I wrote my reply, but I think that’s another battle.
pep.edhelas: it's all about semantics
Ge0rGjonasw: yeah. But that should work on most neutral backgrounds, and with non-neutral backgrounds the displying client has the option to tune the curves accordingly.
pep.XHTML is, really
jonaswGe0rG, yap
jonaswpep., +1, which is why I feel we should keep XHTML-Im
pep.edhelas: which is why, for example, the /code movim leaves in the body is meaningless to me, I don't know what to do with it if I don't use movim
pep.(I agree that the xep could be extended)
edhelassure
vanitasvitaehas joined
jonaswedhelas, re bookmarks and movim, does movim use publish-options or otherwise require that the node is configured correctly or would it publish the bookmarks for everyone to read if the pubsub service doesn’t support the correct access model?
edhelasjonasw it set the configuration of the node on the first start
edhelasset on whitelist actually
Ge0rGhas left
jonaswmhm
lskdjfhas joined
edhelassame for other nodes like avatar, vcard4, geoloc, microblog and subscriptions, with their own config
la|r|mahas joined
Zashhas joined
Ge0rGhas left
stefandxmhas joined
nycohas left
stefandxmhas left
Alexhas joined
Ge0rGhas left
Flowhas joined
zinidhas left
uchas joined
jubalhhas joined
Ge0rGhas left
Flowhas left
Flowhas joined
dwdhas left
dwdhas left
alacerhas joined
dwdhas left
dwdhas left
Guushas left
dwdhas left
Guushas joined
alacerhas joined
dwdhas left
Tobiashas left
Ge0rGhas left
dwdhas left
Guushas left
dwdhas left
Guushas joined
dwdhas left
Ge0rGhas left
jubalhhas joined
blablahas joined
valohas joined
Guushas left
Ge0rGhas left
ralphmhas joined
dwdhas left
Tobiashas left
Ge0rGhas left
blablahas left
dwdhas left
valohas joined
Ge0rGhas left
stefandxmhas joined
Ge0rGhas left
HolgerXEP-0357 says that the app can include arbitrary payload for the app server using <publish-options/>. XEP-0060 says that a "pubsub service advertising support for publishing options MUST reject publications with unknown fields." So I can't use a standard PubSub service to implement an app server, right?
jonaswdepends
jonaswis "unknown fields" qualified in the XEP?
valohas joined
jonaswotherwise, one could argue that the app server understands those proprietary XEP—0357 fields
KevI'm not convinced that pubsub is actually the right mechanism for this anyway.
HolgerI'm ranting against the PubSub syntax for push notifications since forever :-)
HolgerIt should just use a plain message.
Holgerjonasw: "Fields and their behaviour MUST be registered with the XMPP Registrar." -- https://xmpp.org/extensions/xep-0060.html#publisher-publish-options
jonaswHolger, aww
MattJThat's a silly requirement
MattJLike saying you MUST use standards
jonaswkind of
HolgerMattJ: No it lets clients rely on behavior.
HolgerMattJ: Publish options are being used to make sure a node is not world-readable, for example.
ralphmhas left
dwdhas left
MattJYes, rejecting unknown fields makes sense
MattJBut requiring that every field MUST be registered I'm less sure of
HolgerIf you guys are just saying that a non-standard service may accept the 0357 options then that's what I'm saying.
dwdhas left
zinidMattJ: if it's not registered, then how to federate?
HolgerYou can't use a standard service but must build your own PubSub thing to create an app server.
HolgerI think you must do so anyway if you actually need to parse those custom options (such as the secret).
MattJA non-standard service is a non-standard service and doesn't need to follow a MUST in a standard, because it's non-standard
HolgerSo basically I'm back to "don't use PubSub syntax".
dwdhas left
MattJzinid, there are cases where federation is not a concern
HolgerMattJ: Right. So we shouldn't change the standard to also standardize non-standard behavior.
zinidMattJ: ok, but in that case you don't give a damn whether there is MUST or not
HolgerExactly.
Holger<MattJ> Like saying you MUST use standards
Holger0060 doesn't do that.
HolgerIt just says "if you follow 0060 and announce publish-options support, you must behave as defined". This only works if only registered options are supported.
dwdhas left
dwdhas left
HolgerI.e. if you reject options that aren't registered.
zinid> Like saying you MUST use standards
I think it's like "you MUST use standards to federate/interop"
dwdhas left
MattJYes, to federate/interop you generally must use standards
MattJBut this is a case where you don't, right? :)
Syndacehas joined
Ge0rGIf people don't bother to use standards, they won't bother more if the standards write that you MUST use standards.
HolgerMattJ: The idea is that you could use a standard PubSub service.
zinidright, so Holger is right: we shouldn't use pubsub for this
HolgerMattJ: ... and have the app server subscribe to that.
dwdhas left
HolgerMattJ: That PubSub service would be a federating/interoperating 0060 service.
HolgerMattJ: At least that's how Lance argued back when I argued against PubSub :-)
MattJIf the thing doing the publishing knows that the thing accepting the publish supports a certain option in a certain way, it doesn't matter if it's an XSF-blessed standard, is what I'm saying
zinidwhy do we need so complex pubsub, it's kinda relay, what for?
Ge0rGhas left
zinidI mean why would an app server subscribe to it instead of directly receiving stanzas?
HolgerMattJ: I'm talking about "the thing accepting the publish".
MattJwhich has to understand the options, no?
HolgerMattJ: Lance said he's using PubSub to make it possible for a standard publish service to be that thing.
HolgerMattJ: I'm saying this won't work.
MattJExample option?
HolgerMattJ: Yes. The thing has to understand non-standard options.
Holger'secret'
MattJIs this something you made up for your implementation, or is it in the XEP?
HolgerMattJ: Example 13 in XEP-0357.
HolgerMattJ: It's just an example. 0357 says I may include arbitrary options. 0060 says a standard PubSub service MUST reject them.
dwdhas left
MattJWell a simple solution is to register the option ;)
dwdhas left
HolgerNo.
HolgerYou want to allow for arbitrary options.
HolgerChatSecure uses some other stuff.
Steve Killehas left
MattJI still don't see a problem
HolgerMattJ: As you said this is really just communication between the app and the non-standard app server.
MattJSo, you're using an off-the-shelf pubsub service
HolgerMattJ: So it just makes no sense to use PubSub for this.
MattJand it doesn't understand your custom option, but what is it meant to do with it?
HolgerMattJ: That's the next problem, which is why I'm saying this won't work anyway :-)
zinidMattJ: but you need to patch the server in order to accept options in order to be passed them to the app server
HolgerThe node subscriber won't see the option.
MattJRight
HolgerMattJ: In practice the problem is that people try to build an app server on top of the existing PubSub code, because that's what the XEP suggests.
Steve Killehas joined
HolgerMattJ: Then I tell them that this isn't possible because it just looks similar to PubSub but is slightly non-standard.
MattJOk, I see better now
MattJYou're complaining as an XMPP server developer, not as an app server developer
HolgerWell.
zinidwhat's the difference? :)
HolgerSure my immediate issue is that I want to get rid of the support requests :-) But I think the app server developer will also appreciate not running into the problem.
MattJSure
dwdhas left
HolgerAs I said I think the proper fix is just using <message/> syntax. But if for some reason (which?) PubSub is preffered, use some other container for the custom stuff, not <publish-options/>.
Ge0rGI also had that thought about "why not messages" when reading Push XEP back then
HolgerLance' initial 0357 draft did just that, FWIW ...
Ge0rGoh, "push token maintenance" is another thing I forgot on the device-identifier mail.
Holger<Holger> Lance: What's the reason for using PubSub as opposed to plain messages to talk to the app server, BTW?
<Lance> Holger: existing protocol, terminology, and semantics
HolgerThere you go.
zinidgreat
zinidwe can use pubsub for messages and presences btw
zinidbecause why not? existing protocol!
HolgerI would say a <message/> offers all those features as well :-)
Ge0rGTime to ask on standards@?
KevWe can use pubsub syntax for not-default-xep60 services just fine, if we want to (e.g. 369).
KevAnd I think there's an argument for doing so. But if we go that route we need to be clear that it's not a standard pubsub service you're using.
HolgerKev: Same syntax, slightly different semantics sounds awesome to me.
Ge0rGThe road to hell is paved with good intentions?
zinidespecially that in fact we're not reusing *existing* technology, where are using a fork
dwdhas left
Ge0rGhas left
alacerhas joined
stefandxmhas left
stefandxmhas joined
Ge0rGhas left
stefandxmhas left
stefandxmhas joined
dwdhas left
stefandxmhas left
stefandxmhas joined
Flowhas joined
dwdhas left
Steve Killehas left
emxphas joined
emxphas joined
Alexhave just seen that many of teh projects are gone on the client/server/library page, because of the renew data. I don't think this is helpful for us as a XMPP community
Ge0rGHere is a nice one regarding the brokenness of TCP and ICMP on the public Internet. The main focus is fragmentation, but the problems stated also apply to detection of stale TCP connections: https://blog.cloudflare.com/ip-fragmentation-is-broken/
jubalhhas joined
Steve Killehas joined
jubalhhas left
jubalhhas joined
valohas joined
Tobiashas joined
jubalhhas left
jubalhhas joined
jubalhhas left
jubalhhas joined
valohas joined
lskdjfhas joined
Steve Killehas left
Syndacehas left
jubalhhas joined
Steve Killehas left
jubalhhas joined
jubalhhas left
blablahas joined
jubalhhas joined
lumihas joined
jubalhhas left
Steve Killehas left
Steve Killehas left
Steve Killehas left
blablahas left
Steve Killehas left
jerehas joined
Steve Killehas joined
alacerhas joined
ralphmhas left
jerehas left
jerehas joined
lovetoxhas joined
Tobiashas left
alacerhas joined
pep.has left
jerehas left
jerehas joined
winfriedhas joined
Steve Killehas left
alacerhas joined
SamWhitedhas joined
efrithas joined
lskdjfhas joined
Steve Killehas left
Steve Killehas left
waqashas joined
jjrhhas left
stefandxmhas left
Steve Killehas left
jjrhhas left
winfriedhas joined
Steve Killehas joined
jonaswhas left
jjrhhas left
Steve Killehas left
ralphmhas left
jerehas joined
jerehas joined
Steve Killehas left
jjrhhas left
Steve Killehas left
zinidGe0rG: nobody cares, they just invent crap like http2 instead of really fixing things
zinidJust like XSF 😂 Because interop
jjrhhas left
Ge0rGit's even worse.
efrithas left
Kevhas left
Valerianhas joined
jerehas left
jerehas joined
alacerhas joined
jjrhhas left
jjrhhas left
jjrhhas left
jjrhhas left
jjrhhas left
sonnyhas left
sonnyhas joined
Valerianhas left
sonnyhas joined
danielhas left
emxphas left
emxphas joined
Kevhas joined
jjrhhas left
jubalhhas joined
dwdCan someone not using Gajim write something with *bold* and /italic/ things in, please?
Flowhas joined
Ge0rGdwd: at your service. Italics doesn't work though.
mathieuithis is not /italic/ and neither that one is *bold*
Ge0rGDamn https://dev.louiz.org/issues/2722.
Ge0rGDamn <https://dev.louiz.org/issues/2722>.
dwdGe0rG, Yours came as XHTML-IM, I think.
Ge0rGmathieui: "at" was bold.
mathieuiGe0rG, yours, yes
dwdmathieui, Whereas yours was rendered as italic and bold for me, Markdown-like.
jubalhhas left
mathieuijonasw, err, I would like xmpp: links in href :p
Ge0rGdwd: ah, so you were asking for markdown in 'body' and not for XHTML-IM formatted.
dwdGe0rG, Indeed, sorry.
KevI like the idea of markdown in XMPP (I'm not entirely sure that I didn't originate *stuff* in XMPP with Psi), but I really dislike not having a standard. So I think we'd have to actually define a MD standard ourselves (which we pretty much had to with XHTML-IM, of course).
Ge0rGso we are reinventing XHTML-IM without XML now?
SamWhitedI don't especially care what a new thing looks like, but I do like the idea of it being some sort of plain text formatting in <body> as opposed to a separate <fancybody> element or whatever.
Ge0rGpeople will just plug-in their favorite markdown parser and your body texts will end up mutilated and you will still end up being pwned.
SamWhitedIt keeps things simple to have one version of the message. One place to encrypt when doing E2E, no risk of something malicious sending a different plain text / non-plaintext version so that two different clients have tow representations of the conversastion, etc.
Ge0rGSamWhited: there is no amount of specification that will prevent developers from doing stupid things.
alacerhas joined
SamWhitedGe0rG: I agree. What's your point?
SamWhitedSecurity issues will always exist, so we shouldn't even try to mitigate any of them?
Ge0rGSamWhited: XHTML-IM is good as it is.
SamWhitedExcept for the history of insecure implementations.
Ge0rGSamWhited: I have a dozen of CVEs for people not reading the Security Considerations of 0280.
Ge0rGI want to burn Carbons with fire, but for completely different reasons.
Valerianhas joined
Ge0rGSamWhited: by replacing XHTML-IM with markdown, you will keep the exact same security problems.
mathieuimost markdown implementations even allow raw html right in the plaintext, so I don’t see how that solves the "developer get it wrong" part
Ge0rGAnd probably add some more.
Ge0rGwhat mathieui said.
SamWhitedGe0rG: That's why I'm not arguing that we should use markdown.
SamWhitedJust that we should obsolete XHTML-IM.
mathieuiyeah, that’s what SamWhited made a point in the thread to keep it about deprecating xhtml-im
mathieuiyeah, that’s why SamWhited made a point in the thread to keep it about deprecating xhtml-im
Flowhas joined
Ge0rGSamWhited: Council just refused to deprecate 136 despite it not being a replacement/alternative to 313.
SamWhitedGe0rG: I know, it made me sad. This is a security issue though, which I think makes it slightly different and more pressing.
KevI don't see a particular need to deprecate XHTML-IM. I think *anything* involving markup being injected into a DOM is going to see people doing stupid things.
KevBut I do think that it's woefully inadequate at protecting diligent devs from things they haven't considered.
Ge0rGXHTML-IM is not perfect, it's got some ugly warts. But it (or some other markup XEP) has its place, and anything that you can come up with as an alternative will have the same or worse security problems.
SamWhitedI disagree, it would be quite easy to design a spec with the same level of functionality but where it required active effort on the developers part to introduce the same security problems.
Ge0rGSamWhited: maybe you can write that spec up, then?
SamWhitedIt doesn't need to be impossible, it just needs to not be the "default".
Ge0rGand then implement it in a bunch of widely-used XMPP clients.
mathieuie.g. if we design a new markup language with a secure reference implementation
SamWhitedGe0rG: no, I'm not interested. I'm just interested in getting rid of XHTML-IM.
Ge0rGAnd then ask again for deprecation of XHTML-IM?
jerehas joined
mathieuiI remember embedding javascript within my nickname in jappix that would dump account passwords to a MUC
mathieuino need for xhtml-im there
SamWhitedYah, I've found plenty of those too, they're unrelated though.
Ge0rGYeah, so many places for XSS.
mathieuithey have the same root issue: the web
SamWhitedmathieui: If you have a proposal for fixing the root issue, I'm all ears :)
mathieui:D
SamWhitedI would love to fix "the web" :)
ZashSamWhited: So what you really wanna do is deprecated teh web! :)
ZashLet's do tha!
Alexuse markdown :-)
Ge0rGYeah, let's approach the W3C with that.
KevSamWhited: I do think that having even a strawman that demonstrates that it's straightforward to write something better would help with those people who think that replacing XHTML-IM with something else is likely to also be easy to carelessly introduce vulns.
SamWhited*sigh* yah, maybe you're right.
Ge0rGKev: even if there was a strawman, we still have the wide deployment problem.
Ge0rGXHTML-IM is supported over a pretty large client base, as opposed to non-markdown-strawman.
SamWhitedI think you are probably right, that would go a long ways towards convincing some folks, I'm just not sure that I want to put in the work on that. I'm not interested in even having a replacement since I'd probably never implement it myself (not that I think one shouldn't be made, I understand that lots of deployments need basic formatting)
SamWhitedBut I do want to deprecate it, so maybe I need to just waste some time on a thing I'll never use to convince people. I'm torn.
SamWhiteds/deprecate/obsolete/ (I'm trying to be precise about my language, but I still mix those two up constantly)
Ge0rGI want to deprecate GC1.0. And then some.
KevGe0rG: I think I proposed that onlist as an alternative to 2 or 3 or whatever teh number was, and I don't remember any pushback.
jjrhhas left
Ge0rGKev: it was brought up at the last-but-one council and got vetoed immediately, IIRC
Ge0rGKev: you also still wanted to provide more alternatives to 1-2-3.
Flowhas joined
KevGe0rG: I don't think I did. I think my alternative was to do 2 or 3, whichever the one I said I liked was, and to get rid of gc1.
jjrhhas left
Steve Killehas joined
Ge0rGKev: oh, sorry. I must be misremembering then.
KevAnd I might misremember, but I don't recall anyone objecting to it in the thread.
Ge0rGMaybe because it was TLDR, once again.
alacerhas joined
emxphas joined
jjrhhas left
Ge0rGKev: oh, there it is: "Georg’s started a worthwhile discussion here, but I’m sure these aren’t the only 3 options we can consider."
Ge0rGKev: you also liked (2), which was the new-iq-type.
sonnyhas joined
sonnyhas joined
Ge0rGbut I'm interested in the other options before writing a diff to 0045.
sonnyhas joined
KevGe0rG: Did I not follow-up by saying that I thought that if gc1 was the reason that (3) was better than (2) we should kill gc1?
KevI accept there's a very real possibility that I'm simply going mad.
jjrhhas left
Valerianhas left
Ge0rGKev: you ended up discussing with Zash whether we can reliably obtain statistics on "intended GC1 joins" vs "presence updates misunderstood as GC1 joins"
Ge0rGwhich we can't.
sonnyhas joined
ZashWhy not?
sonnyhas joined
Ge0rGZash: how?
Ge0rGKev: I've long believed that every person participating in this chat room and the related organizations is affected by a certain kind of madness.
jjrhhas left
ZashGe0rG: Look at presence sent to a MUC. Does it have the <x>? Is the user already in the room? Log that.
jjrhhas left
Valerianhas joined
Ge0rGZash: and then compare that with <x>-enabled presence from the same full JID in the last X hours?
KevZash: That's not the question.
KevZash: That's just listing which presences don't have <x/> it's not telling you if it's a gc1 join or a presence update.
stefandxmhas left
jjrhhas left
jjrhhas left
alacerhas left
dwdhas left
valohas joined
dwdhas left
SamWhitedSorry, got pulled away… RE GC1.0 I agree, let's deprecate it. I don't think it was vetoed, I think we just decided to get more feedback on list first, but I don't have the minutes in front of me.
dwdhas left
Ge0rGwow, just got a presence from somebody in the form of "phone." + [68 characters that look like base64, including slashes]
Ge0rGthe madness is rising.
Ge0rGSamWhited: yeah, the final decision was to get some list discussion, but there were some proponents of keeping GC1, surprisingly
ZashMadness
Zashhttp://www.youtube.com/watch?v=QH7fIkV8nsk
jjrhhas left
jjrhhas left
dwdhas left
moparisthebesthas left
alacerhas joined
uchas joined
jonaswSamWhited, you quoted me rather unfairly on the ML. I won’t point it out there, because I don’t believe you did that on purpose.
stefandxmhas joined
SamWhitedjonasw: Did I? Sorry about that
SamWhitedI removed the extra, but I didn't think I took you out of context or anything
jonaswyou removed the part where I said "plus providing a reference implementation"
SamWhitedYah, I know, I wasn't responding to that part
SamWhitedIt's unrelated to further restricting the subset of HTML involved
jonaswnot entirely, it’ll simplify the reference implementation.
SamWhitedah, I see, restricting the HTML was about making the reference implementation simpler? Yah, I misunderstood what you meant
SamWhitedEither way, I don't think a reference implementation helps either
jonaswall implementations, but also the reference implementation, because I agree that simply changing the spec won’t solve a thing
jonaswI strongly think so
Alexhas left
jjrhhas left
SamWhitedI think adding a reference implementation won't solve a thing (although I'm certainly not against it, if we can have an implementation that we can more or less guarantee is secure, maybe at least a few things will use it and not be broken out of the box)
SamWhitedBut not everyone will use it, so I don't think it really helps
jonaswif we link the reference implementation prominently in the XEP and doesn’t have any non-DOM dependencies, I think new implementations certainly will use it.
Alexhas joined
SamWhitedYah, some will and that's nice, but not all will
jjrhhas left
jonaswmeh
SamWhitedIt doesn't really solve the problem, just puts a bandaid on it for a few implementations (which isn't bad, and I think you should totally do it, but I think we should still obsolete the spec either way)
jjrhhas left
Ge0rGThere are so many places to inject code into the DOM of a JavaScript XMPP client, XHTML-IM is just one of them.
jonaswsee, my main issue is that I really don’t want to see that we use plain text markup when we have the opportunity to use structured markup (be it XHTML-IM or anything else)
SamWhitedGe0rG: yes… again I don't understand your point though: security is hard, so let's not fix any of the problems?
SamWhitedOther places where DOM injection is possible aren't related to this discussion
jonaswI think that providing a reference implementation is the best we can and should do.
SamWhitedjonasw: I'm not 100% sure but I *think* I agree with you. Deprecating XHTML-IM doesn't mean we're going to use plain text markup in the <body> though.
Ge0rGSamWhited: I'm just saying that security-ignorant developers will keep writing vulnerable XMPP clients, with or without XHTML-IM
jonaswSamWhited, what else are we going to do? The alternative will be to reinvent XHTML-IM.
SamWhitedGe0rG: Yes, I agree. I don't see what that has to do with anything though.
SamWhitedjonasw: Yes, reinvent it, but reinvent it in such a way that it's not HTML.
Ge0rGSamWhited: I think my slightly exaggerated point is: you can't make webchat more secure by removing XHTML-IM.
jonaswWe shouldn’t sacrifice something that indeed works, can be made secure with reasonable effort (if we abolish @style, which we totally should do), to make in total only a few implementations transition from not-secure to secure (only a few will transition by obsoleting XHTML-IM, because many will have other XSS issues)
jonaswSamWhited, people will simply patch tag names and embed it in the DOM.
jonaswif it’s more complicated than that, people will not implement it.
jonasw(and if people simply embed an XML tree into the dom, havoc will be wreaked)
Flowhas joined
SamWhitedjonasw: Your'e assuming @style is the only problem. That's not the problem that I've seen, the problem that I've seen won't be solved by further restricting what HTML is allowed.
Ge0rGMaybe we should provide an XSS bot that will join your MUC with an evil name, post evil messages and change the subject to some <script> tag?
SamWhitedPeople are allowing <script> tags and the like, it doesn't matter how much more stuff you take out, they'll still just allow <script> tags.
jonaswSamWhited, I’m keeping to mention @style, because @style is really really hard to fix.
jonaswthe other parts are more or less a piece of cake.
SamWhitedjonasw: Yah, I agree with you we should take it out. I just don't agree with you that it would solve anything.
Ge0rGSamWhited: the problem you are trying to fix is ignorant developers?
SamWhitedGe0rG: "fix" is the wrong word, but essentially yes. We can't "solve" all the security problems, we can never stop developers from doing a dumb thing and allowing a <script> tag. We *can* make it harder to do that by default.
jonaswSamWhited, with @style, it is entirely unrealistic that any implementation is safe, because nobody will parse CSS.
dwdhas left
SamWhitedjonasw: I'm not arguing against that. By all means, remove style.
SamWhitedBut that's another orthogonal problem.
jonaswonly if you’re set on obsoleting XHTML-IM, which I’m not ;-).
dwdhas left
SamWhitedIt's orthogonal either way. The problem that I've seen, over and over again, is that people say "it's HTML, so take it out of the <html> element and stick it in the dom" or they have some subtle bug in how they do their whitelisting that allows it to be bypassed. Removing style won't solve either of those things (though again, I'm not disagreeing, it's something we should do to help existing implementations)
dwdhas left
jonaswokay, I see your point.
stefandxmhas left
Kevhas left
nycohas left
alacerhas joined
emxphas joined
Tobiashas joined
Valerianhas left
Steve Killehas left
Valerianhas joined
emxphas joined
alacerhas left
dwdhas left
waqashas left
ralphmhas left
dwdhas left
dwdhas left
jerehas joined
jerehas left
jerehas joined
jonaswhas left
dwdhas left
jjrhhas left
stefandxmhas joined
ralphmhas joined
alacerhas joined
jonaswhas joined
waqashas joined
dwdhas left
dwdhas left
jubalhhas joined
jubalhhas left
jubalhhas joined
jonaswhas left
Tobiashas joined
dwdhas left
Syndacehas joined
dwdhas left
alacerhas left
alacerhas joined
jonaswhas joined
jubalhhas left
jubalhhas joined
jonaswhas left
Alexhas left
Alexhas joined
jjrhhas left
Alexhas left
lovetoxhas left
Tobiashas joined
jjrhhas left
Tobiashas left
waqashas left
Zashhas left
jonaswhas left
uchas joined
Valerianhas left
Valerianhas joined
Alexhas left
dwdhas left
alacerhas joined
dwdhas left
alacerhas joined
Valerianhas left
pep.has left
mimi89999has left
Flowhas left
Syndacehas left
Valerianhas joined
uchas joined
alacerhas left
Tobiashas joined
Steve Killehas joined
intosihas joined
intosihas left
intosihas joined
Guushas joined
jjrhhas left
jjrhhas left
la|r|mahas left
Tobiashas joined
la|r|mahas left
matlaghas left
jjrhhas left
jjrhhas left
pep.has left
jjrhhas left
goffihas left
andrey.ghas left
andrey.ghas joined
Guushas left
Guushas joined
Alexhas left
Steve Killehas left
Alexhas joined
andrey.ghas joined
jjrhhas left
Guushas left
edhelashas left
edhelashas joined
alacerhas joined
Tobiashas joined
andrey.ghas joined
Guushas joined
jerehas joined
Tobiashas joined
andrey.ghas joined
Tobiashas joined
la|r|mahas joined
jerehas joined
Guushas left
Guushas joined
andrey.ghas joined
zinidhas left
andrey.ghas joined
Guushas left
Alexhas left
alacerhas joined
ralphmhas joined
Alexhas joined
jubalhhas joined
andrey.ghas joined
Valerianhas left
Valerianhas joined
Alexhas left
Tobiashas joined
Valerianhas left
Valerianhas joined
andrey.ghas joined
dwdhas left
SamWhitedhas left
andrey.ghas joined
tuxhas left
andrey.ghas joined
intosihas joined
Guushas joined
andrey.ghas joined
winfriedhas joined
Tobiashas left
Guushas left
andrey.ghas joined
Link Mauve« 08:39:27 jonasw> you need to know that it’s code though. XHTML-IM does not allow for a <code/> tag », it totally does, fyi.
Syndacehas left
Link MauveI should totally improve poezio’s XHTML-IM module to run pygment on incoming code!
Wiktorhas joined
Wiktorhas joined
ZashI'm almost surprised that you haven't already
mathieuisince 2003!
mathieuiwe’re way behind
mathieuinote to self: DoS Link Mauve by pasting perl code in MUCs
ZashDoes <code> not have a language attr tho?
Link Mauvemathieui, you know you don’t need anything fancy to DoS my server. :p
mathieuiright.
Link MauveZash, hmm, maybe I’d have to write a XEP extending 0071, maybe with a standardised class attribute or something?
ZashMaybe you already discussed this, but what about all the ways CSS can invoke more resources?
ZashLink Mauve: Standardized classes would sorta make sense I guess
ZashEg like vcard thing
mathieuiyeah, a class preset would actually solve all the portability issues of 0071, along with solving the potential for CSS abuse
ZashWay past brain-works-o'clock
Zashmicroformats!
Link MauveZash, don’t say that, I just woke up for the fourth time of the day!
mathieuiyes but you didn’t wake up yesterday, so it evens out
Link MauveTrue.
ZashI haven't woken up today.
ZashMMmm GMT+2 jokes ftw
andrey.ghas joined
Guushas joined
jerehas joined
jerehas joined
Guushas left
Guushas joined
andrey.ghas joined
alacerhas joined
Valerianhas left
Guushas left
jjrhhas left
danielhas joined
jjrhhas left
jjrhhas left
Zashmakes xep-0071.epub and dumps to e-ink-thingy for later reading
XSF Discussion - 2017-10-12