Escape the MCP: Identity Segmentation and Controlled Decoys on GothamNet

Hello everyone, I'm Ed. Have you ever been the green bubble textter in a blue bubble group chat? Or did they kick you out before you even realized you were the one throwing everything off? And if you haven't had that particular pleasure, maybe you've had the joy of trying to get your mom to set up a new messaging app only to realize you just inadvertently signed yourself up for weeks of phone calls with questions much better suited for the geek squad or the IT help desk at what will very soon be her bargain basement retirement community if she keeps up the pastoring. Everybody we come into contact with takes technology and security postures they're most comfortable with.

They have the right to do whatever they're most comfortable with. But as soon as your technology and security posture becomes inconvenient for the people around you, it becomes a social liability. And let's be honest, although being a nerd in the 2020s is a marketkedly better experience than it was in the 1990s when I came up, we don't need any more help increasing our social liabilities than we're already providing ourselves through just existing. So when it comes to mobile device privacy and security, even when really serious people weigh that liability, especially over time, they hedge their bets and default back to a less secure setup when that liability starts to rise. They read the book, they get inspired, they try

the thing, and then three weeks later when their kids school can't reach them and their mom thinks they died because their blue in iMessage chats are now green, they quietly go back to the way things were. Perfect becomes the enemy of private. It's a common story that we've all lived some version of. And if you've ever read any of Michael Bazelle's books, you know exactly what I'm talking about. About two years ago, a client came to me whose personal circumstances had changed in a way that eliminated the option of falling back onto that hedge. The stakes were very real and nice to have. Strict privacy was no longer on the menu. They needed operational privacy, not the blog post

version, the real version, but they also needed their life to continue working. And those two things were pulling in opposite directions. Their nonnegotiables will sound very familiar to you. Their families deeply entrrenched in the Apple ecosystem and devoutly non-technical. They have schoolage kids and aging parents. You can't change the phone number that the school calls when your kid throws up at lunch in the middle of the year without causing a massive uh freak out with everybody. Medical contacts extracurriculars emergency lists. There's an entire web of identity that has to stay intact. A walled garden of their old life wasn't optional. It was required. and untangling it to change it would have required more exposure and risk than

leaving it in place. And their professional life was very tightly intertwined with meta and microsops that if managed incorrectly could poison every attempt at achieving privacy in very important ways. one bad sync, one wrong account linked and the whole thing unravels, possibly in ways that could be dangerous to her life. So they looked at me and said, "I can't burn it down. I need all these things to exist together. Figure it out, Ed. You always do." And this is the story of how and why we were able to ultimately figure it out. We built them a system and because every good system picks up a really dumb name along the way, we did end up calling it

Gothamnet. And there's a pretty good reason behind it and a pretty cool story behind it as well. So, the first thing that we looked at was could we harden what they already have. Uh, that looked like outfitting their iPhone with a VPN. Um, turning on ADP and turning location services off. It also meant tightening up every privacy setting Apple gives you and then appending where necessary. And of course, Apple gives you a lot to work with. Advanced data protection is real encryption. The privacy controls have gotten genuinely better. I would argue that Apple has a legitimately excellent privacy posture and options. No question about it. If you're a regular person trying to angle towards privacy and reduce your

digital footprint, Apple is probably the best option that you have out there right now. Um, however, there's a problem. At the end of the day, if you're in Apple's ecosystem, you are in a trust me bro relationship with a trillion dollar corporation. You're trusting that they won't be compelled to hand over your metadata. You're trusting the cross talk between apps on your device isn't leaking context that you didn't authorize. You're trusting that an operating system you don't control and can't audit is doing what it says that it's doing. And of course, you're trusting that SI who by default reads and indexes everything that you type into that phone or say to it is in fact going to keep

your secrets. For most people, that'll do just fine. And I'm not here to start any conspiracy theories, but for this client, trust me, bro, wasn't an architecture that they could rely on. It was a serious vulnerability. So, I knew that we had to go Android based, which is right about the time that the groans from my client started to get louder. Now, I'll be honest with you. I didn't spend six months evaluating every privacy focused Android operating system out there. I did of course look around to try to do my due diligence. The landscape is thin and after ruling out the iPhone, it was pretty clearly and pretty quickly obvious that Graphine OS was the move. Um it it was the most

mature, most widely recommended amongst privacy and security pros. I've logged plenty of hours behind the wheel and it actually feels like a real phone. Um, I'm not going to pretend that I've spent a lot of time with KLEX OS and some of the others and I've heard some horror stories from Lewis Rossman and some of the other folks about some of the other operating systems out there. So, I've steered clear as well. So, graphine OS on a Pixel it was. And honestly, graphine OS on a pixel solves the device problem. Sandbox, Google Play, user profile isolation, harden OS, great. But it doesn't solve my client's IRL translation problem. Because if we go back to the non-negotiables, their

family lives in iMessage, their boss lives in WhatsApp, and their emails in Outlook. All of this somehow has to keep existing. And and for the most part, most folks who are weighing the option of going, you know, privacy in this direction, have some version of this that they're trying to figure out how to make work. And every solution that I try to engineer for maintaining that Apple ecosystem, especially from a graphine OS device, was either flimsy, super expensive, or only halfway there. Nothing worked as a clean standalone solution. Every path I went down eventually needed some additional puzzle piece in the mix that was above and beyond their old iPhone and the new privacy phone, which of course by this

point had also earned a stupid nickname, which of course was the bat phone. So, as all the requirements for the Apple side started taking shape, a Mac Mini here and always on iPhone there, I started playing around with wire guard and other tunneling options to tie things together. And that's when I had the chance to really dig into Headscale, which for the unfamiliar is an open-source implementation of uh the coordination server for tail scale. And I actually really fell in love with it. Headscale didn't just give us a way to connect the bat phone to the Apple hardware, which I'll talk about here in a minute more. It gave us the ability to explode the whole setup into a private WAN,

which will make a lot of sense when I talk about why there was a need for Apple hardware in this whole mix in the first place. Suddenly, the Batphone wasn't just talking to a Mac Mini in a closet. It was connected to a mesh that could include nodes in different cities, its own DNS resolution, and its own exit points to the internet. The Apple problem forced us to add hardware and Headscale turned that into something much bigger than we had planned. And that's how this whole Gothamnet situation was born. And that's why I'm standing slitting here with you today. Uh not from some grand design on a whiteboard, but from duct taping one problem to another and realizing that

the solution opened up a dozen more possibilities. So let me show you what this looks like and we can walk through it together. So this is Gothamnet. Five nodes, highly simplified of course, five nodes on a private mesh, all connected through headscale. Uh no traffic touches the public internet unless we want it to. Up top we have two coordination servers, one in Charlotte, one in Vegas. Both are running the same stack. Headscale traffic as a reverse proxy, Pi Hole as the DNS server and for ad blocking and domain filtering, plus unbound for recursive DNS, excuse me. Charlotte is primary Vegas syncs to Charlotte and sits there quietly until it's needed. If Charlotte goes down, a DNS-based failover at the

registar flips the A record and Vegas picks up where Charlotte left off. The client doesn't have to do anything but wait for a few seconds. And honestly, by a few seconds, I mean about 60 seconds. Since it's a DNS registarbased fail over, um it's about 60 seconds. On either side, we have two exit nodes, one in Miami, one in Dallas. These are the doors to the internet. When the bat phone needs to reach the outside world, traffic routes through one of these depending on the profile and each one can either exit directly or chain through a Mulvad VPN connection that terminates in the same city. Obviously, this can be changed. So, if the bat phone exits through Miami to the

outside world, it looks like someone browsing from Miami. chain it through Mulvad and now even the VPS provider doesn't see the destination. Two hops, two different parties, neither one has the full picture. Depends on exactly what the client is doing and what kind of security posture they need in that given set of circumstances, but they do have that option. Um, and then at the bottom we have the home lab. This is at the client's physical location. A Mac Mini, a little System 76 Mircat running Proxmox, and the original iPhone sitting in a drawer plugged in doing its job. And I'll dig into what ended up being the solution for the Apple stack of services and how we were able to emulate

and extend all of this uh to the edge on their graphine device. uh here in just a few minutes. Um this is the node that keeps this whole ecosystem alive. iMessage, FaceTime, the whole nine. uh and uh this node also serves as an exit point since some traffic should come from the client's home IP their old identity the legacy stuff the school emails chats from the boss and family that you know traffic that's supposed to look normal it's supposed to look like it's coming from their house because it is so it can be steered to be coming from their house. Um, so that's the landscape. The two coordination servers with automatic failover, two exit nodes

in different cities with optional VPN chaining and a home lab that bridges the old life and the new one. If you zoom into the device itself, the bat phone, and you take a look at the the user profiles, um it is a Google Pixel. Uh in the case of this client, it was a Pixel 8 Pro running Graphine OS. Um for the uninitiated, Graphine OS is an Androidbased mobile operating system focused on privacy and security. verified boot, hardened memory allocator, and sandboxed Google Play if you choose to use it. Got lots to say about sandboxed Google Play and some of the things that you may not think about when you're thinking about Google Play, but it is the real deal. And most

importantly for my client, it looks and feels enough like a normal phone that a non-technical person can actually use it dayto-day without wanting to throw it through the window. Um, that last part matters more than any of the security features, honestly. Um, I say that somewhat jokingly because the most secure device in the world is useless if your client leaves it in a drawer and goes back to their iPhone, especially when their life's on the line. The UX has to work. Graphine OS does a great job threading that needle. For the context of this conversation, what matters is that Graphine OS supports multiple user profiles and they are genuinely isolated from each other. Not like iPhone focus modes where everything

still talks to the same iCloud account. These are separate environments, separate app installations, separate data, separate network configurations. And on graphine each profile can have its own instance of sandbox Google play or none at all. They are independent operating environments on the same device. So what we did is we basically mapped the profiles around my client's threat model tiers and well there we go. And at the top you've got the owner profile or on the top left here. Um, and then you've got the in the in the Tron universe. This would be the user with the capital U. And the user controls the programs. So on the graphine device, the owner profile is the administrative control plane. This

is where the SIM cards live. The network settings are configured where apps get distributed to the other profiles. There are no personal applications that are run on the owner profile on this client's device. So no email, no chat, no browsing. Uh you don't do anything as yourself on the owner profile. Um this is purely about controlling the other identities. So this pro profile's traffic is also always run over to tour using Orbot and for all intents and purposes the admin plane is invisible um since it is run through tour always on VPN and forced um with this particular client we also for went if that's a word I believe it is um Google play al together um with their private

profile. We used Google Play on their exposed um I believe in this instance we called it the home and outside profiles because those were already exposed. Um but with the private profile there is no Google exposure whatsoever. Um and and I'll talk a little bit about why that decision was made here shortly. Um, but you can still obviously get apps for Android devices and in graphine OS without ever installing anything that has anything to do with Google through a variety of different app stores and and methods and everything works just fine. Um, there are a myriad of ways to do things like push notifications by self-hosting your own methods for push notifications as alternatives to

things like Firebase that work wonderfully. But I digress. We'll come back to that here just a little bit. Um, so the profiles and their purposes. Um, first there is the safe profile. This is the hardened private identity, the new bank of disposable numbers that they can use, new email, new everything. This is where the client actually lives now. Their sensitive communications, the stuff that nobody should be able to trace back to them. This profile exists um pardon, this profile exits Gothamnet through a privacy optimized node with additional privacy optimizations that are outside of the scope of this talk. Um and we can stack Molvad at the edge for a second hop for maximum separation depending on the threat landscape at the

time. Then there is the home profile. This is where their legacy identity lives and this is where the philosophy really shows up. So this profile holds everything that already knows who she is. It's where iMessage, FaceTime, the family group chat, the stuff that's been tied to their real name for years all lives. So, Straa and uh you know IoT devices like an Apple watch or something like that is connected as if nothing has changed. No one is the wiser. Um this profile exists at the client's home IP address always and on purpose because think about it if you do suddenly go dark on every platform that knows who you are that's a signal too. If your iMessage that's been coming from

Charlotte for five years suddenly stops, that's a signal. The surveillance grid notices when patterns break. So, we don't break the pattern. The legacy identity keeps doing exactly what it's always done from exactly where it's always been. Now, it's just a controlled decoy. And then there's the outside profile. This one holds the work stuff and contact specific apps. So, WhatsApp for the boss, Outlook for the business email, the services that know the client's identity but aren't part of the inner circle. This profile gets its own known exit node, its own posture, its own rules. Uh, not as locked down a as safe, not as deliberately exposed as home. the gradient in between. And this can go on

for quite some time. I believe in um the most recent graphine OS release, you can have 16 user profiles. Um I've seen clients use as many as six to eight without any slowdown on the latest phone models in the Pro series. I can't imagine using more than three or four having a gradient of more than three or four types of user profiles, but hey, you never know. Uh when you think about um the piece that ties it all together, each one of these user profiles also has its own tail scale instance installed. So each user profile has separate apps installed as if it exists on its own. So it has its own instance of phone

installed, its own instance of tail scale and each instance authenticates as a different user in headscale completely separate identities on the mesh. So when the client switches to a profile and the tail scale session comes up, the exit node for that profile is automatically assigned. The home profile connects to the mesh and exits at the home lab. Their IP um their home IP because that's where the grid expects to see it. The safe profile connects and exit through exits through a privacy node in another city with some special treatment all free mantle and the outside profile goes somewhere else entirely. The client doesn't configure anything. They just switch profiles and the network follows. You know, if you've ever used tail

scale, one of the nice things is there's a pretty nifty UX with a drop down. If you do want to change exit nodes within the UX, it's pretty straightforward and simple. Nothing changes about that with Headscale. It's nice that it is um completely open source and gives you total control. One device, four identities, four completely separate paths through Gothamnet. Nothing crosses. Um, but we can also get a little weird if we want to. And who doesn't love to get a little weird sometimes? Tail scale doesn't just provide exit paths. It also provides endpoints to every node. So when we think about the fact that we're hosting these services, it also means that we're running the availability of these

services back to the device. So ostensibly, iMessage could persist into the safe profile as long as it's safe to host it back to the device in that area and we're not exposing anything back to Apple during the interaction. The client could receive a message from their mom or a FaceTime call from their son regardless of the profile they find themselves in at the time of the inbound action. Uh but everything gets careful consideration. So for example, pardon me, I mentioned uh earlier about swapping out uh notify ntfy for uh instead of using firebase with um for push notifications um because we didn't want to expose the push notification metadata to Google. Um so that's the kind of careful consideration

that we gave from a privacy and exposure perspective. With those kinds of secure delivery considerations, it's completely safe to do that in the safe profile. That metadata isn't being exposed. Firebase isn't being used, so it's not that big of a deal. It's not in the equation. Google doesn't see the ping. And uh the old adage still holds. Um the WAN gives every profile access to every node without requiring them to share the same exit. And that opens up some really creative cross-pollin crosspollination of services across profiles. Um and so the architecture doesn't just isolate, it also selectively connects. Um, but that is also getting into the app stack, which I will get into in just a little bit. And

I know I can go down the rabbit hole with this because there's so many really cool applications that this um redundant headscale setup can give. And I want to get into a couple of them that are hopefully blow your mind as much as they blew mine when we figured them out. Um, for now, the thing I want you to take away is this. The bat phone isn't just one phone. It's four phones in one or a scale of, you know, as many phones as you need, as many phones as you can build into a user profile. Um, or pardon me, as many phones as you can build user profiles for. Each one presenting a different face to the world. Each one

with different security posture requirements. exiting the network at a different door and the person carrying it just switches profiles like you'd switch tabs.

I've already shown you a little bit of an overhead view of the WAN. Five nodes, one mesh. Um let me talk a little bit about what's running on the nodes and why. Um talk about the backbone a bit. Um there are two coordination servers, the primary in Charlotte with the secondary in Vegas. Um both are running the same stack. Headscale for mesh coordination, traffic as a reverse proxy, Pi Hole as DNS server and for domain filtering and unbound for recursive DNS. Charlotte is primary. Vegas syncs to Charlotte continuously. And if Charlotte goes down, that provider outage, maintenance, whatever, the A record at the DNS registar flips and Vegas picks up. The client doesn't really notice. As

I mentioned before, there's no manual intervention that's necessary. The mesh recon converges and life goes on. Um, but it is, you know, it is a DNS record flip that happens. Even though it's automated, it probably does take 60 seconds. Um, and it's probably worth mentioning why I went through the trouble of of adding DNS to the edge of this private WAN and why we went through the trouble of running our own DNS servers and DNS resolution to this. Um, because it's one of those things that sounds a little weirdly paranoid until you think about it. Every time your phone looks up a domain, and it does this thousands of times a day, constantly in the background, it's

asking somebody to translate a name into an address. And whoever answers that question sees exactly what you're trying to reach your ISP, Google, Cloudflare, Quad9, whoever it is, DNS is one of the leakiest protocols in your entire stack. And most folks kind of forget about it because it is so leaky and noisy. Um, with this solution in this client's network um DNS never leaves this network. Unbound runs as a recursive resolver which means when a query comes in from the phone. Uh it goes directly to the authoritative name servers for that domain. The source of truth. No middleman, no upstream provider caching the query history or building a profile of browsing patterns, nothing like that. And on top of

Unbound, Pi Hole acts as a sinkhole. So ads trackers telemetry domains anything on the block list gets swallowed before it ever leaves the mesh. Pardon me. You'd be shocked how chatty a mobile device is when you actually watch the logs. This is also part of the managed service that we offer and Pi Hole being open source and as tunable as it is and also being a really nifty DNS server, it makes it kind of the perfect solution for what we've done with it. Um, it also makes all that disappear. It's not just ad blocking, it's leak reduction and detection in case something looks off. Um, it, as I mentioned, it doubles as our internal DNS server. So, every self-hosted

service on Gotham Neck gets a clean host name and traffic handles the HTTPS layer with wildcard certificates and automated renewal. There's no self-signed searchs, no clickth through browser warning nonsense. Everything is proper TLS. We don't want there to be any kind of situation where there's the potential for, you know, a rogue joiner, somebody sniffing, anything out of the ordinary happening because somebody hops in and and happens to be in the way and able to see something that they're not supposed to. From an exit node perspective, looking specifically at Miami and Dallas, um these are the doors to the internet and they are simpler by design. Their jobs to take traffic from a profile and put

it on the internet from a specific location. That's it. These are $325 mega tiny VPS's um running tail scale endpoints. really nothing to them that are essentially set up to connect to the headscale and be monitored and you can scale these endpoints up to infinity most of the time. Um depending on the the profile of the the client and the circumstances, we will roll these every probably quarter. Um, and you know, lock them down with looks too oftentimes throw Mulvad VPN on there for um, you know, the quick offiscation and a hop option, something along those lines, just to have that chain through setup depending on the circumstances and what that client may be dealing with. Um

but nonetheless they can operate in two modes. We always set them up with the dual mode. Um and having that you know edge of the network option and expans expandability. Um this is very different from using a commercial VPN. When you fire up Molvad or Proton on your phone, you're encrypting your traffic and sending it to their server and hoping for the best on a system like this. The first hop is through our mesh, our infrastructure slashyou mesh, your infrastructure that you own. The second hop is the molvad provider that you've chosen specifically like I said because they use the quick offiscation. Um they don't log and you know for the most part they've they've

uh been raided to prove it. We'll see if that holds um and and neither hop has enough information to reconstruct the full picture. Uh, the VPS only sees the encrypted traffic coming from the mesh and Mulvad only sees the traffic coming from our VPS. Nobody sees both ends. Location isn't a fact that follows you. It's a variable that you set per profile. In essence, on the home lab side, um, this is the node that does the most. And this is really where all of this started. Um, in this case, it sit sits at the client's home office and it's running three pieces of hardware. Uh, first is the Mac Mini. This thing's always on, always

connected to Gotham Net. It's running Blue Bubbles, um, which bridges iMessage from the Apple ecosystem into Gothamnet. Um, I'll get into the details in the application stack conversation in a couple of minutes. But beyond Blue Bubbles, this is also where a lot of self-hosted services live. Think of it as a server room, except it's the size of a sandwich and it sits on a shelf. Next to it, there's an iPhone in a drawer plugged in on the cheapest cellular plan that money can buy. Um, this phone exists for one reason. It is the anchor for the client's Apple identity. As far as Apple's concerned, this phone's the client's phone. It's connected to iMessage. It's signed into

iCloud. It's always at the client's home address. It is the decoy. And then there is the Mircat. Um, this is a small form factor PC from system 76 that is running Proxmox. Fantastic little machine. Absolutely love system 76. running core boot um open- source BIOS. Uh these guys are absolutely wonderful. If you've never heard of system 76, definitely check them out. This handles containerized services, local compute, gives us a proper Linux environment for anything that the Mac Mini isn't suited for. Between these two machines, we've got Mac OS and Linux covered on the same shelf. Um this node's also an exit point. So when the home profile on the bat phone needs to reach the internet, traffic routes

through Gothamnet and exits here at the client's actual home IP because the legacy identity is supposed to look like it's at home. So it's supposed to look normal. It's the exit ramp for the control decoy.

Last thing on the network and we'll move on. Resilience. Um, this system has been running for a real person in their real life for nearly two years. Um, it has to work on a Tuesday morning when they're trying to check their email, not just on a Saturday afternoon when I'm messing with it. Uh, the primary and secondary sync between Charlotte and Vegas means the coordination layer has built-in redundancy. If Charlotte drops, Vegas takes over via that DNS failover at the registar. Um there are better methods but again affordability at the consumer level is part of the decision to go the route that we went. The exit nodes are independent. If Miami goes down we reroute to Dallas and so on. The home

lab is the single point of failure for Apple services but that is a trade-off that we accepted. You know you can't exactly distribute an iPhone and a drawer across two cities. Um the point is that the parts that can be redundant are um the parts that can't we monitor as closely as we can. The whole thing self-heals without the client lifting a finger. Um so that's the infrastructure. The bat phone is the device. Obviously these these terms are very much tongue andcheek. Um, it's more complicated than a shadowy, secretive, quiet, uh, unassuming device would be, which is why the names are so funny. Uh, Gotham Net is the network. Together, they give us identity isolation, geographic

flexibility, and a DNS layer that doesn't leak. Um, but a phone and a network that are just pipes. Um, what makes this livable is what runs on top of it. So, the fun part is the programs um that run on the grid. So, let's talk a little bit about that. And I'm probably running a little short on time, but let me see if I can hit a couple of the really interesting ones. And I definitely want to talk about blue bubbles and how we solve the Apple problem. Uh so, this is honestly the part where the majority of the time was spent. Uh I'm a purist, always have been. The older I get, the worse I become. The

longer I spend suffering through the downfall of Microsoft, Google, and the rest of big tech, the more I'm determined to bring clients into the world of open source and digital self-s sovereignty. So, when possible, I try to bring that message into my work. Um, there are so many apps in this solution that have been deployed in cool and also rinky dink ways, but I've picked out a small handful to spare you my ramblings. Um, so I'm not going to walk you through all of them. However, uh, you would 100% kill me and I would deserve it if I did. But if you are interested in a project like this or digging into a graphine solution for yourself, playing around

with any of this stuff, open source, you name it, I would love to rap about it. Um, please feel free to reach out to me at edgarlaminerresearch.io. happy to answer any questions or attempt to defend or change any position that I have. Um, okay, let's talk apps. Blue bubbles. So, the control decoy in action. So, I've mentioned this a few times now. Um, the iPhone in the drawer and the Mac Mini. So, Blue Bubbles is the software that ties them together. It is an open source app that runs on Mac OS and hooks into the native messages framework. Um, it then exposes iMessage through an API which means that you can send and receive iMes

including a pixel running graphine OS. Um, so the client's family sees blue bubbles. The family group chat works, photos come through, reactions work, chatbacks work, uh, FaceTime works, which blew my mind. Um, as far as anybody on the other end knows, the client is on their iPhone at home like always. Uh, in fact, native SMS and RCS messages also push through. Um, what's actually happening is the iPhone in the drawer is running iMessage with the phone number as the primary method of sending slashreceiving. Those messages simply get picked up by the Mac Mini running the Blue Bubbles server with an implementation of the Bluebubbles private API which is technically a jailbreak. Definitely want to mention that because that means that

no other official App Store apps can run on that Mac Mini while Blue Bubbles is running. Um, I did want to mention that because you know that that may be important. In other words, that's a dedicated Mac Mini. Um, we had the Blue Bubble server on the Mac Mini wired to a Notify Docker container that's actually running on um on the uh the Mircat and uh it handles push notifications instead of Firebase and that's because we don't want to leak push metadata to Google. That way we feel comfortable running iMessage in private profiles and pushing iMessage across any myriad of different profiles with various um security postures and then the messages can travel across Gothamet to the phone and land wherever

doesn't matter to us. The client reads the message they reply reply goes back through the same path. Um, as far as the rest of the world is concerned, the old identity never moved. The decoy is doing its job. Blue Bubbles actually propagates the uh contacts through to the graphine device as well. And the client's texting their mom from a completely different device on a completely different network in a different city, wherever. Um, and that's what contain don't delete looks like in practice. It's a really nice solution. Um, we tested a lot of different solutions out there. Air message was one of the ones that we beat around for a while and and it was um it was quite a bit inferior to Blue

Bubbles which won out by quite a bit. Um, I think beyond the fact that Blue Bubbles is is the coolest and most functionally awesome, this one is my favorite. Uh the the kogram and snick solution is awesome. Uh and this is the be your own character aka I hate you SIP trunking aka be your own my pseudo solution. Um and this one's fun because most people don't know that it's possible. One of the one of the problems that we faced when we were setting this up was that we really had a problem with the exposure that happened when the client was trying to set up phone service on a new device. If you're going to go out and get a a

SIM card and that SIM card has a phone number attached to it, you're exposing your location and identity in ways that are significantly more substantial than you might be if you were getting a phone number that is attached to, you know, a virtual identity like um like a Google voice account or my pseudo which is you know, a popular app that allows you to have a multitude of different phone numbers. And what this combination of apps allows you to do is um you can you can spin up an XMPPP server, very common protocol called Snickett and self-host this SNIK server which is basically like a call center server and download KIO which is a open- source app that

interacts with Jump Jump Chat. Jump Chat is an is an open-source um I guess they're a they're a um nonprofit organization that is that acts as a um a bridge between the internet and the PSTN. And they offer phone numbers and you can rent a phone number, lease a line, do whatever you would like. They're essentially a a SIP replacement. So, you can get a phone number from them for as little as a month and for as little spend of usage as $20. So, you get a jump chat number through this Kog app. Plug it in via XMPPP through your Snickicket server XMPPP protocol. Skip all the SIP stuff altogether. you never have to deal with SIP as a protocol ever

again, which is and was a total nightmare. um all the stuff if you've ever read any of the Michael Basil books and talking about Lynn Phone and any of the other um uh apps trying to get a uh an IP phone set up in lie of doing an uh an old school regular phone number. None of that's needed. you can now do a a jump chat phone number using Kogram and Snickett and it's absolutely phenomenal. So very very cool solution that I I didn't know was possible. Most folks don't know what's possible. So would certainly suggest that if you're looking into something like this jump chat kog snick it there's not much out there on it at all.

notify or as I've called it and continue to call it by accident and sometimes to annoy my friends and neighbors, Nifty. Um, NTFY, it's a really lightweight container that runs in Docker that really is just push notifications. Um, Firebase, Google Firebase is a really common push notifications engine system that is used by Google Play services and by Apple apps all the time to send push notifications. It's really good at what it does, which is why it's used so often. Um, but it is a metadata collection machine and it can collect time and date and IP address and all kinds of other stuff information if it's allowed to. Uh, and so well-intentioned people who are trying to

obscure their identities may be banging on Firebase and not realizing that that's what they're doing by exposing push notification functionality. And so, you know, when you're when you're thinking about doing something from a privacy perspective and you're building out something on graphine OS, consider using Nifty as your uh as your push notification service. Dropping it on a a VPS or virtual machine on your own Gotham Net works like a champ. Absolutely wonderful solution. Another one that works extremely well and actually interestingly enough is now owned by um by Proton is simple login. Um they they they are open source. They still offer their solution as uh a really easy to install containerized setup. Um but simple login is fantastic.

They have a um essentially they you can create as many email addresses as you would like um and they map back to a parent email address. So under perfect circumstances you would have a single email a different email address i.e. a different username for every single login that you have um and a different password for every login that you have. That way when there is a data breach and a leak of that information that that is the only instance of that login information that exists and you know all you have to do is change or delete that one instance and you're good to go. Simple login makes that really easy and you can self-host that. Um, go get

yourself a Elchipo domain, create your own, set it up, have it forwarded. One of the coolest things about simple login is when you set it up and you, you know, have an email that comes through to one of your um, one of your uh, I guess I don't want to call it fake email addresses, but we'll call it a fake email address. Um you can actually hit reply in your inbox and it will reply through that email address. Absolutely wonderful setup. Um such a cool such a cool project and uh very well supported and yeah you know you can create a random email anytime you create a new login for a new service. It's one

button click bada bing bada boom really easy to use. Absolutely fantastic. And of course, Bit Warden, also self-hostable, the password solution. There's no reason you shouldn't be setting up passwords and uh self-hosting that stuff, backing up on your own. I think I am getting to the end of my time here as I knew I would. I think that is it. And folks, one last mention because it really is important to get away from big tech. Do your searches through a metaarch engine and not directly on the big guys because you are being tracked and your information is being sold to the highest bidder and sometimes to the lowest. Cir a really great one. If you want to try one out to

see how good it is, try scour.ninja. It is free. you are not being tracked and it's a pretty good search engine. You can self-host your own. It is an open source project. And if you have any questions, if you want to rap about open source, if you want to tell me I suck, please reach out. My name is Edfreemantle. I am at laminer research. Edgar laminerresearch.io. I really appreciate you guys having me. Hopefully I gave you some cool information to think about, maybe some good ideas. would love to hear if you build something awesome on top of what I started. And uh yeah, thank you so much. Cheers everyone.