XSF Discussion - 2021-12-28

hi everyone. I wanted to make some editorial changes to my pull request, regarding the xml schema in xep 0353,but I'm not sure if I understand xml schema sufficiently enough to do the right thing.

https://github.com/tmolitor-stud-tu/xeps/commit/ea90fd54c063c341ae41586901fb1d6b841a8048

the reason element is copied over from the main jingle xep, but I want to reference the jingle schema and use it rather than copying the parts needed over to xep 0353. Is my commit correct or did I make some xml schema mistakes?

jonas’

I don't speak XML schema very well myself, but I'll take a look when I look at the PR

due the recent "superseed" changes to the XEPs, I became aware that we are probably missing a nice disclaimer that this XEP is superseeded by another in the XEP header (you know, just like RFCs / I-Ds have such a thing)

hmm it's probably not so hard to xslt such a thing™

> https://xmpp.org/extensions/xep-0403.html#usecase-iq-relay > The MIX channel will modify the JIDs in the outgoing message, so that the 'to' is the full JID of the recipient Last time I checked, MIX room members are registered by their bare jid not full jid. How is this supposed to work?

> https://xmpp.org/extensions/xep-0403.html#usecase-vcard > The MIX service will then address the vCard request to the user's server (using bare JID) So the MIX service will need to have special handling for vCard and not just handle it like every IQ?

I kinda get the feeling that MIX replicates all the dirty quirks we already have in MUC implementations today rather than fixing them properly...

larma, not that I know the answer, but is the MIX server maybe subscribed to the user's presence?

And what happens when you have two devices online?

magic :)

> MIX replicates all the dirty quirks we already have in MUC

but yes, that seems to be fragile and maybe it should be clarified that it only works under certain conditions

Maybe just accept that IQs are not meant for (semi-)anonymous groups?

and vCards

I can only assume that the authors intention was to allow for certain established use-cases

I mean... vCards are literally about sharing your personal details which is the opposite to staying anonymous...

B- but muh muc avatar!

larma, I am curious what you have in mind what "fixing them properly" could mean here

Either allow the sender to decide which resource/device the IQ should be sent to (or that it should go to the bare jid) or just don't do IQs. If you want vCards or avatars in semi-anonymous groups, allow users (optionally and per room) to upload those to the group server.

> If you want vCards or avatars in semi-anonymous groups, allow users (optionally and per room) to upload those to the group server. This sounds like it'd also fix the one-vcard-many-rooms problem (having different avatars & stuff in different rooms). Awesome

yep, I think that would be an improvement, but also complicates the protocol. not sure if it's worth it, I currently tend to be happy with IQs not working in semi-anonymous rooms

however, people want avatars everywhere, even in semi-anonymous rooms where they could be a way to de-anonymize them…

flow, that's probably because most people don't care if they are semi-anonymous in the room

Yea, avatar is like an extension of nickname

I mean, you are also writing on public mailing lists without anonymity.

Matrix seems to make that assumption too, which numerous xmpp users take issue with (me incl.)

I'm not against semi-anonymous rooms, just that we either should keep that promise or give it up. not the current mix where someone with sufficient resources can deanonymize room members based on vCard and PEP

btw, even if we got rid of semi-anonymous rooms entirely, we still have other means of joining rooms anonymously, like 0383 burner jids

#

larma, not that its the right solution, but the problem goes away we storing your vcard and avatar on pubusb

and making the node only accesible for people you share presence with

that gives people who dont care about anonymity the choice to show their avatar to anyone, and the others not to

if i think about it, no it does not feel right to disallow a service to request private data

you should store your private data in a place where you can set permissions

that xmpp not offered such a place was a lack of the protocol

but it does now

so now its on you if you dont use it

lovetox, the problem does not go away, we still have weirdly broken IQ rules for MUC services. Your suggestion just solves the deanonymisation issues in MUC at the cost of features unrelated to MUCs.

yes thats what i meant, the problem of deanonymisation

this goes definitly away

weird IQ rules, i agree, but i dont see how they hurt people

Let's say I want to share my vCard with everyone that has my JID, but still want to be (semi-)anonymous in MUCs.

please dont invent now use cases

That's not new, that's reality

so store it on pubsub accessmodel=open?

then everybody can request it

but also the muc

if you need fine grained permission management you need to use whitelist

I don't want fine-grained permission management, I want MUCs to not make everything more complicated

and if you really need your use case, then you need to add a new protocol for that

If you go to a public place, you show your face but don't advertise your home address. Like here, avatars shown but not JIDs.

larma, its not complicated, i store my vcard on pubsub so only people I WANT can access it

what is there complicated?

and a MUC is just "people"

To complete Zash's example: If people already know my home address, I'm fine with them being able to ring the bell to discover my face.

yeah valid use case, but i dont see how thats easily possible

the problem with the protocol is that identitys are not easily identifiable

there is no sure way how you even can identify a user account

what you would need is some way to treat requests from a MUC or non-user-accounts, differently

but its still possible with pubsub, but its a burden on the client developer

hm no

no its not possible, you basically want, the world to read your vcard, but not if they share it with others ..

its not in your control what they do after you showed them your vcard

jonas’ do you think I should incorporate my changes into the already open pull request or ceate a new one once the old one was merged?

I also added a disco feature in a separate branch...same question: should I include that n the aleady open PR or should Iceate a new one for this?

lovetox: you are thinking it the wrong way round. You want to restrict access to data for services that forward it to others, when instead we could just get rid of those services.

Because MUCs are the only services that forward data to users that don't have your real jid.

but you cant, this is a decentralized protocol, your approach would be to share your vcard and then say, pretty please dont share it

it would be a solution, but not a very stable one

its a solution depending on developers honoring your wishes

when in reality you want your server to guard your data, and you should be in control with whom you share it

Normally, services don't have my JID except when I explicitly tell them. And I won't tell them when I don't believe they will follow the rules that we agreed on. ✏

Same as with semi-anonymous rooms I believe they won't share my real JID to everyone but just to moderators and admins

so what are you saying? get rid of anonym mucs because they are not really anonym because you cant decide to not share your JID with them?

No, I say clients should stop relying on IQs in MUCs for vCard and avatars, so MUC servers can default to disable IQs

yeah as i said, thats just hoping for developers honoring your wishes

dont know if hope is a good thing to depend on if at stake is your privacy

That's not hope. I already trust servers to follow the protocol. The problem is that the protocol just doesn't provide an important feature here.

feature? nobody forces a MUC to relay IQ requests ?

The standard does

Or at least suggests doing it would be good

And clients rely on it, so they will do

Server developers are not at fault here, they're just doing what client developers ask them to do

> I say clients should stop relying on IQs in MUCs for vCard and avatars, so MUC servers can default to disable IQs

i dont agree with your trust argument, no case comes to mind where i trust a MUC server to do anything

thats why we have e2e

When you join semi-anonymos MUCs that announces to have logs disabled, do you expect it to publish the chat history including your real JID on a website?

no i dont expect it, but that shifts the goal, do you want to fullfill expectations? yes then i agree get rid of IQ routing rules

do you want to have privacy? then this is just a bandaid

im not arguing that iq routing rules are something good here

I want privacy when I join MUC servers where I trust the operators. Like in this MUC.

i just think the vcard case to show it, is not a very good one

but yeah lets do both

use pubsub AND fix routing rules

its nothing that is in opposition to each other

Yep

thilo.molitor, small PRs are nice for review, I can merge them all at once if they fit the requirements – just make sure to *not* include a revision block then

jonas’: okay, thanks :)

XMPP <3

Re 0363, at no place it specifies that HTTP headers are case insensitive, would it be useful to say that?

I took HTTP for granted, but I’m reviewing an implementation which only accepts Title-Case headers.

Link Mauve, what. yeah.

might be worth making it explicit, in addition to the fact that multiple values may be present and that their order must be preserved and they must all be passed to the HTTP server

I couldn’t figure out how to say that in the schema though.

Do we have any other similar case in the protocols?

I don't think so

but The Schema Is Not Normative™ ✏

jonas’, https://github.com/xsf/xeps/pull/1135

order?

Done.

thanks

editor is on vacation until next week though :)

There is no hurry. :)

Editor can take his time, I won’t come knocking to his door all angry or anything.

that's good

thilo: https://github.com/tmolitor-stud-tu/xeps/commit/ea90fd54c063c341ae41586901fb1d6b841a8048#commitcomment-62599720

https://www.yes-www.org/

Esp. <https://www.yes-www.org/why-use-www/>. Then again we redirect www.xmpp.org to xmpp.org.

And it should be https:// I guess. Neustradamus you overlooked that?!?!

Also TLS.

Holger, ^5

🙂

https://xmpp.org/extensions/xep-0166.html

XML Schema for the 'jingle' namespace: <http://xmpp.org/schemas/jingle.xsd>

Everything is broken.

I'm in it to increase web related suffering as revenge for not adopting SRV records! 😉

???

Ellenor Malik, there's SRV records such as `_xmpp-client._tls.example.com` to point XMPP clients to the server handling the example.com domain, which might be `xmpp.example.com`. There's no `_http._tcp` record to point browsers querying https://example.com to the actual server handling that query, e.g. www.example.com. The absence of support for such SRV records is part of the reason why the `www.` subdomain got popular.

;w;

_tls? _tcp even.

There's no HTTP/StartTLS. ✏

Yes, there's HTTPS, which would require `_https._tcp` records, if there was SRV support in the first place.

There was starttls for http somewhere

`Location: https://...`?

Wait, disregard that

It might be useful to add HSTS Preload to our HSTS header, so that xmpp.org would be included in the list of domains which always want TLS on HTTP, shipped with browsers.

> www. in URLs is that it serves as a gentle reminder that there are other services than the Web I prefer `web.` for that. More explicit and doesn't suggest the domain serves a site _about_ w3

I'm a fan of this myself ``` set $should_upgrade "$https$http_upgrade_insecure_requests"; if ($should_upgrade = "1") { return 307 https://$host$request_uri; } ```

I stopped serving anything on port 80 some year ago, after years of doing that redirect, and nothing broke because of HSTS Preload.

mjk, I'm not sure how large the proportion of users is that will be confused by "www" suggesting a site about the web technology 😉

Link Mauve: do browser vendors actually harvest the interwebs for HSTS headers? My impression of the technology always was that each browser installation learns on its own

Which freed it for certificate retrieval as well as the occasional proxy bypass port.

But the whole reminder idea is nonsense of course, except that you might be happy about being reminded if you knew anyway.

mjk, no, you go to https://hstspreload.org/ and request your domain to be added there.

It will check that you do serve the HSTS Preload header, so that no one but the website owner can include this header in browsers’ lists.

Holger: probably in minus 6th order of 10. :) But I sleep better

🙂

mjk, the process is explained on that website.

Link Mauve: ah, TIL, thanks

Link Mauve, also firefox now has that annoying behaviour to try https if something goes wrong on http. (which adds to the "not serving port 80 doesn't break anything")

it is about as annoying as it adding .com or whatnot to a domain name if something goes wrong

Oh, TIL about this behaviour.

Annoying for debugging port 80 issues, I guess. But the .com thing is just... ugh, whyyyy

mjk, it's also annoying for developing locally when your dev server just crashed and you get "redirected" by firefox to https and you don't notice and then f5 won't do anthing anymore because it's going to 443 instead of 80 now.

Ellenor Malik, watch your language

*sigh* ✏

LMC'd

jonas’: that... is suspiciously specific :D

Firefox should do better. It should say "port 80 doesn't work" and _offer_ preloading 443.

jonas’: browser.fixup.fallback-to-https seems the tweak for that

thanks, toggled <3

Thanks!