- 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.
among the high-level problems which prevent me from taking a closer look at how this works at a lower level:
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:
and you replied this:
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:
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.
thank you for your (belated) honesty on this :)
thank you and you’re welcome
Hello,
Sorry to bother you again. I just wanted to share some architectural changes I’ve made recently.
I’m taking advantage of the fact that you’re the only one who has given me valuable feedback so far, so please feel free to ignore this message if you judge it’s not worth your time.
Along with moving the public key away from Firebase (the MITM issue), and implementing the sealed sender feature (sender information encrypted before it reaches Cloudflare), I’ve added a TOR service that the sender uses to connect to Cloudflare, both for the wake-up (instructing Cloudflare to send the FCM message via Firebase) and for signalling. I think this strengthens the “sealed sender” property.
I don’t think I can avoid cloud services entirely, except when the two peers are within Bluetooth range, I have that feature too. But I believe the sealed sender design limits metadata leakage in a reasonable way. My understanding is that Signal does something similar.
I’m now focused on defining a solid architecture rather than working on my landing page, which, as I appreciate, was initially built with a marketing mindset. So, I’m now more interested in technical feedback. I’ll get to the landing page later, once things have settled.
The App is not for sale anyway at the moment, if and when I will eventually try to sell it, I was thinking about a monthly subscription, that would cover the cloud services costs plus some revenue.
i won’t comment on your tor-to-cloudflare-to-google design because i haven’t looked at it and don’t expect i’ll make time to anytime soon.
Lots of similar things are able to avoid cloud services entirely; your perceived need to use them is driven by your so-called “server-free” design which isn’t really free of servers at all because, as the saying goes, “there is no cloud, just other people’s computers”.
You could also use Google’s push notifications but make them optional, btw. Making the protocol have a hard dependency on that is a choice you are making.
having users’ devices transmit fixed identifiers while moving around is terrible for privacy / great for surveillance, and firmly in the category of things which i not only do not recommend but implore people to not build. please don’t.
But your landing page is still up, and still making unsubstantiated claims and encouraging users to trust in (aka rely on) a thing which is totally half baked. You are still peddling snake oil. You should fix that.
I see, now we’re getting down to it :)
A few questions on that front:
About cloud services: The core idea behind the “server-free” design is to keep users’ messages from ever touching the cloud. Wake-up notifications and signalling (metadata) do require some kind of cloud service before the peer-to-peer connection is established. The only way to avoid third-party cloud services entirely would be to build your own, though I’m not sure that would really change how the dependency is perceived from a client’s perspective.
About Bluetooth: Messages are still end-to-end encrypted, anyway It’s a user choice, you don’t have to use it, and I found a lot of people appreciate this feature, Briar has it.
About the landing page: At least I’m clear I’m still in beta, evolving situation, anyway I’m working on the right wording.
About the questions:
given that the messages are encrypted, what is the advantage that you perceive in using “the cloud” (servers) only for signaling rather than transmitting the actual ciphertext through them? Wouldn’t your “cloud” servers see “just the metadata” either way?
It saves some costs for you, but it comes at the cost of requiring users to be online at the same time to exchange messages… is there some other advantage that you see?
ah, so it will be the kind of “free open source software” which can only be used via Google Play 🙄
that’s another thing you should inform potential users of explicitly, if you want to be honest.
that sounds reasonable
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 🤔