daniel, 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
jonasw
voice yourself on the ML :)
jonaswhas left
pep.
Will do
jonasw
and thanks
pep.
What/how/who would write that reference impl. though? XSF itself doesn't do that kind of stuff right?
zinid
reference implementation of what?
Ge0rGhas left
jonasw
pep., I wouldn’t say that
jonasw
there are RFCs which contain a reference implementation (e.g. the Opus Codec)
jonasw
so I don’t see any strict reason against that
jonasw
ideally 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@
zinid
ah
jonasw
alternatively we could take a look at existing web clients wich get this right, but it appears that there are none :)
zinid
not interested :)
jonasw
afk 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
edhelas
I choose to not implement XHTML-IM actually, it's also to keep the UI clean
edhelas
and it's heavy to cleanup/process XHTML messages on the volume
pep.
Xhtml-im* messages
Ge0rG
I'm absolutely in love with poezio's /code plugin.
zinid
https://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
jonasw
Ge0rG, /code is annoying in the sense that the sender chooses the colours; they may not fit with the recipients background for examle
uchas joined
edhelas
zinid used in Movim for the bookmarks and other things
edhelas
Ge0rG I'm also handling /code in Movim :)
zinid
edhelas: and how to deal with clients who don't support it?
zinid
edhelas: the same thing we did with avatars: nothing? :)
edhelas
zinid for bookmarks ? well I don't
edhelas
Movim is actually not in sync with Conversations regarding bookmarks
zinid
and you think it's ok? :)
pep.
edhelas: not the same way as poezio does. You leave the /code in your body :/
edhelas
because I choose to not use the old prive-xml XEP
pep.
And it doesn't make sense on any other clieny
pep.
Client
edhelas
pep. poezio put colors on the code using xhtml-im ?
pep.
Yes
edhelas
ouch
pep.
Why?
edhelas
then no, because it will look ugly
pep.
Why?
edhelas
well movim has its own color palette and so
edhelas
I don't want you to impose your pink and green colors in the Movim UI
pep.
Sadness
edhelas
also I can easily colorize the code myself, a simple lib on Movim side can take care of it
jonasw
edhelas, allowing XHTML-Im but filtering @style seems like a reasonable thing to do
jonasw
you 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
edhelas
then XHTML-IM is not a solution for it
jonasw
edhelas, itym then XHTML-IM should be extended ;-)
edhelas
pep. 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.
edhelas
why ?
edhelas
having 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
jonasw
yes, it would be better. but it works today, and breaking that would break a lot of clients for little gain
edhelas
if you don't like /code I understand, but let's be consistent
jonasw
/code is a client-side feature
jonasw
the "/code" is never transmitted
pep.
edhelas: history is never really consistent though. :/
pep.
Also it's not just about /code
vanitasvitaehas left
edhelas
but 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
edhelas
this 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
Ge0rG
jonasw: 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)
edhelas
I'm ignoring xhtml-im
edhelas
only use the body tag
edhelas
XMPP is a transport protocol, like HTTP is transporting HTML
pep.
Ge0rG: that sounds nice
edhelas
the forating rules of HTML/CSS/JS is another playground
edhelas
*formating
edhelas
to XMPP can tell me if a message contains code, like HTTP tell me if an answer contains text or images
edhelas
but doesn't tell me how to format thoses
jonasw
Ge0rG, +1
pep.
Well xhtml-im doesn't, you choose
jonasw
I thought about that when I wrote my reply, but I think that’s another battle.
pep.
edhelas: it's all about semantics
Ge0rG
jonasw: 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
jonasw
Ge0rG, yap
jonasw
pep., +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)
edhelas
sure
vanitasvitaehas joined
jonasw
edhelas, 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?
edhelas
jonasw it set the configuration of the node on the first start
edhelas
set on whitelist actually
Ge0rGhas left
jonasw
mhm
lskdjfhas joined
edhelas
same 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
Holger
XEP-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?
jonasw
depends
jonasw
is "unknown fields" qualified in the XEP?
valohas joined
jonasw
otherwise, one could argue that the app server understands those proprietary XEP—0357 fields
Kev
I'm not convinced that pubsub is actually the right mechanism for this anyway.
Holger
I'm ranting against the PubSub syntax for push notifications since forever :-)
Holger
It should just use a plain message.
Holger
jonasw: "Fields and their behaviour MUST be registered with the XMPP Registrar." -- https://xmpp.org/extensions/xep-0060.html#publisher-publish-options
jonasw
Holger, aww
MattJ
That's a silly requirement
MattJ
Like saying you MUST use standards
jonasw
kind of
Holger
MattJ: No it lets clients rely on behavior.
Holger
MattJ: Publish options are being used to make sure a node is not world-readable, for example.
ralphmhas left
dwdhas left
MattJ
Yes, rejecting unknown fields makes sense
MattJ
But requiring that every field MUST be registered I'm less sure of
Holger
If you guys are just saying that a non-standard service may accept the 0357 options then that's what I'm saying.
dwdhas left
zinid
MattJ: if it's not registered, then how to federate?
Holger
You can't use a standard service but must build your own PubSub thing to create an app server.
Holger
I think you must do so anyway if you actually need to parse those custom options (such as the secret).
MattJ
A non-standard service is a non-standard service and doesn't need to follow a MUST in a standard, because it's non-standard
Holger
So basically I'm back to "don't use PubSub syntax".
dwdhas left
MattJ
zinid, there are cases where federation is not a concern
Holger
MattJ: Right. So we shouldn't change the standard to also standardize non-standard behavior.
zinid
MattJ: ok, but in that case you don't give a damn whether there is MUST or not
Holger
Exactly.
Holger
<MattJ> Like saying you MUST use standards
Holger
0060 doesn't do that.
Holger
It 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
Holger
I.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
MattJ
Yes, to federate/interop you generally must use standards
MattJ
But this is a case where you don't, right? :)
Syndacehas joined
Ge0rG
If people don't bother to use standards, they won't bother more if the standards write that you MUST use standards.
Holger
MattJ: The idea is that you could use a standard PubSub service.
zinid
right, so Holger is right: we shouldn't use pubsub for this
Holger
MattJ: ... and have the app server subscribe to that.
dwdhas left
Holger
MattJ: That PubSub service would be a federating/interoperating 0060 service.
Holger
MattJ: At least that's how Lance argued back when I argued against PubSub :-)
MattJ
If 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
zinid
why do we need so complex pubsub, it's kinda relay, what for?
Ge0rGhas left
zinid
I mean why would an app server subscribe to it instead of directly receiving stanzas?
Holger
MattJ: I'm talking about "the thing accepting the publish".
MattJ
which has to understand the options, no?
Holger
MattJ: Lance said he's using PubSub to make it possible for a standard publish service to be that thing.
Holger
MattJ: I'm saying this won't work.
MattJ
Example option?
Holger
MattJ: Yes. The thing has to understand non-standard options.
Holger
'secret'
MattJ
Is this something you made up for your implementation, or is it in the XEP?
Holger
MattJ: Example 13 in XEP-0357.
Holger
MattJ: It's just an example. 0357 says I may include arbitrary options. 0060 says a standard PubSub service MUST reject them.
dwdhas left
MattJ
Well a simple solution is to register the option ;)
dwdhas left
Holger
No.
Holger
You want to allow for arbitrary options.
Holger
ChatSecure uses some other stuff.
Steve Killehas left
MattJ
I still don't see a problem
Holger
MattJ: As you said this is really just communication between the app and the non-standard app server.
MattJ
So, you're using an off-the-shelf pubsub service
Holger
MattJ: So it just makes no sense to use PubSub for this.
MattJ
and it doesn't understand your custom option, but what is it meant to do with it?
Holger
MattJ: That's the next problem, which is why I'm saying this won't work anyway :-)
zinid
MattJ: but you need to patch the server in order to accept options in order to be passed them to the app server
Holger
The node subscriber won't see the option.
MattJ
Right
Holger
MattJ: 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
Holger
MattJ: Then I tell them that this isn't possible because it just looks similar to PubSub but is slightly non-standard.
MattJ
Ok, I see better now
MattJ
You're complaining as an XMPP server developer, not as an app server developer
Holger
Well.
zinid
what's the difference? :)
Holger
Sure 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.
MattJ
Sure
dwdhas left
Holger
As 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/>.
Ge0rG
I also had that thought about "why not messages" when reading Push XEP back then
oh, "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
Holger
There you go.
zinid
great
zinid
we can use pubsub for messages and presences btw
zinid
because why not? existing protocol!
Holger
I would say a <message/> offers all those features as well :-)
Ge0rG
Time to ask on standards@?
Kev
We can use pubsub syntax for not-default-xep60 services just fine, if we want to (e.g. 369).
Kev
And 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.
MattJ
zinid, https://xmpp.org/extensions/xep-0207.html
zinid
MattJ: I know :)
Holger
Kev: Same syntax, slightly different semantics sounds awesome to me.
Ge0rG
The road to hell is paved with good intentions?
zinid
especially 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
Alex
have 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
Here 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
zinid
Ge0rG: nobody cares, they just invent crap like http2 instead of really fixing things
zinid
Just like XSF 😂 Because interop
jjrhhas left
Ge0rG
it'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
dwd
Can someone not using Gajim write something with *bold* and /italic/ things in, please?
Flowhas joined
Ge0rG
dwd: at your service. Italics doesn't work though.
mathieui
this is not /italic/ and neither that one is *bold*
mathieui, Whereas yours was rendered as italic and bold for me, Markdown-like.
jubalhhas left
mathieui
jonasw, err, I would like xmpp: links in href :p
Ge0rG
dwd: ah, so you were asking for markdown in 'body' and not for XHTML-IM formatted.
dwd
Ge0rG, Indeed, sorry.
Kev
I 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).
Ge0rG
so we are reinventing XHTML-IM without XML now?
SamWhited
I 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.
Ge0rG
people will just plug-in their favorite markdown parser and your body texts will end up mutilated and you will still end up being pwned.
SamWhited
It 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.
Ge0rG
SamWhited: there is no amount of specification that will prevent developers from doing stupid things.
alacerhas joined
SamWhited
Ge0rG: I agree. What's your point?
SamWhited
Security issues will always exist, so we shouldn't even try to mitigate any of them?
Ge0rG
SamWhited: XHTML-IM is good as it is.
SamWhited
Except for the history of insecure implementations.
Ge0rG
SamWhited: I have a dozen of CVEs for people not reading the Security Considerations of 0280.
Ge0rG
I want to burn Carbons with fire, but for completely different reasons.
Valerianhas joined
Ge0rG
SamWhited: by replacing XHTML-IM with markdown, you will keep the exact same security problems.
mathieui
most markdown implementations even allow raw html right in the plaintext, so I don’t see how that solves the "developer get it wrong" part
Ge0rG
And probably add some more.
Ge0rG
what mathieui said.
SamWhited
Ge0rG: That's why I'm not arguing that we should use markdown.
SamWhited
Just that we should obsolete XHTML-IM.
mathieui
yeah, that’s what SamWhited made a point in the thread to keep it about deprecating xhtml-im✎
mathieui
yeah, that’s why SamWhited made a point in the thread to keep it about deprecating xhtml-im ✏
Flowhas joined
Ge0rG
SamWhited: Council just refused to deprecate 136 despite it not being a replacement/alternative to 313.
SamWhited
Ge0rG: I know, it made me sad. This is a security issue though, which I think makes it slightly different and more pressing.
Kev
I 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.
Kev
But I do think that it's woefully inadequate at protecting diligent devs from things they haven't considered.
Ge0rG
XHTML-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.
SamWhited
I 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.
Ge0rG
SamWhited: maybe you can write that spec up, then?
SamWhited
It doesn't need to be impossible, it just needs to not be the "default".
Ge0rG
and then implement it in a bunch of widely-used XMPP clients.
mathieui
e.g. if we design a new markup language with a secure reference implementation
SamWhited
Ge0rG: no, I'm not interested. I'm just interested in getting rid of XHTML-IM.
Ge0rG
And then ask again for deprecation of XHTML-IM?
jerehas joined
mathieui
I remember embedding javascript within my nickname in jappix that would dump account passwords to a MUC
mathieui
no need for xhtml-im there
SamWhited
Yah, I've found plenty of those too, they're unrelated though.
Ge0rG
Yeah, so many places for XSS.
mathieui
they have the same root issue: the web
SamWhited
mathieui: If you have a proposal for fixing the root issue, I'm all ears :)
mathieui
:D
SamWhited
I would love to fix "the web" :)
Zash
SamWhited: So what you really wanna do is deprecated teh web! :)
Zash
Let's do tha!
Alex
use markdown :-)
Ge0rG
Yeah, let's approach the W3C with that.
Kev
SamWhited: 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.
Ge0rG
Kev: even if there was a strawman, we still have the wide deployment problem.
Ge0rG
XHTML-IM is supported over a pretty large client base, as opposed to non-markdown-strawman.
I 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)
Ge0rG
Also related: https://blog.plan99.net/its-time-to-kill-the-web-974a9fe80c89
SamWhited
But 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.
SamWhited
s/deprecate/obsolete/ (I'm trying to be precise about my language, but I still mix those two up constantly)
Ge0rG
I want to deprecate GC1.0. And then some.
Kev
Ge0rG: 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
Ge0rG
Kev: it was brought up at the last-but-one council and got vetoed immediately, IIRC
Ge0rG
Kev: you also still wanted to provide more alternatives to 1-2-3.
Flowhas joined
Kev
Ge0rG: 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
Ge0rG
Kev: oh, sorry. I must be misremembering then.
Kev
And I might misremember, but I don't recall anyone objecting to it in the thread.
Ge0rG
Maybe because it was TLDR, once again.
alacerhas joined
emxphas joined
jjrhhas left
Ge0rG
Kev: 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."
Ge0rG
Kev: you also liked (2), which was the new-iq-type.
sonnyhas joined
sonnyhas joined
Ge0rG
but I'm interested in the other options before writing a diff to 0045.
sonnyhas joined
Kev
Ge0rG: 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?
Kev
I accept there's a very real possibility that I'm simply going mad.
jjrhhas left
Valerianhas left
Ge0rG
Kev: you ended up discussing with Zash whether we can reliably obtain statistics on "intended GC1 joins" vs "presence updates misunderstood as GC1 joins"
Ge0rG
which we can't.
sonnyhas joined
Zash
Why not?
sonnyhas joined
Ge0rG
Zash: how?
Ge0rG
Kev: 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
Zash
Ge0rG: 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
Ge0rG
Zash: and then compare that with <x>-enabled presence from the same full JID in the last X hours?
Kev
Zash: That's not the question.
Kev
Zash: 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
SamWhited
Sorry, 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
Ge0rG
wow, just got a presence from somebody in the form of "phone." + [68 characters that look like base64, including slashes]
Ge0rG
the madness is rising.
Ge0rG
SamWhited: yeah, the final decision was to get some list discussion, but there were some proponents of keeping GC1, surprisingly
Zash
Madness
Zash
http://www.youtube.com/watch?v=QH7fIkV8nsk
jjrhhas left
jjrhhas left
dwdhas left
moparisthebesthas left
alacerhas joined
uchas joined
jonasw
SamWhited, 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
SamWhited
jonasw: Did I? Sorry about that
SamWhited
I removed the extra, but I didn't think I took you out of context or anything
jonasw
you removed the part where I said "plus providing a reference implementation"
SamWhited
Yah, I know, I wasn't responding to that part
SamWhited
It's unrelated to further restricting the subset of HTML involved
jonasw
not entirely, it’ll simplify the reference implementation.
SamWhited
ah, I see, restricting the HTML was about making the reference implementation simpler? Yah, I misunderstood what you meant
SamWhited
Either way, I don't think a reference implementation helps either
jonasw
all implementations, but also the reference implementation, because I agree that simply changing the spec won’t solve a thing
jonasw
I strongly think so
Alexhas left
jjrhhas left
SamWhited
I 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)
SamWhited
But not everyone will use it, so I don't think it really helps
jonasw
if 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
SamWhited
Yah, some will and that's nice, but not all will
jjrhhas left
jonasw
meh
SamWhited
It 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
Ge0rG
There are so many places to inject code into the DOM of a JavaScript XMPP client, XHTML-IM is just one of them.
jonasw
see, 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)
SamWhited
Ge0rG: yes… again I don't understand your point though: security is hard, so let's not fix any of the problems?
SamWhited
Other places where DOM injection is possible aren't related to this discussion
jonasw
I think that providing a reference implementation is the best we can and should do.
SamWhited
jonasw: 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.
Ge0rG
SamWhited: I'm just saying that security-ignorant developers will keep writing vulnerable XMPP clients, with or without XHTML-IM
jonasw
SamWhited, what else are we going to do? The alternative will be to reinvent XHTML-IM.
SamWhited
Ge0rG: Yes, I agree. I don't see what that has to do with anything though.
SamWhited
jonasw: Yes, reinvent it, but reinvent it in such a way that it's not HTML.
Ge0rG
SamWhited: I think my slightly exaggerated point is: you can't make webchat more secure by removing XHTML-IM.
jonasw
We 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)
jonasw
SamWhited, people will simply patch tag names and embed it in the DOM.
jonasw
if 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
SamWhited
jonasw: 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.
Ge0rG
Maybe 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?
SamWhited
People 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.
jonasw
SamWhited, I’m keeping to mention @style, because @style is really really hard to fix.
jonasw
the other parts are more or less a piece of cake.
SamWhited
jonasw: Yah, I agree with you we should take it out. I just don't agree with you that it would solve anything.
Ge0rG
SamWhited: the problem you are trying to fix is ignorant developers?
SamWhited
Ge0rG: "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.
jonasw
SamWhited, with @style, it is entirely unrealistic that any implementation is safe, because nobody will parse CSS.
dwdhas left
SamWhited
jonasw: I'm not arguing against that. By all means, remove style.
SamWhited
But that's another orthogonal problem.
jonasw
only if you’re set on obsoleting XHTML-IM, which I’m not ;-).
dwdhas left
SamWhited
It'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
jonasw
okay, 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 Mauve
I should totally improve poezio’s XHTML-IM module to run pygment on incoming code!
Wiktorhas joined
Wiktorhas joined
Zash
I'm almost surprised that you haven't already
mathieui
since 2003!
mathieui
we’re way behind
mathieui
note to self: DoS Link Mauve by pasting perl code in MUCs
Zash
Does <code> not have a language attr tho?
Link Mauve
mathieui, you know you don’t need anything fancy to DoS my server. :p
mathieui
right.
Link Mauve
Zash, hmm, maybe I’d have to write a XEP extending 0071, maybe with a standardised class attribute or something?
Zash
Maybe you already discussed this, but what about all the ways CSS can invoke more resources?
Zash
Link Mauve: Standardized classes would sorta make sense I guess
Zash
Eg like vcard thing
mathieui
yeah, a class preset would actually solve all the portability issues of 0071, along with solving the potential for CSS abuse
Zash
Way past brain-works-o'clock
Zash
microformats!
Link Mauve
Zash, don’t say that, I just woke up for the fourth time of the day!
mathieui
yes but you didn’t wake up yesterday, so it evens out
Link Mauve
True.
Zash
I haven't woken up today.
Zash
MMmm 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