 So, and without stealing further time from Keith McManaman, who's coming here from Toronto, who's working at Siphon, a censorship convention NGO, and speaking about evading the censors in 2018 now, so censorship year roundup, I'm very happy to have you here and to see your talk now on the last day of Congress. Thank you. Hello. Thanks everyone for coming this afternoon. Hope you had a fantastic Congress this year. I know I did. Thanks for sticking around to the final sessions. For many of you, this will be the last talk you see until next year, so I hope it's worthwhile. And to everyone watching this dream online, hello and welcome. My name is Keith McManaman. I'm an analyst at Siphon, where we operate a circumvention network that's used worldwide by tens of millions of people, and we provide free open source circumvention tools for Windows, Android, and iOS. Yes, there is a circumvention tool that's running a whole device VPN for iOS in Siphon. Due to its accessibility, freeness, localization, and overall network resilience, that has made Siphon a widely adopted circumvention tool, which provides a decent sample size of internet users and therefore a reasonable barometer of circumvention tool usage in a country, which makes it an apt vantage point from which to analyze the impacts of internet censorship. In my work, the kinds of questions that I'm interested in are how the social and political dynamics of information controls in different places, for example, the trends in the censorship legislative environment, political cycles, social unrest and social movements, emerging discourses in the media and online, how do these factors add up and determine what content is accessible and how does that shape people's online behavior and their use of circumvention tools, including Siphon. This is an overview of what we'll be talking about today. I'm going to go over the basics of censorship technology and how it's deployed. I'll talk about some of the circumvention methods and technologies that are in use today. I'll recap some notable events from the past year and then talk about some notable trends that we've observed in this environment. Just a short note on framing and metaphors. The cat and mouse game is a terminology that's kind of widely used to describe the interplay between the circumvention tool providers and the sensors. You'll hear militaristic framing, like the battle for the free Internet or the technological arms race. I just want to say that there's nothing really, there's no Sylvester and Tweety, there's nothing mad gap or wacky about it, as you will see. What is Internet censorship? It's the control or suppression of what can be accessed, published or viewed on the Internet. I just took this definition from the Wikipedia. It comes in many different manifestations and forms. I'm going to be focused on the digital interceptive forms of censorship, which is what circumvention tools are designed to deal with. As you can see, there are other very important categories that have increased in their prevalence in recent years. Specifically the shift from direct interceptive forms of censorship, sometimes referred to as the first generation of information controls to the second and third generation, which is characterised in this excellent series called the access series by Rod Debert and the Citizen Lab and his colleagues, which is really the seminal work on that transition. This is what we'll focus on for this talk. Censorship is preventing you from treading all of these fascinating, wonderful paths. It does that by taking advantage of certain features in the way the Internet works. How they're able to do that is the sensors control all connections across the international gateway to the respective country. Through the information industries, they control the Internet service providers and they possess powerful methods of detection. Interestingly, the Internet censorship space is enabled by private sector actors. The cost of purchasing and running those technologies that allow you to maintain national black lists, sort and filter different types of traffic have become much more accessible for national governments and to deploy at scale. The methods that we're going to go over vary in their complexity and their resource intensity. This is something called the OSI model of basically computer and telecommunication systems. Suffice to say that censorship can happen at all layers, from the application layer all the way down to the physical infrastructure. So one of the lower level tactics is IP address blocking. Users can learn the IP addresses of the sites that they want to block and add those to a black list of forbidden IPs. So requests to those addresses will be discarded. It's a simple diagram of how that looks. So when you attempt to visit a site that's black listed, you'll either get a connection reset or a 404 error. The weakness of IP address-based blocking is that a lot of IPs are not static. In many cases they're hosted on content delivery networks which are ephemeral in a way. They shift from place to place and people's IP address could constantly be migrating to a new location. So it's not effective and it's a lot of work to maintain oftentimes. It also comes with a high risk of collateral damage. You'll tend to block other parts of content that are hosted on the same IP. And generally this kind of works better for blocking either specific apps basically rather than specific content. In the same vein, URL blocking involves a black list of forbidden URLs and when you attempt to visit that or a keyword or a black listed keyword, then your request will similarly be rejected. Port blocking also works the same way. So a sensor can choose a certain port that they don't want to allow any traffic through and similarly you would not be able to connect to those end points. Okay, DNS hijacking or sometimes called DNS poisoning, DNS spoofing. This involves basically the DNS lookup process so how our URL is resolved into an IP address because that's controlled from a highly centralized vantage point, the sensor can actually intercept your DNS resolution request and deliver a page of their choosing basically instead of the page that you've requested. Typically that involves a block page of some kind saying that the site you've requested to visit is forbidden but they can also even deliver a malicious page pretending to be the page that you've requested but actually isn't. There was a case in China before Wikipedia was HTTPS enabled, SSL enabled. If you requested the page for Tiananmen Square, the Wikipedia article, they were actually delivering a kind of sanitized version of that site instead of the legitimate article. Of course, HTTPS adoption kind of prevents blocking specific sub pages nowadays. So if you're in Iran, for example, this is a page that you might see that says you can't go to this site but here are some great other sites that you can visit. In Saudi Arabia, this is a block page that you would see that's put there by the information ministry. So in both cases, there's a clear kind of accountability, someone that you can contact an email address, someone that you can contact about your inability to access that content. But oftentimes, your request will just fail to complete. You might get a 404 error and there's not a clear indication of is this site banned content, is there a problem with the content provider or is there a problem with my own internet connection? So some kind of ambiguity as to why you're not able to visit that content. Keyword filtering is kind of an escalation because it allows the center to filter URLs based on keywords anywhere in the path name. Again, pre-HTTPS, that was a bit more relevant because TLS or SSL enabled connections you can't see into the path name except for the top-level domain and it also allowed them to block new or unknown pages that are related to that type of content rather than having to discover the domain and the IP address and add it to the blacklist manually. They also have the ability to blacklist or whitelist entire protocols, say HTTPS. They can't see into it. This is something that happened in Iran in the 2013 elections. So gradual escalation between the circumvention providers and the sensors there which culminated in eventually only HTTP traffic being whitelisted. And obviously I come back to the term collateral damage that really is something that can break a lot of other essential internet services and make that essentially unusable. Deep packet inspection, this is a word that some may have heard, spoken about through the Congress earlier in the week. This is basically a high-level processing method that allows the sensors to look throughout the content of a web request in the header, in the inner traffic, as well as the URL for certain keywords and other specifications that pertain to a repository of blacklist arguments and choose to block that traffic. So with the keyword filtering and deep packet inspection, the sensors need to process a lot more data. It's very much more resource intensive. And it really depends how deep they want to dig. And as I mentioned at the beginning, the technology has gotten much more widely available, cheaper and easier to implement and more effective. Traffic fingerprinting is something that's enabled by that because even without knowing the domain or the IP address or being able to see it through encryption, the sensor can record what a browsing session looks like and create rules for how the user sees that page or if they do. This encryption doesn't change that technical configuration. And so they can block a page based on its size, load time, and other kind of technical details, which would even allow them to block, say, specific subpages of Wikipedia that are HTTPS enabled. They might incidentally block some other page that follows that specification. But that's kind of the trade-off that's being made. And I will come back to this, but just to mention VPN traffic, SSH traffic, though they are encrypted, they have a very obvious signature, a size and shape that's identifiable on a network perspective that can be fairly easily fingerprinted, which is definitely a vulnerability. Now I'm going to switch tracks and talk about some circumvention methods. So to each of the censorship methods that I discussed, there's kind of a circumvention answer and it escalates from there. So if your DNS is being poisoned, then you could switch to an open DNS resolver or a third-party DNS resolver. You've often heard of people switching their DNS to 8888, which is the Google DNS, or 1111, the Cloudflare DNS. It's like Google and Cloudflare maybe aren't going to censor us, you could argue, or it's at least better than trusting your ISP if you're in China or Iran or something like that. If you're a content provider and you think that your domain is blacklisted or the IP of your domain is blacklisted, you can migrate or mirror your block domain to a new one. I mean, you're always racing the sensors in that case, like chances are they can discover your new site just as fast as your readers can, but that's another way of kind of evading the lower-level censorship techniques. Another circumvention method you can use is by connecting to a web proxy. So first, you connect to some other website that's not on the blacklist, and from there you use that as your vantage point to kind of browse the open internet. Of course, you can use a VPN and you can use other circumvention tools like Siphon or Tor, which I'll tell you more about. So SSH, this is a protocol that's used to communicate with servers and administrate them. It's great because it's encrypted. Anyone, any man in the middle that's trying to look at this request, they're only going to see something that they can interpret. But again, because of its regular size and shape on a network perspective, SSH can be fingerprinted using off-the-shelf technology. Same thing with VPN. And so for most censorship regimes, it's easy enough to block all VPN traffic in and out of the country just by flicking the switch that says we're not going to allow VPN. And increasingly this year, we've seen during, say, politically important moments like elections or public demonstrations that the sensors will utilize this ability and leverage that over the networks they control. So which brings me to OSSH. OSSH is an obfuscated protocol. It stands for obfuscated SSH. There's basically ways that you can innovate on the existing SSH tunnel to make it as much as possible indistinguishable from random bytes of generic web traffic. So rather than looking like this strange encrypted thing that the sensors can pick out and block, it's designed to blend in with all the rest of the web traffic that's going on. And there are a lot of different things that you can do to sort of change the exact configuration that it follows so that it's as random as possible. And some of the things that you can do are insert random packets alongside the tunnel, like random web traffic both ways. You can vary the packet size, the packet interval, and other kind of ways of making that as amorphous as possible. Again, back to the concept of collateral damage, a sensor that's going to endeavor to block something that's indistinguishable from random web traffic based on certain features that they identify and probably cause them to block, incidentally block, some generic web traffic as well, which is a calculus that they're always going to have to make. What deep packet inspection is doing is it's scanning deep into every web request, but that process, as I mentioned, is quite resource intensive. So generally the sensor can only look at the first subset of packets, try to make a decision based on what their categorization of that traffic might be, and decide to either let it pass or filter it. So what circumvention technology is trying to do is make that more computationally intense for them. And it really depends how deep they want to dig. And they do risk kind of slowing down general internet performance in the country if they do that. This is another technique called MIEC, or domain fronting, basically involves routing traffic through what's referred to as high value domains, so typically large infrastructure pieces of the internet, and hiding the real request inside the encrypted, the TLS encrypted connection. For example, forcing traffic through CDN data centers. That typically get a different blocking treatment because they're large infrastructure components of the internet that a lot of essential services require to run on. This is a diagram just showing how that request is passed along. And if you're interested in learning more, I'd encourage you to refer to the paper David Fifield and colleagues worked on, including some Siphon developers. What are some vulnerabilities of circumvention tools? The sensor can attempt to disrupt your distribution. If people can't get your apps, then they can't use them. So one thing that we do is we have multiple redundant distribution methods. The sensor can always block your website where you have your applications available for download. They might even blacklist the Play Store or the Apple App Store, or some countries that's embargoed and not available anyway. So one of the innovations that we use at Siphon is email autoresponders. Basically, you can request a number of generic email addresses. And the return email you will get has links to secure cloud-hosted download sites. And even the APK or EXE file as an attachment. The sensors might also be able to enumerate your servers one by one, even if you have thousands and thousands of servers. If they have enough people running enough discrete copies of your software, you have to make sure that they can't catch up with all your endpoints before you roll them over. So on the Siphon network, it's fairly ephemeral, like no IP addresses are really static. And the servers are constantly turning over, really protects us against that vector of attack. Another thing is no individual copy of the software is ever going to know more than a very, very, very small subset of the servers, like maybe 1% or less. Protocol-based attacks are interesting. Siphon is using what we call a multi-protocol architecture and basically protects against the blacklisting of one or even a few protocols, because there's always redundant transport methods that the traffic can use. And then as I mentioned, we do various traffic obfuscation methods to be resilient to traffic fingerprinting as well. In terms of transports, what makes a protocol relevant? So one, is it effective? Does it work? Does traffic get through? Is it able to actually transport actual throughput? Secondly, resilience. For how long is it going to work before it gets figured out and blocked? Another thing is it should have low overhead. You can't insert too much extra data into the tunnel. And lastly, not placing too much demand on users. For instance, peer-to-peer traffic, it requires users to actually do something to run themselves as a proxy node in a network, and that could affect scalability and even performance. The reason I say that is because even though some circumvention methods, experimental new methods that have been discovered and worked on are excellent, but they're not as easy to scale from tens or hundreds of people to tens of millions of people, especially not rapidly. And some of the examples I'm going to show will show you how this network has really the ability to rapidly scale itself in critical events, and that keeps people connected to the open internet. Just a small note on network data as well. I'm sure everyone in this crowd has, at one time or another, or regularly uses a VPN. And not all VPN providers are created equal. Not all of them are to be trusted. So I want to just make a note on how to be privacy conscious as a VPN provider. You're not technically anonymous from your VPN provider because at the end of the day, you are agreeing to tunnel all the traffic from your device across some third-party servers that you don't know them and you don't really know what they're doing with your traffic. And you have to click that button that says, I trust this provider. So with Siphon, we make sure that we don't log anything. The only data that we are privy to is statistics that come from the network, aggregated network statistics, and no personally identifying information on any users. You can know where people are without collecting their IP addresses because you can do the GeoIP lookup on the client side and discard their IP address without it ever having to leave their device. And another great feature that Siphon offers is you just download an application. You don't have to register. You don't have to provide your email address, your phone number, credit card, et cetera. So what this data allows us to do is make some conclusions about the censorship environment that's being faced in different places and try and make sense of how our network protocols are being affected by those dynamics. It allows us to see how the software is performing and how that could be improved. And it also allows us to ensure that we stay one step ahead of the censors. This is a map in real time of just showing where Siphon users are in the world. There are at least some users in every country have highlighted Sudan in the center there because the recent blocking event that occurred starting December 19th, it involved basically centrally orchestrated blocking of all the major social media platforms, Facebook, Twitter, WhatsApp. And within a matter of days, as you can see, we've gone up to half a million users a day there. Interestingly, a lot of VPN tools are not available in Sudan because of the sanctions, economic sanctions. So I think that's another factor driving adoption. And it works. It's not the first time that we've seen a rapid spike in Siphon usage in response to social media blocking. There was a case earlier this year in the summer starting about mid-July in Iraq where there were protests in Basra and the southern regions. And again, the government reacted by blocking Facebook, Twitter, WhatsApp, basically essential social media and communication platforms that people rely on, like anyone from the MENA region. Like you know, WhatsApp is life. A lot of other regions, too. And we were above 4 million users a day over that time period. This is a snapshot of the protest period that began near the end of December last year in Iran, where thanks to, I guess, overall good network performance in the country where sometimes VPN connections or other circumvention methods like the Tor Network aren't as reliable, Siphon has a fairly good reputation there. And we reached a peak of 14 million users a day after they blocked a telegram that basically the only essential instant messaging service, you could argue, that was already left uncensored by the authorities there, as well as Instagram, same case. And so basically, there was a country-wide demand for ways to stay connected with that. And that kind of represents almost a fifth or even a quarter of all internet users in Iran. We're using Siphon during this time period. Another note on scalability is that the network is pushing at the peak 1.4 petabytes of data per day on networks that are known to be average speed of two Mbps connection or something like that. It's pretty impressive. And again, I did mention the challenges of scaling peer-to-peer type circumvention services. One of the advantages of having a cloud-based centrally managed system is that we are able to provision servers rapidly when there are incidents like this. Iran has been some of the most challenging, some of the most sophisticated, some of the most aggressive censorship that we've encountered over the past year. And that comes from their motivation not just to block content, but also to block the methods that people use to get around the filtering there, which has become, in the past decade, a regular part of going on the internet. Telegram was finally banned via a court order, which also stated that Telegram must be blocked in such a way that no Iranian can access it, not even with circumvention tools. And so there was a push from the internet providers there, which are, so some countries you might see a lot of heterogeneity in the blocking enforcement. As say, the talk that was about the Telegram blocking in Russia, which was given by Lenny yesterday, his research showed that there was some varied compliance from some internet providers there. In Iran, the ISPs seemed to be very centrally controlled. And so the blocking rule was basically implemented country-wide. So these statistics are showing daily users of Siphon and a Telegram client that was deployed integrated with our library called Telegram DR, which within the first day was already up to close to a million users. This is a shot of tour usage during the same time. You notice tour direct connections start to drop off in favor of bridges. But that's maybe 10,000 users a day compared with 10 times, 100 times. This is an example of the advantage of the multi-protocol architecture that Siphon is using for transports. These are just by protocol group showing hourly connections. And you can see when one or two types of protocols get knocked out, the balance of connections is picked up by the other transports that we use. So effectively, without blocking all the protocols, the network will remain resilient. This is another example showing China during the 19th Party Congress, which happened last October. Basically, beginning in July of that summer, WhatsApp, Voice, and video calls were beginning to be blocked, and only messaging was working sort of drove the adoption of lots of different circumvention tools. But there was simultaneously an order to ban VPNs in China as well, which was slowly being orchestrated and even complied with by parties like, say, Apple, which removed VPN apps from the app store. Finally, in about mid-September, WhatsApp was blocked completely. And you can see that our usage there started to increase a lot. Then at the beginning of the Party Congress, actually an attempt to filter Siphon based on protocols. And actually, the protocols that were targeted were not connecting successfully or were taking a long time to connect. But nonetheless, we were able to sustain usage through that time period to make sure that people had open access to information. OK. So just a recap of some of the trends that have been noticed over the past year. For sure, deep packet inspection is getting cheaper and easier to implement, possibly even able to look deeper into web traffic without sacrificing performance. A spec that I saw, it was an article from Radio for Europe Radio Liberty, which was about a meeting of the, basically, DPI filtering providers in Russia. The newest spec was they wanted these systems to be able to run at scale on a one terabit per second feed data, which, I mean, that's a really shockingly high number. So that's possibly the next generation of this technology that we're going to see. As I mentioned, a crackdown not just on content, but on circumvention tools and VPNs, VPNs especially becoming a lot more easy to block, not just for the sort of notoriously sophisticated sensory nations like China and Iran, but any government can really afford a DPI box nowadays. And it really has just a switch that you can turn off VPNs if you want to. Another good point is collateral damage is becoming less reliable. So the example that I showed from Iran, we observed that, so this is just an anecdote on the same story. Basically, even when you have encrypted communication on the internet, some part of that transaction happens unencrypted. It's called the TLS handshake. So basically, when you're going to communicate encrypted to that server, you are going to say, hey, there's server. I'd like to talk encrypted with you. The server is going to say, OK, I can talk TLS 1.1, 1.2, 1.3, and then you agree, and then you talk encrypted. So Iran blocked traffic based on some TLS handshakes that were suspected to be being used. The TLS handshakes that Siphon was using at that time were emulating some of the most ubiquitous and common TLS handshakes that are used online, like Google Chrome, Firefox, Chrome Android. It was like most widely used web browsers in the country. And when this filtering rule was implemented, users reported problems with using those central internet services, your web browser, starting to break because of filtering rules that were deployed to target one specific thing, but not surgically enough. That said, it seems that sensors in 2018, oops, yikes. Sorry about that. Sensors in 2018 are willing to sustain large amounts of collateral damage or block unreasonable amounts of benign web traffic going in and out of the country, just in an effort to enforce their blacklist rules. Another thing that we've seen, not in 2018, but in previous years, is the willingness to even block entire CDNs. So using kind of critical infrastructure pieces as a way of concealing or obfuscating circumvention traffic may not be the most reliable method going forward. Another thing that has been observed is sensors are beginning to block only certain IP ranges at the sub-level of the CDN as well that are suspected to be involved in circumvention traffic and kind of being able to block just part of a CDN instead of the entire domain. So that's something to look out for in the coming year. So by way of conclusion, what can you do? One, don't settle for partial internet. Anything less than the entire open internet is not the worldwide web. Secondly, you can't blow the whistle on censorship if it's safe for you to do so. Thirdly, you should use free open source circumvention software and support it. Fourthly, come work with us. If you're a researcher, if you're a developer, if you're a media provider, we can work together. And we'd love to collaborate. And lastly, especially app developers, you can use our open source libraries. They're all on our GitHub. If you want to add some censorship resilience to applications that you're working on, then that's something that's highly encouraged. And we'd love to speak more about that. And we have about 10 minutes for questions. So I will leave it at that. Thank you very much. And I already see people lining up at the microphones. And we also have questions from the Signal Angels. So we just hurry to your questions. Microphone 1, please. Hi, I wonder, did you mention like, I see the biggest threat from censorship is from big tech giants like Google, Facebook, and their manipulative algorithms. So this is like the biggest threat that you kind of didn't mention. I think this would be like, I think this should be the focus, like how do we bypass this? Because these tech giants become more powerful than any head of any state. And they're like really, I experienced just days ago, we started petitioning, which was totally shadow banned on Twitter and Facebook. So this is the biggest threat from censorship, even bigger than state parties. I mean, what you haven't mentioned, I think what's your perspective on that? I think I did mention at the very beginning, kind of the shift from first generation, that's interceptive forms of censorship to the second and third generation of information controls, which is like, one, being able to have legal mechanisms that enforce the blocking of content. And even the takedowns of content from say major social networks like Facebook and Twitter. And other apps too, Telegram has kind of administrators on their channels and groups now that are accountable to sort of local laws. That's something that circumvention technology doesn't expressly deal with at this time. We are more concerned with maintaining access to the sort of the web platform itself when it gets blocked. But sure, that's definitely a concern. I would say an even greater and more difficult concern in this day and age than simply being able to access content, is being able to preserve content that's up there. So that's not something that I have an easy solution for, but definitely something that I'm gravely concerned with. Sure. Democracy can be preprogrammed by their algorithms and censorship. So this is kind of the biggest stride from censorship as is here. But thank you. Thanks. So next one from the Signal Angel, please. So you mentioned the OSSH protocol, that of your case, SSH, what clients and servers can you recommend that protocol? As far as I know, it's implemented in Siphon. I'm not aware of any other clients that use it, but I believe it's an open source transport. So probably there's some people out there using it. And I should add to that, it's not always guaranteed to be the same thing. Like, it doesn't stay the same for long, and probably other implementations of it have different ways of confiscating the traffic specifically. We have more questions on microphone two. Thanks for your talk. I have two questions. This one is, as I understand right, the end user software is open source. How about the server components? Can I run my own VPN provider? And do you plan to open source the software from the server side? Second question would be like, I can imagine that running a infrastructure that serves so many users at this scale is pretty costly. So what is the business model if you don't need to register and donation based? Where do you get the money to pay the bill at the end of the month? Okay, first question, thank you for the question. First question first, Siphon is open source. The client software, server software, or server code, it's all in our GitHub. Theoretically, you could compile your own circumvention client, run your own network. If you have some servers at your disposal that you want to do that, then there's nothing stopping you from doing that. Second question, sure, it's definitely a challenge maintaining a user base this large on a free service. So some of the ways that that's supported is, one, we have an app that allows you to subscribe for premium service for like the sort of not explicitly censored countries like the United States or European Union or whatever. People that feel conscious enough that they want to support internet freedom for others by supporting the network, that's really encouraged. We also work with international broadcasters that have a mandate to support internet freedom around the world and we can work with them to basically provide circumvention technology that helps them deliver content into closed societies and in exchange, we have a way of supporting the free users. Okay, thank you. I would take the signal, Angel, again, because the others can also come in front, then later. Have you seen countries with surprising amount of users, countries which are not usually considered to have heavily restricted internet access? Pardon me, could you repeat the question? Have you, in your statistics, do you have countries where the amount of users in that country surprised you because that country is not usually considered to heavily restrict internet access? Yeah, absolutely. Plenty of Western countries have pretty significant Siphon user bases, maybe tens, maybe hundreds of thousands of users. But even here in Germany or in the UK, it's not to say that countries that are known to be free internet, open internet countries, it's not to say that every network in that country is free and open. Plenty of institutions, workplaces, universities maintain a pretty aggressive blacklist of some types of content or some applications. So that's something that I see as a key driver of circumvention usage in those countries. Thank you. Microphone 4, please. Let's suppose I'm a sensor and who likes to use traffic finger printing to sensor. And I wonder how efficient is it if I want to keep a number of force positives low? Are there any studies on the effectiveness of traffic finger printing? I want to filter the bad traffic but to keep good traffic safe. Thanks for your question. Traffic finger printing is known to be fairly imprecise. I mean, I don't have any studies I can reference, but anecdotally, within the internet freedom community, what people are saying is that it's becoming better. But, yeah, collateral damage is a calculation that every sensor needs to make. And in some cases, they don't mind. In some cases, they don't know what other traffic is being filtered as a result of the measures that they're implementing. And it remains in many ways kind of a whack-a-mole approach. There was a study last year that was on specifically machine learning-enabled censorship, which was extremely imprecise. It had a lot of false positives. It was like something like 80% successful, they claimed, the researchers claimed, which obviously that's not enough to deploy it at internet scale. Okay, and we have one question at microphone one. Hi, hello, hello, hello. So sometimes I wear your hat and sometimes I put on another hat where I'm your enemy. I won't go into the recent slide. I sometimes find that throttling can be more effective than blocking because a user might get bored, downloading, waiting for a YouTube video to load and go away and do something else which leaves the bandwidth available for other people. So I'm wondering if you've ever seen that tactic being used where rather than you would actually block a website and give up a message saying 404 or second action reset or something where you just actually make it unusably slow. You're assisted, man. Are you assisted, man? Of course. Thanks for your question. Yes, that's definitely a tactic. I think also trying to diffuse the accountability for censorship is another reason that they do that because there's sort of no guarantee that it's not a problem with the content provider's site or something. There have been lots of examples. I mean, I can share with you afterwards of internet throttling used on specific domains to sort of like in China, for example, famously kind of not exactly blocking your connection but just throttling you to a completely unusable degree. I would say when that's deployed on specific domains, circumvention tools still work effectively. When it's deployed on a network scale, then there's not too much that we can do or like an internet shutdown. That's one case where it doesn't matter how robust and resilient the circumvention software that you're using is if no one has an internet connection with one exception, notably an insight on history where we kept networks online in the case of an internet shutdown. Does that answer your question? Thanks. Thank you, and we have one more question from the Signal Angel. Have you had governments or other organizations try to fight you legally for enabling their users to circumvent the content filters? No. That is a nice short answer. So we have one more question here of three more in the audience. I take microphone two, please. You mentioned domain fronting as an effective way for high-value domains. When Google and Amazon stopped tolerating domain fronting, have UNISO organizations been in touch with them? We were part of some discussions on the issue since we notably do use that as a technique. Syphon has never done domain fronting through Google or Amazon. I mean, to go back to the example of a circumvention method that works for tens or hundreds of users, but may not work for tens of millions of users, this is a perfect case in point, I think, for that. It's like, sure, it's a cool trick. Maybe it doesn't require a lot of technical sophistication to put Google.com in the header of all the traffic that I send. But if I have tens of millions of users, then that's potentially gonna sabotage the person's domain that I'm using. So any domain fronting that's done on a scale that the Syphon network uses, it's done under close collaboration and a formal agreement, not in the informal way that it was being done by so many different app developers, which I think is the reason that it was eventually cracked down upon. And so it does violate the terms of service of those domains. So, yeah, is that your question? So the person on microphone four is now disappeared. Not coming back? Okay, so thanks a lot, Keith, for your presentation and for answering all those questions. And you're still here for a few offline questions. That's really nice. So, thanks you all that you were here. Thank you. Thanks, Keith.