Modern XMPP project discussion - 2024-06-18

I know devs mused about making it a server module, so the xmpp server can load the picture for the client. But I guess nobody had yet time to act on it.

A proxy for downloads is something I want to do - it can be done with XEP-0215, but no clients are using it for HTTP proxies (XEP-0215 is only used to discover TURN servers/credentials currently)

For previews though, sender-provided previews are the best option overall. You can read more about the trade-offs with different approaches here: https://www.mysk.blog/2020/10/25/link-previews/

Many platforms choose to do them server-side, but this leaks every exchanged URL to the service provider

Some resources about this: https://wiki.soprani.ca/CheogramApp/LinkPreviews https://dev.gajim.org/gajim/gajim/-/issues/11640

It might not even be a real vulnerability ✏ ↺

Sharing an IP address is often required to use the Internet Protocol as it was intended

If you have a strict threat model, that can be a problem. But for most people it shouldn't matter if they share their IP or not

IRC shares IP by default.

Just shame on the authors to treat an Internet Protocol feature as a vulnerability that requires literally censoring the name of an app

It's been 4 years since its publication too. After 4 years you should've posted full details of the vulnerability anyway so you can indicate the incompetence of the app's developers to fix the issue and keep users informed.

Most people seem to be rather uninformed of the implications you get when using the Internet Protocol and its applications.

Some people join my Mumble server and get surprised or upset when I run internet diagnostics tools against their IP address

But this is required in order to assess IP connectivity issues. Especially with consumer ISPs, not running IP diagnostics tools means I cannot know how good the peering is between me and my clients.

It's not illegal to send ICMP messages to an IP address, is it?

Or would that need to be specified in the privacy policy?

> It's not illegal to send ICMP messages to an IP address, is it? Who knows? TCP SYN is considered illegal in some contexts :)

In what contexts?

Port scanning, for one

Is it illegal to port scan?

It's just like knocking on a door

In some jurisdictions, yes

But doing an aggressive port scan could be disruptive though

If an aggressive port scan is the same as continuously knocking on a door to get refused, but keep on knocking, it might be considered harassment ✏

At least ICMP should be a lot less controversial than scanning ports

Now I'm wondering, is there an application-layer protocol for listing the public services served on an IP address?

Then we don't need to port scan anymore to find out what's meant to be publicly available

> Some resources about this: > https://wiki.soprani.ca/CheogramApp/LinkPreviews > https://dev.gajim.org/gajim/gajim/-/issues/11640 One though about this ↺

I'm doing link previewing in Movim. I'll never trust and implement such thing.

To me link previewing must be done client side, on the receiver side. It's too easy to "fake" previews this way.

Oh yeah that's a good point

But still, maybe users shouldn't trust a preview to begin with?

It's the Internet after all

The specific thing with Movim is that its the web server that is doing the job so the receiver IP is protected.

But it could be done by the XMPP server as well, like a "link preview service", looks like another XEP to be written :p

I doubt how useful it will be when it can be very very bad in the context of E2EE to send the link to the server ✏

Well in E2EE you don't have preview :D

But maybe if E2EE is off (commonly in MUCs), it could be interesting

You can't have every shiny things with E2EE :p

> But still, maybe users shouldn't trust a preview to begin with? Yes, and of course there's trade-offs with different ways of implementing a link preview. It just itches me when it feels like things are left at a stalemate of not providing _any_ option of link previews at all, despite user preferences. ↺

additionally, just as I was going through the XEP for vCard-based avatars: I suppose a mediaproxy could be helpful for fetching out-of-band (HTTPS-hosted) avatars, rather than avatars being constrained to: "The image SHOULD use less than eight kilobytes (8k) of data", since of course it has to fit in base64-encoded form in a single stanza

as I'm curious how many clients do fetch any out-of-band avatars, or if it's solely down to just in-band base64-encoded avatars

would be interesting if I could share media by .onion or ipfs:// but I suppose even fewer clients would support that… I guess that's where feature discovery comes in.