 Goose, Alex and George. They're going to tell us more about the road to mobile tour and improvement censorship circumvention. Please listen to the updates from the Onion. That's your stage. Thank you. Hello everybody. My name is Goose. I'm from the Tart Project. English is not my first language so maybe you are going to learn a little bit about Portuguese today too. So we want to talk a little bit about Tart and what we are working in the last months and year. So first thing about Tart is Tart is a free software. So you can download Tart, you can check the source code and everything. And it is very important to have a free software project because you can inspect the code and you can check the code. The second thing is about Tart is about is an open network so you can grab the source code and be part of the Tart network too. At the moment we have like 6,000 relays. So it is servers around the road and they are all run by volunteers. And why we are going to use Tart? Basically we are going to use Tart to mitigate against online tracking and against surveillance, against censorship and to be safe online. And Tart is a non-profit based in the US so many of us, we don't live in the US but Tart, the headquarters of Tart is based on Seattle. And how do we spell Tart is like that and it's not our caps. We trained that in the last few years. It's not more Tart, the Tart is just Tart, it's easier for us. And we are organized in different teams. I'm part of the community team and we also have the anti-censorship team, applications, fundraising, metrics, network, sysadmin, UX and research. And when we talk about Tart we are talking about a network that is used by between two millions and eight millions of people. And we have these numbers because first we don't track the users so we don't actually know how many people are connecting the Tart network. So these numbers are based on two different methodologies to study the Tart network. And how Tart works? Basically we have this network of Tart servers around the world. And when you want to enter your website you are going to access three servers in the Tart network. So you're not going to access directly the website. Your traffic is going to pass through three servers around the world. These servers that are run by all volunteers. And at the moment we have the network is growing. So if we have old Tart users here in the past years we had a very slow connection using Tart. And now these connections improving is much more faster nowadays. And it's because we have more faster relays and more faster servers. And about community. In the last years we have been working in doing trainings in the global south. So for those that you are not familiar with trainings basically it's an opportunity to meet the users and to talk about Tart and not only about Tart but about privacy, about security. So we have been doing digital training security workshops with human right defenders in the global south. So in the last six months we traveled to six countries like Colombia, Kenya, India, Indonesia and other countries. And we did 45 workshops. And each workshop usually takes like three hours. So it's not just like, oh, you're going to install Tart browser and that's it by. But it's about what kind of questions do you have about privacy? What kind of questions do you have about security? And if Tart cannot help you, what we can do for you? What kind of other free software solution we can present to you? So we have been doing this work in the last months. And we are going to do more Tart trainings in the next months. And another thing that we are doing, we released the new website. So now it's localized. As you can see, it's not in English anymore, only English anymore. We have been this is our priority on Tart. We need to have more users and we need to achieve this population that don't speak English. So Tart is translated in many languages now, like in 12 languages. So you can access the Tart web page and you can change the language for what your preferred language. So here we have the main website translated to Spanish. Navega con privacidad, explora libremente. This is my Spanish portal. It's not a real Spanish. And we also have other portals that we are working on. We have the support portal. It's a portal to help Tart users. And we are working in the community portal. So we are going to have the training slides so you can download and you can help your community. And also we are going to have the relay operators documentation there. And also how to localize the website and other things. And the next step, we are going to develop, we are going to start to call the new developers web page that we don't have now. It was all mixed in the old portal. And we are building different portals for that. And another thing that we are working is the docs hackathon. So because we are moving a lot of documentation in splitting different websites, we notice that many of these documentation is old. So we need help to improve this documentation and to fix that. So in the first week of September, we are going to do a documentation hackathon. It's open for all. And more details about that you can check in the blog in the Tart project. And basically, we already have tickets about what we want to change. So we need, you need to subscribe in the hackathon and help us on that. And people that, the top contributors will receive an award. And that's it. Thanks, Kas. So, hi. I'm Geiko. I'm working on the applications team. And they are mostly on Tor browser stuff. As Tor browsers are largest application, I think it's smart to spend some time on what we did in the last couple of months and what is yet to come in the next couple of months. So one big milestone, we had a couple of months earlier when releasing Tor browser 8.5, which brought for the first time a Tor browser to Android devices. The nice folks from the Guardian project had crappled with the situation that there was no real privacy browser for the Android device and developed Orfox. But we finally were able to take them off and take off the work for them and deliver a proper Tor browser to Android users. And as you can see, this is not just a copy from the desktop version, in case you already tried the desktop version. It's, together with our UX team, a new design for, specific for the Android platform. And it has been a huge collaborative effort from different teams within the Tor project to get this project going and having a Tor browser for mobile. That's not been the only user interface improvements we made for Tor browser 8.5. We have, as well, redone our toolbar, which is a pretty important thing in a browser because you have all these shortcuts on them and see easily status of different extensions and stuff you have installed. So if you compare the upper one, the upper toolbar, this is from Tor browser 8 and the below one is from Tor browser 8.5. You see that we removed the icons in the upper right. Those were from extensions we ship with Tor browser, which is no script and HTTPS everywhere. And it's pretty confusing to use this. What are they supposed to do with those icons? If you click on them, you're getting even more confused because then you're already in the settings dialog and you don't know as a normal user what you're supposed to do there. So it's not really informative having those icons there and they are just taking precious space on your toolbar. So remove them. If there are experienced users with some use cases which are not covered by the defaults, it's easy for them to drag them on the toolbar again and using them as they were used to. And while we're doing, we moved the toolbar icon to the right and added a shield icon, which is meant for giving easy access to the security settings, which allow you to make some trade-offs between improved security in your Tor browser and features on the web, which could be dangerous in some contexts. And another big feature here is that you have the state of your security settings visible in your toolbar. You don't have to click into different menus anymore to see what security setting you're currently on. That's been another important collaborative effort with the UX team. And that's not just to give you a pretty user interface. There's a deeper point here in the sense that you get more users if you provide them with a user interface they are used to. And they make less mistakes if they use those user interfaces than those you ship and are not really in line with what they're expecting when they're using your browser, for instance. And more users, in turn, means it's good for your anonymity set, for your anonymity network, because there's a larger crowd which you can hide in as a user. So the key point to take away here is the usability improvements we are doing and which are yet to come are not just meant to give you eye candy. They are really an integral part in providing anonymity to as much people as possible. So what's up next? So up next is Tor Browser 9, which is supposed to be based on Firefox 68 ESR, which is a special flavor of Firefox. So some of you might know that Firefox is coming in at least, depends on how one counts, at least two flavors. There's a normal one where you have Firefox 68, 69, 70, and so on. And then there's a special one originally made for enterprise environments, which are struggling with updating their Firefox user base so quickly because those releases get out every six to eight weeks. So Mozilla made a special series for those needs, which means that you only get security updates every six to eight weeks. And there's one big update you make once a year. And on this train, Tor Browser is based on because we have to redo our patches which are like 200 or 150, and doing this every six to eight weeks seem to be infeasible yet. So this is a big new thing, which means that Tor Browser 9 will be based on the new Firefox ESR. We have improved user interface in the browser, meaning that it's easier to select bridges from within the browser. It's more integrated with the network settings. As you can see, it's right now, you will get an easy access to new features in the toolbar, which means like new identity, which gives you, if you press this button, a clean slate, a clean new session, which you can start serving without bothering whether there are still cookies and things left from the previous session. And this is released, probably released in October later this year. So a bit longer in the future, we plan to move away from the Firefox ESR to the regular one. So I said there are some benefits from being on the Firefox ESR train, like we don't have to rebase our patches every six to eight weeks, and have the quality control which comes with that every six to eight weeks. But there are disadvantages as well. One of those is that there is no ESR for mobile. And as you recall, we have a mobile browser for Android now, so we have to do something here. And the plan is to first start moving away from the ESR train to the regular Firefox release for mobile, test this, figure out what we need and what is probably needs to get fixed in our processes. And then we plan to move to this new away from ESR for desktop as well. Because there is an argument to be made that being on the Firefox ESR is not giving you all the security improvements you want to have. So Mozilla's policy right now is back porting just high security bugs, critical bug fixes. But there are sometimes a ton of moderate bug fixes we might want to have as top browser users as well. And we want to have those too. But without Mozilla notifying us that there is this kind of stuff we want to back port. Because you might miss things. And there's an additional argument to be made that in general these kind of ESR series are not as secure as the regular ones. Because you don't have so many people looking at the ESR code anymore, because everyone is just looking at the latest one. So there are bigger chances that you are missing a severe bugs in those ESR series. And we will get improved usability and performance improvements quicker. And this aims at retaining users and getting more users to a browser. So thanks. Hello there. I'm George. And together with Alex over there, we're working on the network team of Tor. The network team is basically the team which is responsible for like safekeeping the Tor network, kind of writing the code that implement the Tor protocol and kind of making sure that the network is healthy and the protocol is secure and that the code is not a huge spaghetti mess. And we're basically working on a huge code base, the Tor code base. It's written in C. And we have also started doing stuff in Rust. And right now I'm going to talk to you about the work we did over the past year. And after this, I'm going to talk to you about the work we're going to be doing next. So one cool thing we did about a year ago, last summer, is that we released the tool for onion services and also clients which is a Python program which you can enable. And it will give you advanced protection against attacks like guard discovery and various kind of like traffic analysis attacks. In particular, you can get it from GitHub and enable it on your onion service or client and it will try to block certain attacks and also give you like warnings if it sees certain kinds of like suspicious patterns. It's still an experimental thing and I asked you to install it if you care about the security improvements. And it's mostly like an experiment that if we see if we see it working well, we will eventually port things into upstream Tor. So that's a cool security thing we did. So another thing that's been happening particularly this year is that like there is certain denial of service attacks going on on the network right now. We don't know the exact nature of them given that we're like an anonymity network. But what we know is that people are attacking each other and particularly onion services by pretty much spamming them with requests. And this is causing lots of chaos on the network. And it has two effects. One effect is damaging the network because all this traffic is causing too much like activity and overloading the relays and the relays drop stuff and they retry and like a whole circle of chaos so cares. So this is one thing. And the other is that the services are unavailable. So since the start of this year, we've been looking into this and doing tests and trying to figure out defenses. And we have done a pretty good job but like kind of like improving the situation of damage on the network. And by doing like rate limiting or blocking one hop requests, we are kind of much more gentle to the network now under attack scenarios. And we're also kind of looking into like improvements that would allow services to have better availability when they're under attack. But this is a pretty hard thing to do. An anonymous network because like in the normal Internet, you have companies like Cloudflare which get like million dollars and they basically do denial of service protection using CAPTCHAs or like reputation based stuff. And in Tor, we don't have reputation because it's like anonymous so we don't have much memory in the network. So it's a hard job like distinguishing the good clients from the bad. We have a few ideas, particularly application level stuff. But if you're in this like business and you have ideas on how to move forward, please come and see us. So another cool thing that's happening is that like a few years ago a research project came out which is called WTF and it's supposed to protect Tor clients from certain website fingerprinting attacks or other types of traffic analysis. And what this research project was doing is introducing padding which is fake traffic into the circuits. So by adding some sort of smart padding on the circuits, you could kind of make things blend more together and kind of like confuse the adversary into not knowing what's going on. So we went ahead and implemented this like adaptive configurable padding thing into Tor. And it's enabled right now since like a few months ago. Basically what's going on is that we have enabled two padding machines. They're basically like state machines that kind of specify how padding should be done. And their aim is to like obfuscate whether an onion service client, a client who visits an onion service is actually visiting onion services or doing real like website traffic. And we're still looking into this because this like blending in with other circuits is kind of hard in such a chaotic environment. But we're doing research and we have like motivated more researchers into using this framework. We've also been working on improving the mobile support. This means that like we have better integration with Android now. Now you can build Tor as a library and you can like integrate it easier with third party applications. And we have also introduced like a dormant mode which is like a special mode that Tor goes in when it's not used and it needs like relax and stop like using bandwidth or battery. And basically like if you have Tor deactivated or like on your mobile and you forgot about it, it's not gonna like spam the network with request. It's just gonna like relax a bit. And when you need it next, it's gonna activate again. So now I'm gonna talk to you about the things that we have planned for the future. Particularly this upcoming year. So one huge project that is happening on Tor and also on like a whole project level and not just on the network team is that there is lots of people and projects and browsers and whatnot that are interested in like playing with Tor and integrating it into their product. And they want some sort of guarantee that Tor is gonna work under different scenarios and under different level of users and all that. And right now, our metrics and our performance evaluations are kind of hacky, let's say. So one big thing we're doing and we're applying for funding for this and trying to like go serious on this is take a look in performance in a serious way and try to understand what kind of performance currently Tor provides and what kind of performance currently users expect and how to improve this and how to like measure this over time based on events and how many users get in and a new browser, user store, how does that affect performance? And we're also like planning to play with, for example, moving to a datagram transport and practicing other types of congestion control, or we have implemented a new bandwidth scanner, which basically like measures how much bandwidth it really has. And we use this for load balancing, but we're experimenting with new ones to see how that works out. And in general, we expect that this is something that is going to take lots of our time in the future to kind of be able to provide a more consistent and scalable Tor in the future. And also we have funding for onion services for many months forward. And we plan to do certain improvements on them, along with the ones we've already done. One pretty good one is that we plan to port onion balance, which is currently only supports the old onion services, we plan to like revamp it and do support for V3 onion services, which is something that lots of people are asking us for. And it's basically one of the major ways to provide a big onion service right now. And another thing that we've been thinking about a lot is that we have problems with the usability of onion services, and the fact that the onions are super long and the names are super long. And we are thinking about how to improve this, particularly with the new onion services that are like 56 characters long. And we plan to experiment with HTTPS everywhere to blend onions into it to provide some sort of smart bookmark system, which you can share with other people as a temporary solution for now. And as we go forward, we're looking at more advanced naming systems and more secure and smart stuff to kind of integrate them with Tor. And we've also been working on the anti-sensorship level and trying to improve the pluggable transport specification and make it more integrable with other like projects and make it more versatile. And we've been doing lots of improvements around anti-sensorship in general. And this is what Alex is going to talk to you about now. Thank you. So my name is Alex, I'm usually part of the same team that George is on, namely the network team, which is responsible for the core part of the Tor network demon. In middle, in the middle of 2018, we realized that usually the network team were responsible for the anti-sensorship part of the organization. But we didn't really have time for it and we didn't prioritize it high enough. So what we did was that we created a dedicated anti-sensorship team, we had a hiring round where we hired two people, and a small amount of the network team joined in on the anti-sensorship team to sort of get it started. The idea with the anti-sensorship team is that they're going to fight the thing you can see here, namely the censorship we see in various regimes around the world, different countries. Some of these are from the Middle East, but there's also one of them that contains one from Denmark. It's practically the same system. It's just used in different tuning parameters and how much they're being used. So the big thing we have here is that we generally know that UPS4 seems to be working. It works for many users around the world. But one of the problems for it is to get access to reliable bridges. These bridges are the ones that people need to put up in their tour configuration or via the browser to get it running. We also know that domain fronting, which is the technique where you sort of establish a TLS connection into one of the big public clouds with where you set an SNI header to, for example, a big site that the censor is unlikely to block. And then you make an HTTP request inside of it with a different host header where the load balancer at the edge of the cloud will route you to the right customer, which then happens to be someone from the tour project who's running a bridge. One of the problems with the domain fronting pluggable transport that we have that's called MEAK is that it's incredibly expensive to operate. For people who are familiar with tour, they will know that sort of the in-going traffic is the same as the out-going traffic when you're running a relay, which means we have to pay for all this traffic that's going in and out of the clouds. This is something we would really like to deal with. This means that we're continuing the efforts to generally make it easier for people to get access to bridges. One of the things we did recently in the last year is that we integrated something called MODE. MODE is a system where you access bridge to be over a domain fronting connection directly in the UI of the tour browser. So people who are not familiar with bridge to be, bridge to be is the system that people who are in censored areas have to access to get access to these bridge lines that you put in the configuration. This has generally been a difficult thing for some people to get access to. You have to solve a capture first. You have to go to a website. We also have different entry points to it. So you can, for example, send an email to a Gmail account. We will then reply with an automated system with these bridge lines. But now it's integrated directly in the browser. So when tour starts up, for the majority of people here in Germany, when you use tour, it's mostly about the anonymity and the anti-tracking features you get from it. But for some people in other parts of the world, it's about reachability. So for them, it's not the same thing. When they start tour, they normally don't connect to the network because all the entry points to the network is censored. So having this UI directly in the browser generally makes it much easier for people to get access to it. They now have to solve the capture inside of the browser instead of going to a separate website, solve it there, get the lines, copy them into the browser and then being able to connect. So this is a very good step in the right direction for the UX of getting access to bridges. So I mentioned before that we have Meek, which is the domain fronting technique that generally seems to be working very well, but it's very expensive to operate. One of the big things the new anti-censorship team has been working on, together with BridgeDB improvement and so on, is a pluggable transport called Snowflake. The general idea about Snowflake is that we have a client inside the censored area. What it does is that it does a domain fronting request to a broker, which could be seen a little bit like a more fancy way of having a BridgeDB. What the broker responds with is a token, which is the connection identifier from one of the Snowflake proxies that exist on the uncensored part of the internet. These proxies are running in people's web browser. People like you in here, you can go to this website, download the web extension in your Chrome or Firefox browser. And what you're doing is that you're practically providing access for people to enter the tour network using your web browser. So your web browser becomes sort of a mini tour relay without actually all the features of the normal tour relay. This is a good system for us in that it has significantly less cost because the data is going via a lot of people. We distribute sort of the load of the traffic out to multiple people's web browsers. And the only domain fronted data we need to exchange is the initial request from the client to the broker. And then the brokers respond. And then we are done having any connections between that. So it's a very limited, it's just a small string that's being exchanged. What your web browser will be doing is that it uses a web socket connection to a specific bridge that is currently running. And from the bridge on, the user will be able to connect to their final destination, which is the tour network in this sense. But it's designed like a pluggable transport. So there are certain other organizations that are providing systems that are compatible with these pluggable transport. And they will be able to use the Snowflake system as well with slight modifications. But you can go to the website and check it out. It's a very cool project and it's still sort of in development. We're coming to the end of this presentation, but we have a few things we would like to say. People in here are probably very familiar with that the tour works like a typical sort of research organization that is a nonprofit. So what we do is that we sit down twice a year, discuss what we would like to do over the upcoming year. And then we have a grant writing team that needs to make sure that we get some money. These grants make sure that we can do the general features, the big features we would like to do. But there's a lot of things that, first of all, we cannot find grants for to do, like things we would love to do. And there are also certain things that just shows up. For example, one of the things that George was talking about, about DDOS, we had in December 2018, there was a very high performance integration in the network. That was not something we had planned for. So that is where when we get donations, these money are being spent for developers hours to fix these things when they come up, these things that we cannot foresee. We're going to have this box smash fund here in August. The idea is that people donate money to us and we have some of the box that we find interesting that we would really like to solve but that we haven't been able to find funding for over a longer period of time. These money will go directly to developer hours to sort these things out. So do donate. So one of these things is, how can you help with the tour project? We're generally trying to separate the network from, like, the organization. We have a certain overlap of things but generally everyone in this room should be able to run a tour relay or a bridge if you want to do that. We recently had made a relay guide to make it easier for people to get started operating and running relays. That is one thing you can do or you can also run a bridge. We're going soon to have a campaign about getting more Ops4 bridges as part of the anti-censorship team goals because right now we have a lot of Ops4 proxies that are not really working so we could really use some more of those. One thing we have done recently is that as Gus also mentioned with the website translations and so on, all our applications these days are getting translated using this central system we have, we could really use help with getting people to translate our stuff. Both website and our applications are in need of having active maintainers to translate them. And as mentioned, you can donate to us which is very much appreciated and we will also send some swag to you if you do that. One thing we're changing now is that we're going to differentiate a little bit between one-time donors and recurring donors and the recurring donors are going to receive more goods if they continue to donate to the project. We have a small booth here at the CCC camp at the About Freedom Village. You can go by probably a little bit after the event but at some point during the day you can donate and get t-shirts and we also have some stickers if you are very interested in that. We have time for some questions now and once we're done if people are not comfortable with doing questions here we'll go outside and people can come and ask us questions. Thank you. All right, so if you have questions for Gekko, Gus, Alex or George please queue up here at the microphones. Do we have a question over there? Do we have some questions? I'm sure that we have some questions. Come on guys. Maybe people want to do them outside? It is too hot in here. Could that be the case? It is too hot. So do we have anything from outside the tent, from the net? No, we don't. There we have the first question. Please shoot ahead. Are there any independent tar networks like decentralized, like in running, using your tar? Not all connected to one tar? We can't really hear you. Can you get closer to the microphone and ask the question again? Sorry about this. Are there any independent tar networks installed, running? Any what? Oh no, so not to my knowledge. Do you guys know if we have any independent tar networks that are not operated by like the normal official network? We have a test network, but that's operated by us as well. So that doesn't get the independent label. Any more questions? It would be... Well, queue up in the microphone, please. Here we go. How do you measure the traffic over the network? Is this also included a fake traffic you generate by yourself to make more entropy? Or is it just traffic entering the network and so use that traffic? So all relays, the nodes of the network actually report statistics about the traffic that goes through them every day. I think that also includes the padding traffic by default. I think there are plans in the future to kind of distinguish these two so that we can see how much padding overhead we have over the network. But I think we don't have that right now. I think so. I'm not sure. And an additional question. And an additional question, Technic-Karlois-Snowflake solution with WebRTC. It's a first step for censored clients. How is this different to the classical solution? So you still have to provide a signaling server for the WebRTC client that you get to the WebRTC connection. So what is different with this server? You have to provide the signaling server and still the server can be blocked. Right. What does it work? So the general game you play when you're doing the anti-censorship arms race is that these sensors usually don't want too much sort of collateral damage. So we are sort of exploiting a little bit this sort of centralization that's happening on the internet right now where so many sites are hosted by Amazon, Google, and Microsoft. And by using IP addresses in their IP space and doing the domain fronting part, we generally start playing a game where the sensor will need to block the whole area of the IP space for these public clouds, just like we do with Meek in practice. The people who are running these snowflake proxies that is the small lightweight installations in the web browser should generally not be in areas where there is censorship because that is the place where you can block the access to the central bridge, which is the access point to the Tor network. Did that explain? Thank you. So we do have new questions over there. Could you make use of the monitor here that we might hear the question? Hi guys. I remember last year, Google and then Amazon announced they were going to be prohibiting domain fronting, but I saw in your talk that you said that domain fronting is still working pretty well. Could you spend a minute or two sort of describing sort of the current status of domain fronting, which providers are still allowing it, which ones are prohibiting it, and how is it working if two of the biggest companies have said they're not going to allow it anymore? Right, that is definitely a big problem. I think we are only having one entry point right now with Meek. Am I right about that? Which I think is Microsoft. Amazon and Google does not do it. So there are other options we can use there. Domain fronting is a general technique and the one we explained here was the, where we cheat with the TLS SNI header. For example, Amazon also has their symbol queuing service, which is a central endpoint that all applications that integrates with those will use. Using that, you can do sort of request response applications using Amazon, which is, I would say, a more legitimate way of using their service, whereas the other thing, we're sort of exploiting the difference between how web servers handle TLS versus the HTTP header. So that is one thing we're investigating right now. The other one is the ESNI, which is, if people are familiar with Cloud Flare's work on this, ESNI is one of those proposed standard, I'm not sure it's a standard yet, but it's an idea where you start encrypting SNI, but it generally works best if you have many websites on a single server or as a single provider. There are some things we can do there that we're experimenting with right now, but they're still missing support for these in the big TLS libraries. Was that good enough? Awesome. All right. So by the looks, nobody is queuing, therefore we're gonna close that over here. Gekko, Gus, Alex and George. Thank you very much for the update on the onion, and that is your applause. Thank you.