XSF Discussion - 2023-09-09

I recently read an article that got me thinking: should we add suggestions to scan uploaded content for malware in XEPs like XEP-0363?

I'm primarily interested in figuring out what the best course of action would be: report back to the uploader that there's malware found - or assume it's a malicious user and _not_ tell them, instead prevent downloads only (which I guess would be trivial for a malicious user to detect anyways)...

For me first would be able to even know what upload belongs to what user and beeing able to work with these single files

Scanning is both something that an implementation can easily add without need for a XEP, and something easily evaded via encryption

True, but are those reasons to not add it to the XEP though?

Just some text saying it's a thing you could do?

The reason not to add it to the XEP is that it's not a protocol thing, so I don't know what value it would add

if a way to tell the client that the scan came back positive was added, it would be a protocol thing.

There are many things you could do, personally I don't see a need to list them all

<policy-violation/><malware-detected/>

It would have to be in the HTTP response

oh, yes, indeed

And even then, how fast are those? Do you block until the scan completes?

Depends on the implentation usually content filter daemons on UTM Firewalls do non blocking scans on the streams (yes they basically MITM) encrypted or not, if using an external upstream CDS I suppose the XMPP service could be completely agnostic of the upload state and so could be the CDS where the file would be just deleted.

(re "encrypted or not": that doesn't hold for OMEMO encryption)

(yes, but that's marginal.. as that would apply to direct messages only, or small private groups)

Yeah, by "encrypted" I meant OMEMO specifically

Actually there's nothing to stop someone using aesgcm:// in public channels, it just isn't usually done

> <MattJ> Actually there's nothing to stop someone using aesgcm:// in public channels, it just isn't usually done Yes but then that would be garbled content if not decrypted, which makes that harmless

No, the key is included in the URL

and I suspect any client (that supports aesgcm) will decrypt it, regardless of whether it's in a public channel or not

or part of an OMEMO conversation or not

Pretty sure I've seen this happen already

🤔, tbh I glanced at that URI a handful of times so that should tell something about the actual support, but I digress

For science aesgcm://share.snikket.de/4C83eQnR39geR5HmGFy1wLgk/zb2rhjY7uD1CgEUk3DtigyGJknQpjVGUJer2LKyYwx7wdvb8J.jpg#78c0fe74ad84a31cea9cdd14bb6210bb9acee693f7659a2fe257ce5aa249cae201df0a920cfdfdf04b97794a

For science https://share.snikket.de/4C83eQnR39geR5HmGFy1wLgk/zb2rhjY7uD1CgEUk3DtigyGJknQpjVGUJer2LKyYwx7wdvb8J.jpg#78c0fe74ad84a31cea9cdd14bb6210bb9acee693f7659a2fe257ce5aa249cae201df0a920cfdfdf04b97794a

Menel, you're violating the most sacred rule of http upload, you include some descriptive text!

Menel: first one in C doesn't work

(Second One is garbled of course)

aesgcm://share.snikket.de/4C83eQnR39geR5HmGFy1wLgk/zb2rhjY7uD1CgEUk3DtigyGJknQpjVGUJer2LKyYwx7wdvb8J.jpg#78c0fe74ad84a31cea9cdd14bb6210bb9acee693f7659a2fe257ce5aa249cae201df0a920cfdfdf04b97794a

^ that works in gajim without the text of course, shame on me Zash

> It would have to be in the HTTP response I made a quick proof of concept that simply returns bad request. Having uploaded data being processed via an external ClamAv daemon is pretty straightforward.

It's far from bulletproof, but it's also a lot more than simply serving totally unverified content.

I wonder how likely the aesgcm format is to trigger antivirus with a false positive? It should be indistinguishable from random data after all

Million monkeys / shakespeare?

Or maybe antivirus tags them as suspicious every time

Maybe instead 363 should just have a note that the recieving client should scan for malware if they want

If it's a thing, mark received files as received from the internets

"363"? If you mean office apps/Windows they already do some detection to assert if the file comes from network sources

XEP-0363?

Maranda: https://xmpp.org/extensions/xep-0363.html

Office 363 is the light version of 365? 🤣

Menel possibly 😅 or some funny reference shortcircuit. Although those note in the XEP sounds superfluous you're suggesting something that probably is already done by either the OS or AV/EDR. In security considerations it could be added a general note that "the service operator should ensure the safety of the uploaded content"

..which at least in dumb Europe will be a requirement after the dumb (DPA/)DSA kicks in member countries.

> In security considerations it could be added a general note that "the service operator should ensure the safety of the uploaded content" I don't think that's *possible* so I'm not sure saying that would be helpful

I agree but in the terms of receiving reports and removing content it unfortunately *has to be possible* ✏

If you can't scan it because of encryption, it's not possible to guarantee safety at all Even without encryption pretending anyone can "guarantee safety" is a lie

So I'm not sure about the correct wording but a related note might be more useful than references for all the other corner cases

You can certainly remove it if you get reports or whatever

Nothing also prevents servers to try to stop the usage of XEP-0454 for uploaded content

> I agree but in the terms of receiving reports and removing content it unfortunately *has to be possible* This is indeed something I consider much more important to specify in the/a XEP

Specifically we're lacking a standard way to report a URL to its operator, and a way for users to delete their own URLs

Even no way to determine operator for sure given a URL, though in practise with most implemetations it's pretty easy

Indeed

Bring back the Jabber-ID header ;)

Can xmpp do uploads without relying on http?

Theoretically yes. In practice no

Ask Link Mauve

Jingle upload, but I think cheogram.com might be the only component in the network with such a concept

What's http's reporting mechanism and why isn't it sufficient?

HTTP is too low level to have that kind of thing

People manage to report HTTP URLs just fine no?

As part of a larger app context that includes a support link on a website or something yeah

You can build one over top of it. GET /reportupload?url=https://cheogram.com/uploads/thegreenbelt/somegreenbelt.jpg HTTP/1.1 Host: cheogram.com Ofc then you must filter chaff. ✏