- cross-posted to:
- androidapps@lemmy.world
- cross-posted to:
- androidapps@lemmy.world
I have been working on an Android App quite a while now, starting from a simple idea.
A messenger where messages travel directly between phones with no servers in between. Using direct WebRTC encrypted connections (SRTP/DTLS), there are no servers that stores, reads, or relays content. Group chats use a gossip protocol where members relay to other members.
The only infrastructure the app touches is a signalling relay to set up the connection (no message content), a push notification to wake up a sleeping phone (also no content), and a TURN relay for restricted networks (encrypted packets only).
I wrote a detailed white paper explaining the full architecture: https://www.mindtheclub.com/white-paper.html
The app is in Open Testing on Google Play (1,000 tester cap): https://www.mindtheclub.com/beta-signup.html
I’m interested in this community’s perspective on whether the architecture holds up.
You must log in or register to comment.
among the high-level problems which prevent me from taking a closer look at how this works at a lower level:
- it depends on both cloudflare and google. it claims “Groups don’t have a single point of failure. No central server means no central point to fail, be compromised, or be compelled to hand over data.” but it sounds like both cloudflare and google (both companies in the business of surveillance capitalism, as well as other kinds of capitalism, and also longstanding government surveillance partners) are each a “single point of failure”: if either goes down, the system stops working, and if either is compelled to hand over data, they DO have (at the least) useful metadata they can hand over. (i didn’t bother to review it closer so i have no idea if compromising/compelling google and/or cloudflare could ALSO allow key replacement (and mitm) to circumvent the message confidentiality.)
- messages cannot be (re)-delivered until both parties are online simultaneously
- it’s mobile only for some reason, despite not being phone number-based
- i don’t actually think it’s a good idea to reveal one’s IP address (from which location can be inferred) to chat contacts all the time
- it gives strong slop vibes
these attributes prevent me from wanting to look any closer at it.
@GradleSurvivor@lemmy.ml i recommend that you ask your LLM to write a threat model document (first based on the current design you are distributing today, in the interest of honesty, and then a new one for your updated design as it continues to evolve) which explicitly describes which attacker capabilities are needed to perform which attacks. eg, assuming a compromised/compelled google and/or cloudflare, is it possible to mitm people? or collect metadata about people and groups? or selectively denial-of-service targeted users? can a user’s contact silently record their online presence and IP address on an ongoing basis?
in the interest of transparency, after asking your LLM these questions you should publish an updated threat model document which is far more sober and emphasizes what kind of attacks you acknowledge the software cannot prevent before talking about the specific attacks which you believe it can prevent.
Thank you very much for this feedback. It gives me the opportunity to discuss in more depth some details you have rightly highlighted and, more importantly, I have updated my white paper accordingly, (How MTC Connects You).
On the Cloudflare and Google dependency, you’re right, and you put your finger on the line in the white paper that overstated the case. The “no single point of failure” sentence conflated three different things (availability, compromise, compelled disclosure) and treated them as one. I’ve rewritten the relevant section.
The accurate framing is narrower, message content never reaches any third party, there is nothing on Cloudflare’s, Google’s, or our side to hand over, because no one ever received it. But availability does depend on those providers being reachable, and metadata exposure exists at the signalling and push layers.
To address the metadata exposure, I have implemented a sealed-sender design inspired by the Signal’s approach, the wake-up payload is encrypted with the recipient’s public key and the sender’s identity is inside that envelope, so the push provider sees the recipient but not the sender.
The per-step detail of what each component can and cannot see is now on How MTC Connects You.
About MITM under a compromised provider, both peers verify each other’s public key independently after one QR scan. The scanner gets the other party’s fingerprint from the QR, the scanned party gets the scanner’s fingerprint sealed inside the contact request, encrypted to a key the scanner has already verified. A compromised directory cannot substitute either key without producing a fingerprint mismatch on one side or a failed decryption on the other, and it doesnt hold the private material to do either. The mechanism is now documented in “How MTC Connects You”.
On messages requiring both peers online, yes, that’s structural and intentional. It’s the cost of holding no message content on any server. Briar and Jami make the same trade off for the same reason.
On IP exposure to contacts, also fair, and intrinsic to direct WebRTC peer-to-peer, same as Jami. The mitigations are the TURN relay path (peers see no direct IP, Cloudflare sees encrypted packets only) and, for users who want it, the option to force relay-only. Briar avoids this by routing through Tor, that’s a real architectural alternative with different costs.
wait a minute… i asked this:
assuming a compromised/compelled google and/or cloudflare, is it possible to mitm people?
and you replied this:
About MITM under a compromised provider, both peers verify each other’s public key independently after one QR scan. The scanner gets the other party’s fingerprint from the QR, the scanned party gets the scanner’s fingerprint sealed inside the contact request, encrypted to a key the scanner has already verified. A compromised directory cannot substitute either key without producing a fingerprint mismatch on one side or a failed decryption on the other, and it doesnt hold the private material to do either. The mechanism is now documented in “How MTC Connects You”.
in my first reply here i said that “that sounds reasonable” but now i looked a little closer. you say this is “now documented” but you actually also mean now implemented, don’t you?
I just looked at github and i see that until this commit one hour ago (four hours after i asked) you were actually calling
db.collection("users").document(peer.userId).get()to read a publicKey from Firebase. This is my first and last glance at your github for the time being; I’m going to stop reviewing your project for now because the design is fundamentally changing while we’re talking, and not in a transparent way. i shouldn’t need to find out from git that your answer to my question is the result of a change you just made after i asked the question.I’m also going to share here what i wrote to you privately about why i still don’t want you to post this to !cryptography@lemmy.ml, even now that you’ve removed the claim about not having single points of failure:
i [still] don’t want you to post it to /c/cryptography in its current state. the website is not saying “this is unreviewed cryptography, do not rely on it for anything serious” but on the contrary it says “Why Choose MindTheClub?”, “Uncompromised Security”, “Total Privacy”, “Unbreakable Encryption”, “Privacy Without Compromise”, etc. you’ve written the marketing copy to encourage regular users to rely on your software before having independent review of it; this is backwards.
if your website didn’t say all of those things and you were asking for review of your design and/or source code without simultaneously telling the general public that your “very new” software already provides “Total Privacy”, it would be a good post for /c/cryptography and other places.
HTH.
Yep, true. As I said, the conversation we had today was very helpful for me to understand and work on some stuff, and I will continue to work on it. There is another couple of observations I would like to think about. So genuinely, thank you for your time and feedback, of course I respect the decision, not going to re-post.
The scanner gets the other party’s fingerprint from the QR, the scanned party gets the scanner’s fingerprint sealed inside the contact request, encrypted to a key the scanner has already verified
that sounds reasonable
The “no single point of failure” sentence conflated three different things (availability, compromise, compelled disclosure) and treated them as one. I’ve rewritten the relevant section.
I wouldn’t say your previous text conflated these things per se; it said all three aren’t possible failure modes when all three in fact are.
And unless I’m mistaken, you didn’t rewrite it but rather simply removed that bullet point altogether? I think it would be more honest for the ‘white paper’ to explicitly acknowledge that Google and Cloudflare are both single points of failure for availability, and also enumerate what an adversary gains by compelling or otherwise compromising them. Assuming your qrcode key verificaion works as described, it sounds like it’s “just” metadata (who talks to who, and when, who is in what groups with who, users’ online/offline and location history, etc) and also the ability to do targeted denial-of-service. Right?
Also it would be nice to disclose what your business model is; presumably you’re paying for these cloud services, but how much? and how long and to what scale can you afford to do so?
I hope you’ll forgive my bluntness; to be clear I appreciate you building something with cryptographic identifiers and not requiring phone numbers, but it isn’t something i would use or recommend as long as it relies on companies like google or cloudflare.
i don’t see any advantage over SimpleX except for that it “doesn’t require a server” (and btw SimpleX’s default preset servers also don’t have a very confidence-inspiring answer to the business model question i asked you here - it’s we’ll do some freemium thing later), but, since you still require cloud services, sacrificing the ability to store-and-forward a message to someone who is offline doesn’t seem like a very good tradeoff 🤔
I personally wouldn’t use it because of the firebase signalling. I don’t want to share meta data like that, which is associated with every message transmission unless I’m misunderstanding your architecture.
No, you got it right, and is a fair point, I do use firestore for signalling, I can guarantee user messages are only transferred from one peer to the other with nothing in between, but I do not hide metadata.
Okay, this sounds good, but why is the app on google play and not F-Droid? Whenever I download an app from Aurora Store I immediately assume that the source code has been modified by google and that the app isn’t trustable. I know 99% of the time this won’t happen, but it’s absolutely something that could happen.
Another issue I have with it is the AI-generated images on your home page. Please don’t enslave yourself to the environmental destruction machine.
Currently the App is in beta testing, I’m in the phase of trying to find people willing to stress-test it. Once the App is fully debugged my plan is to open-source it, making my GitHub public, and this is a pre-requisite for uploading the App on F-Droid.
just use session, threema, sessionx, they solve this
SimpleX*
yep that, thnx
Wait, did you not know that Session will die soon?
i do, but i donated, so i had hope
Am I not seeing the actual white paper or is the “white paper” just a short blog post? Usually a white paper is a ~50 pages technical PDF, but you said detailed so I expected at least 100.
I agree, is actually quite high level, describing the main architecture and functionality`. What I intend to do, once the code is fully debugged, is to make my GitHub public, and upload a more detailed technical doc there. I thought not to make a public landing page, that targets a broader audience, too technical. In the meantime I’m happy to respond to any kind of technical question.
Like XEP-0174 from the XMPP protocol set but using a server for making the connection?
Not quite, with XEP-0174 you can only reach peers on the same LAN. I use standard WebRTC signalling to establish the connection, so peers on different networks can reach each other across the internet. Discovery itself is out of band, you add a contact via QR code or a profile link, then signalling just brokers the connection to that known peer.
What I’d like is something that doesn’t use Firestore, but uses either XEP-0174 or proximity handshaking to establish the initial shared secret between two devices, after which something like TOR or I2P could be used fir signalling against the shared secret.
That way, interception gets you nowhere and nobody’s able to follow the signal back to host to gain connection metadata.
The initial identity exchange between two devices isn’t done via Firestore, it’s done offline (shared by QR code). The key material used to verify a peer is authentic never touches the internet. Signalling is done through Firestore, and here it’s fair to say metadata isn’t hidden: Firestore knows that userId 01 contacted userId 02 at a certain date and time.
Awesome work! Just curious as to how different your product is from Briar? From what I understand, it is used by quite a few activists and journalists and seems to do exactly what you have tried (and more).
Briar is good, it has just has a different positioning.
MTC is a balance between standard rich multimedia real-time messaging, including audio/video calls, and privacy (full peer-to-peer).
Briar’s design, based on Tor, limits the possibility of a full messaging experience (WhatsApp-like), but it’s strong on metadata hiding, and its target users are different (activists and journalists in hostile or censored environments, etc.)
MTC’s target users would be standard messaging app users with some more attention and concern about protecting their private conversations, without giving up all the standard messaging features they’re used to.
so it sounds like this is more for group chats, to ensure at least one member is online at all times. Otherwise, if it were just 1-1 messaging, and one person’s phone went offline, the other person would have to wait until it was back online to send a message, right?
That is correct, but it works well for 1 to 1 messages.
There’s no relay in between, but you don’t have to wait to send, you hit send normally and the message just queues locally on your device, then goes out automatically the moment a direct connection re-establishes. Nothing sits on a server in the meantime.
Is this just a clone of SimpleX?
Not quite, SimpleX runs on a client-server architecture, messages route through relay servers that hold them temporarily until delivered, then delete them. MTC messages go device to device with nothing storing them in between, not even temporarily.
