15
Carpenter here. I got fed up with messengers wanting my phone number, so I built my own. Looking for honest criticism. (lemmy.world)
submitted 4 months ago by to c/privacy@lemmy.world
57 comments fedilink hide all child comments
 

Bit of an odd intro: I'm a carpenter, 42 years at the bench. I'm the type who can't stand making the same thing everyone else makes, so I've always chased the technical side too - CNC, laser cutting, and lately building software to run my machines.

At some point I wanted to send my own designs to people without them leaking anywhere, and I went down the rabbit hole of how messaging actually works. What got me was realising how much of the "free" stuff is paid for with our privacy. That annoyed me enough that I decided to build my own messenger, mostly to learn. It grew from something simple into a real thing. I called it Sherlock.

Two things I cared about: proper encryption, and NOT tying it to a phone number - I built a different system for that.

I'm not going to pretend I reinvented cryptography. I'm a woodworker who got obsessed. So I'd rather hear it straight from people who actually know this stuff:

  • How much does the "no phone number" approach really buy you if I get the rest wrong?
  • For a small independent project, what's the bar before any of you would even consider trusting it - open source, audit, something else?

Genuinely here for the criticism, not the pats on the back.

you are viewing a single comment's thread
view the rest of the comments
[–] 3 points 4 months ago (3 children)

Congrats on your project! Sounds interesting. I’ve got a few things for you to consider.

The phone number is often (but not always) there as a shared identity token — you need to have something by which you can establish trust between the two endpoints, and most people have a phone number.

In cases like Signal, it’s hashed locally and sent to them as a hash value that can be “discovered” by other people who have never connected with you before.

In cases like Apple Messages, it’s used as an optional part of 2 factor authentication and as an SMS routing avenue — purely optional, as you can use an email address / Apple ID instead.

In many other cases, it’s used as a way for the messaging provider to track who you really are.

On to the “trust” bar — Open source and using industry standard libraries, at a start, with a real person and a physical address on the other side, and a fully transparent and auditable build chain.

These days, it’s really really common for a malicious actor to stick something into your supply chain that will give them full access to all the devices using your solution… at some point in the future during a series of innocent looking updates. If I don’t have full trust in all the upstream code being used by your messenger, I can’t trust your messenger either, no matter how much I trust you as the developer.

  • permalink
  • fedilink
  • source
  • hideshow 3 child comments
    •
  • [–] [S] 2 points 4 months ago (2 children)

    This is genuinely the most useful reply I've gotten - thank you for taking the time. The breakdown of what the phone number actually does for is clarifying; I'd been thinking of it purely as a privacy leak, but you're right that it's also doing the "shared identity token" job, and dropping it means I have to solve that some other way (I use a locally generated ID, but I'll admit discovery/trust-on-first-contact is the weakest part).

    The supply chain point is the one that lands hardest, and it's fair. "Trust me, the developer" is worth nothing if the code underneath isn't inspectable - I hadn't framed it that sharply to myself until you put it that way.

    One thing I'd like your read on, since you clearly think about this properly: if a small project gets to open source + standard vetted libraries + a transparent build, but realistically can't afford a full third-party audit for a while - is that a "come back when you're audited" situation, or is open + standard libs + reproducible builds enough to be worth a careful person trying? Trying to understand the actual order of priorities, not just the wishlist.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 4 months ago (1 child)

    Yeah; I think you’re on the right track. Without the audit, you’ll have got it to the point where people with whom you’ve already established some level of trust should be able to use it. If it takes on a life of its own, you’ll need the external formal audit to establish trust with the larger audience. But any sort of a security review will be beneficial; implementing security is hard.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] [S] 2 points 4 months ago

    That framing really helps - "fine for people who already trust you, formal audit before it goes wider" is a clean line to hold myself to, and it stops me from overselling it in the meantime. I'll treat the audit as the gate for any broader claim.

    Thank you for taking this much time with it. You gave me the most useful thread in here by a mile - the supply-chain point and this trust-staging both reframed how I think about it. Genuinely appreciated.

  • permalink
  • fedilink
  • source
  • parent