Flow, there was the argument that identities may be localized.
Dave Cridlandhas left
Dave Cridlandhas left
SaltyBoneshas left
Tobiashas joined
andyhas left
SaltyBoneshas joined
Dave Cridlandhas left
Dave Cridlandhas left
suzyohas left
suzyohas joined
moparisthebesthas left
Seve
I changed my email address. Does anyone know who should I get in touch with to subscribe myself with my new email address, please?
moparisthebesthas joined
danielhas left
jonasw
Seve, to all lists but members@, you can manage that yourself
danielhas joined
jonasw
I’m not sure if you can change your email address for members@ yourself
jonasw
you could try checking the options at https://mail.jabber.org/mailman/options/members/your.old@email.address
Seve
Ohh
jonasw
(note the email address in the URL)
Seve
Sorry!
Seve
I forgot to mention that I want to subscribe to members@, yes.
jonasw
ha ok
jonasw
I don’t know who’s responsible for this, but somebody from iteam will do
andyhas joined
jonasw
the two I have in mind aren’t here right now though
danielhas left
danielhas joined
andyhas left
andyhas joined
ralphmhas joined
andyhas left
Guushas left
andyhas joined
Guushas left
remkohas joined
andyhas left
rionhas left
danielhas left
rionhas left
Dave Cridlandhas left
jubalhhas joined
tim@boese-ban.dehas joined
Tobiashas joined
Dave Cridlandhas left
SaltyBoneshas left
Dave Cridlandhas left
Dave Cridlandhas left
moparisthebesthas left
andyhas joined
Ge0rG
I'd like to propose a new marketing slogan: *XMPP - as popular as the Metric system in the USA*
jonasw
:<
Ge0rG
jonasw: it could be worse, e.g. "XMPP - as popular as the Measles"
andyhas left
jonasw
:<
Fabianhas joined
Fabianhas left
moparisthebesthas joined
Alexhas joined
Dave Cridlandhas left
hanneshas left
Guushas left
andyhas joined
Dave Cridlandhas left
Fabianhas joined
Guushas left
rionhas joined
tuxhas left
tuxhas joined
andyhas left
Steve Killehas left
mimi89999has joined
Alexhas left
Alexhas joined
Steve Killehas joined
Fabianhas left
jubalhhas joined
blablahas joined
andyhas joined
andyhas left
Dave Cridlandhas left
tim@boese-ban.dehas left
tim@boese-ban.dehas joined
Dave Cridlandhas left
Dave Cridlandhas left
jubalhhas joined
marchas joined
Dave Cridlandhas left
blablahas joined
Martinhas joined
rionhas left
rionhas joined
rionhas left
rionhas joined
intosihas joined
rionhas left
Kevhas joined
Fabianhas joined
Dave Cridlandhas left
Alexhas left
mimi89999has joined
Alexhas joined
Fabianhas left
jonasw
oh my god
jonasw
I’m just reading XEP-0013
jonasw
why did it seem like a good idea to use disco#info for the number of messages?
Kev
-13 is pretty old, we've got a lot of best-practice knowledge that's built up since then.
Bunneh
Kev: I'll remember that.
jonasw
-13
Bunneh
jonasw: pretty old, we've got a lot of best-practice knowledge that's built up since then.
Kev
What the smeg?
jonasw
hah!
ralphmhas joined
Tobias
:D
jubalhhas left
Fabianhas joined
marchas left
Fabianhas left
Fabianhas joined
jubalhhas joined
jubalhhas left
jubalhhas joined
jubalhhas left
Flow
jonasw, ok, so why an extra hash for localized identities?
Fabianhas left
jonasw
Flow, separating them so that entities can profit from their cache for features and forms
jonasw
(also, there are precedents for quickly-changing forms)
Neustradamushas left
jonasw
(e.g. the number of users in a MUC in its disco#info)
Syndacehas joined
SaltyBones
What does "localized" in this context mean? "translated"?
jonasw
in such a quickly-changing-form-case it would be profitable if entities could opt-out of the forms hash to indicate that it is quickly changing and must always be considered stale.
Flow
that sounds like an argument for an extra hash for forms
jonasw
yes
jubalhhas joined
jonasw
question is if separation of identities makes sense, too.
Flow
but I still don't see the advantage of an extra hash for localized identities
Flow
given that the identities will not frequently change
jonasw
I don’t see it either, necessarily
Flow
SaltyBones, yep, usually it's about the xml:lang attribute
Flow
are there many other popular precedents for quickly changing forms?
jonasw
Flow, I don’t know, honestly
jonasw
that’s why I *wish* there was more feedback on this on-list
Flow
I was going to write yesterday, but then figured that I possibly don't know what it is really about
jonasw
so I need to make it clearer?
Flow
jonasw, dunno, it appears you also don't know an example where extra hashes for identities, feature and/or forms are beneficial
lumihas joined
jonasw
for forms, the MUC case is rather beneficial; the current workaround which is used is that the form wtih the numebr of users is not included when answering disco#info for a caps node
Flow
besides when protocols come into play that put dynamic information into e.g. features
jonasw
which is bad
jonasw
and in many cases, entities might not be interested in the form data, which is almost alwyas supplementary
jonasw
thus making them miss the cache because of uninteresting form data is not totally great
jonasw
(for example, entities which put OS version into the disco#info data; you’d then build a cache where each release of every operating system on which the client runs is held, which is kind of not very useful to have in the first place)
jonasw
I’m not sure there’s a strong argument for separating identities, but separating forms seems appealing to me
jonasw
I hoped that zinid would comment on this since he told me about the MUC forms use case.
Flow
hmm I see/saw caps mostly as an instrument to discover the caps of a remote "client". I can't even tell from the top of my head if caps works with xep45: Do you get a presence from the MUCs bare JID?
Flow
If ecaps2 is missing something, then it is possibly a mechanism for clients to annouce their features even if they are offline (e.g. via PEP)
SaltyBones
XEPs should mandate a list of intended use-cases.
Flow
SaltyBones, don't they?
jonasw
Flow, recent developments make you get a presence from the bare MUC jid on join, yes
jonasw
that’s a result of summit
Flow
jonasw, is that xep45 change live already?
jonasw
it is being developed and evaluated against client implementations
Flow
jonasw, ok, i guess it's part of the multi nick sharing initiative
danielhas left
jonasw
Flow, no, it’s part of the avatars for MUCs initiative :)
jonasw
and knowing the disco#info of a MUC is probably useful
Flow
from what I know till now, I don't feel that it is worth separating the hashes. Instead we should consider adding a best practice to xep30 that disco#info results are supposed to be not short-living
jonasw
Flow, how are you suggesting to fix the xep45 use-case then?
jonasw
also, short-living isn’t the same as high-cardinality, whihc is also an issue
jonasw
(as in the OS Version case)
Flow
jonasw, the os version case is not xep92?
Flow
but yes, you are right, it's not the same, i'm not sure if high-cardinality is an issue and if it needs fixing
marchas joined
moparisthebesthas joined
jonasw
softwareinfo
Flow
same is true for xep45, I possibly could live with an cold caps cache every time an occupant leaves or joins
jonasw
hm, we could test that, we have a huge repository of caps data
jonasw
I think I’ll do that :)
Flow
jonasw, sorry, softwareinfo?
jonasw
https://xmpp.org/extensions/xep-0232.html
jonasw
that one
jonasw
I had to google the namespace myself
pep.has joined
Flow
uh, i forgot that we have an update to xep92, would be great if there where a pointer from xep92 to it's possible successor
jonasw
Flow, the issue is that caps cache should be persistable; defeating that because we’re spamming the databases with pointless updates/minor differences is kinda sad.
jonasw
but sure, I’ll run a test on the capsdb
Flow
jonasw, but is it an issue?
jonasw
it’s a bit dated, but probably a good source of a first estimate
jonasw
Flow, that’s what I’m going to find out
andyhas joined
ralphmhas joined
Flow
hmm not sure if xep232 is really an improvement over xep92
andyhas left
marc
Ge0rG: how do you implement "pending XMPP URIs"? E.g. you add a contact but don't have an account set up yet and show the corresponding dialog after account setup. IIRC you do this in yaxim
rionhas joined
stefandxmhas left
Ge0rG
marc: I'm keeping the Intent and re-firing its handler after account creation
SaltyBones
what does that mean? you can add people who don't have an account??
marc
Ge0rG: what if multiple activities are involved before you can re-fire it? Do you pass it to all the activities?
jonasw
SaltyBones, XEP-0401
SaltyBones
-xep-0401
daniel
> Ge0rG: how do you implement "pending XMPP URIs"? E.g. you add a contact but don't have an account set up yet and show the corresponding dialog after account setup. IIRC you do this in yaxim
Conversations does that as well
SaltyBoneskicks Bunneh.
Ge0rG
marc: the only flow allowed is "main activity [optional: prefs activity ->] main activity"
jonasw
SaltyBones, -xep 0401
jonasw
SaltyBones, {xep 0401}
Bunneh
SaltyBones: Easy User Onboarding (Standards Track, Experimental, 2018-01-25)
See: https://xmpp.org/extensions/xep-0401.html
SaltyBonespours a bucket of water on Bunneh.
jonasw
there we go
marc
daniel: really? What version?
daniel
Not with the entire uri though. Just the jid. But that could be changed
daniel
marc: dunno. Maybe 1.23.0
Ge0rG
Bunneh is b0rked
marc
Ah okay, because I need the full URI
daniel
yeah changing that is probably fairly easy
marc
Okay, I'll take a look
SaltyBones
marc, did you write this XEP?
SaltyBones
Anyway, good stuff.
nycohas left
SaltyBones
And of course as always thanks to Ge0rG for all his efforts in this direction!
marc
SaltyBones, Ge0rG also did lots of stuff
marc
SaltyBones: yes
Ge0rG
SaltyBones: 🙇
rionhas left
danielhas left
Dave Cridlandhas left
ralphmhas joined
Steve Killehas left
lumihas left
Ge0rG
So I've installed kaidan, and it is _very_ basic
Seve
it is
blablahas left
marchas left
jubalhhas left
daniel
seems to be a pattern
Ge0rG
The CADT pattern.
Ge0rG
Oh, I've installed 0.2.3 from their repo, github has 0.3.2
Seve
Well, it is relatively new, so...
Ge0rG
https://github.com/KaidanIM/packages/issues/1 :|
Ge0rG
Seve: 0.3 was a significant change
rionhas joined
Ge0rG
also half a year of development between the releases.
jjrhhas left
Ge0rG
So Kaidan reflects the general status of XMPP very well.
jjrhhas left
MattJ
6 months between releases is not long, or what are you saying? :)
nycohas left
Ge0rG
MattJ: I'm saying that having 6 months old DEBs on their own repo is really bad.
Ge0rGhas joined
Ge0rGhas joined
Ge0rGhas left
Ge0rGhas left
Ge0rGhas left
Ge0rGhas left
Ge0rGhas left
Ge0rGhas left
Ge0rGhas left
jubalhhas joined
jubalhhas left
jubalhhas joined
jubalhhas left
jubalhhas joined
marchas joined
Guushas left
Steve Killehas joined
SaltyBones
You can deploy QT to iOS?
Dave Cridlandhas left
Tobias
Some Qt pars, yes
Tobias
Qt Quick GUIs you can
danielhas left
SaltyBones
Does GTK have something similar?
Tobias
no clue
stefandxmhas joined
suzyohas joined
danielhas left
SaltyBones
Tobias, this https://doc.qt.io/qt-5/qtquick-index.html ?
matlaghas joined
Tobias
yes...that stuff works across desktop and ios/android platforms
SaltyBones
huh...nice
jonasw
"works"
SaltyBones
oh...
jonasw
it lacks quite a few things/controls, it is a pain to use with C++ and I think you’ve got to do accessibility quite all by yourself
jonasw
but I haven’t looked deeply into the last part
jjrhhas left
jjrhhas left
Dave Cridlandhas left
Dave Cridlandhas left
ralphmhas joined
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
moparisthebesthas joined
Dave Cridlandhas left
stefandxmhas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
dwd
Gosh, Gloox. There's a blast from the past.
Dave Cridlandhas left
Dave Cridlandhas left
MattJ
Indeed
jubalhhas left
Dave Cridlandhas left
jubalhhas joined
Dave Cridlandhas left
Dave Cridlandhas left
nycohas left
Dave Cridlandhas left
la|r|mahas joined
Dave Cridlandhas left
lskdjfhas joined
Dave Cridlandhas left
vanitasvitaehas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
jubalhhas left
jubalhhas joined
jubalhhas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
vanitasvitaehas left
Dave Cridlandhas left
Dave Cridlandhas left
suzyohas joined
marchas left
Alexhas joined
marchas joined
vanitasvitaehas left
Dave Cridlandhas left
Dave Cridlandhas left
jerehas joined
jubalhhas joined
jubalhhas left
marchas left
Ge0rG
jonasw: I think the impact from http upload might be comparable to dns rebinding attacks
Dave Cridlandhas left
jonasw
Ge0rG, the local servers thing is a point
jonasw
so I’d suggest to add a reference to CWE-918 in the security considerations and write that clients need to treat themselves as HTTP Proxies w.r.t. security considerations
jonasw
maybe we can find HTTP documents which elaborate on those
Ge0rG
jonasw: with newlines, the attacker can forge any payload to the http post
lskdjfhas joined
jonasw
daniel, ^
jonasw
Ge0rG, but we agreed to reject newlines.
Ge0rG
jonasw: I'm not saying it's impossible without newlines
daniel
Yes the newline thing doesn't need debating anymore
Dave Cridlandhas left
Ge0rG
daniel: good luck finding out what is "on the LAN"
daniel
Ge0rG: any of the reserved IP ranges I mean
Ge0rG
Gets you into trouble in enterprise deployments
jonasw
Ge0rG, "unless the server is in a LAN"
jonasw
that’s by the way similar to the application boundary enforcement NoScript does by default…
jonasw
nightmare
Ge0rG
jonasw: yay for complex filtering rules!
Dave Cridlandhas left
jonasw
Ge0rG, that wasn’t my idea
jonasw
Ge0rG, do you have a better solution, considering that some services will need headers for authn?
jonasw
(and authz)
jonasw
and we can’t predict the header names reasonably?
daniel
By the way the exploiting your plastic router scenario is kinda independent of the header discussion
daniel
Those are usually exploited by get parameters anyway
Alexhas joined
Ge0rG
daniel: indeed. Having PUT instead of POST does us a favor here.
Ge0rG
daniel: besides, it's easier to exploit things via POST than via GET, but most browsers block cross-origin-POST
Ge0rG
And then, the HTTPS certificate requirement should effectively protect typical LAN routers.
Flow
Ge0rG, why is PUT different from POST in this case?
daniel
Ge0rG, assuming your $10 router distinguishes between the different methods :-)
Ge0rG
but those are all mitigations
Ge0rG
daniel: touché
Dave Cridlandhas left
MattJ
"Let's use HTTP because it's simple"
MattJducks
Ge0rG
Flow: most HTTP appliances use POST for form submission, not PUT
Flow
yeah, XMPP is way simpler
jonasw
Ge0rG, browsers don’t block cross-origin post unconditionally; I know that you can cross-origin POST with a <form/> for example
Flowducks
Ge0rG
stop it now! I'm just reading Jingle-FT and it's gruesome.
Ge0rG
jonasw: good point. Does that make all HTTP POST endpoints exploitable?
jonasw
Ge0rG, that’s why we have CSRF tokens
Ge0rG
I love those.
Ge0rG
Let's add an CSRF token to HTTP-Upload.
Alexhas left
Fabianhas joined
Flow
I whish we had a magic marker which tells us when ge0rg is serious nor not
Ge0rG
Flow: I wish I had such a marker myself.
SaltyBones
what is the original document you guys are discussing?
Ge0rG
SaltyBones: XEP-0363
SaltyBones
-{XEP 0363}
Flow
-xep363
Ge0rG
SaltyBones: also https://mail.jabber.org/pipermail/standards/2017-November/033936.html
Tobias: I can only hope that all of the complexity comes from the domain and not from Jingle-FT itself.
Tobias
Ge0rG, in what way? what bit is in there that's not needed to get peer-to-peer file transfer working in all cases
Tobias
the complexity likely comes from the problem domain
Tobias
WebRTC is similarly complex
Ge0rG
Tobias: except WebRTC also has proper NAT traversal and e2ee ;)
Flow
I think both Jingle and WebRTC have room for improvement when it comes to reducing the complexity. But I doubt that it's going to happen, because their deployment reached the critical mass
Flow
Ge0rG, Jingle has E2EE too (not sure what the current state of the xep is)
jonasw
"Experimental"
Ge0rG
Flow: "horrrible"
Tobias
WebRTC has decent e2ee? I thought it's e2ee was MITM-able
Ge0rG
or maybe "abandoned"
stefandxmhas joined
la|r|mahas joined
marchas joined
andyhas joined
marc
It has E2EE if the signaling channel is protected
Ge0rG
marc: ITYM if the server is trusted.
SaltyBones
Maybe this is controversial but I think 0363 should NOT allow "unlimited other headers" at most it should allow one or two specific ones but imho none would be more appropriate.
jonasw
SaltyBones, but there are services which require headers
jonasw
integration with those services was the goal of the update which introduced headers
Dave Cridlandhas left
SaltyBones
Why doesn't the server just take the data and the put it wherever it belongs?
Ge0rG
HTTP-Upload headers are the XHTML-IM of this year's compliance suite.
Ge0rG
SaltyBones: because traffic and scalability
jonasw
Ge0rG, you’re exaggerating
Tobias
Ge0rG, what's your opinion on XEP-0385?
rionhas left
SamWhited
For once I disagree about the complexity. The trade off seems justified here, without the headers you can't have auth or signed URLs
marc
Ge0rG: not exactly, you could use OMEMO to protect the credentials
rionhas joined
jubalhhas joined
SaltyBones
So, why doesn't the server simply communicate the URL it passed to the client to whoever actually gets the data?
SaltyBonesshould really stop talking.
Ge0rG
SamWhited: I'm only slightly serious, but I'd like to hear your input on how a malicious server could abuse http-upload to wreak havoc
Ge0rG
a malicious xmpp server
jubalhhas left
Dave Cridlandhas left
SamWhited
I want to make sure that a client can't upload unlimited stuff, but the http server is on another host and knows nothing about the xmpp server. How can I do that without some way for the client to also communicate with the http server? I could maybe shove one or two things in the path, but that's going to get ugly quick
SamWhited
mostly I just want to use s3 directly though, which requires auth headers.
Ge0rG
SamWhited: so instead you opt for making the client a generic protocol proxy?
stefandxmhas left
jonasw
(a generic XMPP->HTTP proxy)
SamWhited
It's nothing close to that, it has to support http to do a post anyways, so you're just telling it how to structure its request
jonasw
SamWhited, this is exactly what proxying is
Dave Cridlandhas left
jonasw
I was flabbergasted when Ge0rG said that first, but I think he’s right.
Martinhas left
jonasw
in the end what the client is here is a proxy supporting PUT with arbitrary headers to an arbitrary HTTP(S) host with an arbitrary URL
jonasw
the only thing the server can’t control is Content-* and the body
SamWhited
this sounds dangerously close to a semantic argument, so sure, it's a simple proxy without the complex body bits. that seems fine.
Ge0rG
SamWhited: I'd argue that we have a whitelist of HTTP headers that the module is allowed to override/set.
SaltyBones
SamWhited, isn't that impossible? The client has to request a slot from the XMPP server and must include the filesize and the receiving host must validate that filesize. They have to communicate, right?
Ge0rG
SaltyBones: they don't *have to*, the HTTP server can be independent
jonasw
SamWhited, SaltyBones, mod_http_upload_external for prosody essentially includes an HMAC of the content size and file name into the PUT URL query which is verified by the peer.
jonasw
but other, already existing things require HTTP headers to dot hat✎
jonasw
but other, already existing things require HTTP headers to do that ✏
SamWhited
Ge0rG: what benefit would a white list provide?
Ge0rG
SamWhited: we would severely limit what a malicious server can do via the client-proxy.
SamWhited
SaltyBones: upload servers often need things at point of upload, eg a bearer token.
SamWhited
Ge0rG: I see, that seems fair.
Ge0rG
SamWhited: have a look at http://blog.portswigger.net/2017/07/cracking-lens-targeting-https-hidden.html#host for how to abuse an HTTP proxy to access non-HTTP protocols
Ge0rG
Seems like nobody is reading my emails :>
SamWhited
I'm reasonably sure this isn't actually a problem here, but I'd be interested in trying to come up with a POC. Will read that when I get to my desk
Dave Cridlandhas left
Ge0rG
SamWhited: tl;dr: if you can inject raw multi-line text into requests to custom ports, you can own many text-based protocols.
SamWhited
oh, well yah, headers have to be sanitized
Ge0rG
I'm pretty sure that SMTP looks sufficiently close to HTTP to be able to send an email just by passing a long list of custom headers ;)
jonasw
I’m not so sure
jonasw
or does SMTP use colons everywhere?
Ge0rG
jonasw:
MAIL FROM: foo
RCPT TO: bar
jonasw
ew
jonasw
but can you add spaces to HTTP header names?
Ge0rG
jonasw: it depends™
daniel
Ge0rG: but you can't pass a data and a dot
daniel
As mentioned earlier
SamWhited
it also uses mime like headers, yah. But that's an easy fix.
SamWhited
That being said, I agree it's going to be a problem.
SamWhited
Actually, no I don't. I need to be at my desk to test this, but I'd be suprised if most http libraries allowed invalid requests that way.
jubalhhas joined
jerehas left
jerehas joined
SamWhited
The attack vector here relies on the users server or a component being malicios too, but part of xmpps security model is that you have to trust your server, so it botheers me less, though if we can mitigate it without too much trouble that seems fine.
SamWhited
/thinking-out-loud
SamWhited
spling is herd
Ge0rG
SamWhited: I tend to agree with what you say, but having such a reverse proxy in a corporate network will surely ring some compliance bells.
SamWhited
I doubt it, but I'lk ask our compliance person when I get to the office
andyhas left
SaltyBones
Who are these people who want to put their http upload data on a different machine but cannot be bothered to give it an interface which can check urls with HMACs and why should we care about them? :p
Ge0rG
SamWhited: I'm also not sure that all http libraries properly sanitize headers.
Ge0rG
SaltyBones: amazon cloud was called out
SamWhited
We didn't use it at HipChat for this reason if you need a real world example.
SamWhited
Also S3 gives you 5 gigs of free storage or something, but the bandwidth to proxy it is not free.
Dave Cridlandhas left
SamWhited
Well, in all fairness I'm not sure that it would fit HipChats use case anyways, but it was immediately discounted because there was no control over requests
SaltyBones
and they wanted total control or would some kind of "provide this token" have been sufficient?
jonasw
SaltyBones, headers, obviously, because the server had full control over the URL all the time
SamWhited
We needed the ability to set auth headers, I think. Can't remember if we needed other stuff for signing or not, seems like that didn't end up making it to the final thing.
Ge0rG
SamWhited: so can we agree on a whitelist of "Authorization" and "Cookie"?
Ge0rG
and _maybe_ "X-*"
jonasw
Ge0rG, also, what is the issue we’re seeing here by the way?
jonasw
the only real issue is with network boundaries, isn’t it?
Dave Cridlandhas left
jonasw
and the possibility for the malicious XMPP server to disguise itself behind the HTTP upload-ing clients
jonasw
otherwise the XMPP server could carry out the attacks themselves
jonasw
and with much more precision
Ge0rG
jonasw: yes.
jubalhhas joined
SamWhited
maybe… if it's not actually a problem a white list seems like it will just be ignored by half of clients and end up causing interoperability problems. We should try to prove that it is, or is not, a problem first in my mind.
jonasw
so if there is stuff which breaks from unauthenticated plaintext being sent, I’d be inclined to argue that the stuff which breaks is at fault
jubalhhas left
jonasw
+1 SamWhited
SamWhited
I still think trusting the server is okay too.
jonasw
that too
jonasw
(even though the server might be in an entirely different trust domain than the network the client is on)
Ge0rG
SamWhited: if we make it a closed whitelist, we can just provide according xmpp elements for each header name
Ge0rG
SamWhited: so that clients can't make dumb errors.
jonasw
Ge0rG, for all X-* headers? ;-)
jonasw
(blanket-allowing X-* is a bad idea though, IMO)
Ge0rG
jonasw: this is why I wrote "closed" :P
Guushas left
Ge0rG
jonasw: yes, blanket-allowing X-* is bad. But less bad than blanket-allowing *.
MattJ
A whitelist makes the feature next to pointless, if the point was to allow arbitrary 3rd-party upload protocols
jonasw
that
SamWhited
Agreed.
jonasw
Ge0rG, I’d argue that an overly-open whitelist is worse than "*"
Ge0rG
A blacklist is worthless as well, due to the complexities and lack of standardization of HTTP.
SamWhited
Also agree.
MattJ
If we're really worried, we can solve it by just ("just") having the client enforce the same same-origin policies a browser would
jonasw
MattJ, you mean "none"?
Ge0rG
MattJ: awesome idea. because same-origin works so well on HTTP already?
jonasw
POST/PUT can be sent cross-domain
MattJ
Ge0rG, imagine a world without it
MattJ
jonasw, since when?
jonasw
MattJ, at least with <form/>
Dave Cridlandhas left
Ge0rG
MattJ: a world without cross-origin scripting? It would be great!
MattJ
jonasw, ah, but you can't send custom headers that way, at least
Ge0rG
so we need to disable custom headers in 0363. QED.
jonasw
MattJ, true
MattJ
for not-same-origin?
jonasw
not-same-origin will ~always be the case with s3, won’t it?
MattJ
CNAME
jonasw
does that work?
jonasw
with Host header etc.?
Fabianhas left
jonasw
.oO(CNAME and set Host header. bazinga)
MattJ
Yes, you can serve any domain from S3 with the right configuration and DNS records
Ge0rG
the problem with CNAME will be one of HTTPS certificate validation
MattJ
Amazon handles this for you, not an issue
jonasw
MattJ, amazon maybe, but $non-amazon-cloud-provider object storage?
jonasw
do we want to pin people to amazon with that rule?
SaltyBones
I'm in no way an expert on the matter but https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy clearly says "Cross-origin writes are typically allowed" and https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest has a function "XMLHttpRequest.setRequestHeader()"
MattJ
You're not pinning them to Amazon - any provider can use Let's Encrypt for example, if you point a CNAME at them
la|r|mahas joined
jonasw
MattJ, yes, but I bet not many do
MattJ
jonasw, this is not a protocol problem
jonasw
MattJ, yes, but .....
MattJ
Delegating to a third-party is something people (rightly) want to do. It can be done.
jonasw
do we need to make it harder for people?
SaltyBones
So it seems to me, like what we are trying to prevent, can be accomplished with JS in a w ebsite...
MattJ
They don't have to do this, it's optional
SamWhited
hmm, this seems sensible at first glance. It does limit what you can do with the upload, but it does seem desirable from a security standpoint and the drawbacks aren't that severe. It moves the place you define trust to DNS, which is how xmpp does things anyways.
Dave Cridlandhas left
daniel
but same origin doesn't protect you if your own server is bad
jonasw
hmm
daniel
they could just point a cname to 192.168. something
SamWhited
you have to trust your own server anyways
jonasw
SamWhited, in that case the whole discussion is moot and we can just allow arbitrary headers!
jonasw
daniel, +1
daniel
SamWhited, the entire debate is about not trusting your server
Guushas left
SaltyBones
Can somebody tell me why what we are trying to prevent is NOT something that JS on websites can do?
SaltyBones
In other words, something that is "somebody elses problem".
Ge0rG
daniel: pointing a cname to 192.168.x.x won't give you a valid certificate.
Ge0rG
SaltyBones: modern browsers will use CORS to prevent cross-origin POST/PUT
Ge0rG
SaltyBones: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
> Additionally, for HTTP request methods that can cause side-effects on server's data (in particular, for HTTP methods other than GET, or for POST usage with certain MIME types), the specification mandates that browsers "preflight" the request, soliciting supported methods from the server with an HTTP OPTIONS request method
Dave Cridlandhas left
Dave Cridlandhas left
SaltyBones
Ge0rG, CORS is a way so circumvent the SOP and the SOP is what I quoted above as not protecting you against cross origin writes...where is the error?
jonasw
SaltyBones, because you read "typically" as "always"?
SaltyBones
jonasw, but this is enforced in the browser not per site, right?
jonasw
SaltyBones, https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Preflighted_requests
> In particular, a request is preflighted if any of the following conditions is true:
> * If the request uses any of the following methods:
> * PUT
MattJ
It's enforced in the browser. In our discussion, the XMPP client is in the place of the browser
jonasw
I think that is pretty clear
jonasw
so SaltyBones, if e.g. your plastic router instructs the browser to reject cross-origin POST requests, it would be safe with modern browsers.
jonasw
but it would not be safe against HTTP-Upload
Ge0rG
MattJ: so we need to mandate the XMPP client do an HTTP OPTIONS call to the server and to check CORS
uchas joined
jonasw
Ge0rG, noooooooooooooooooo
MattJ
> 13:19:49 MattJ> "Let's use HTTP because it's simple"
Ge0rG
I'll -1 the XEP until this is mandated, or until I'm kicked out of Council.
MattJ-1's Ge0rG
jonasw-1's HTTP
jonasw
I think that’s the right course of action anyways.
MattJfirst performs an OPTIONS request to verify he's allowed to -1 Ge0rG
Ge0rG
MattJ: you are not.
Guushas left
intosi
303 Pull the other one
Dave Cridlandhas left
jonasw
Ge0rG, what about my "if a thing breaks by unauthenticated plaintext, it is that things fault"?
Dave Cridlandhas left
Alexhas joined
Ge0rG
jonasw: talk to a BigCorp CSO and explain that to them, and how their "trusted core network consisting of the datacenter and the office network" must be fixed yesterday.
Alexhas left
jonasw
SamWhited, my feeling is that "trust your serevr" is not applicable here, because this is a different level of privilegue. I trust my XMPP server to handle my IM, but I wouldn’t trust it with remote code execution on my client. Likewise, I’m not sure I’d trust it with "arbitrary" network access.
Dave Cridlandhas left
jonasw
Ge0rG, why the hell would you allow people to run XMPP clients in your trusted core network?
valohas joined
jonasw
or any not thoroughly audited software for that matter
jonasw
if it’s so crucial to your operations and there’s no additional layer of authentication except being in that network.
Ge0rG
jonasw: because Gajim portable and Direct-TLS on :443
jonasw
don’t allow removable drives?
Ge0rG
don't allow The Internet?
jonasw
on the same note, why would you allow people to accsss the intenet at all from that network. you’re doing it very wrong in that case.
jonasw
yeah
SamWhited
You're alreadytrusting that by virtue of connecting to a thing in an srv record.
jonasw
SamWhited, but it can’t control what contents I send there, except for its domain name
jonasw
and even that it can’t really controll
jonasw
while HTTP Upload does let it control a substantial part of the content I send
SamWhited
fair
jonasw
so, strawman proposal: what about we make a disco#info form or something which tells the client which headers will be used by a given upload service. They can then decide whether to use that service at all (before showing in the UI that an upload would be possible, thus improving UX in the "no, that’s not okay" use case). And then clients can keep their own whitelist, while we recommend a whitelist in the XEP which contains Authentication, Cookie, Cookie2 (maybe?), and whatever S3 needs
Dave Cridlandhas left
Ge0rG
jonasw: please don't.
jonasw
mention the trade-offs clearly in the security considerations, too
jonasw
Ge0rG, why not?
Ge0rG
jonasw: the client can't decide that, and the user even less so.
jonasw
how can we decide what the client can’t decide?
Ge0rG
jonasw: the client can't decide anything.
danielhas left
Guushas left
Flow
Ge0rG, it's hard to follow your arguments when you don't provide an explaination
Dave Cridlandhas left
jonasw
I’m fine with allowing any header then, I think. Most havoc can be wreaked (on the web side, which is why we have CORS etc.) due to cookies
jonasw
and existing sessions
jonasw
which isn’t applicable here
Ge0rG
Flow: which argument do you want explained?
Flow
Ge0rG, why can't the client decide which headers to use or not?
Ge0rG
Flow: because client developers are already incapable to securely implement IQs, Carbons and XHTML-IM. I'm a full-time IT security consultant and I have a hard time figuring out which HTTP headers might have malicious side-effects.
andyhas joined
Dave Cridlandhas left
Ge0rG
Flow: a client doesn't know if it runs in a "secure network" of some sort
Flow
got it, thanks
Ge0rGhas left
Ge0rGhas left
daniel
Ge0rG, could you name one header that can cause bad side effects? (something that couldn't be done with the URL)
daniel
(assuming the headers are stripped of \n which I already agreed to)
Ge0rG
daniel: sending a mismatching `Host` header will confuse middleboxes.
jubalhhas joined
Dave Cridlandhas left
Guushas left
Ge0rG
a `Connection` header might at least confuse the server, causing a small DoS
daniel
a middle box that mitm https?
Seve/SouLhas joined
Ge0rG
daniel: yes, that's a common setup at BigCorps
danielhas left
Ge0rG
We could also require an Origin header to be set to the HTTP-Upload component name, cf. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Origin
Ge0rG
But this is less strong than any enforced filtering
Dave Cridlandhas left
jonasw
Ge0rG, that concurs with my argument "do not let the server override any header you’re setting yourself"
pep.
Let me jump in an propose a jingle-ft component on the server to counter http-upload :-°
jonasw
both Connection and Host would typically be set by the client (one due to how the lib works, one from the URL)
pep.is waiting for the stick
jonasw
pep., do it
Ge0rG
jonasw: "typically"
daniel
> Ge0rG, that concurs with my argument "do not let the server override any header you’re setting yourself"
that by the way i'm fine with and i'm actually implemting this in Conversations right now
Ge0rG
jonasw: do you know from memory which HTTP headers are set by your favorite http client library? And which of those can't be overridden?
pep.
jonasw, I wish I had the knowledge and time for it, but yeah I've heard ideas here and there about this already
Dave Cridlandhas left
Ge0rG
jonasw, daniel: so what you are doing is the blacklist approach.
daniel
in that case yes
daniel
although it is not a fixed blacklist
Ge0rGhas left
Ge0rGhas left
SaltyBones
Proposal: We ditch alls this in favor of something that ONLY supports what amazon s3 does
SaltyBones
Which hopefully should be easy to tighten...
SaltyBones
This gives people the option to 1. Use S3 2. Use their XMPP server 3. Emulate one of two API
intosihas left
intosihas joined
Dave Cridlandhas left
MattJ
Except that I wanted to experiment with using Dropbox/NextCloud/etc. as upload services
MattJ
and neither mimic S3
andyhas left
stefandxmhas joined
daniel
MattJ, maybe do your expirments and see what headers they require? probably most of them will just use authorize anyway?
daniel
in which case instead of allowing header we could just allow authorize or something
SamWhited
I really want to try Joyents blob file storage with the Content-MD5 header.
SamWhited
Also allowing the server to set the durability-level header which indicates the number of backups in different regions that are required.
moparisthebesthas joined
Ge0rG
SamWhited: that sounds like a _very special_ special case.
daniel
SamWhited, that sounds a bit dangerous to give the client control over that?
MattJ
daniel, I don't know about Dropbox, but NextCloud is either basic auth (if you don't mind sharing credentials with your server) or cookies
SamWhited
Not especially; they could cost me a tiny bit more money by having the max replication factor all the time, or not have backups of their own files
SamWhited
But yah, fair enough, that's a special case.
daniel
MattJ, then maybe authorize and cookie
Holger
FWIW, being able to set an X-ejabberd-something header would be very useful for me.
Ge0rGhas joined
Ge0rG
daniel: I could live with `Authorization` and `Cookie` being the only whitelisted headers.
Holger
(Or without the "X-", IIRC today's youth dislikes that?)
Ge0rG
Holger: what for?
Holger
Ge0rG: Mapping the HTTP request to a virtual host (configuration).
MattJ
Dropbox is also Authorization it seems
daniel
the thing is that i wasn't the one who wanted headers in there in the first place
Ge0rG
Holger: you are doing it wrong.
Dave Cridlandhas left
daniel
so it's hard for me to argue for either one side
Holger
Ge0rG: How to do it right?
Ge0rG
Holger: use the Host header to route to virtual hosts? :P
Holger
No.
Holger
Or well.
Dave Cridlandhas left
Ge0rGhas joined
Dave Cridlandis just thinking this is definitely more complex than the Security Considerations of the XEP makes out.
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
daniel
I mean if we white list only cookie and auth you could set a cookie Holger
Ge0rG
Holger: on your own infrastructure you could also `PUT https://yourserver.com/yourxmppdomain/random/random.jpg`
jubalhhas left
daniel
If you don't want to use the vhost
Holger
Ge0rG: That works if you have an 1:1 mapping between HTTP 'Host' and virtual hosts of course, but admins will spam your tracker if you impose such restrictions.
daniel
Or what Ge0rG said
Holger
Yes I suggest such things in the docs.
Guushas left
Holger
Still tracker spam :-)
SamWhited
I'm not sure the whitelist really works; as soon as we do that most signing schemes break. Eg. Joyents requires Host, Amazon's requires that you specify headers to sign up front, I think and has a handful that it always requires.
Holger
daniel: Yes I could probably abuse Auth/Cookie headers.
Dave Cridlandhas left
SamWhited
And if we're really worried about invalid headers from a malicious server, having any headers at all is a problem (though as I said, I'm not convinced we should be worried about that)
Holger
I'm just saying that I doubt we'll come up with all possible use cases in here.
daniel
> I'm not sure the whitelist really works; as soon as we do that most signing schemes break. Eg. Joyents requires Host, Amazon's requires that you specify headers to sign up front, I think and has a handful that it always requires.
Can you find out what exactly it requires?
SamWhited
Yah, just a moment, I hate looking at the S3 docs (which are terrible) so I was being lazy and looked up Joyents instead.
Holger
So the idea now is to cope with a few services that are popular today and just hope for the best that the next one will use the same headers?
Alexhas joined
SamWhited
a bunch of x-amz- headers, otherwise I'm having trouble finding info.
SamWhited
But what Holger said.
suzyohas joined
Ge0rG
So it's ["Cookie", "Authorization", "X-*"]
Holger
...
Dave Cridlandhas left
SamWhited
I'm still not sure what problem we think we're solving with this.
SamWhited
Amazon also does Host and User-Agent at least, I think
SamWhited
Although User-Agent makes no sense to me, so maybe this is wrong
daniel
SamWhited, the user agent has to be set to something specific?
SamWhited
I'm reading this page, and being confused: https://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html
SaltyBones
SamWhited, the problem we are trying to solve is that we are currently giving the server the possibility to trigger arbitrary HTTP requests from the client.
daniel
oh signed
daniel
i get it
SamWhited
SaltyBones: that is not a problem description. Why is that bad?
SamWhited
I know we've been through this, but I'm just not sure that it's actually a problem and am trying to figure out if it would really cause any security issue.
SaltyBones
SamWhited, I'm not convinced that it is but Ge0rG's link does suggest otherwise.
Ge0rG
SamWhited: that signature needs to contain the content md5. I can't see how you can make a client generate that header.
Dave Cridland
[[ 20 minutes until Council, BTW ]]
SamWhited
Does it? I know I've made amazon work before, but yah that doesn't seem like it can be supported easily without additional modifications
SamWhited
SaltyBones: his link was about malicious invalid headers, right? (I lost it, sorry, no search in any of my clients) This doesn't solve that (again, if it's actually a problem in our case)
stefandxmhas left
Ge0rG
SamWhited: the signature also depends on YourSecretAccessKeyID, which I'm sure you don't want to leak to the client.
SamWhited: so either the xmpp server needs to have the MD5 in advance or you are doomed.
SamWhited
Ge0rG: that's fine, you can generate one per request
intosihas left
SamWhited
But yah, MD5 is a problem. It might not always be required though, because I know I've made this work before
intosihas joined
Dave Cridlandhas left
Guushas left
suzyohas joined
Dave Cridlandhas left
lskdjfhas joined
waqashas joined
pep.has left
tuxhas left
MattJ
SamWhited, I think it's optional, in that I think if you don't provide the header you just put an empty string in the string-to-sign
Dave Cridland
By the way, if anyone wants to take some minutes for the Council meeting (in a few minutes from now), that'd be tremendously useful.
Dave Cridlandhas left
Ge0rGhas left
blablahas left
andyhas left
vanitasvitaehas left
MattJ
SamWhited, and at this point... it looks like S3 allows putting everything into the query string? :)
vanitasvitaehas joined
Ge0rGhas left
Ge0rGhas left
Ge0rGhas left
Ge0rGhas left
Ge0rGhas left
Ge0rGhas left
Ge0rGhas left
Ge0rGhas left
SamWhited
That's useful, I didn't realize that. I would prefer not to put auth in the query string either way though.
Ge0rGhas left
Ge0rGhas joined
Ge0rGhas left
SaltyBones
Why?
Ge0rGhas left
jubalhhas joined
Ge0rGhas left
SamWhited
Because it's generally accepted best practice that you don't. Things log URLs and it's acceptable to do so, they don't generally log headers (because that's generally where you put things you don't want logged like this)
tuxhas joined
Dave Cridlandhas left
Dave Cridland
[[ Council time over in council@muc.xmpp.org ]]
goffi
pep.: I have a server side jingle-ft component
pep.
goffi, !
pep.
Is it in a working state
goffi
I'm currently working on it, but it's already working yes
pep.
Also, there's no XEP for that right? Or how much is it covered by the current XEP?
goffi
the XEP is jingle FT
goffi
instead of sending to an other client, I send to the component
goffi
nothing else to do
tuxhas joined
Dave Cridlandhas left
SaltyBones
and then the server offers it via httpupload or again jingle?
pep.
Sure but then you can do things with your component you can't do with clients
pep.
You can use your component to proxy the transfer, to retry when the other contact is back online etc.
pep.
Or just serve the file
SaltyBones
I'm not complaining just trying to figure out what's happening. :)
goffi
SaltyBones: I'm on this part currently, implementing XEP-0329, but I'm not happy with it, I plan to write a feedback on standard@ about that
pep.
SaltyBones, jingle
pep.
I hope
pep.
I don't see the point of http-upload here
pep.
It's not unfeasible though, the component could serve via http as well
goffi
I'm saying that since HTTP upload is on the table. The only interest is has, is that it's easy to implement when jingle is not yet implemented in a library
goffi
but once you have jingle, it's more easy to do this way.
Dave Cridlandhas left
andyhas joined
goffi
and with namespace delegation, you can even send fileto your bare jid, you don't even need to find the component. I've not done it yet, but it's in my TODO
jjrhhas left
Dave Cridlandhas left
blablahas left
blablahas left
blablahas joined
jubalhhas left
Ge0rGhas left
Dave Cridlandhas left
jubalhhas joined
jubalhhas left
Dave Cridlandhas left
Guushas left
Guushas left
Dave Cridlandhas left
efrithas joined
jjrhhas left
jjrhhas left
jubalhhas joined
Dave Cridlandhas left
Dave Cridlandhas left
lumihas joined
la|r|mahas joined
Kevhas left
Dave Cridlandhas left
jubalhhas left
blablahas left
SaltyBoneshas left
rionhas left
Dave Cridlandhas left
jjrhhas left
blablahas left
Dave Cridlandhas left
tim@boese-ban.dehas left
Dave Cridlandhas left
andyhas left
Dave Cridlandhas left
Ge0rGhas left
Dave Cridlandhas left
tuxhas joined
blablahas left
Guushas left
efrithas left
efrithas joined
Guushas left
Guushas left
stefandxmhas joined
lskdjfhas joined
Dave Cridlandhas left
lovetoxhas joined
Guushas left
pep.has left
Dave Cridlandhas left
Kevhas joined
jubalhhas joined
Dave Cridlandhas left
stefandxmhas left
Dave Cridlandhas left
andyhas joined
Dave Cridlandhas left
SaltyBones
message-id question: why can't we use a counter
SaltyBones
I have heard: 1. State keeping is impossible, 2. Attacks based on guessing the id but I'm not convinced that either is a real thing.
la|r|mahas left
Dave Cridlandhas left
SamWhited
State keeping is very difficult if you have a cluster. Your counter has to be centralized and atomic, which rather defeats the purpose of having a cluster.
SaltyBones
can I PM you for discussion? I don't want to spam this channel all the time :)
SamWhited
Message me directly please (sam@samwhited.com); none of my clients handle PMs well.
SamWhited
Though this is probably good discussion and I don't think you'd be spamming this channel :)
Dave Cridlandhas left
jerehas left
jerehas joined
Dave Cridlandhas left
andyhas left
Dave Cridlandhas left
pep.has left
@Alacerhas left
waqashas left
@Alacerhas joined
@Alacerhas left
@Alacerhas joined
Dave Cridlandhas left
Kevhas left
jerehas joined
jerehas joined
Steve Killehas left
Dave Cridlandhas left
Dave Cridlandhas left
jjrhhas left
blablahas joined
Dave Cridlandhas left
Steve Killehas joined
Tobiashas joined
andyhas joined
Dave Cridlandhas left
jonasw
yeah
jonasw
I’d prefer such discussions here too
jonasw
most of the time they’re insightful
Dave Cridlandhas left
waqashas joined
intosihas left
andyhas left
Dave Cridlandhas left
jubalhhas joined
moparisthebest
SaltyBones, state keeping client side is impossible too
andyhas joined
moparisthebest
see: vm snapshots
moparisthebest
(server side also)
Dave Cridlandhas left
Dave Cridlandhas left
andyhas left
Dave Cridlandhas left
jjrhhas left
andyhas joined
Guushas left
jjrhhas left
Dave Cridlandhas left
lskdjfhas left
andyhas left
la|r|mahas left
andyhas joined
Dave Cridlandhas left
rionhas joined
Guushas left
Dave Cridlandhas left
jjrhhas left
jjrhhas left
Seve/SouLhas left
Seve/SouLhas joined
Seve/SouLhas left
Seve/SouLhas joined
ralphmhas joined
Dave Cridlandhas left
jjrhhas left
stefandxmhas joined
Dave Cridlandhas left
Syndacehas left
Syndacehas joined
rionhas left
rionhas joined
Dave Cridlandhas left
efrithas left
jerehas joined
Dave Cridlandhas left
Guushas left
Dave Cridlandhas left
lskdjfhas joined
Dave Cridlandhas left
efrithas joined
lumihas joined
lskdjfhas joined
rionhas left
Dave Cridlandhas left
Dave Cridlandhas left
stefandxmhas left
Dave Cridlandhas left
Dave Cridlandhas left
Guushas left
Dave Cridlandhas left
Guushas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
Guushas left
Dave Cridlandhas left
Ge0rG
We could also discuss why MUC-PMs are still broken in some clients :>
SamWhited
They're just broken in general whichever model you take for them. There are tradeoffs both ways.
Dave Cridlandhas left
Ge0rG
They are broken in poezio, but it seems that once you explain to a reasonable developer how to implement them, they magically start working.
Ge0rG
At least it's a problem that's easier to solve than MUC reflection matching
efrithas left
efrithas joined
Guus
Ge0rG: are they more broken than UI's not being aware to check if PMs are permitted in the room?
nycohas left
Dave Cridlandhas left
SamWhited
Guus: you either have what Conversations / Mcabber do where they're mixed in with room traffic and you constantly accidentally send things you meant to be a PM to the room, or they're separate conversations in which case they look like 1:1's except a lot of stuff you'd expect to work just doesn't because they're actually MUCs.
SamWhited
Also if they're mixed in with the room it's just hard to follow a conversation by PMs if there's also room chatter going on.
Dave Cridlandhas left
Dave Cridlandhas left
Ge0rG
Guus: that should be solved by properly augmenting outgoing messages with their error bounces
Ge0rG
SamWhited: I think that daniel's take at integrating PMs into the MUC is a conscious effort to make them unusable ;)
Ge0rG
Besides of not working when you are not in the room, and most clients getting MUC-PM Carbons wrong, my experience is that they work just like normal messages, except you don't know the actual JID of the receiver.
SamWhited
Ge0rG: as opposed to having them being separate conversations? That's almost as unusable, just for different reasons. Especially since if the person changes their nickname it immediately breaks everything and makes the world a confusing place.
daniel
> Besides of not working when you are not in the room,
or the recipient.
but yes not working messages. pretty minor
Ge0rG
SamWhited: a smart client would probably implement nick change tracking, but that doesn't work well for history.
Holgerhas left
Ge0rG
SamWhited: but as opposed to nickname wars from the IRC days, people have pretty constant nicknames today.
daniel
it's almost perfect. expect. you know. messages don't work if the recipient drives through a tunnel
SamWhited
Right; MUC PMs in general are just a bad experience, no matter how you slice it.
Dave Cridlandhas left
Ge0rG
I don't know. My experience with them has been better than with some MUCs, and even better than with direct messages in some corner cases
daniel
and yes. making the UX bad in Conversations and 'hiding' it behind a long press is an attempt to guide people to send regular messages
Ge0rG
daniel: except people botch it all the time and send private things in public by accident
blablahas left
Ge0rG
daniel: it's okay to hide them, but please don't make them easy to mis-use
andyhas left
Dave Cridlandhas left
Dave Cridlandhas left
Holgerhas left
Holgerhas left
Neustradamushas left
Neustradamushas joined
marchas left
marchas joined
Ge0rG
I think that with always on clients and some self-presence checking code they can be made to work pretty well. Bonus points if you keep outgoing PMs stored until the nickname comes back online
daniel
Lol sure. But why?
Dave Cridlandhas left
jonasw
Ge0rG, so I can steal that nicknames PMs?
jonasw
sweet
daniel
The serve no purpose besides annoying me when people think that I help them faster if they pm me
Ge0rG
jonasw: how do you know that I'm me?
jonasw
Ge0rG, I could’ve established that during the conversation.
blablahas joined
Ge0rG
(besides of the obvious one, me being the only person who cares about PMs)
daniel
> Bonus points if you keep outgoing PMs stored until the nickname comes back online
Until you are both online at the same time
Ge0rG
jonasw: I could have left the conversation and been replaced by Mallory at any moment in time during our dialog
Dave Cridlandhas left
Ge0rG
daniel: you can't see their presence if you are offline 😛
daniel
Pretty cool feature these PMs
jonasw
Ge0rG, not with a client which reasonably checks identity
jonasw
i.e. either uses the real JID if available or assumes the worst :>
Ge0rG
daniel: so you are annoyed because your client is popular? Note taken.
daniel
And I could even have four conversations with four different Ge0rGs in four different mucs
daniel
And I wouldn't even know if it's the same Ge0rG
daniel
Pretty fucking awesome
daniel
Plus the regular conversation with the real Ge0rG if have
jonasw
I like what pidgin does (yes, really)
Ge0rG
jonasw: daniel: now you are arguing against anonymous MUCs
jonasw
if it knows the real JID, it’ll just make a conversation with that
daniel
jonasw: execute code remotely?
jonasw
completely circumventing the MUC. and your privacy if real JIDs are only visible to mods, I guess.
jonasw
daniel, hah.
Ge0rG
jonasw [21:11]:
> I like what pidgin does (yes, really)
Who are you and what have you done to jonasw?
Dave Cridlandhas left
Holger
> now you are arguing against anonymous MUCs
Go go go!
Holger
Once we ditched anon MUCs, there's clearly no point anymore in keeping MUC PMs, is there?
jonasw
we might need to solve the SPIM issue first.
jonasw
or also ditch public MUCs in general. and even then I’m not convinced that this is a good idea.
Zash
Solve you say?
daniel
maybe we need a small protocol where you can ask someone for their real jid . or give them your real jid. sort of like an invite to chat 1:1. and the other person can accept or decline
jonasw
Zash, yes.
Ge0rG
Holger: tell that to the people who created MIX proxy JIDs.
Holger
jonasw: Yes my suggestion is ditching public MUCs.
jonasw
Holger, hm.
daniel
so clients could render that as Ge0rG (georg@domain.tld) wants to talk to. is that cool?
jonasw
Holger, what IM system would you propose as support channel for, say, prosody, then?
Dave Cridlandhas left
Holger
jonasw: Or keep them the half-broken way we have them now. That's good enough for the few of us who use them.
Holger
jonasw: IRC.
jonasw
ugh
Holger
Ok, Matrix :-)
jonasw
Holger, okay, if we agree on that, we could "just" solve that with UX
SamWhited
Maybe we ditch anonymous mucs, and then if you need to be anonymous your server could issue you with some sort of temporary JID that you could use. Some sort of "burner" jid, maybe. (actually, there were reasons this wasn't ideal, but I forget what they were every time this conversation happens)
Ge0rG
SamWhited: didn't you even write a strawman xep for that?
Ge0rG
BTW, was MIX even mentioned at the summit?
Seve
Heh..
Holger
Or just register an anon JID manually if you need that.
jonasw: Rather than investing time in fixing PMs we should fix that multi-account story!
Ge0rG
SamWhited: the only problem with burner JIDs is that they are free and nobody can block them
andyhas joined
jonasw
Holger, I tend to agree
Ge0rG
So all we need to do is a PoW attached to creating them!
jonasw
I’ll... just ... stop following that discussion at this point.
SamWhited
Ge0rG: yah, there needs to be some better policy or access control around them, but there didn't seem to be enough interest for that to be developed.
Ge0rG
Do I hear blockchain m
Guushas left
SamWhited
But it's no different than people running their own server that they could add tons of JIDs on really, and public servers can certainly rate limit since it requires authentication to get a burner JID
SamWhited
Servers could even say that burner JIDs aren't allowed to federate, so they could only be used for MUCs on that server (in which case you could also allow them with SASL-ANONYMOUS)
Dave Cridlandhas left
Ge0rG
SamWhited: now this is a really useful idea. I'm running a non federated anonymous server for support MUC purposes on my domain.
SamWhited
Ge0rG: yah, I do the same, that could be a burner JID service as well and just don't allow burner JIDs to send to stuff on other domains to prevent spam.
jonasw
daniel, IIRC, when zinid announced that he was working on the MUC bare-presence thing, you asked whether it’d include disco#info caps. Why did you ask for that? Which part of a MUCs disco#info do you need?
Ge0rG
SamWhited: I'd say your last proposal is sufficient to kick all that proxy JID stuff from MIX.
Dave Cridlandhas left
SamWhited
Ge0rG: there was some reason that it wasn't that I think I ended up being convinced by, but I can't remember what it was.
efrithas left
SamWhited
But I would love it if we just ignored anonymous MUC and that was handled out of band, by my proposal or something else.
SamWhited
Anonymous identities are useful for more than just chat rooms, so it doesn't make much sense to me that it should be part of the groupchat spec and only useable there.
daniel
jonasw: mhhh I guess I don't really *need* it. I think I always query the muc anyway to get a response and avoid server not found et al. But I do work with the non anonymous, members only feature
efrithas joined
daniel
And the form field that tells me if users are allowed to write pms and set the subject
jonasw
daniel, okay, so you essentially need the Form :/
daniel
Which currently doesn't provide the information I need anyway on ejabberd...
Ge0rG
daniel: you should write an xep (or a new section for 45) on how to properly create a private MUC
goffihas left
daniel
jonasw: yes. I'm aware of ejabberd putting in the member count though... Which makes that difficult...
Dave Cridlandhas left
Dave Cridlandhas left
jonasw
daniel, so that use-case wouldn’t profit from splitting the caps hash into identities+features and forms
jonasw
pity
daniel
Other than that a lot of my conferences are configured the same. And having a caps hash would actually minimize the traffic a bit
jonasw
daniel, but only if the occupant count isn’t in there
daniel
Yes
jonasw
and if it isn’t, it probably doesn’t matter a lot if we split the hashes because MUCs generally don’t have a very diverse feature set I assume
Ge0rG
I'm displaying the occupant count in MUC invitations... 🤔
andyhas left
jjrh
Is there not a way to set a MUC to show everyones full JID?
Because this issue is more of a annoyance in 'trusted' places - aka internal chat where there is no reason I shouldn't know you're JID and when I click your name in group chat (as a lazy way to send a PM vs going to my roster) it should do the right thing.
daniel
jonasw: fwiw the split of what muc puts into features and the form is pretty weird and confusing anyway
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
daniel
And the naming of the features as well
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
moparisthebest
I quite like that burner jid thing
moparisthebest
what were the downsides again SamWhited ? (or whoever)
Dave Cridlandhas left
SamWhited
I wish someone would remind me, but I do remember being convinced that it wouldn't work for MIX ¯\_(ツ)_/¯
Alexhas left
jjrh
beh i'm dumb, I didn't know showing jids was a option in room configuration that probably solves /my/ issue at least.
Dave Cridlandhas left
Dave Cridlandhas left
stefandxmhas joined
jjrhhas left
Dave Cridlandhas left
Dave Cridlandhas left
moparisthebest
SamWhited, oh, because burner JIDs aren't shared across devices?
moparisthebest
which basically means multi-device can't work
moparisthebest
so what if you essentially just solved the alias problem while you are at it?
Dave Cridlandhas left
moparisthebest
a XEP that gives 'burner JIDs', except rather than being extra logins, the server just delivers all messages to that JID to your account, and you can also send things as that JID, same connection
moparisthebest
it would be a bit complicated, but would solve the alias problem *and* the anonymous muc/mix/future mux/whatever problem
Dave Cridlandhas left
jonasw
if multi-device doesn’t work, I’d be pretty unhappy wtih that
Syndacehas left
Syndacehas joined
Dave Cridlandhas left
stefandxmhas left
efrithas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
danielhas left
danielhas left
danielhas left
Dave Cridlandhas left
danielhas joined
Dave Cridlandhas left
brahas left
Dave Cridlandhas left
Syndacehas left
Syndacehas joined
andyhas joined
Dave Cridlandhas left
intosihas joined
Dave Cridlandhas left
jubalhhas joined
danielhas left
Dave Cridlandhas left
SamWhited
yah, that's probably it; multidevice seems like a must. I actually had it that way originally before someone reminded me that SASL provides an authorization identity; mixing the two streams felt *really* dangerous to me though.
andyhas left
SamWhited
The server could always issue the same burner JID to all of your devices though.
Dave Cridlandhas left
danielhas joined
Alexhas left
Alexhas joined
Dave Cridlandhas left
valohas left
valohas joined
Dave Cridlandhas left
danielhas left
danielhas joined
Dave Cridlandhas left
Tobiashas left
moparisthebesthas joined
SamWhitedhas left
jubalhhas left
Dave Cridlandhas left
Dave Cridlandhas left
Ge0rG
Burner could work as a jabber transport as well.
SamWhited
Ge0rG: I didn't understand that?
suzyohas joined
Dave Cridlandhas left
Tobiashas joined
stefandxmhas joined
andyhas joined
Dave Cridlandhas left
Ge0rG
SamWhited: implement it as an xmpp 2 xmpp transport...
Ge0rG
Would give us roster control and the ability to unsubscribe and obtain a new identity
SamWhited
I don't think a second JID would help you with that, you still need the client and server to speak the protocol. I suspect I'm missing something though
SamWhited
oh, not 'xmpp2 to xmpp transport'
SamWhited
I am still not sure how it helps or what use an xmpp to xmpp transport is though
lskdjfhas joined
SamWhited
Different identities in your roster I'll grant, although merging rosters is weird UI wise
andyhas left
Dave Cridlandhas left
SaltyBones
I postulate that all of this is caused by people wanting to use the same software for private chats and anonymous public chats. There is surprisingly little overlap in terms of both functionality and UI.
SamWhited
I tend to agree
SaltyBones
Also, people don't understand how any of this works anyway. If we completey drop anonymous JIDs it will be strictly better because nobody even understand what the benefits are or when they apply so they cannot make use of them. :p
blablahas joined
Zash
More or less public chats are what we use XMPP for ourselves. Don't underestimate that use case.
SaltyBones
Zash, what do you mean by more or less public chats?
Zash
SaltyBones: This very room for example.
SaltyBones
This room could have JIDs of everybody and nobody would care...
Zash
I would, I'm not entirely comfortable with random people being able to contact me out of band just becasue I join a room.
Zash
Not that my JID is secret
SaltyBones
That's imho a matter of spam handling
blablahas left
Dave Cridlandhas left
Zash
I don't mean because of spam
SaltyBoneshas left
Dave Cridlandhas left
SamWhited
I can see anonymity being useful, I just don't think it makes sense to lump it in with grouochat.
SamWhited
groupchat, even.
Zash
In the prosody support room, the intention is for people to ask the room, so that someone who has time and will can reply and help. Sometimes they instead go directly to PM someone, which can create some amount of stress over not being able to shift the work to others.
jjrh
While I set everyone to who may discover JID's, clicking someones name still creates a message in the context of the MUC instead of a direct message. This is with Gajim but i'm guessing this is a issue with other clients.
Tobiashas joined
SaltyBones
Zash: so you re saying it is already as bad as if there were no anonymous IDs? ;)
Dave Cridlandhas left
Dave Cridlandhas left
jjrh
Zash, it's not just stress - chances are the answer is probably useful to others. :)
Zash
That too
jjrh
MUC message threads in a smart UI would be really cool on high volume channels where multiple questions/discussions are going on at the same time.
Zash
There was a client that did that, IIRC. Vacuum-IM perhaps?
Zash
There was one (mabye the same) that did #hashtags that let you filter on that as well.