00:00 Hello, I'm Seth For Privacy, and welcome to Season 2, Episode 14 of Opt Out. Opt Out's a show where I sit down with passionate people to learn why privacy matters to them, the tools and techniques they've found and leveraged, and where we encourage and inspire others towards personal privacy and data sovereignty. Are you looking to explore alternatives to Signal and Herd of Session, but not sure what it sets it apart? This episode, we're going to sit down with Key Jeffries, CTO of Session, chat about their messenger and its approach to chat, encryption, and network privacy.

Welcome on to Opt Out, Key. Yeah, really nice to be here. I've definitely watched a few of your shows, and I'm happy to be here myself just to explain the differences and tell people in which kind of threat models they might want to use something like Session. So yeah, happy to be here. Perfect. Yeah, the messenger space inside of the privacy space is always a little bit of a hectic one, and it's a little messenger worry. So I'm excited to answer some of the, I think, key questions that listeners have, and that I had to get a clear picture of what Session is, what it's trying to do, and kind of what threat models and use cases it fits.

So I'm excited to dig into some of the technical approach and even a little bit of the kind of the economy or monetary security behind Session as well. And just, yeah, dig through a lot of that. But for those who might not know you, do you mind just introducing yourself and then telling us a little bit about what Session does? Yeah, so I'm the CTO here at Oxen. And, you know, as kind of a subproduct of that, I'm the CTO at Session as well, because kind of Oxen is the main developer of Session.

Session is basically a, it's a messaging application. You know, it's heavily focused on metadata security and encryption. It's originally actually a fork of Signal. So we originally started with their code. We've deviated quite significantly now because we've been forked from them for, it must be two and a half years now, and we've been developing our own code on top of what they've written. But yeah, we're really focusing on kind of a few key things.

One is Session doesn't require any phone number to sign up, as opposed to lots of other messages or email or anything like that. You basically just generate a public-private key pair. It onion routes all of your messages, which means that your IP address is kept secret from the kind of the node that you're retrieving and sending messages to. And also it's a decentralized architecture as well. So it doesn't rely on a central server, like most messaging applications out there, like, you know, Signal or Wicker or WhatsApp, or, you know, most of them out there rely on a central server.

So those are kind of our three main differentiating factors and an explanation of kind of what we do. Awesome. Yeah, I know there's a lot of differences now. And back when I first checked out Session, it was that mostly fork of Signal with the phone number stripped out. But a lot has changed since then. So I'm looking forward to digging into specifically the onion routing and the kind of the decentralized structure behind it, as well as that focus on metadata protection, since that's a big pro or con of most of the messengers in the space is how they approach the metadata, since most of them are encrypted for the message content itself.

So definitely want to dive into that more. But before we dive into the technical detail, I always like to kind of circle back and hear what it was that woke you up to the need for personal privacy. Yeah, I think kind of it would have been maybe five or six years ago, probably because I'm pretty young, ran into like some articles talking about the dark web, which was, you know, very illustrious at that point in time. And I think I just wanted to know more about it.

Like, you know, you read these kind of articles that are like very pop, like pop pieces that talk about the dark web as if it's this like really super scary place where you're going to lose all of your money and, you know, end up in having your kidneys harvested or something like that. But, you know, really the technology behind it is a very interesting innovation on decentralized networks. And obviously, when people are talking about the dark net, they're mostly talking about Tor Onion Services.

And getting into that was super eye-opening because kind of I think a lot of people will enter through that space of looking at Tor and then they'll become more interested in decentralized networks and privacy in the internet in general. So I think I kind of came through it with those eyes, like coming through the Tor ecosystem and then, you know, looking at how they had done stuff and wanting to apply it to different technologies and wanting to see how, you know, Onion routing and end-to-end encryption could be applied to different areas of the space.

So, yeah, that's kind of my introduction. Interesting. Yeah, I don't think I've ever heard anyone kind of entering through the Tor or dark web space. That's usually kind of where they end up later on. So definitely an interesting origin story there. I'm curious if that ties into maybe what prompted the creation of Session since obviously that Onion routing piece has been a key focus from the beginning. Yeah, and the decentralized aspect of Tor as well in terms of, you know, having this network of, you know, 7,000 or 8,000 routers which are run by different people all over the world.

So we essentially saw Tor as a really interesting network structure and we wanted to build something like that on top of a privacy coin at the time. So we were really interested in Monero at the same time, which, you know, your audience will probably be aware of, but, you know, this obviously is a cryptocurrency coin in the cryptocurrency space. So we were kind of interested in how could we build networks which kind of combine privacy on multiple different layers.

So we see you have the privacy on the currency layer, but then also having privacy on an application layer, which is built on top of an incentivized network. So we got really interested into that space after looking at stuff like Tor and stuff like Monero and Dash at the time as well and thought, you know, these could be combined to kind of create a suite of privacy products, which is what we kind of ended up doing, which is like, you know, creating this base layer incentivization, incentivized network, which is the service node network, and then kind of building out applications on top of that, like Session and LokiNet, which, you know, kind of use those resources in a similar sense to the Tor network to kind of provide service to these applications.

So, yeah, it was kind of looking at the entire stack and working out how to integrate kind of privacy vertically. Awesome. Yeah. That's an interesting thing coming from that Tor perspective again, and tying that in to a cryptocurrency and maybe let's just kind of kind of dive in to what separates Session from the other messengers, because I feel like obviously the key focus of Session is messaging. So that kind of normal question that we walk through here is pretty straightforward.

But obviously the difference is how Session accomplishes that and what the technologies are that Session uses to do that while protecting user privacy. So maybe we can just kind of start off with a quick comparison of how Session compares to something like Signal or maybe Threema as well. And then we'll dive into kind of the approaches that are unique to Session after that. Yeah. So from a user perspective, kind of said this earlier, but the kind of the three main things that differentiate us from other, almost other messaging applications is that, first of all, we have a decentralized network.

So, you know, in Signal, they have a bunch of servers that are run on AWS. And, you know, when you communicate with other people, your messages are flowing through their servers and your messages are stored on their servers as well. Although they're encrypted, they are stored on their services to be able to be fetched by other people if they're offline, for example. So we don't use that structure. We use a decentralized structure. We use the Service Node Network, which is essentially an incentivized network of nodes, about 1800 nodes posted all over the world, to store people's messages and also to do the onion routing aspect of things, which kind of leads nicely into the second point, which is we onion route all of your traffic in the application.

So that means when you send a message or when you retrieve the messages that belong to you, you're actually doing that through kind of a three-hop path, which is very similar to Tor, but it's also using the Service Store Network that I spoke about before, this decentralized network of nodes. So we kind of hide the user's IP address in that sense, because, you know, when you connect to, say, the signal servers, your device is leaking its IP address directly to the signal servers.

So they, you know, they know that your IP address accessed their servers at a particular time and also, you know, sent a particular set of packets or received a set of packets as well from their servers too. And the final point is that we allow registration of accounts. And this is probably the biggest point for most people. We allow registration of accounts without phone numbers or any kind of real world identifier, like an email address or a phone number or kind of any contact information that you might have from your real world.

A session account is basically just a public private key pair, similar to how you would generate it in Bitcoin or any other cryptocurrency. You basically just generate your identity on the fly and then that's the identity

10:00 that you use long-term in the application. And that's really beneficial for people who don't want to sign up for a phone number because in a lot of countries, you have to connect your identity to your phone number or you might use that phone number in a business sense or give it to a lot of personal contacts you might not want contacting on the application. There's just a whole bunch of reasons why you don't necessarily want to use phone numbers as the main kind of identifier in a private messaging application.

So yeah, those are the main things. Yeah, that phone number piece I know is kind of the stickler for most people when they're perching Signal because while it doesn't harm the privacy of Signal, of the actual messages and the actual things that you do within Signal, it obviously does at least make anonymity while using Signal much more difficult. And it's complicated to get a phone number that's not tied to your ID. And yeah, there's just a lot of pieces that go into that that are definitely a negative for the anonymous or pseudonymous usage of something like Signal.

So moving that requirement in session is definitely a big win, even if the privacy was just equal with Signal and the other things were just equal with Signal. That would, I think, be a big step forward there. But one of the things you mentioned is that you use this decentralized network for the backend. And I understand how Onion Routing has privacy advantages for users. And I want to dive into that next as well. But first, I'm kind of curious, why do you view a decentralized network as being useful or important when all messages end in encrypted?

Because for a little bit of context, I think the way that I approach Signal is that the centralization doesn't matter for most people because the messages, their content, and the vast majority of metadata is not accessible to the Signal servers themselves. So you're not giving up much, even though, like you said, you are revealing the IP that you're using, whether that's your real IP, VPN, Tor, etc. You're revealing that to Signal, but they're not able to tie that with specific messages, etc.

So maybe just why is that decentralized network useful if all messages are end-in encrypted anyways? Yeah, so you're definitely right. If messages are encrypted, then the kind of centralization or decentralization of the messenger matters less. But I think what we're starting to see more of is that governments are trying to step in legally to potentially shut down services. And if you have a centralized service that's funding the running of all of those servers or operates all of the infrastructure for those services, then it becomes kind of a centralized point of failure as well.

So you can imagine, and I don't see any legislation on the table, at least in the US right now, which is where Signal, like the Signal Foundation is based. But you can imagine a world, you know, in the next 20 years or the next 50 years where potentially like a despotic government gets elected or takes power and then they decide, well, like the Signal Foundation who runs all of these servers, well, we're just going to like, we're just going to like kill them basically, you know, we're going to shut down the entire infrastructure there.

And we're going to target that particular organization to say that you have to shut down your infrastructure that's running those services. In the session case, because the infrastructure isn't run by us, a government coming to us and saying like, hey, we want to, like we want you to shut down all of your service nodes that are providing network services to your messenger. We are basically just like, well, that's nice, but like we don't have any power over that.

Like we distribute open source software. We don't actually run the services. So I think in that aspect, it's not, I don't think it's important, super important right now, but I think it could become very important in the future. Yeah, that's definitely an angle I hadn't thought through. I think that it aids more the security and longevity of the service itself rather than necessarily the individual person using it as a messenger, which is a definitely important part that I hadn't considered about Signal is it does make them much more vulnerable to, well, you can't give us all the data about your messages, but let's just remove this as a tool that people can use outside of our control by telling them to shut down servers and preventing people from using Signal until maybe someone else spins up servers, et cetera.

Like it could be done, but obviously if you shut down the central servers of Signal, that would cut off the vast majority of users instantly. Definitely. So let's dive a little bit more into the Onion routing approach that I'll take. I mean, obviously for those familiar with the Tor network, that's how Tor is built is those layers of encryption that get peeled away as you go through that chain of decentralized and community-run servers and you'll take a similar Onion routing approach.

Do you mind maybe just kind of comparing how Sessions Onion routing compares in both the approach and the practical privacy to using the Tor network? And then maybe why did you go with your own version of the Tor network rather than just relying on the obviously robust and decentralized network infrastructure of the Tor network itself? Yeah. So the technical approach is like very similar in terms of like we wrap your messages in layers of encryption and they're peeled off at each kind of node that you hop through when you're transiting the network.

So that approach basically stays the same, you know, whether you're using technically the Onion routing protocol that we use in session is called Onion requests, but we will be transitioning to something called LokiNet later down the path, which kind of provides a little bit more flexibility to the protocol. But in terms of the actual privacy considerations and like why we didn't use Tor, the main kind of benefit that we see in using the server-stone network is that we maintain a level of civil resistance that Tor doesn't.

This is not to say that the server-stone network is entirely civil attack resistant and for those people who don't know exactly what a civil attack is, it's basically where one person is running lots of nodes and they're pretending to be lots of different operators. So like, you know, you could say like a malicious party like the US government for example or, you know, just a malicious actor who wants to gather data from the network would be running say hundreds or thousands of Tor nodes and then there's this chance that you kind of select one of or you select one of those for your guard which is your entry kind of node and then one of those for your exit node and that kind of allows for more simple traffic analysis to work out what your IP address is when you're, you know, kind of sending packets to the destination.

So those attacks in Tor, the only resources that you need is bandwidth essentially like a VPS and some bandwidth to be able to set up those nodes whereas in Oxen there's a significant or to run an Oxen service node which is used in session for the onion routing you need a significant financial stake to be able to do that. So right now it's about 15,000 Oxen which I guess on current prices is about seven and a half thousand US dollars and that might not sound like much to a state level actor and it isn't but the thing is with Oxen because, you know, 50% of the supply is already locked up in the service node network to have more, to gain more of the supply to be able to run more of the nodes you start fighting against like kind of market forces like the more you buy the more expensive the price of the token becomes and the less nodes you can run because of that.

Like it starts becoming price prohibitive even for really large actors to buy a large portion of the network. So yeah, we're basically adding in some civil attack resistance that we believe that Tor doesn't have and the thing with Tor that you've seen over the last kind of couple of months and years is that more and more articles are coming out or more and more research articles are coming out about how for example like the Tor exit node network like a large portion of the Tor exit node network is actually sniffing traffic or redirecting traffic to try and like scam users from crypto exchanges.

I think there was a recent research article that came out and it was something like 20 or 30% of the Tor exit node network was redirecting like people who were going to like the HTTP version of Binance like to go to like a fake version of Binance so that they could like steal their cryptocurrency and that doesn't necessarily reflect on the entire Tor network because that's only really talking about the exit part of it but because the like resources required are fairly low to be able to run really high bandwidth Tor nodes Tor relays Tor middles Tor guards you can see easier attacks occurring in terms of in terms of civil attacks so that's really where we see the main benefit from the Oxen service node network is just the financial resources required to own a larger percentage of the network are higher and therefore we feel like using it as a routing network is a bit of a stronger experience for us wouldn't you if you use the Tor network natively wouldn't you work around the vast majority of

the risks around civil attacks and the other common attacks because your the direct peer-to-peer connections between people messaging would be done as hidden services within the Tor network and never touching exit nodes so wouldn't you not really have to worry about at least the vast majority of civil attacks and other attacks that happen in the network and be able to piggyback off of all of that existing infrastructure anyways well this this presumes that the only part of the Tor network

20:00 that's being attacked is the exit node network. But if you have, like, it's hard to prove this stuff because obviously, you know, governments won't be telling people, hey, we're running all of these nodes on Tor. But if they are running a significant portion of relays or a significant portion of guards, for example, then even if you use KIDN services, if you have the guard and then the final hop, like after the rendezvous point and stuff, that's going to the other peer, you can still do, like, traffic correlation attacks in that sense.

It does obviate some of the issues with, like, we know, like, publicly that these exits are doing these malicious attacks. But there definitely could be a large portion of relays out there that are attacking the network or theoretically could be kind of civil attacking the network without much resources being required to do that. So, in a sense, the service node network strengthens against that attack as well, whether it's theoretical or actually occurring right now.

Are you all worried or do you do any kind of, like, active monitoring or attempts at mitigation to prevent a, basically, a slower passive civil attack within your network? Especially because these nodes do require that financial stake, you obviously would not want to reveal that you're civil attacking the network. But if you do it slowly and are able to evade detection, you ultimately will gain economically long-term because you get the rewards that come with running an aux in node while also being to surveil the traffic that's happening in the network.

And especially with session being, it sounds like right now, they're about a third of the size of the Tor network in node count. Is that kind of a concern of yours that you would essentially... I know it is harder to initially get into the network, but once you're in, you are financially rewarded for staying within that, even if you are a civil attacking node. So, any kind of specific concerns or mitigations going on there? Yeah. So, on the last point, like the network size, it's a little bit, like, simplistic just to look at node counts because the way that Tor does its routing is bandwidth-based routing.

So, if you're a node, like, is providing more bandwidth to the network, it gets used in more paths. So, even though the Tor network is, you know, like, I think it's 7,000 or 8,000 total nodes, like, if you add in the exits, you add in all of the middles, you know, every single type of node. The actual size, like, in terms of there's, you know, because I actually ran a really big Tor exit node for a while, so I know a little bit about the network.

You know, it's more like the top, like, couple thousand Tor nodes are doing, like, you know, I would say, like, 80 or 90% of the routing in the network just because they're providing the vast majority of bandwidth to the network. So, I think when you look at it in that sense, like, the differentiation between the network size, like, doesn't matter so much. It's more about, like, which, like, what nodes route a particular amount of bandwidth. And because on the service node network, we don't do bandwidth-based routing, like, each node is equally likely to route your traffic.

I think, like, the kind of node size argument or the size of the network becomes kind of very similar in terms of their size. In terms of the, sorry, what was the first point that you were making? I forgot about that. The other part, so, before I dive into that, actually, one quick response there and then we'll kind of break it up into another question. So, while Tor definitely does handle the way routes are built using bandwidth as a part of the metrics, it also uses the long-running reputation to prevent quick, simple attacks.

So, ultimately, you have this ramp-up period when you spin up a node where you'll have no chance of being routed and then it will slowly build over time as you prove yourself and show good uptime, have good bandwidth, that sort of thing. But that definitely is an important point that people understand that it's not an equal chance that you get every single node. Like, for instance, my Tor guard slash relay node that I run hovers usually between 0.25% and 0.3% of the probability of being used as a guard, even though there are far more guards than that because it is a very stable, long-running, high-bandwidth node that's proven itself.

So, there are definitely pieces that are good and bad to that because no new node can immediately become a key part of the network or even a part of the relay network immediately. It takes time to be able to accept that. Yeah. But it's not too long, though. Or at least last time when I was running guards on Tor, like, the directory authorities were giving the guard flag, I think, within, like, seven days. I don't know if it's changed from that point.

But, yeah, you're right. Like, there definitely is this, like, kind of startup process where you have all of this unused bandwidth. And then as you start getting flags from the directory authorities, your node actually starts to get used, like, way more. But I don't think, like, the spin-up time isn't that long unless they've changed it. Like, do you know how long it is before, like, you get the guard flag, for example? Yeah, I believe it's between seven and 14 days before you're allowed to become a guard.

And then the ramp-up period past that is usually about 30 days until you reach at least the beginning level of the probability that you'll sit at based on your bandwidth and other attributes. I actually, I remember the first part. It was basically, like, are we doing any active, like, monitoring of the network to understand whether there is, like, a long, kind of, a long-term civil attack going on? The answer is yes. You know, you always don't want to reveal, like, too much about, like, what you're specifically looking at.

And I think this is, like, similar with, like, the case with the Tor directory authorities and how they kind of manage that as well. But it's, the important thing to understand about, like, the civil attack protection is that it's just a protection. It's not, like, 100% foolproof, right? We're just trying to build a system that is slightly better or, like, like, better than what we think that Tor is providing, essentially. So, yeah, there are particular circumstances where, you know, if you had an attacker that was extremely patient that was buying up large portions of the network over time, that would be much harder to detect than someone who just, like, came in, like, gung-ho and just, like, you know, bought a massive portion of the supply.

But from what we have seen, we don't think that is likely. Just because we talk to a lot of the operators, we know who a lot of the larger operators on the network are just through, like, kind of social interaction. Like, you know, they'll come into our channels and ask us, like, questions about running, you know, running Oxen service nodes. And I think we've seen kind of over time and match those up to kind of real-world identities. So that would be, like, an argument that Tor would make as well.

Like, you know, that they know a lot of the people are operating the largest kind of exit nodes and guards. So a lot of this does come down to, like, there is an element of, like, social, like, you can't just design everything to be, you know, 100% technically secure. You do need these, like, kind of social fallback layers. So, yeah, we have those as well. Awesome. Yeah. Yeah, I think that the approach makes sense and is definitely interesting. And, I mean, just civil attacks are always going to be difficult in an anonymous or pseudonymous network like this.

Obviously, you can't permission the people who join and perform part of that role or else it quickly breaks down into just a regular centralized permission system. So, obviously, you'll have the same struggles Tor does with some different approaches changing up, at least, the game theory behind that. Yeah, exactly. Like, that is the 100% like, way to solve this problem is just to, like, get everyone who runs a status node to KYC, like, when they run it.

But it's really not, like, it's not the way you want to go about things just in terms of, like, building a private network. You don't want people to have to KYC and to run a node. And even then, like, you could have, like, front people as well. Like, you know, the US government, like, hires, like, a couple of people to be, like, node operators on the surface and then they still, like, control the nodes in the background. So, even then, it doesn't solve all the problems.

Yeah. Yeah, for sure. It just introduces different risks and kind of breaks down the core. value proposition of the protocol itself. So, migrating a little bit off of the network approach itself. I know that y'all started out as a Signal fork and used Signal's own protocol to enforce entity and privacy and handle metadata and all of those pieces. But you've since migrated off of Signal's protocol to your own. Do you mind just kind of sharing why you decided to migrate off of such a proven and well-understood approach to messaging privacy?

and then maybe break down a little bit of how your new approach compares with what Signal does. Yeah. So, the primary reason that we migrated off is simply state management. Signal has a centralized server and most, because WhatsApp uses the Signal protocol as well, or we think it does at least because it's not open source so you can't really check, but they've promised. So, yeah, it's basically state management. Like, when you look at the Signal protocol, there's a significant amount of state that is used to kind of ratchet your keys in every session or every message that you're talking to.

So, you have these things called, like, pre-key bundles, which are traditionally stored on the Signal servers or the centralized server that you're using. You'll

30:00 also have like the entire message state which is where kind of the key rotation happens to provide like the kind of properties that they provide in the signal protocol like deniable authentication and perfect for secrecy you really kind of need consistent message state because you'll be rotating keys during those protocols and if someone misses a key rotation then you can potentially have a client which encrypts for like encrypts for a key that doesn't exist or that the other client doesn't have access to yet and really what happens in in session is because we have this decentralized network of 1800 service nodes and the swarm that is kind of responsible for storing your messages is like continually changing and then we also have like a time to live on messages as well of 14 days so if you're offline for more than 14 days then you won't like the messages that are on the swarm you won't receive them like if someone sent you something that's more than 14 days old it just gets cleared from the storage server so there's a bunch of places where state can be messed up

essentially in the signal or in this in the session kind of decentralized server architecture which makes like management of a uh ratcheting key protocol extremely difficult um so that was kind of the primary reason that we went to a much more simple end-to-end encryption protocol which is essentially encrypting just for the long-term key and not ratcheting um the keys you know every session or every message um depending on how you implement uh the signal protocol so a really quick note before we go on i just want to make sure people understand what that that ratcheting thing that you're you're uh referring to is so just a quick note for those who don't know that term basically what signal does is it uses a double ratcheted encryption protocol that basically builds a connection between you and the person you're sending messages to with a specific key and then over time you keep swapping out that key with a new one is provably yours but also cannot be tied back to and cannot reveal previous messages or future messages so

essentially you keep breaking that link and if one of those keys was taken somehow they couldn't use that key to decrypt all of your previous messages or all of your future messages it would only be for that short time period before you um switched to a new key in that process so that's what that that ratcheting term that uh you're talking about is there in the this the signal protocol right and then understandably when you don't have those central servers to handle that key exchange um and to handle the state of those keys that gets really tricky within the the session protocol approach yeah and and kind of the like the reason that signal um does this kind of ratcheting like the main properties that they're looking for uh perfect forward secrecy and uh deniable authentication or deniability um so we we don't get both of them we don't get those um in in the session protocol that we're using but when you actually look at kind of the practical application of these um like these protections you start to see that

like they're the practical cases are somewhat limited especially in the context of the session uh like the session network like so if we were to look at deniability which is probably the weaker of the two um protections like deniability is basically or cryptographic deniability is kind of this idea that you know if i was to take like a message transcript to like a court or like to some kind of third party that because you cryptographically signed this message it's like a proof that you know that person actually did that thing the practical application we haven't really seen much practical application of cryptographic deniability though like we've actually seen people take cryptographically deniable messages to courts and courts have just basically said well we don't care that it's like cryptographically deniable this person did or didn't send this message we just care that like the screenshots are on like the participants like devices or something like the the burden of proof doesn't nearly ever get to the

cryptographic deniability aspect of things so i think like that it's a much more kind of theoretical um protection like that hasn't really borne out a use case in real life i think the the like kind of more protective thing that you could do is like allow for like people to forge like fake uh kind of fake uh screenshots or something because that tends to be what's used in in courts like they don't really go down to the cryptographic level that often um on the perfect ford secrecy front um it does like there's a there's a bunch of conditions that need to met needs it need to be met for perfect ford secrecy to to kind of matter in terms of protecting your um historical messages so first off it requires the local like it requires the long-term key of the device to be compromised and the way that you would generally compromise the long-term key of the device is by getting like full kind of access to the device itself um the only place that we store um the long-term key in session is on the device itself it doesn't go anywhere else so necessarily to get access to the

long-term key and this is the same in um signal as well it's stored locally on the device so to get access to that long-term key you kind of necessarily need to get access like kind of near root level access to the device or there needs to be like some horrific bug where you're like leaking out like the key which would be very hard to happen without uh it being noticed then so say you have access to the local device if the user doesn't have disappearing messages you turned on then there's a very high likelihood that because you have local access to the device you can just read the messages out from their database um even if it's encrypted you can just wait for them to in import their pin and then read all of their messages out of the device itself so you're not like breaking future messages but the database locally on the device has to have messages in it right um and if you have those messages on your device when they get local access to get your keys they're going to get the messages as well so

the person needs local access to the device you need to have disappearing messages turned on and then the person who's attacking you also needs the ability to scrape encrypted messages from the network as well because what they're doing is like they're grabbing your local device's key and then they're using that to like trial or to decrypt the messages that they've scraped at the network level um and in session's case uh you know for example if you're a malicious isp you can't get access to the um the messages because we're actually using onion routing in that sense so you wouldn't get access to the you wouldn't get access to um content that you could actually decrypt at that point you would actually need to be a service node in the network to get access to a person's um you know encrypted messages um and that is going to have a financial um you know contribution requirement as well you'll need to be in uh you'll need to probably be in every swarm because swarm allocation happens randomly which is

basically like the swarms are like the decentralized party who stores your messages it's not everyone who gets access to everyone's messages the network is kind of sharded up into different levels so you would need to have um swarm access to that particular user's um messages as well which is going to require you to kind of own northwards of like 10 20 of the network as well so you know when you look at those different aspects of perfect forward secrecy um you see that it is a protection so in the case where you have a network scraping attacker you have local device compromise and the user is turned on disappearing messages signal is stronger than um session in terms of the protocol that it's using but because those cases are so unlikely and because we're using a decentralized network it's really hard to manage that state we think it's a good enough trade-off um for users so i mean i know i went pretty deep into that but i think it's important to kind of understand like that what like what the differences are in

in the practical cases in which they apply and we have a little article as well um on the internet if you look up the session protocol technical details that kind of goes through the symbol detail as well so yeah no that was great i mean that was a one of the key questions that i had because obviously moving off of a well trusted and well vetted messaging protocol to your own especially as a small project can kind of be viewed as obviously not actually rolling your own crypto but kind of be viewed in the same in the same uh way that you're you're deciding to do things your own way and going away from something that is very well understood and and well trusted um so i i it's it's great to learn the what not only the why and the what but the the um i guess the why of how it still is a similar approach in the actual end encryption but does have those trade-offs that may not have real world impact to most users um so it's good to get a better understanding there i think you did a great job breaking down the the

technical and the nuance into uh quite approachable terms yeah and and just on the like the rolling your own crypto stuff because i know that that is a separate concern like for example um you know like telegram has rolled their own kind of ratcheting protocol which is only used in um secret chats um called mt proto 2 i think that is like i would i would never try and roll like i would never let us like try and roll our own ratcheting protocol just because the protocols are like very

40:00 complicated when you actually look at like the signal protocol in terms of what it's doing, pre-key bundles, ratcheting every message. Getting something like that right is really hard. So, you know, but with our approach, like it's just like the encryption is very simple. It's still end-to-end encryption, but it's essentially like one or two calls to Libsodium, which is an audited cryptographic library. It doesn't contain like nearly the level of complexity that, you know, rolling your own kind of ratcheting protocol does. So yeah, we did really did try to keep it simple and that's been audited now as well and come through as looking good. And because it's so, it's because it's basically like 10 lines of code that all of the encryption happens in, it's extremely easy for the public to audit it as well. So yeah, that's just kind of, you know, what I want to say on the rolling your own crypto stuff, because I know that that can be scary, you know, like, are these guys like doing something weird that's, you know, going to get them like,

you know, pwned from like hackers or something like that. But yeah, it's really a simple protocol, the session protocol now. And those keys that you mentioned are that long-term key that is important to keep safe. That is tied to the seed phrase that you get when you create an account and to that public key that you get as well. So keeping that seed phrase safe is the only thing you need to restore that. And the main thing you need to make sure no one gets their hands on in order to be able to decrypt messages, correct?

Exactly. Yep. And your session ID is basically just a public key or a representation of the public part of your private key, which, yeah, you write down with your seed. Let's take a quick break from this episode to chat about the sponsors of Opt Out, Cake Wallet, and LocalMonero. Cake Wallet is a key tool that I use daily, as it allows me to easily and quickly use Monero for private by default payments. It's available in both iOS and Android. It is a fantastic way to get started buying and using Monero with a simple and easy to understand user experience. I regularly onboard new users to Cake Wallet and hope that it will help simplify and ease your journey into cryptocurrency.

If you're interested in purchasing Monero for the first time or helping to bring others into a parallel economy, I'd recommend you look at using LocalMonero, like I do, to buy and sell Monero while maintaining your privacy and avoiding invasive exchange surveillance. LocalMonero is entirely peer-to-peer and is an important part of opting out of the surveillance state and into a parallel economy. Thank you to both sponsors for their incredible support and partnership. And I hope you'll take a moment after the episode to learn more in the show notes or at optoutpod.com slash sponsors. So what are some of the, maybe some of the core limitations with Session as opposed to something like Signal? Maybe a missing feature or I think you broke down a lot of the specific limitations that generally aren't real-world or impacting, but important to know about the approach to encryption. But any other limitations that users should be aware of when they're approaching using Signal?

Yeah, I think like there's a lot of features that we have, like we spent a lot of time working on the security side of things. So we haven't necessarily, or the security and anonymity side of things. So we haven't necessarily caught up to kind of the mainstream messages in terms of all of the features that they provide. One of the major ones being stuff like voice and video calls, which we're actually working on and probably will be out by the time that this podcast is released. But, you know, those are things that we haven't been able to get as quickly as some of the mainstream messages like Signal.

I think we're like, we're working towards more feature parity now. But that would be one of the biggest kind of things that's, that's kind of most people bring up with us is just the user experience. You know, with these more centralized messages, just they've been able to integrate more features over time that we haven't gotten to yet. But I think one of the biggest things that we can't do, which is inherent in our design is Signal really heavily relies on your mobile like contact book. Because when you sign up for the Signal, like, I think they send out like messages to your contacts, or if your contacts are already on Signal, they get a message like, hey, this person like is on Signal now, like chat to them. And although that's like, I don't, I don't like it, because I think it removes some of the anonymity from the messaging application. It's a really powerful tool in terms of building social networks. And because messengers are so reliant on, you know, you being able to talk to your friends,

it's a really powerful thing for them to be able to like bootstrap into their messaging application, your existing list of friends. And that is something that we can't really do, because, you know, your signal or your session ID isn't linked to any kind of real world that identifier, and we don't want that to happen either. So I think we really need to work on building tools that allow people to make their session ID known if they want it to be known and, and make that process of like finding friends on session or finding communities on session much easier. Because I think that's something that people struggle with right now that they don't struggle with as much on applications like Signal or WhatsApp, or, you know, name your privacy messenger, basically, or your messaging application.

Yeah, I know that feature of notifying your contacts when you join Signal and vice versa is one that's a bit divisive within Signal. I mean, it is important that people understand that it is done in a way that Signal never has access to that contact data. So even if you do enable that, they're not getting the phone numbers and names and everything of your contacts. But it uses a really interesting method to be able to do that in a way that they can notify people who you're connected with without them actually knowing who you're connected with.

So it's a cool approach, but obviously the downside is, like you said, you may be creating a Signal account that you don't want tied to you. You don't want people who have your phone number to know that that Signal account is you. And if people don't realize the implications when they're going through and give access to contacts and all of that, it can break some of those or it can create some links between their Signal account and their real world identity that they may not want to make.

But yeah, like you said, that's a key difficulty for bootstrapping something like session. What's kind of the key way right now you recommend people get the word out on that they're using session and connect to groups and that sort of thing since that native method isn't available? Yeah. So I think we've been kind of, I mean, there's the kind of obvious front that it's just like word of mouth kind of stuff. Like tell your friends that you're on session and give them your session ID.

That's kind of the most basic thing. But I don't think that's enough. And I think what we've been working on recently is trying to really push like the community creation aspect inside of session. So we have this kind of thing called the open group server, which is kind of a self-hostable open source server that you can run inside of session. And then you can kind of have communities of like up to thousands of people inside of session. So, for example, like we have various groups like the LokiNet group, the politics group, you know, the outdoors group, you know, like the prepping group.

Like there's all different types of groups now and building communities inside of session is getting easier and easier. So I think eventually people who download session and don't have any friends yet on session will be able to join into more of these communities and they'll be able to create their friends group there. Because the biggest thing that I think, you know, messaging applications suffer from is like people think it's a really cool idea.

Like they're like, oh, yeah, privacy. Like I want that, obviously. Then they'll download the messaging application and then they have no one to talk to because like they're so sticky, like messaging networks because all of your friends are on them. So if we can bridge that gap by giving them access to communities that they might like. And this is how like Telegram got a lot of its users as well. It's like they have these really big channels that people go into to talk about different things.

And although you might not have any friends on there, like you can join these communities. And then once you join the communities, it's easier to get your friends into the messaging application because you're like, oh, there's all of this cool stuff on this messaging application. You know, like they have these massive communities. Come and join me. So that's really kind of what we've been working on in the on the on the kind of community building side of things.

So what are some of the other kind of settings or features that listeners should take a look at or just really get familiar with when starting to use session? Yeah. So I think one of the bigger ones that we're will be releasing probably by the time that this podcast is out is session voice and video calls. Nice. So really happy to put that out and happy for people to test that. But the main kind of draw card, I think, of session is just the anonymity aspect.

And there's a lot of features that we've built into the application to take advantage of that anonymity in terms of, you know, when you're adding someone, you're not adding someone based on their phone number. You're adding someone based on their session ID. And I think that's like that's kind of the main stuff that we have in here. And then big communities as well that I talked about with open groups that you can kind of discover out of that. So, yeah, I would really like if people looked into that stuff.

And then we have closed groups as well, which are basically end to end encrypted groups that are kind of much smaller, which deal with kind of 100 people. And you can create your own little communities as well. So, yeah, I mean, there's a lot of features to look at in the application that you'll kind of find out naturally. And then you can also see some cool stuff. Like you can see your path, like which different countries you're routing through and the IP addresses that you're routing through as well, which is a bit different from other investors.

50:00 applications. I haven't tested this myself, so I have no idea the answer to this question, but do you support multiple accounts, especially with the kind of private public key model? It would be very easy to, from the same key, have multiple public keys and kind of separate pseudonyms that way. Is that something that's supported now or that maybe you have plans to support? Not right now, but it is in the future plans. Right now, I mean, you can kind of do it ad hoc.

Basically, you would just generate one session ID and then delete your account and then restore from the other public-private key pair that you've created, but it's not all managed in the same client where you can just decide which identity you want to send a particular message from or have different inboxes for different identities, but definitely something that we want to do in the future and that we will be doing in the future as well because, yeah, that is a really powerful feature to kind of have, you know, you could have like a more public session ID that you post everywhere on Twitter, for example, and then you can have like a more private account that you only deal with your personal friends with. Yeah, yeah, I definitely see a lot of value there and something that I think would set it apart from most messengers because there's normally not multiple accounts supported within these things natively, especially when there's a phone number requirement because obviously that gets really annoying and tricky quickly.

So that would be a cool feature to see there. Now, last question before we dive into some listener questions is just, is there a way that, we talked about it a little bit, but what is the process like for people to self-host session nodes and what benefits are there for them for doing so and the network if they do go that route? So there's a few things that you can kind of self-host in session. Like we try and keep it that kind of any default service that we run is able to be self-hosted as well. So we run some open groups on the messaging application, like the official session ones, the LokiNet ones, but anyone can set up their own kind of open group server. And that's, that's just a, you know, if you have a VPS, you just downloaded that package and run it and you can have an open group server up and running. The that's the same with the session file server as well, which is kind of the way that we store attachments in session. Anyone can self-host that too. Outside of session, like if you're looking to run an aux and service node, there's a really good guide on our doc side on

how to do that. Basically you just need the required amount, um, aux and or, um, you can also kind of have a split contribution where you have a percentage of the, um, amount needed and then you source, um, contributors, um, elsewhere to your node as well. Um, but basically it's just a VPS that you run has to have a specific amount of resources and then you run a dev package, which will install LokiNet. It'll install the, um, session storage server and then the, um, aux and service node components as well. Um, and you can run that. So yeah, I know, um, I was having a look in that Twitter thread and some guy was saying, yeah, I run an aux and service node and there's, you know, hundreds of other operators out there, um, who run aux and service nodes, including me. So it's, um, you know, not too hard to, to get involved in that process of running a service node, or if you don't want to, um, kind of commit the, the aux and required, um, to run that, then you can look at running some of the session

infrastructure, like an open group server, where you can have your own little communities, um, or a session file server as well. So yeah, lots of, lots of ways to get involved. If you have kind of spare bandwidth or, or VPS capacity. Yeah. Some of the key benefits of being at a centralized network and not being just this decentralized set of servers is people can give back or just kind of do something fun as a hobby or whatever approach they take for, for why they do it, but you can actually contribute to the network, which is always a fascinating piece. And I think it's a big part of the draw in cryptocurrencies running your own node. And I'm just getting familiar with the software that runs behind the scenes. So glad everything is, well, I'm assuming, but everything is, is free and open source. I assume of the, the code that underlies all of these pieces.

Yeah. Uh, nothing. I don't think there's, well, I know that there's no, um, closed source code in any of our, um, repos. So yeah. Um, anyone can run any aspect of the network. And if, if, you know, if we, you know, somehow fall off the edge of a cliff or something like the entire, um, team here, network will keep running and, and people will be able to, to fork the session clients and, and use their own, um, services as well, or run their own open groups and do all of that stuff. So yeah, everything's open source free. Do all of our, um, development in, in the public as well. Um, you can see every pull request that we put in and review it yourself, um, to see what code we're kind of applying, um, to the network. Um, to the network.

Nice. Yeah. That, that segues nicely into the first listener question, which was just what are the legal attack vectors for, uh, or from governments, uh, since session is a legal entity. Um, and then you mentioned it briefly there, but how survivable is session as a tool? If for instance, the team was told to, to shut down operations by, um, by the government where, where y'all are a legal entity under. Yeah. So, um, essentially like we don't really hold a very, like we don't hold any privileged position in the network. Um, the service node operators are the ones that decide to run our software. So if we were forced to push like some sort of ridiculous, like backdoor or something into the software, the service nodes can easily just say, well, we're not going to run this. Um, and all of our development happens open source as well. So if we were forced to put in a backdoor into the software, um, it would be noticeable if it would be noticeable if it was going into the main kind of GitHub repository. Now there is attack vectors that don't really involve us that I would tend to be more worried about, which would be because all of our code is open source.

And we do distribute applications, for example, through the app store and the Google play store. Um, you could imagine like, you know, potentially a government in like in conspiracy with, uh, the Google play store, for example, could fork session, put a backdoor in themselves and then distribute that binary, uh, to people, um, through the Google play store. Um, the protection that we do to get around that is that we sign all of our releases, which are, um, signed from team members keys. I'm one of the signers on that. Um, so that they would need to compromise us as well in that circumstance. And then if we were compromised, um, there's always the, you can always build your own software as well. Um, from kind of the open source repositories.

Um, and you can compare that against, um, um, the binaries that we're producing, um, or that are distributed through the app store as well. And there are people that do that. Um, and there are people that are on our team that are in different jurisdictions who, um, we could potentially signal to that something funny was going on as well. So legally, because we are an open source organization and we don't run any of the network infrastructure. Um, we are much more protected against these kind of attacks.

Then I would say like some other, um, organizations that are more centralized in nature and that run all of the network infrastructure. Yeah. The signing of APKs especially is, is definitely a vital piece of things. People can make sure they're actually running the code that they're seeing, um, in the repo and a further step are reproducible builds. Is that something that y'all do right now for APKs where people can actually build the APK itself and validate that that that is exactly what they're being given in like the Google play store?

Or an F-Droid or whatever other avenue they're, they're getting the app itself from. It's not something that we do right now, but it is something that I really want to do. It's just technically reproducible builds. Like they've made a lot of progress, I think in the last couple of years. Um, but there's, I think there's still a bit to go. I think signal only does reproducible builds for Android right now. I believe, um, I guess it's a little bit less important on iOS because, you know, sideline, sideloading iOS apps is, you know, not, not often done. Um, but does, I guess, provide like a way for people to authenticate that the IPA that's running on their device is actually the IPA that we intend to distribute. Um, but yeah, definitely something that we will be looking into doing more of. It's just like, it's more of a technical, um, kind of boundary that we're yet to kind of, um, accomplish.

Right now. Yeah, it's certainly not an easy thing. I mean, reproducible builds are kind of the, the Holy grail of verifiability, but they're, they're not done by most projects for a reason. Cause it does take a lot of time and effort and re-architecture of, um, of a project to be able to, to build those in. It's, it's not something that's easy, but as I think a very important thing within any kind of network like this, especially in your case, since there at least is some legal avenues of attack, um, since you're not just an, an anonymous, small open source project. Like you are a legal entity. So it would be great to see that, but I definitely understand how difficult that is, is I've kind of walked through that process in the Monero community as we. Introduce reproducible builds. I say we, I was not at all involved in actually enabling them, but I've been verifying them along the way. Um, so I know that that's a very, a very in-depth and involved process, but I would love to see that long-term.

Yeah. Definitely something that we, um, definitely something that we, um, want to look at is kind of overhauling the build system. So there aren't like, yeah, components of the build system, which are, are not, uh, which are essentially happening differently on

1:00:00 some like real devices than they are on others yeah it's it's not an easy problem to solve for sure um last listener question i have for you is is more around aux in itself rather than session but obviously the aux and network underlies session as a tool so i got a lot of feedback and i've heard from a lot of different people just questions around both why a token is necessary and then what kind of percentage of supply or issuance your team actually gets or has gotten out of the network for that um i know we touched on a bit of the token being a tool against civil resistance uh but maybe if there's any any other pieces there that are important and then maybe some details about kind of what what stake in the network what control of the network's uh supplier issuance your team has yeah so like the reason that we created um token is basically because we needed a way to bootstrap um the server network and we thought that the best way to bootstrap that was to provide it to provide a financial incentive um for that bootstrapping um so the way that the block reward works is that

um every time a new block is created um a service node will receive 16 and a half oxen um and that is essentially the reward that they get for hosting or like providing network resources like bandwidth to the network or storage capacity uh for session for those um 14 days that message uh that the 14 days that uh messages are stored on the network um so with another model that you could have looked at for example is like and i know i saw in like a lot of your comments i think it was like a fair bit of bitcoin like people talking about like you know you don't need a you don't need a shit coin for this as they say um like you know several people have said like oh you could have built this on the lightning network for example um but that would necessitate uh people actually paying to send messages because they're consuming network resources and presumably the people that are providing those network resources if we want to have this civil attack resistant network need to be um paid to to do that and the issue with that is

like it's very hard to bootstrap a messenger where people need what where people need to pay per message that they send um the user experience like is just very complicated as well like you need people to you know get bitcoin get on the lightning network and then like set up a channel to be able to do that first which is pretty complicated compared to the um like experience of people just downloading a messenger using it and not necessarily even knowing that there's a blockchain you know backing this network or financially rewarding this network so we thought that that was a much more kind of sound um model to go with and you know as i spoke about before we didn't want to go with like a completely free um like model like tor is doing where it's just like kind of reliant on the altruism of node operators we wanted to have like this network where we could actually provide a little bit more of a protection against civil attacks so um we did look at a bunch of network structures and decided that this was the best one for us

um on the like what percentage of tokens do we get um every seven days uh there's a reward that goes to the oxen foundation um which is as i said it's you can look it up at the optf.ngo it's um a registered charity um or a registered knob for profit in australia which has its own kind of reporting requirements but it's 10 of the block reward um that we get um on aggregate if you were to look at all of the blocks so yeah we've we've tried to maintain as little control over the network as possible like some of that oxen could be used to run service nodes um but the the foundation which is um has a has a cap of only running it can only ever run more than it can only ever run up to 10 percent of the um nodes in the network and that's listed in its constitution as well and it doesn't actually have that much um oxen either um so yeah that's that's kind of how we um you know structure the network um so that we're able to consistently develop um things for the network and then also um provide services to people that are

using session and stuff like that in in a free um way which is able to you know help us get more users on board into the application yeah yeah i know that's uh i think an important one for people to understand the the why but also just the how of how much y'all get uh what that that means long term and and importantly people at least get the transparent side of that um yeah and and i mean the other thing that i saw a lot in the twitter thread was like is this a pump and dump you know like where is you know where is all of the um you know are these guys going to be around forever we've been around for four and a half years now and um because of that structuring that we have like we're not just some sort of for-profit company that's going to run away with you know all of the money that we've kind of raised to build this application i think you can be pretty sure that we're in this for the long run um we actually do care about people's privacy and work every day trying to improve that so um yeah i don't think at least as far as i know

we're not a pump and dump you know so one more question around that and just kind of an impromptu one and one that has become i think a broader debate with this is an aside but zcash is exploring moving to proof of stake and they have a founder's reward kind of similarly to to oxen and the issue is when you have a proof of stake network and a central entity has a foundation reward that they get from every block it leads to this spiral of that central foundation constantly having a higher and higher percentage of the network and that's a higher percentage of the block reward etc etc is that something that y'all are i don't really know how you mitigate that um but is that something that y'all are are worried about or approaching or trying to be transparent about the risks of having such a large percentage of the network over time that you that those funds could be used to symbol attack the network or to to um control it long term yeah it's not something that we're super worried about just because all of the foundation wallets

are um you know we use a system we use wherefore from an era so um all of the like view keys for the foundation wallets are published and then we get audited every year um which show like the financial transactions that are going through those wallets as well um and also like in the constitution of the foundation we limit the percentage of nodes that we can stake as well so it's not like a um growing like demand that we're always capped at like um less than 10 percent of the network so we can't actually grow beyond that then we'll just have oxen like sitting around and i think um it might be more concerning like if the foundation was just like an anonymous entity that didn't have like real people behind it but because it is a registered australian charity and there's all these reporting requirements around that financial auditing requirements around that i think there can be a bit more trust in in you know what we're saying in terms of how we're interacting with the network and and the rewards

that we're receiving as well so um i think that's the main kind of way that we're tackling that issue is is through kind of social consensus and people understanding kind of our role in the network and being able to audit that independently through our wallets and also through um the independent auditors which which provide reports of our financials each year as well so yeah that's that's kind of um my response on that one so one more quick question around that um does that publishing of view keys allow people to see which nodes and how many are actually linked back to the the foundation wallets yes uh it should because actually the service node aspect of um oxen is because we have to audit the amount of people or it's certainly the amount of currency that someone's staking those transactions optionally expose the transaction private key which allows for amounts to be audited and um and for the contributor the contributor addresses maintaining the tx extra as well um in the clear so both those aspects allow for the service node aspect of the oxen network to be uh essentially

they're non-private transactions because they're trying to commit um you know oxen to to be publicly auditable um once you go back from those transactions um you know you you get back into the anonymity set again um but while you're actually staking oxen all of that is um public publicly viewable and auditable because it needs to be for the the um network to continue operating so people aren't just saying you know i have 10 000 oxen i'm staking it but then not being able to audit whether that's actually occurring or not so yeah awesome yeah that's a good response i was curious if that could be kind of an end-to-end audit as part of that but it sounds like there's a is a solution to that which is important for people in the community to be able to hold y'all responsible and it not just be a a blind faith or blind trust so good to see that you've approached it with the technical perspective of transparency and not just the the trust perspective there um well that is the last question i had for you i really just

want to end with giving a chance to to share how listeners can help support what you're doing with a session yeah so um we have a pretty big uh following on twitter so if you look up um i think it's session session underscore app on twitter we have a twitter account there that you can follow if you just look up session on twitter you probably find it um would also love people to join session as well and we have some open groups there to discuss um the session messenger and other topics too so if you jump on session and then um join the kind of default um session group and say hello there um be super keen and i also have my um session id posted on on twitter and a bunch of other locations so i'm

1:10:00 to my GitHub as well. So if you want to reach out to me or you have any other questions that didn't get answered in this interview, give me a ping on session. And yeah, I hope to see more people trying out the application or at least considering the points that I brought up today in terms of which threat models session might be kind of interesting for you and your personal case. So yeah, thanks for having me on, Seth. Yeah, awesome. Thank you so much for taking the time out to jump on.

I know time zones make things very tricky. You're very accommodating. So glad to be able to walk through, I think a lot of both simple and deep technical questions about why session approaches things the way it does and how it makes these trade-offs both positively and negatively from things like Signal. So it's very helpful, I think, to help people, like you said, assess where this fits, if this is a tool that will replace Signal or maybe fit for a different aspect of their life to separate identity or kind of where the key pieces fit with that.

But very excited to explore more and I think much more interested myself in using session after being able to have such an in-depth chat with you. But thanks so much for coming on, Key. Thanks, Seth. Lovely to be on. Thanks for listening and I hope you enjoyed this episode of Opt Out. If you did, please take a moment and subscribe to the podcast. Or if you're already subscribed, share it with one friend or family member this week. As always, you can check out the link to the guest content and contact info, as well as links to all of the tools we discussed in today's episode.

Now get out there and opt out this week.