Conversations: Delete Media File on Http upload Server

[mulles]

General information

• Version: 2.2.9+fcr
• Device: Google Nexus 4* Android Version: eg Android 8.0 Lineage Os
• Server name: movim.eu
• Server software: ejabberd (version to be completed)
• Installed server modules: to be completed
• Conversations source: F-Droid

Steps to reproduce

1. Long Press Media file (e.g Image) in Chat window.
2. Select Delete image/audio/etc.
3. New placeholder for the mediafile: "The file has been deleted"

Expected result

The file will be removed from my phone and Server it is stored on. Should the media file not been uploaded by yourself, conversation should inform you that it can only delete the file locally.

Another option, might be to make clear to the user that the file will only be delete locally. The current behavior, could led the user to believe that the file does not reside any longer on the server. This would still not allow the user to delete files from his used Server, thus he would need to contact the System Administrator in order to get his files removed.

This might be related to the following issue: #2367

Actual result

The file is only deleted from my phone but not from the server.

[licaon-kter]

That's not how XMPP works.

Use OMEMO so files are encrypted.

/Close as wontfix

[wiktor-k]

Unfortunately this is a limitation of the underlying HTTP Upload XEP that defines only GET and PUT methods. So to properly support removing files one would have to extend XEP-0363 by introducing DELETE slot, then the server implementations should add support for that and clients (like Conversations) would have to remember DELETE slots for uploaded images.

The feature is not unreasonable but would require quite a lot of work. Fortunately with media confirmation dialogs deleting uploaded media is not a big concern (IMHO).

[mulles]

@Wiktor

thx for elaborating. I knew it is a limitation of the Http Upload XEP, but I am not into the XEP's to much, thus preferred not to share my incomplete knowledge.
What do you mean by Media confirmation dialogs?

Furthermore, I think conversations should still be adjusted to more specifically indicate what happens exactly with the media file on "deletion"

I will try to do a pull request enhancing this.

[wiktor-k]

What do you mean by Media confirmation dialogs?

In Conversations 2.3.0 you have to confirm that you want to send the picture to a contact. This avoids many accidental media messages to random people. Previously it was too easy to send media to wrong people or channel by using Android's Quick Share.

[mulles]

thx for clarifying.

In resume you mean: The requirement to delete media files from server is not so important as chances are low that you shared them with the wrong person.

Please note that still the server administrator has access to media files you choose to share unencrypted, for whatever reason.

When encryption becomes mandatory, the issue might be consider obsolete. Still one need to keep in mind that your information resides encrypted on a server you don't have much control over.

[wiktor-k]

Please note that still the server administrator has access to media files you choose to share unencrypted, for whatever reason.

If you think your server administrator is evil you better run your own as if they were truly evil they could still make a copy and fake deletion.

By the way you may like to discuss the XEP changes in this room: [email protected]

One interesting bit of trivia - SRV records for XMPP over TLS was initially just a PR for Conversations but it was properly standarized by the PR author as XEP-0368 and now it's widely deployed both in clients and servers. So maybe your deletion slot (or whatever method you'll find appropriate) can also succeed...

[zz-ha-dum]

Is the omemo encrypted file housed by MAM or carbons? When erase history is actuated are not also those files erased?

[zz-ha-dum]

I would extend deletion to Self Destruct (in N units of time)

[mulles]

@zz-ha-dum I got it wrong. The files themselfs are not OMEMO encrypted just the link pointing to the file.

The file itself is encrypted using the aesgcm:// scheme.
See:https://github.com/iNPUTmice/ImageDownloader

@wiktor-k
You are right concerning the trust of the administrator ( thx for specifing) .
The idea is that one can delete the files without requesting the admin to do so manually, but as you sugguested the xsf chat is the right place to enhance that.

In resume one must trust the server/admin to behave as expected, on manual or automated delete.

[MalevolentGrin]

I would extend deletion to Self Destruct (in N units of time)

Awesome!