 Well, he was just asking me why would I want to do that, and luckily that's my first topic of discussion. And the reason is because it fits on one slide. The internet's become in some ways really, really centralized. And Evan Moglin talked about that a bit earlier today, and a lot of people are becoming more and more worried that these people, these companies, really good companies doing wonderful work, but the fact that things are so centralized has certain implications, and that's sort of a summary of my opinion on it. Speaking of sort of getting into more detail, when I say the web is centralized, what I mean by that is most of our computers and most of our devices are not part of the web. They're consumers. So you're running a browser, and if you want to communicate on the web, you have to take your data, your blog post, or your photo, or your video, or whatever, and you have to upload it. And usually, you're uploading it to somebody else's computer. And even if you rented a virtual machine somewhere, you're still uploading it to someone else's computer, and if you get in trouble with that person, you violate their terms and conditions, or they change their terms and conditions, and you're in violation all of a sudden, they can shut you down and remove your content from the web, effectively censoring you. If you're using the web for personal stuff, for private communication, which a lot of us do thanks to things like Facebook, then you need to worry about privacy policies. What are companies going to do with your data? And most of us have responded to this by just shrugging, not reading the policy, not worrying about it, and hoping we don't get burned. People who are doing sort of, shall we say, controversial things, they might have to be actively worried about censorship. You might have to worry about the DMCA if you're trying to remix content that somebody has copyright over, and there are questions about fair use. Data retention laws bother some people here in Europe. There's issues like that. It would be really nice if everybody had the option of running a web server if they wanted to. And then there's the question, can we do that? Is that possible? And a little bit of history on why that's generally considered a hard thing. We're raised with the idea that servers are hard, clients are easy. And it's a cultural thing, and it's not really true. Client software is no simpler to write. Software complexity is no lower for a client than for a server. And we can do this. Web servers used to be high-tech. We used to have to know how to compile a C program to do it. Today it's built into everything. We have more processing power in our pockets today with our cell phones than the first web servers had. And our desktops, although there's still some security issues, we now are comfortable sharing open Wi-Fi with a room full of strangers. So we understand security better. But we have this problem left. We've run out of IP addresses. That problem is not getting better any time soon. Last time I gave a variation on this talk, we hadn't technically run out of IP addresses yet, but now I can say that we have. But in practical terms, we ran out of IP addresses a long time ago. Because from the point of view of the consumer and the average person, you've never been able to go to your ISP and say, hey, I want 10 IP addresses. Your ISP would say no. That's not a service that's available unless you're willing to pay the prices that the companies pay for dedicated lease lines. The average person never had enough IP addresses to run a few servers at home. So that's the issue that I'm trying to work on with PageKite, overcoming this. So assuming we had a web server on every single device, how do you make it reachable? How do you put that server actually on the web where people can see it? And the solution that I'm working on is based on fancy word protocol layer routing. It's really just tunnels and proxies. And there's some existing code that you can sort of hack together to achieve this. If you set up an SSH tunnel from your laptop, you can do some forwarding logic in Apache. You can make a website visible, but it's a lot of work and it's not very stable. And it's certainly not something the average person's going to do. If you're an anonymity person, then you might like Tor and you might know about hidden services. And those are cool. They get the job done. But you're stuck with a really slow website with a really, really ugly name because every single hidden service has an MD5 hash for a name. You can go close source and use Opera Unite. That means that your web server is living inside a web browser, which just seems weird to me. Or you can try PageKite, which is a dual project of a company that's doing a service and then an open source implementation, which is completely free. One of the questions I get is, you know, isn't IPv6 going to solve this problem? And I say no. And the reason I think IPv6 won't solve this problem is because of two things, firewalls and mobility. People are not going to stop putting firewalls on their networks because they're afraid of the internet and rightly so. So you're not going to have unfiltered access. The ISPs are going to do this for you. They're going to block access to Port 80 because they want to sell you that service. And you're mobile. You're changing networks three or four times a day. You don't have a static IP address most of the time. So here's a little diagram of what protocol layer routing, application layer routing looks like from the point of view of Firefox. So that green thing there represents the tunnel that we would establish between the laptop and something I'm calling a front end. Browser looks up the domain, gets an IP address, contacts it, requests a web page. That just gets forward and the data comes back. Now, the important thing about this is most of you know how this works. But the important thing about the solution is that from the point of view of the web browser, this is exactly the same. Nothing's changed. The fact that the request goes over a tunnel and then comes back, the web browser doesn't even know. So I can't tell how much time I've used, but I'll start talking about PageKite itself. So PageKite Pi is a single file Python program. I've tried to keep it as simple and easy to install as possible because I want this to be able to run everywhere. And if you've got a Mac, you already have Python, you can run it without installing any dependencies. It's free software. It's supposed to be easy to install and use. It does HTTP, it does HTTPS, and it also does SSH. So if you have a machine somewhere that's stuck behind a firewall and you want to be able to SSH in, PageKite's probably one of the easiest ways to make that happen today. The tunnel itself is protocol agnostic, so we can add support for other protocols as people become interested in those. And it compresses the traffic because people generally have limited upstream bandwidth. This single Python program will implement both ends of the tunnel. So on the diagram before, you had one computer in the cloud and one computer at home. The same piece of software implements both ends. This is all you need to use this. It has a HTTP server that gives you some diagnostics and eventually might allow you to reconfigure it. Some limitations. I'm not going to dwell on this, but I'm going to acknowledge them because I don't have much time. The most telling one there is the HTTPS limitation, where we basically have to wait a few years for everybody to upgrade their browsers and things like that in order to be able to do reliable, name-based, protocol-level routing of HTTPS requests. But if you can convince the people that are visiting your website to install Chrome or use a recent Firefox, then it's not a problem. And of course, there's this one. A lot of people just don't like the idea. But it does work really, really well. So here's an example of what you'd have to run on your server on the internet. Running that is root because it needs to bind port 80 and 443. You can also use some IP tables, tricks, kernel-level stuff to get around that. But this command will work. And this is what you would run on the laptop. So basically the same stuff, the name of the domain, which services you're interested in publishing. And then you tell the back-end page kite where the actual server is. And it doesn't have to be on localhost. It can be some other device on your local network. But localhost is the common case. Then there's the other half. There's the service, the company, all that stuff. And I'm trying to do this because I want to accomplish two things. I want to be able to fund further development of page kite. And I want to bring this technology to the average people, not just to the geeks in this room. And that means that someone needs to provide these front-ends. And the front-ends, they cost bandwidth. They need some resources. So I'm trying to build a company and some sort of business model around making that service available to people because it doesn't exist today. Some features that the service and the company provide. The one I'm really excited about right now, which is also going to be controversial. I'm hoping to have arguments with some security people about this, is I would like to provide SSL to everyone all the time. And I can do that by putting a wildcard certificate on the front-end, terminate the encryption there, and then make sure that the tunnel itself is encrypted as well. And this, of course, means that the front-end can spy on your traffic, but nobody else can. And that's a significant improvement for people that are worried about things like fire sheep. There's the business model we have today. It's really simple. I don't know if people are gonna like it. This is an example, same thing as before, except this time you just say minus, minus defaults. And I'm showing you here at the bottom how you would actually expose your SSH server as well because it's turned out that's one of the things that gets the geeks excited. So this is simple. Long term, I would like technology like this. I'm not just selfishly saying I want everyone to depend on my company. But if we can put technology like this, things like diaspora or status net or those things, we can start getting some really interesting innovations in what people do with these servers. Once the web server itself has direct access to your webcam, has direct access to your media library, has a terabyte of hard drive space, you've avoided a lot of limitations that these cloud providers have to deal with every day. And we can start implementing features that are just too expensive for them to implement in their centralized networks. So we could start competing on something else, some other message than just, you know, it needs to be private. Because that message doesn't resonate with everybody. But if you tell people, hey, you can share your files with your family and you don't need a separate application to do that, then a social network starts becoming pretty interesting. I've seen some other use cases. This is stuff that I've done. I've run it on my phone. I did that at a conference just to show off that it worked. I've got four Linux virtual machines running on a server in a corner in my living room. And they're all visible. I didn't have to reconfigure the router. I didn't have to do anything. I just ran that Python command. The guy who does the web designs for me, he's really excited about this because he can show off his work as it's in progress. He can just call up a client and say, hey, just visit this website. This is what I'm doing right now. He can avoid completely the step of uploading and copying and going through some sort of publishing rig-a-moral, which he just has it on his laptop. I've seen teachers publishing class material off recycled hardware, pulling up some old machines. They just install this. They never have to talk to the network admin. It just works and that appeals to them. I've seen Arduino hackers sending weather information to Petrub because, again, they didn't have access to reconfigure the Wi-Fi they were using. So they couldn't do the port forwarding trick. And this is the one that surprised me and it was guys that are cutting chicken using automatic machinery and factories. They were like, hey, this means we can just give every single chicken cutting machine a name. And we can use SSH and we can use VNC and we can just go right in there from home and save thousands of dollars on plane tickets. And I was like, okay, do that. So anytime a router or firewall is in the way of publishing a server, this can be a useful tool. And as I said, it's open, it's free, and I would really need more users to test it and help me figure out what to do with it. So I think I have time for questions, I'm not sure. Yeah, any? I can encourage you by doing the bonus slide. All right, check it out. We have a Twitter account named pagekite and I tweeted the location of the slides if you wanna go over any of this stuff again. And of course, there's the website and so forth. Thank you.