This again? 🙄

I did answer your questions, but if I missed something, feel free to ask and I can clarify.

The clients (apps) enforce key symmetry for your own keys, server identity, and the exchanged with the other person part of a conversation. Constantly. There is no way to MITM that.

The clients are open source, and audited regularly, and yes, builds are binary reproduceable and fingerprinted on release.

That’s not to say someone can’t build a malicious copy that does dumb stuff and put it in your phone to replace the other copy, but the server would catch and reject it if it’s fingerprints don’t match the previously known good copy, or a public version.

Now you’re just coming up with weird things to justify the paranoia. None of this has anything to do with Signal itself, which is as secure as it gets.

The closest you’re probably going to get to a half decent looking WYSIWYG editor is something templatized top to bottom. Odoo, Ghost…things like that.

I don’t use any Meta products, so not sure how you mean. If you are a user that has been sending e2e messages, then you can surely decrypt said messages if you’re a participant in those messages transactions.

It doesn’t matter if it’s criminal or civil. The costs to bring such a case are massive, and you’re leaving yourself open to a behemoth like Meta just dragging out the case for lengthy periods of time which drastically increase those costs.

No law firm files suit against a giant company like this unless they have rock solid proof they will, at the very least, land a settlement plus recuperation of costs. Just not a thing.

🤣🤣🤣

You need a juice and a nap, Ke-mo sah-bee.

Do you know what size channel attacks are? Because nothing you’ve even tried to bring up describes one at all, or how it applies to your original comments.

Well they did this whole stupid “rebranding” of it becoming e2e after Facebook bought them a few years back, but literally every security researchers was like “Nahhhh, pass”.

What in the world are you talking about here, bud? Your comments are making zero sense.

Look, seriously, if my comment is being upvoted, it’s because I responded to yours, and people understand what I am saying in response.

You, unfortunately, clearly do not understand what I’m saying because you do not grasp how any of this works.

See every other comment in this thread describing in great detail why you are wrong, but that you fundamentally DO NOT UNDERSTAND how any of this works whatsoever.

Dude…your comments here clearly display that you do not have a single clue as to how cryptography works. You should just pack it up in this thread and head on down the road.

🤣🤣🤣😂

Bruv, before Signal launched they posted an entire whitepaper detailing their protocol, the working mechanisms of the system, and source code. So to reply to your 3 points:

1. No, this is stupid and easily verified by watching network traffic from any device. Signal isn’t secretly sending plaintext messages anywhere.
2. No, it’s not impossible to tell this at all. That’s what source code is. The executable code. Not only have NUMEROUS security audits been done on Signal by everyone from Academia, to for-profit security researchers and governments, you can easily verify that what you’re running on your phone is the same source code as what is published publicly because the fingerprint hashes for builds are also published. This means the same fingerprint you’d get building it yourself from source should also be the same as what is publicly published.
3. See my point above, but also when two users exchange keys on Signal (or in any other cryptographic sense), these keys are constantly verified. If changed, the session becomes invalid. Verifying these keys between two users is a feature of Signal, but moreover, the basics of cryptography functioning can, and have been proven, during the independent audits of Signal. Go read any of the numerous papers dating back to 2016.

If you don’t understand how any of this works, it’s just best not to comment.

It’s already a known risk, because WA uses centralized key management and servers, and always has regardless what Meta says. If you believe their bullshit, then I feel sad for you.

Also…you don’t think that LAWYERS willing to go up against Meta would have rock solid proof from these whistleblowers FIRST before filing a lawsuit?

C’mon now, buddy.

Signal

DUH

All the catches

Bud…been doing this for 20 years. Don’t need your explainer.

The fact you didn’t mention the barest of minimums in your comment if where the issue lies. You’re just adding stacks on stacks of things by using any other network mount and having the user manage an encrypted image inside that mount. Also absent from what you were trying to explain. I’d work on that.

Point being, for a multi-user/tenant utility like OP is asking for, there are better tools for the job, of which I just named a couple standalone options. If they are running TrueNAS, Synology, or QNAP, or even NextCloud, there are already built-ins for this purpose, and apps to match.

If not, any of the other solutions I mentioned are much better suited for the use-case, especially, and if not only because, OP specifically said they DID NOT want exactly what you’re describing.

OP said they DON’T want LUKS. I’m also missing how the admin of the server (OP) wouldn’t have or store the keys unless and have these mounts available at all times?

You seem to be suggesting there is some way for a remote user to mount a LUKS image on its host, which is not a thing unless you’re first SSH’ing to said host and mounting it and making it available for export mount elsewhere, which is clearly not what OP is asking for here when they just want space for people to store media. Maybe I’m misunderstanding.

There Hook, Filen, Yeetfile, BatchIT…tons of these self-hosted stacks that do this with auth and user management built in. That’s what OP is asking about.