Updates from the Onion
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
GeKo
The Tor Project is building usable free software to fight surveillance and censorship across the globe. In this talk we'll give an update on what we have been up to in the past months, what happened in the wider Tor ecosystem, and what lies ahead of us. In the last year the Tor Project has been working hard on improving the software, building and training communities around the world as well as creating an anti-censorship team and roadmap that can push forward technologies to circumvent censorship. This talk will cover major milestones we achieved and will give an outline about what is lying ahead. In particular, we'll talk about the release of Tor Browser for Android and restructuring our anti-censorship efforts as well as working on next generation pluggable transports. Moreover, we'll explain our defense against website traffic fingerprinting attacks and plans for improving onion services and making them more usable (DDoS resistance, better user interfaces for authentication and dealing with errors). Finally, we'll shed some light on efforts to get Tor support directly embedded into other browsers, like Firefox and Brave, and educating users both by reorganizing the content on our website and extensive trainings throughout the world.
 Music Gekko, Gus, 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. Applause Hello everybody. My name is Gus. I'm from the TAR 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 TAR and what we are working in the last months and year. So first thing about TAR is TAR is a free software. So you can download TAR, 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 check the code. The second thing is about TAR. It's about an open network. So you can grab the source code and be part of the TAR network too. At the moment we have like 6,000 relays. So it is servers around the world. And they are all run by volunteers. And why we are going to use TAR? Basically we are going to use TAR to mitigate against online tracking, against surveillance, against censorship and to be safe online. And TAR is a non-profit based in the US. So many of us don't live in the US but TAR, the headquarters of TAR is based in Oceato. And how do we spell TAR is like that and it's not our caps. We changed that in the last few years. It's not more TAR, the onion routing, it's just TAR. 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, CISA domain, UX and research. And when we talk about TAR we are talking about a network that is used by between 2 million and 8 million 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 TAR network. So these numbers are based on two different methodologies to study the TAR network. And how TAR works? Basically we have this network of TAR servers around the world. And when you want to enter your website you are going to access 3 servers in the TAR network. So you are not going to access directly the website. Your traffic is going to pass through 3 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 all TAR users here in the past years we had a very slow connection using TAR. And nowadays these connections are improving. It's 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 TAR. And not only about TAR but about privacy, about security. So we have been doing digital training security workshops with human rights defenders in the Global South. So in the last 6 months we traveled to 6 countries. Like Colombia, Kenya, India, Indonesia and other countries. And we did 45 workshops. And each workshop usually takes like 3 hours. So it's not just like, oh you are going to install TAR browser and that's it. But it's about what kind of questions you have about privacy. What kind of questions you have about security. And if TAR 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 TAR trainings in the next months. And another thing that we are doing, we released a new website. So now it's localized, as you can see, it's not in English anymore. Only in English anymore. We have been, this is our priority on TAR. We need to have more users and we need to achieve this population that don't speak English. So TAR is translated in many languages now. Like in 12 languages. So you can access the TAR web page and you can change the language for your preferred language. So here we have the main website translated to Spanish. Navigar con privacidad, esplora libremente. This is my Spanish portuñol. 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 TAR 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 code 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 noticed 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 TAR project. And basically, we already have tickets about what we want to change. So 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, Gus. So hi, I'm Geico. 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 grappled with the situation that there were. There was no real privacy browser for the Android device and developed all Fox. But we finally were able to take them 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 tool bar, 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 tool bar, 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 shipped with Tor browser, which is NoScript and HTTPS everywhere. And it's pretty confusing to users. 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 we removed 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 were 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 settings 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 are expecting when they are using your browser, for instance. And more users in turn means it's good 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? Up next is Tor Browser 9, which is supposed to be based on Firefox 68 ESR, which is a special flavor of Firefox. Some of you might know that Firefox is coming in at least two flavors. There's a normal one where you have Firefox 68, 69, 70, and so on. And then there's the 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 like once a year. And on this train, Tor Browser is based on it 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 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 tool browser users as well. And we want to have those too. But without Mozilla noticing, notifying us that there is this kind of stuff we want to back port. Because we might miss things. And there is 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 tool 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 implements 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 it working well, we will eventually port things into upstream tower. 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, 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. And then 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 like a few years ago, a research project came out which is called WTF-PAD. 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 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. We're better. 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 to 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 going to like spam the network with request. It's just going to like relax a bit and when you need it next, it's going to activate again. So now I'm going to 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 what not. That are interested in like playing with Tor and integrating it into their product. And they want some sort of guarantee that Tor is going to 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 in 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 like experiment with HTTPS everywhere to blend onions into it to provide some sort of like smart bookmark system which you can share with other people as a like a temporary solution for now. And as we go forward we're looking at like more advanced naming systems and more secure and smart stuff to kind of integrate them with Tor. And we've also been working on like the anti-sensorship level and trying to improve the pluggable transport specification and make it more integratable with other 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 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 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 are 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 Ops 4 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 Tor 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 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 Tor project who's running a bridge. One of the problems with the domain fronting plugable transport that we have that's called Meek is that it's incredibly expensive to operate. For people who are familiar with Tor they will know that 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 Mote. Mote is a system where you access bridge to be over a domain fronting connection directly in the UI of the Tor browser. 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 Tor starts up, for the majority of people here in Germany, when you use Tor, 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 Tor, 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 bridge-to-be improvement and so on, is a pluggable transport called Snowflake. The general idea about Snowflake is that you do, 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 bridge-to-be. 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 Tor network using your web browser. So your web browser becomes sort of a mini Tor relay without actually all the features of the normal Tor 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 Tor 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 Tor works like a typical sort of research organization that is a non-profit. 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 these things that George was talking about, about the DOS, we had in December 2018 a very... 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 bugs 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 Tor project? We're generally trying to separate the network from the organization. We have a certain overlap of things, but generally everyone in this room should be able to run a Tor 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 ops 4 bridges as part of the anti-censorship team goals, because right now we have a lot of ops 4 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. Thank you. Alright, so if you have questions for Gecko, 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 a 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 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 on the microphone, please. Here we go. How do you measure the traffic over the network? Is this also included 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. Technic, Karlo is a snowflake solution with WebRTC. It's a first step for censored clients. How this is different to the classical solution? So, you still have to provide a signaling server for the WebRTC client that you get. So, the WebRTC connection. So, what is different with this server? You have to provide the signaling server and still this server can be blocked. So, the general game you play when you're doing the anti-censorship arms race is that the censors usually don't want too much collateral damage. So, we are sort of exploiting a little bit the 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-froending 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 light weight installations in the WebRouser, 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 a new question 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-froending. But I saw in your talk that you said that domain-froending is still working pretty well. Could you spend a minute or two sort of describing the current status of domain-froending, 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 Meeg. 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-froending is a general technique and the one we explained here was where we cheat with the TLS SNI header. For example, Amazon also has their simple 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 there's 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 going to close that over here. Keko, Gus, Alex and George, thank you very much for the update on the Onion, and that is your applause. Thank you.
 Music  Gekko, Gus, 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.  Applause  Hello everybody. My name is Gus. I'm from the TAR 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 TAR and what we are working in the last months and year.  So first thing about TAR is TAR is a free software.  So you can download TAR, 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 check the code.  The second thing is about TAR.  It's about an open network.  So you can grab the source code and be part of the TAR network too.  At the moment we have like 6,000 relays.  So it is servers around the world.  And they are all run by volunteers.  And why we are going to use TAR?  Basically we are going to use TAR to mitigate against online tracking, against surveillance, against censorship and to be safe online.  And TAR is a non-profit based in the US.  So many of us don't live in the US but TAR, the headquarters of TAR is based in Oceato.  And how do we spell TAR is like that and it's not our caps.  We changed that in the last few years.  It's not more TAR, the onion routing, it's just TAR.  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, CISA domain, UX and research.  And when we talk about TAR we are talking about a network that is used by between 2 million and 8 million 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 TAR network.  So these numbers are based on two different methodologies to study the TAR network.  And how TAR works?  Basically we have this network of TAR servers around the world.  And when you want to enter your website you are going to access 3 servers in the TAR network.  So you are not going to access directly the website.  Your traffic is going to pass through 3 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 all TAR users here in the past years we had a very slow connection using TAR.  And nowadays these connections are improving.  It's 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 TAR.  And not only about TAR but about privacy, about security.  So we have been doing digital training security workshops with human rights defenders in the Global South.  So in the last 6 months we traveled to 6 countries.  Like Colombia, Kenya, India, Indonesia and other countries.  And we did 45 workshops.  And each workshop usually takes like 3 hours.  So it's not just like, oh you are going to install TAR browser and that's it.  But it's about what kind of questions you have about privacy.  What kind of questions you have about security.  And if TAR 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 TAR trainings in the next months.  And another thing that we are doing, we released a new website.  So now it's localized, as you can see, it's not in English anymore.  Only in English anymore.  We have been, this is our priority on TAR.  We need to have more users and we need to achieve this population that don't speak English.  So TAR is translated in many languages now.  Like in 12 languages.  So you can access the TAR web page and you can change the language for your preferred language.  So here we have the main website translated to Spanish.  Navigar con privacidad, esplora libremente.  This is my Spanish portuñol.  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 TAR 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 code 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 noticed 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 TAR project.  And basically, we already have tickets about what we want to change.  So 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, Gus.  So hi, I'm Geico.  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 grappled with the situation that there were.  There was no real privacy browser for the Android device and developed all Fox.  But we finally were able to take them 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 tool bar, 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 tool bar, 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 shipped with Tor browser, which is NoScript and HTTPS everywhere.  And it's pretty confusing to users.  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 we removed 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 were 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 settings 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 are expecting when they are using your browser, for instance.  And more users in turn means it's good 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?  Up next is Tor Browser 9, which is supposed to be based on Firefox 68 ESR, which is a special flavor of Firefox.  Some of you might know that Firefox is coming in at least two flavors.  There's a normal one where you have Firefox 68, 69, 70, and so on.  And then there's the 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 like once a year.  And on this train, Tor Browser is based on it 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 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 tool browser users as well.  And we want to have those too.  But without Mozilla noticing, notifying us that there is this kind of stuff we want to back port.  Because we might miss things.  And there is 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 tool 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 implements 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 it working well,  we will eventually port things into upstream tower.  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, 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.  And then 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 like a few years ago, a research project came out which is called WTF-PAD.  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 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.  We're better. 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 to 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 going to like spam the network with request.  It's just going to like relax a bit and when you need it next, it's going to activate again.  So now I'm going to 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 what not.  That are interested in like playing with Tor and integrating it into their product.  And they want some sort of guarantee that Tor is going to 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 in 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 like experiment with HTTPS everywhere to blend onions into it to provide some sort of like smart bookmark system which you can share with other people as a like a temporary solution for now.  And as we go forward we're looking at like more advanced naming systems and more secure and smart stuff to kind of integrate them with Tor.  And we've also been working on like the anti-sensorship level and trying to improve the pluggable transport specification and make it more integratable with other 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 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 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 are 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 Ops 4 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 Tor 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 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 Tor project who's running a bridge.  One of the problems with the domain fronting plugable transport that we have that's called Meek is that it's incredibly expensive to operate.  For people who are familiar with Tor they will know that 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 Mote.  Mote is a system where you access bridge to be over a domain fronting connection directly in the UI of the Tor browser.  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 Tor starts up, for the majority of people here in Germany, when you use Tor, 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 Tor, 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 bridge-to-be improvement and so on, is a pluggable transport called Snowflake.  The general idea about Snowflake is that you do, 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 bridge-to-be.  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 Tor network using your web browser.  So your web browser becomes sort of a mini Tor relay without actually all the features of the normal Tor 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 Tor 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 Tor works like a typical sort of research organization that is a non-profit.  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 these things that George was talking about, about the DOS, we had in December 2018 a very...  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 bugs 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 Tor project?  We're generally trying to separate the network from the organization.  We have a certain overlap of things, but generally everyone in this room should be able to run a Tor 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 ops 4 bridges as part of the anti-censorship team goals,  because right now we have a lot of ops 4 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.  Thank you.  Alright, so if you have questions for Gecko, 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 a 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 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 on the microphone, please.  Here we go.  How do you measure the traffic over the network?  Is this also included 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.  Technic, Karlo is a snowflake solution with WebRTC.  It's a first step for censored clients.  How this is different to the classical solution?  So, you still have to provide a signaling server for the WebRTC client that you get.  So, the WebRTC connection. So, what is different with this server?  You have to provide the signaling server and still this server can be blocked.  So, the general game you play when you're doing the anti-censorship arms race is that the censors usually don't want too much collateral damage.  So, we are sort of exploiting a little bit the 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-froending 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 light weight installations in the WebRouser, 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 a new question 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-froending.  But I saw in your talk that you said that domain-froending is still working pretty well.  Could you spend a minute or two sort of describing the current status of domain-froending, 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 Meeg.  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-froending is a general technique and the one we explained here was where we cheat with the TLS SNI header.  For example, Amazon also has their simple 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 there's 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 going to close that over here.  Keko, Gus, Alex and George, thank you very much for the update on the Onion, and that is your applause.  Thank you.
camp19-10340-eng-deu-Updates_from_the_Onion_hd_0_167.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_168_815.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_816_863.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_864_911.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_912_959.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_960_1079.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_1080_1139.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_1140_3587.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_3588_3791.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_3792_3887.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_3888_3959.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_3960_4091.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_4092_4163.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_4164_4259.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_4260_11471.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_11472_13403.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_13404_13643.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_13644_22835.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_22836_23771.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_23772_24095.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_24096_24227.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_24228_24335.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_24336_24467.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_24468_24803.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_24804_25499.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_25500_25559.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_25560_25607.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_25608_25667.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_25668_26423.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_26424_26543.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_26544_30827.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_30828_30935.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_30936_31139.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_31140_31679.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_31680_31787.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_31788_38039.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_38040_38339.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_38340_38675.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_38676_41543.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_41544_41603.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_41604_41675.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_41676_41723.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_41724_42119.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_42120_50447.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_50448_51947.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_51948_52007.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_52008_52367.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_52368_52511.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_52512_55007.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_55008_55067.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_55068_55139.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_55140_55187.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_55188_55247.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_55248_55295.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_55296_61319.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_61320_65243.png camp19-10340-eng-deu-Updates_from_the_Onion_hd_65244_65637.png