Setting Up and Using the PoC to Browse Safely

Great. Slides are working. Awesome. Hello, everybody. My name is Tino.

I'm from the Hopper team, and today I want to show you how you can get started with the current version, the POC of NOSY CPN, set it up on your laptop, if you're willing to follow my lead here. Otherwise, just look at what I'm doing. It's going to be an interactive session, and ultimately, get a working VPN connection through the Hopper network going. So, again, this is an interactive session, so I will have some practical steps where I need to sit down and show you some terminal interaction. If you want to follow along, there's a couple of tools which you will need to have installed.

So make sure you have internet connectivity. Depending on whether you're on Linux or macOS, you need some different tools installed, so make sure you do that while I'm talking, and then you could follow the step-by-step process. You will need a Hopper node to use the NOSY CPN. We have a couple of demo nodes prepared for you. So if you need access, if you don't have your own Hopper node, then there's my colleague around here somewhere who has handouts.

So just make sure here, get a handout from Mikhail. It has the connection info for Hopper nodes, which you can use to get your VPN connection going. Okay, very rough. I will give you an overview of what NOSY CPN actually is. If you are interested in that, you can also, on Wednesday, see another talk by Sebastian Bergel about the NOSY CPN.

I will give you some very high-level information of what the Hopper network does. That's important to understand because it's an integral part of NOSY CPN. And then we go into setting up the VPN on the laptop. Afterwards, I'll give you a little bit of an outlook, what's coming next for the product, and then Q&A. Hopefully, there's some questions.

Okay, so everybody here has probably used the VPN. Let's have a show of hands. Who has used the VPN in the last year or so? Okay, everybody, great. Who is using more than one VPN?

Okay, half of the room. Who has built their own private VPN for their personal use or maybe friends and family? Awesome, at least one person. Well, Ashton, I know you're very privacy conscious already having used VPNs and multiple VPNs. But the general VPN architecture in the market, by the way, this is a $50 billion market we're talking about, is counterproductive in terms of increasing privacy.

It's meant for you to tunnel all of your internet activity through single servers, trusting a single provider, a VPN provider, which is a company somewhere you might not even want a relationship with. So it relies on you having a lot of trust in a single company, single server, to do its job and not harvest the data you're pushing through. In my opinion, this is not the right way to do it. And that's why we are building those VPN to improve the state of art in this massive industry and improve the general privacy consumers can expect. So that's the reason why we build those VPN.

We want to remove trust from the equation. As a VPN user, you shouldn't have to trust anybody really, because what you want is a safer infinite browsing experience and not handing over your data to a company which you have full trust in. Communications are private right now, and we want to really make it private. On a very high level, this is trustlessness in a nutshell, right? So the VPN itself should be trustless.

It also be centralized. As you will see, there is a fundamental layer of the Hopper network, which is a peer-to-peer network consisting of many nodes. So there's never a single server you have to work with. And also, it should be censorship-resistant, because the Internet, as you know, has a lot of parts which might be blocked based on your geolocation or not. And a VPN should actually allow you to get past censorship like that.

We are right now, product-wise, in the POC stage, so proof of concept. And as you will see, it's very technical still. You have to use the terminal, so bash shell. And obviously, this is going to improve over time. But that's also the reason why this is a technical workshop.

So bear with me there. The funding for this product development is coming from the Gnosis DAO. We've had two GIPs, one which was already completed. That's GIP 98. And one, the more recent one, is GIP 122.

And that covers the development to make this an end-consumer product. So moving from highly technical, low-level, only-developer orientation to being an end-consumer product, having UI, a desktop app. If you're interested in that, check out the forum, the GIP, and the details which we've outlined for that. Okay. How do we move from this super-centralized, single-servers, single-trust relationship and architecture to something which is more meaningful?

What we are doing is we are putting the Hopper network, which is the decentralized network, on the fundamental lower layer between the client and the server, or the web server you want to access, so the internet web server. In order to do that, we have to have some client on the laptop, let's say, on your user devices, which understands how that works, so it can interface with the Hopper network. We have to have some entry nodes. That's the Hopper node, which is talking to the Hopper network and translates normal internet traffic into Hopper traffic. And on the other side, there's something called the exit node, which then takes Hopper traffic and translates it back into internet traffic and talks to web servers, websites, and so on.

So, as you can already see, we've removed this single point of trust and added a decentralized network underneath, which will help you get this trustlessness, this decentralization censorship resistance. Just to give you a little bit of insight on what the Hopper network does, and this is very high level, really, if you're interested in more details, I'm going to be around and my team as well, so we can give you more details in the next room afterwards. The Hopper network is a mixed net. The idea of a mixed net is that whatever data comes in is being chopped up in small packets, which all look the same size-wise. It's all encrypted, and then it's sent through many different paths through the network.

We call that hops. And eventually, it will come to the destination where it's going to be reassembled again, and then you get the final data together. In between, none of these hops which the packets pass through can actually identify what the content is. Obviously, that would be detrimental. But also, any adversary who has access to these hops in between can only look at the hop, but cannot really follow the packet flow.

The reason why this is important is, if you can understand packet flow coming in and out of a system server, you can actually understand what is going on, who's communicating with whom. What we want to do is we want to hide that knowledge. A single hop is doing what we call mixing. Packets come in, it adds latency, it changes the sequence of packets, and then sends them out again. When you look at that from a technical perspective, you see packets coming in, and you can never make that relation from a packet coming in to a packet going out.

This is really important to counter any adversarial observation. The second fundamental improvement of what the hopper network does is, it makes it sustainable to run a hopper node. Every packet which is going through the network is actually incentivized. You, as a hopper node runner, are incentivized to relay packets through the system because you're constantly getting paid for it per packet. This is important because otherwise, why would you actually run a node?

It has to be sustainable in the long run, it's a decentralized network after all. Coming to our workshop here, let's assume, just to kind of build the scene a little bit, we had a conference, your favorite conference, like DEPCON. You want to have anonymous internet access, so the DEPCON organizers provide you with access to hopper nodes and want you to run node CPN connections and browse the internet over the possibly insecure Wi-Fi here. This was what we are going to do. We are going to set up the VPN client for you.

Now, in step number one, and this is maybe a little bit small for you to see, but this is our original architecture, right? In step number one, you need access to a hopper node, which you can get from my colleagues. Step number two, we will install the noses VPN client on the client machines and configure them. Step number four is we're going to establish a VPN connection. This is already then establishing a fully encrypted VPN tunnel.

Step number five, we are going to browse the Web, the ultimate goal. Okay, so we are going to go into the terminal, so you can either copy that or type it out, but you can also follow that link. I put all of the long-term commands on a Web page, so you can just copy-paste it and hopefully not have any typing errors. Oh, I need access to a hopper node as well. Obviously, no cheating here.

Okay. All right, so step number one out of the slides here is we have to download the install script. Since it's still terminal-based, we've prepared a bash script to make it really easy for you to download the binaries which you need for your particular system, if it's a Mac OS or Linux, and build the initial configuration. So I'm going to take that link. Is that actually readable?

Is that better? Okay. So I'm just copy-pasting the same command like you would do. I'm downloading the install script. Let's check what I've downloaded.

You should obviously later, you can inspect that. This is a very exhaustive install script. It tries to give you as much information as possible, what's going on, what are the next steps which you should follow, so it's really like a tutorial in itself. And then I'm going to install a particular version. This is just for making sure while the product is being improved, I'm sticking to a version which will work for us.

So I tested that version in particular, so we have a working experience. Okay. So the installer gives us a lot of information on what the requirement is, basically what I just mentioned already, so I'm going to skip over a lot of this. And we can just go through the steps by clicking enter. Now I'm being asked where do I want to install the binaries and the configuration file.

This can be anywhere on your machine, obviously. So you can enter any directory. I'm just going to use the default here. So just clicking enter. Then I'm being asked for the Hopper Admin Interface URL.

This is just a convenience feature. So if I already have access to Hopper now through what we call the Admin Interface, I can copy-paste that URL in here, and the installer will chop it apart and get the right information from it. What you got from us here is the individual piece of information, so I'm And now it's actually asking me for the information from our vouchers here. So enter Hopper D API endpoint. I'm going to copy what I have printed out here.

So it's the IP import. Double-checking. Okay. Then the token to talk to the API. Okay.

And then I have to enter a so-called session port. So Hopper D node can support many sessions at a time. And as a user, I have to just specify one particular port since some of these nodes might be used by different people since these are demo nodes. Everybody has a specific port assigned. Normally, if you have your own node, the default port is 1422, and you would never have to change it, really.

You can use the default. So I'm using a different one for the demo here. Okay. And then it's going to check whether API access is working. It will download the binaries themselves.

And this is macOS-specific. I have to de-quarantine the binaries because on macOS, if you just download binaries, they are not usable. So the install script tries to do that for me. So I'm just going to enter my password here and complete. Okay.

So this all has worked. So this is good already. This means I have access to a Hopper node. It was reading the API. It understood in which network the Hopper node lives, so the production network.

And it configured. We can look into that. It pre-configured the default configuration for me. So what the configuration shows, and you don't have to really mess with that here, is all of the information which I put in on top, and on the bottom, a set of servers or destinations which I can connect to. And very specifically, this is configured to use OneHop.

So we are already going through multiple nodes in the network, in the peer-to-peer network. So packets not only travel from my laptop to the destination node, the exit node, but rather over two nodes in between. As you can see, this is not IP data or anything. This is pure IDs. So basically a synonym in the Hopper network to address servers or peers.

Okay. Now I could just follow the commands which the InstaScript has given me here, as you can see here. This would work just fine. I have a little bit shorter variant in our slide deck. So I'm just going to copy-paste from the slide deck.

More for me. That's easier. So you could do the same thing. So first, what I have to do is I have to start the service itself. The service running on your machine has to have elevated privileges.

That's why I'm using sudo, because it needs to create a network interface and a tunnel. So you do this once normally, and then it's being run until you stop it. And you can create new VPN connections throughout the day. So this is a one-off operation normally. So I execute node-vpn as a service binary and point it to the right configuration.

The service will basically do nothing on startup. It will just enter the listening mode and then wait for instructions whether you want to connect to a particular server. So you have to go into a different terminal and use the second binary which we downloaded, and that's the control binary, right? And this is used to send control commands to the service. So I'm going to use that first to check the status.

And since I haven't done anything yet, the status is disconnected. The VPN tunnel is down. But it shows me the different servers which I can use as exit nodes. So here I'm just going to use the one in Germany, copying the peer ID, and then use node-vpn control, connect, and the peer ID. Hit enter.

And then we already see on the left-hand side the service. Let me up again here. It's then going to try to establish a connection to the server I'm trying to connect to. Let me check the logs here. Seemingly some error.

Typical demo. So let me try a different server. Maybe I have a problem accessing that particular server. Let's try Spain. Okay.

So this has worked. So now I'm just going to stand up for this. I have a VPN connection established. So if I check the status again, it tells me I'm connected to a particular peer and my VPN connection is up and running. Great.

Now what I have to do is, since this is still a proof of concept, it's not being used for all of the connection and the network access you do on your machine, because that might be detrimental if the quality is not great yet. What we do instead is we offer an HTTP proxy on the other end, which you can configure in your web browser or in your system settings. So for this demo, I'm going to configure that HTTP proxy in Firefox. So going to Firefox settings and then into the network settings. And here, normally you would have something like use system proxy settings or no proxy.

If you want to use the VPN connection, you then have to configure the HTTP proxy, which is on IP 10.128.0.1 and port 3128. You have to make sure that it's used for HTTPS as well.

Now this HTTP proxy is actually on the other side of the VPN tunnel, right? So by doing that, you're actually already going through the tunnel itself. So I'm going to hit OK and then checking whether the VPN connection works. And it's able to load. What is my IP.

com to test? What I wanted to show here is, and maybe I show it in my other web browser, which is not using the VPN connection. Just reloading that. If I go through the Wi-Fi here, I am being terminated here in Berlin. It's showing me even radial systems, which is our location here.

If I go through the VPN connection, which we just established, I'm being terminated in Spain, where that server, which I connected to, is located. So I can verify that the communication is indeed going out through Spain to the internet. And I can then continue browsing through that connection and visit websites as normal, right? So this is kind of a functioning setup now of my local Gnosis VPN setup. OK.

I'm going to just assume it worked for everybody here. And if it didn't, feel free, just so we don't run out of time, feel free to catch me or my team outside, and we can troubleshoot your setup if it didn't work. OK. Now, I already mentioned that this is Linux and macOS specific right now. If you are on Windows, it's a little bit more complicated.

We don't have a native version yet for Windows, but we have something which you can make work through the Windows Linux subsystem. So just follow this website if you want to try it out, and I would be certainly would be happy to hear from Windows users who tried this in order to understand what the user requirements are. We can jump over this since it's essentially what we just went through. OK. I mentioned this is using Hopper underneath.

You already saw it's also using WireGuard to establish the actual VPN tunnel. And then it's using the configuration in the web browser. So there's a lot of components involved to make a successful private connection work. And this means that there's a lot of packet tunneling going on. If you look at it from the high-level perspective, a working Internet connection to a web browser is normally just an TCP connection, which is TCP-based, and it's end-to-end encrypted, right?

So you can be sure whatever that connection is sending over as a response or if you send something as a request, nobody can actually look at it. So it's end-to-end encrypted between your web browser and the web server. And obviously, this has to stay that way over a VPN connection. Nobody in between should be able to decipher what's going on. So what happens is with that running VPN connection, the web browser will actually talk TCP to the WireGuard client.

The WireGuard client locally will talk to the Hopper entry node that was the node which you got the API information for, will talk UDP because that's what WireGuard uses to tunnel data. So it's already wrapping, splitting up TCP packets into UDP packets, doing additional encryption. The Hopper node will send Hopper packets through a decentralized network. So that's again taking UDP packets, turning them into Hopper packets, doing even more encryption. On the other hand, on the other side, on the exit, we get Hopper packets.

We have to turn them back into UDP packets. Then WireGuard has to turn UDP packets back into TCP packets, which ultimately are being sent from the proxy to the web server. So it's a three-level wrapping and unwrapping of packets from TCP to UDP to whatever the Hopper nodes speak with each other. This can be very complicated. This obviously uses a lot of computation and therefore increases latency, which we use in the end also to improve the privacy of that connection.

Okay. So given that we can already establish a working VPN connection over all of this locally, like we saw earlier in the terminal, what are the next steps? I mentioned this is the POC. So we have working binaries which can create end-to-end encrypted connections. We can browse the web.

You could use it in your daily workflow to browse the web. The next step is to build something which is normally called an MVP, which is not only more private, but also more usable, because ultimately a VPN connection which can only establish by dropping into the shell isn't really usable by anybody outside of this room. So we want to make it, we want to add some more privacy perimeters, very important stuff to the Hopper protocol, but also we want to remove the dependence on the separate Hopper node. Obviously, if all of you would have to run a Hopper node, set that up, configure it, keep it running, that would be quite a requirement in the long run. Now, I expect all of you, since you're in here, to go out and install a Hopper node and set it up tonight, but I don't expect that for the next 10,000 users.

So what we want to do is we want to take the Hopper node, make it possible to turn it into the library, and add it into the client itself, so that ultimately you start up the VPN client locally. It starts up in, let's say, 10 seconds, and all of a sudden you have a working Hopper node running, which can connect to the decentralized network. The end user doesn't need to know about Hopper. This is really a technical fundamental insight, which nobody should care about. And once we have that MVP, we have to take care of making it as usable as a normal VPN client.

So we're talking about all of the platforms, mobile, desktop, Windows. We have to have incentives, so that if you want to run an exit node, if you want to become part of that ecosystem, it should actually be good for you. You don't do it for ideological reasons. That is great, but you also should get incentives out of it. And then we need better throughput.

While you can already browse the web, you might want to do other stuff over the VPN. If we want to tunnel all of your traffic from your laptop, which you're doing on a day-to-day basis, through the VPN connection, we have to have much higher throughput than just what you need to browse a website. So there's a lot of stuff ahead of us. We have a timeline, which is outlined in the GAP, which is going over the next one and a half years. So if you want to follow us along, it would be greatly appreciated.

We rely heavily on feedback. So since we don't do, obviously, any tracking in our clients, being very privacy-concerned, we rely on feedback, which is actively given to us. So very much appreciated if you want to share kind of your user stories, what's important to you as a VPN user, so we can take that into account. And ultimately, if you want to see when there is new product updates, just follow us on ossicpn.com, where we push, every time we have new product updates, some news.

All right. Thanks. Now, opening up to questions. Any questions? I think there's a microphone in the back, maybe?

Might be easier. I just came in in the last minute, so sorry. Does it work on IPv6? Because my DS Lite connection at home, I don't have a public IPv4. It should work on IPv6, yeah.

Okay, cool. Great. Any more questions? Okay, one up front. Can we get the mic?

That's fine. Yeah, it's fine. At what step runs the mixing? Because it's a mixed net. Yes.

And there is a hopper node, and... Yeah, that's a great question. So the mixing obviously runs within the hopper network at every step. And the first step is your entry node. So if we go back to that overview...

Hold on. Here. So the first mixing is actually done when the packets are created and are going out of your entry node. Even there, let's say you are making an HTTP request, which ends up being 10 hopper packets, so packet 1 through 9, 1 through 10. Even then, we already change the order, the sequence, and add latency, and send it out through different paths through the network.

And this same process, adding latency, changing the sequence, happens on every hop in between. So in our example, it was one hop, so that means there was one node in between, which did the relaying, which also did some mixing. And then the packets end up at the exit node, which only puts it back together. So there's no mixing involved on the exit node. So if you want to look at it from this example, it was three nodes involved, and the first two do some mixing.

Say again? Okay, the question is, do the packets go to the second node or somewhere else, right? Okay, so what I was referring to is the mixing of packets for which you choose a particular path, right? But what happens, obviously, let me go to this one, or this one. The node, the relay node in between, it's not only serving me, it's serving maybe 50 other entry nodes, and on the way back, some other exit nodes.

So there's lots of packets coming in from different sources and destinations. And this is all going into that, what we call the mixer, the process which adds latency, which changes sequences. So it's basically mixed up. It's being put into a bowl altogether, and then stuff comes out again. Some packets go a different route because they have different destinations.

So that ultimately, for somebody looking at it with a high-level network view, it looks like there's random packets coming in from different transport connections, and there's random packets going out. No packet looks the same because of encryption and decryption going on. Every packet has the same size. So you cannot really make that one-to-one link between packets and understand based on the metadata who's doing what through that server. A mixer is a part of a node?

Yeah. Or is it separate? It's in the node. It's like an integral part of the transport pipeline in the node. Yeah.

Any more questions? How many exit nodes do you have in the Hopper network? Is every Hopper node also an exit node? Also a very good question. So for the NoCPN use case, exit node has to be specific to the VPN use case because it has to understand it needs to terminate a VPN tunnel, right, not just talk Hopper.

So while potentially you could run that sidecar exit server on every Hopper node, that is not the case. Right now only Gnosis runs exit servers. But every Hopper node in the network could be used as a relay. The idea behind this approach is ultimately to have an ecosystem. So while we are in the POC stage, Gnosis is running the servers, the exit servers, because it's for one, we can move very fast by deploying new versions.

On the other side, we can provide good quality of service in this product development stage. Ultimately, though, we said we want this to be trustless and permissionless. So what we want is to enable everybody to run exit servers, register through some permissionless process that they are available, given a certain usage pattern they allow. So let's say I want to run an exit node on my residential IP at home, and I only want to allow access to websites in Germany for some reason. Then I can configure that in my exit server and announce that through that permissionless process to the rest of the ecosystem.

And then users could use my exit node if they are browsing the web in Germany only, yeah, German websites. And if they want to browse websites which are somewhere else, IPs which are located somewhere else, they just have to use some different exit server. Any more questions? There's one. Last question.

I would like to know more about eventually the tokenomics. If I imagine, I'm thinking quickly, I imagine you want VPN users to maybe use, is it called Hopper, I think the token, and validators or exit nodes, sorry, would get Hopper if they run the node? Yeah, that's a great question. So incentives, right? And I mentioned incentivization for the Hopper network itself is important, but then also on the VPN ecosystem level.

The Hopper network uses Hopper tokens to incentivize relaying. So every packet can ultimately, could be redeemed for Hopper tokens. So when you want to send out packets, you have to pay basically for the packet to be relayed through the network. Now this is on a different layer though than the VPE service work, which is done by the exit servers, right? I cannot give you a full answer yet.

So this is the kind of R&D we still have to do. So happy to talk about that afterward separately, but we have to find a way to incentivize exit servers to do their job, whether this involves Hopper tokens or Circle or whatever, I don't know yet, but there needs to be something. Any more questions?