So this panel is the hackers, the lawyers and the defense fund. I am Harley Geiger and I am your moderator for this panel. There is unlikely to be a hacker at this conference that has not contemplated at some point the potential legal trouble that they may face as a result of good-faith security testing. And many people have experienced this directly themselves and many more will experience it at some point in their hacking careers. So one of the things that makes the security community so effective is that it is always pushing the boundaries of permissible behavior. And by pushing that boundary, it helps to find that boundary, it also creates space to innovate and to simulate criminal attacks so that we can better prepare ourselves to defend and preempt those very attacks. This is how we fix vulnerabilities before malicious actors get a hold of them. In many ways the laws recognize this now and are working to accommodate this kind of security research activity. But there, so we're seeing more coordinated vulnerability disclosure in laws like in the United States, at the state level, abroad. However, we are also seeing that the hack continues to face legal threats from various sources like the governor of Missouri threatening a newspaper. And some of these are bogus or empty, but some are also quite serious. So what is it like for a hacker that faces legal threats and what sort of resources are available for security researchers that run into legal complications? So for this panel we're going to hear first from a hacker that has lived this and faced legal threats that is Miles McCain. And we'll hear from Charlie Schneider from Google about how the ecosystem benefits from the work of security researchers and that the chilling effect that legal threats can have. Third, we'll hear from Kurt Upsall. He is the associate general counsel at Filecoin Foundation and has provided legal representation to many security researchers. Then we'll hear from Hannah Zhao from the Electronic Frontier Foundation about the ways that EFF provides legal services to hackers through the Coders' Rights Project and impact litigation. And then lastly, we'll hear again from me about the Security Research Legal Defense Fund. This defense fund was recently launched and aims to provide funding for the defense of good faith security research. So one last thing before we kick that off, which is that nothing you hear on this stage should be construed as legal advice. You do need a lawyer. Lawyers are really great, but they're not sitting up here at this moment. So Miles, if you wouldn't mind, please introduce yourself and tell us your story. Awesome. Thanks, everybody. Hey, everyone. I'm Miles. I am a college student, open source software developer and enthusiast security researcher. Right now I'm just going to briefly share my experience receiving a legal threat for good faith security research, and then I'm going to zoom out and talk about some key takeaways that I had from this experience. But before I do that, I want to give a shout-out to Adi right there and the whole Stanford Applied Cybersecurity crew. If you want to stand up and just wave as I say this, Adi was one of my co-conspirators on the vulna disclosure that I'm about to talk about, and we would not have been able to stand up for ourselves in the way that we did had it not been for the amazing support of the Stanford Applied Cyber community. So thanks for being here. All right, so this is a fun story. Last October, a Stanford student startup called Fizz was getting super popular on campus. This was an anonymous social media app that claimed to be 100% secure. What could go wrong with something like that? Well, you know, me and a few security-minded friends, Adi, being one of them, we were drawn like moths to a flame when we heard that. And so one Friday night, we decided to evaluate whether Fizz really was 100% secure like they claimed. Well, dear audience, as you might be able to tell from me sitting here, they were not. Within a couple hours, we were able to gain full read-write access to their database where they were storing all posts and users and everything you could imagine entirely de-anonymized, 100% secure. All right, so at this point, we did what any good security researcher is supposed to do, which many of you have probably done, which is that we've responsibly disclosed what we found. We wrote a detailed vulnerability disclosure report. We suggested remediations. And we also proactively agreed to not talk about our findings until an embargo date, which was fair about in the future. We wanted to give them time to fix the issues. And we sent them the report via email. At first, they were super grateful. They said, hey, fixing these issues is our absolute top priority. And every couple weeks, I guess every week or so, they would send us an update. And then one day, they sent us a threat. This was a crazy threat. I remember it really vividly. I was just finishing up a run, and I looked at my phone. And my heart rate went way up. That is not what's supposed to happen after you finish a run. In the threat, they said that we had violated state and federal law. We had conspiracy to commit a felony. They also brought up the Stanford disciplinary code, which I thought was pretty odd. And then at the very end of their threat, they left a demand. Don't ever talk about this publicly. And if you agree to never talk about this, then we will not pursue legal action. Well, as you can probably tell by me sitting here, we did not agree to that demand, and I'll talk about why. But clearly, they wanted to scare us into silence. So what do you do when you get a letter like this? Well, I totally freaked out. I was angry and scared. I'm usually a try to be a pretty level headed person, but this was something different.  We're gonna need a lawyer. And if you can't tell from this advice, this was not Cooper's first time receiving legal threats. So we started asking for help in our network. And within a few days, we were connected to Kurt, who's sitting right here, and Andrew Crocker at the Electronic Frontier Foundation. And after talking with them a little bit, Kurt and Andrew generously agreed to represent us in our response to the letter pro bono. So we walked them through our disclosure and our documentation. And with their advice, we made the decision to not cave to the threats. Also, hey, I see a big crowd of AC people who just walked in. Love y'all. And so Kurt and Andrew drafted a response to Fizz, and they totally shut the threat down. And as an aside, the Stanford Daily published both the threat and our response. This is public, I really recommend you read it if you haven't. Anyway, after we responded, the Fizz team asked to meet and we were able to resolve the situation amicably. We pushed Fizz to proactively disclose the vulnerability to their users publicly, which they did eventually do. So taking a step back, getting a legal threat for our good faith security research was incredibly stressful. And the fact that it came from our classmates just added insult to injury. And I have three sort of key takeaways from this experience that I want to share. First, keep your research above board and really well documented. Ahead of time, think about what you're trying to accomplish, write it down, and make sure that you don't cross any ethical lines. A big reason why we were able to resolve the situation amicably was because we played by the rules. We didn't save or leak the data that we had access to. We didn't mess with anyone's account. We didn't cause any damage. And we kept really detailed documentation of absolutely everything we did. And that clean documentation helped us as we were writing our disclosure, and I imagine it also probably helped Andrew and Kurt as they were drafting the response. Second thing, stay calm. I cannot tell you how much I wanted to curse the Fizz team out over email. My God, but no, we had to keep it professional, even as they were resorting to legal scare tactics. Your goal when you get a legal threat is to get out of it, to resolve the situation amicably, to not go to jail. That is it.  And the third and final takeaway is get a lawyer. And I am not just saying that because I am on a panel with a bunch of lawyers. We could have tried to navigate this process on our own, but that would have been an absolutely profound mistake. They would have escalated. After all, they were banking on us being naive and falling for their scare tactics. But thankfully, Kurt and Andrew stepped in and really saved the day. Now, I recognize that not everyone has the ability to get the Electronic Frontier Foundation to represent them pro bono, and they don't have the ability to represent everyone who faces a legal threat. But there are an increasing number of resources available for good faith security researchers who do receive legal threats. We're going to be talking about those on this panel, and you should absolutely try to make use of them. Do not try to fly solo. Now, I will hand it off to Charlie, who is the head of security policy at Google and who has spent a long time on the other side of the vulnerability disclosure process. Thank you, Miles. So yeah, so as Miles said, I kind of am here to represent the other side of the equation, the bug collectors. And throughout my career, I've had the privilege of collecting bugs from skilled researchers all over the world. And my career has been spent exclusively in very, very large organizations who in theory hold a lot of power and leverage over hackers. And so at the Department of Defense, I helped found and manage the first bug bounty pilot called Hack the Pentagon, and I wrote their first vulnerability disclosure policy. Later, I worked at a financial institution where I led researcher engagement and their bounty programs. And now at Google, I get to work with our bug collector teams all over the company. And in all of these experiences and throughout, I've seen kind of firsthand the power and leverage that organizations like mine can hold over researchers. Even before we could found the, and start the Hack the Pentagon bug bounty pilot, I first had to kind of search through the massive Defense Department bureaucracy to identify who within the department had been machine gunning out cease and desist letters to anyone they could find who had been scanning any part of our slash eight IP ranges. Like talk about sending a mixed message as you're trying to get a bug bounty program started. And during the first bug bounty, one of our very top contributors to the program who I believe has continued being one of the top contributors to all the various kind of DoD vulnerability disclosure programs was an individual who ran a foul of US computer hacking laws. And he served his time and he got out and was in the first wave of people to raise their hands to contribute to government security in kind of the first bug bounty. And I think that took a lot of courage to have gone through what that person did and faced those risks and still come back to help us. And at Google, we see there as well kind of the power that companies have to chill security research. Sometimes we receive reports from researchers for bugs in other companies' products because those researchers are afraid of what those companies might do, their reputation on disclosure issues. And so they come to us instead. And I think that's really unfortunate and that's ultimately those companies' loss. And I think it's all of our loss if hackers can't contribute. You know, from a bug collector's perspective, we want hackers to be able to engage on an equal footing with us without fear of legal reprisal. With more kind of legal certainty in the equation, we can have more open and deeper collaboration and conversations. And ultimately from a company's perspective, we're gonna get more and better bugs. And each new report gives us an opportunity to close off an avenue of attack and protect users. But when vague laws and companies behaving badly allow kind of the creation of this chilling effect on security research, I think ultimately the only ones who truly win are attackers and it's users who lose. So that's why I'm super excited to be here and why I'm glad that the Legal Defense Fund exists now. And I think all companies and all kind of bug collectors should be glad it exists. So I'll turn it now to Kurt. Hey, everybody. Doesn't appear to me. Hey, everybody. That is on. Hey, my name is Kurt Opsall. I'm the Associate General Counsel for Cybersecurity and Civil Liberties Policy with the Filecoin Foundation. And I also volunteer my time with EFF as a special counsel and for many, many years I was working with EFF on the Coders Rights Project. I've been in this community trying to help by the legal situation since the Alexa Park days back in DEFCON 13 was my first one. We had an exciting time with security researcher, Mike Lynn at Cisco and some disputes over a program that had to be physically removed from the program book due to some threats. And I've really enjoyed working with countless people in the security research community and how to help them out avoid situations or deal with situations that occur. So I want to talk to you a little bit about some of that experience. So just to set the stage a bit sort of broadly speaking, there are two types or categories of legal issues that come up for security researchers. The first are issues around doing the research itself, legal issues that may arise because of, are you hacking onto someone's system? Will that be considered an intrusion? Is there a anti-circumvention issue arising out of the Digital Millennium Copyright Act? An end user license creamer terms of service will have a potentially contractual provision that might go on. If you're doing wireless research, it may involve getting contents of communication which brings up what the law likes to call wiretapping. And so there's a host of issues that can come up in the course of it and how you navigate those in order to minimize risk. And the second large category is the disclosure. And this comes out where if there is a vendor or a commercial entity especially who you are exposing a vulnerability, they may become sad and upset. Now these days it's actually fairly well established for technology companies that people who've been around this space for a long time, receiving bug reports, they may have a bug bounty program that's been going on successfully for a long time. And this has been a really great advantage to the community to have bug bounty programs so you can look at, see what the rules are, work with it, have points of contact. But it's not always the case. More old school industries, sometimes I call it first contact situations, the first time that they have been reached out to by the security community, say your security is broken, people can see all this info and sometimes they panic or they want to make sure this shuts down. Are they thinking of it from a sort of a calm's point of view, a communications point of view of trying to not have that communication. So the good news is for disclosing vulnerabilities if you disclose truthful information about a vulnerability that is strongly protected by the First Amendment, it is hard for someone to build a case around saying you should not say something which is truthful even if that is something that is embarrassing or awkward. But some of the tension arises is that these two issues can be interrelated. One of the issues is that if perhaps there was something was towards the edge of legal lines or can be construed that way in the course of doing the research, publicly disclosing it, well one, if done un-carefully, might involve admitting to things on stage that well, cannon will be used against you. But also even if you did play by the rules, you did it well, there's a threat of litigation over it and the possibility that you'll be sort of facing a very awkward situation getting these threats that may worry you not about the legality of the disclosure but that they may go after you for the underlying research. So what should hackers do in these kinds of circumstances? Well, a lot of it, first of all, have a lawyer with you at all times. But that is somewhat inconvenient and hard to do. So it's the question of when should you reach out and also what can you do to help mitigate some of these things as early as possible? And so when I talk to security researchers, some of the advice is very dependent on what stage things are at. If it's early on, you can minimize the risk in doing the research itself. So for example, if it's a hardware bug you're trying to find, if you own the hardware then that resolves whether you are intruding on somebody else's hardware. You'd be amazed at the number of machines that you can buy on eBay that if you wanted to test, say, voting machines in the early days, it was very hard to get cooperation from the voting vendors, but you could buy used voting machines on eBay. Someone was doing a test of some TSA scanning machines. Turns out those are available on eBay as well. So you can do a lot of that stuff. Wireless communications, well, you can minimize risk around wiretapping by just having your own communication that I say where you've consented or you and your buddy, but not doing it more broadly to strangers. So there's a lot of things that can be done early on, though sometimes our first contact with a researcher is after some of that research is done and it's about trying to navigate the path forward. But I would say one of the things you can and should reach out, if you have some questions about that, reach out to the Coders Rights Project at EFF and Hannah will talk a little bit more about that to avoid some of these problems. But at the disclosure stage, I would say probably the key thing to start out with if you're about to disclose is make sure that you get someone who understands security or is an engineer trying to establish sort of a geek to geek protocol communications, not going through marketing or legal, but with an engineer. And sometimes people in this community know somebody there or you can check the disclose.io has a list of points of contact, but if you can have an engineer, they probably will understand it. Even if it's an engineer working in an old school firm, it might be an internal advocate for like, yeah, this is embarrassing, but this happens and we gotta deal with it. But sometimes the only path forward is going through a more public-like comms channel or things get escalated, and that is a sign. A sign things might be going weird. That is an excellent time to reach out for a lawyer. If there are signs, if you're a lawyer is getting back to you, even if it's not a threat, if they're asking some weird questions, maybe you wanna talk to your own lawyer for a response. As Miles was saying, like document some things, especially if there are documenting things that show that you did the right thing, you behave properly, that you didn't mess with customer information. And also if they say nice things about how much they appreciated early on, save a copy of those emails later because in case things get weird later, it's good to have. And most of the time, these things can be resolved. And everyone goes away ultimately happy and there's some awkward moments along the way, but more often than not, it can be resolved. And even when there is this kind of, I say Barbara Streisand is your friend. The Streisand effect, as many of you I'm sure know, is when the news about the dispute gets more coverage to the issue then the issue they're trying to cover up would have gotten any way. And I think that helped to have the Stanford Daily publish the Streisand assistance response letters. And on my mind today is that many years ago, I think it was 2008, there was a presentation here at DEF CON about a subway hack, the Charlie Card and the MBTA. And the MBTA did get very upset. In fact, so upset they went to court, tried to get the talk shut down. They got a temporary restraining order. And that led to the talk being replaced to a press conference about how they had swelled speech about their security, which ultimately probably had more people in attendance than your average talk and got it into big news. So that's a strong incentive if someone is behaving rationally on the other side. That them going ballistic on you will actually hurt them far more than trying to resolve it amicably. But of course, not everybody is rational. And oftentimes we say that you can guess what a rational person might do, but your opponents in litigation are not always rational. And so that's when things step up to litigation. And one of the challenges is that while you can get some great pro bono services and I think definitely reach out to EFF, EFF can't represent everybody in litigation. Litigation is a much more time consuming and legal intensive process. It can be fun as a lawyer doing this, but it is not fun to be the person in the litigation. Even if you're going to win, it still sucks to be along the way, but it's good to have counsel on that. And so one of the things I like about the security literature, legal defense fund is in those circumstances where some money will help get an attorney that is where pro bono resources have been used as best they can, but are not enough to have that fund available. And hopefully like it's one of those things that hopefully never gets used, but having it available can help reduce the chilling effect that comes from these streets and the cities.  Some of the ridiculously short deadlines, things like that trying to induce panic. And part of that is the bullying that's going to after someone who is not represented sees the scare thing and just stops speaking about it even though they have every right to. And so having some of that reassurance available can help out and make sure that talks continue to happen. And so the good news on the MBTA is I was just seeing yesterday that some other researchers also found some problems with the Charlie Card on the MBTA and this time they were very nice to the researchers. They listened to what the vulnerability was. They talked it through politely and so things can change and get better. And it went from a bad first context situation to now the way we'd like to see vendors, researchers working together to solve this common problem we have of security. And one last thing before I pass this on, we talk a lot about, I'm a U.S. lawyer, talked a lot about the situation in the United States, but security research is a global phenomenon and is done all over the world. And one of the things that is cool about the United States is there's a long tradition of pro bono legal representation and a lot of lawyers, even ones who work at big law firms and such, see it as part of their job to give back some of their time to the community through pro bono work. But this is not a universal tradition and in many places around the world, your choice is, pro bono counsel is not readily available or not available at all. And so that is another reason it's good to have some funding available to try and help people who are in a bad spot somewhere outside of the U.S. So with that, let me turn it over to Hannah. Hi everyone, hi everyone. My name is Hannah Zau, I'm a staff, excuse me, I'm a staff attorney at the Electronic Frontier Foundation and I'm part of EFF's Coders Rights Project. So I'm gonna talk a little bit about Coders Rights Project, the kind of help that we offer to security researchers and the kind of counseling that we can provide for y'all. So first, EFF, I'm sure a lot of you are familiar with but it was actually founded over 30 years ago in order to defend developers and programmers. Legally, so Coders Rights Project currently continues that tradition of representing and counseling tinkerers and hackers and people who want to innovate while protecting their rights and promoting innovation. So if you are someone who is doing security research, what happens when you need help? How should you reach out to us? Well, there are several ways that we get our clients at the Coders Rights Project the first way is through intake, which is our email info, i-n-f-o at e-f-f dot org. You can email your questions there and say that you're seeking legal counsel about your issue. Those emails that we exchange thereafter will be privileged and so you can disclose a lot more information so that we can help you. Another way that we get folks is through informal referral networks. This means that people might say what happened with Miles, people are asking around, maybe they're in some sort of trouble where they receive a cease and desist letter or something like that and other people will say, well, I know someone at EFF or you should reach out to EFF and those folks reach out to us. And then the last way that happens all the time is here at conferences like DEF CON and other security conferences where people will come up to us after our talks or come up to the booth and say, hey, we have these issues and we can give out our contact information. So again, please do not talk about the possible felony that you committed in a room full of people, but we will have a private conversation instead about it so that we can ensure that your privilege is protected. We do get a lot of requests through intake. We are able to provide counseling for the vast majority of folks who reach out to the CodersRise project. And what that means is that we will sit down with you, we'll get information from you to make sure we have no conflicts of interest. Then we will get details on what you did, how you did it and what exactly your worries are and what your goals are. And we will tell you about the legal risks, the possible laws that could be invoked by adverse parties and the different things that could happen and whether they're more likely to happen, less likely to happen. It's hard to talking absolutes in the law, but we can definitely give you an idea of what your choices down the road can bring. So why should you reach out? Well, the earlier the better because the earlier you know, if you have even an inkling that may be there might be some legal problems down the road, you shouldn't wait until you get that cease and desist letter. Reaching out early is really helpful because we can lay out the path before you and you can make informed decisions based on your risk tolerance and your priorities about what actions you want to take and what actions you don't want to take because now you know what kind of risks those decisions can bring in the future. So earlier is always better. As was mentioned before, EFF doesn't always represent our coders rights clients in litigation and the reason for that is because EFF is an impact litigation firm and that means we are always either trying to make good law with cases or trying to prevent bad laws from happening with cases. And so that means that when we are thinking about what case to take, we think about things like the facts of the case, whether they are good, whether they might be in a good jurisdiction, who are the judges that are likely to listen to this case and whether those judges are friendly to the arguments that we're making. So those type of considerations come into play and the reason we can't take on everyone is because we have limited resources and there's the same Chinese that says you need to use the good steel on the blade of the sword. So you don't want to use it for the hilt, you don't want it to use it for the sheath, you want to use it on the blade itself. And because we have limited resources, we really want to make sure that we're creating the most impact when we spend those resources. Now, individual representation on the other hand means you want to fight the best for your individual client. So I used to be a public defender before I joined EFF and no matter who my client was, I had to defend them, I made the best legal arguments I could for their case. I don't think about things like are those arguments good for the community? Whereas with impact litigation, you think about are the arguments we're going to argue going to be good for the security research community as a whole? So that's another reason why we don't take on every one of our counseling clients as our litigation clients. But that's not to say it never happens. Just a couple years ago, Cara Caciliano, another member of the Coders rights team, as well as I, we represented another college student actually who was also a security researcher. He looked into the code of the proctoring software that his university used and he realized there were references in that code to two functions that Proctorio, the Proctoring software company, claimed that they don't have in their software and that they never do. So he posted the snippets of those code online and criticized the company. Proctorio took a bunch of different actions to take down the criticism as well as the code and he came to us and we began to counsel him on how to help him respond to the takedown notices so that his code gets, and his criticism gets posted back up on Pay Spin and GitHub. And later, as we were in the process of counseling him, we actually decided to take him on as a client in litigation and we filed a suit against Proctorio for what it was doing. And the reason that we did that was because that to this case had a lot of specific facts about it that was good. At first, we think that it's very important to protect security researchers when they expose hypocrisy and inconsistencies in a company's claims versus what its software seemingly is actually doing. And we think that it is a good for the security research community as a whole. On top of that, it also concerned various other issues that EFF is involved with, including student privacy and copyright. So, like I said, it's not impossible for us to take on our counseling clients as direct litigation clients, but it doesn't happen all the time. And with that, I will hand it off to Harleet. All right, so I'm gonna talk about the security research legal defense funds and sort of round us out. We may or may not have time for questions because of the sound issue earlier, so we're running a little bit behind, but we'll get to it if we can. I am Harley Geiger and I am a counsel at Venable LLP. I work on cybersecurity and privacy law. I've been doing so for about 15 years. And I'm also the coordinator of the World's First Security Research Legal Defense Fund. I'm gonna talk about that as a resource that security researchers facing legal threats are able to use. So, the defense funds is an independent nonprofit organization. The defense fund is intended to help individuals who face security threats due to good faith security research, sorry, I said security threats, legal threats due to good faith security research or vulnerability disclosure. The defense fund is not going to provide direct legal representation, so it's not gonna act as your attorney. You know, you have to find your own attorney. However, the defense fund will provide funds for legal representation if you meet certain criteria. So some of the criteria for being eligible are mostly, these are mostly centered around making sure that the defense fund is independent and acts in the public interest. So, one, the defense fund has an independent board. The board approves who can qualify for funds. The board is presently Amy Stepanovich from the Future Privacy Forum, James Dempsey from UC Berkeley and Kurt Opsol from the Falkland Foundation. Security researchers, second criteria, security researchers have to show some financial need. They don't necessarily need to be completely indigent, but in order to get community funds to be fair, there has to be some sort of financial need. And then, as I mentioned a little bit earlier, the defense fund aims to help individuals for threats related to good faith security research and vulnerability disclosure. So in that definition, loosely, is testing or investigating security flaws for the purpose of enhancing the security of the devices, the users, or the systems. The defense fund has to act in the public interest and so it's not gonna defend, even if you're normally a good faith security researcher, if you commit an act of extortion, or if you have deliberately harmed the system or exfiltrated PII, things like that, then you may not qualify. Militious attacks cannot qualify. So, for an example, as an example, an independent hacker finds a vulnerability in a smart product. They reach out to the product manufacturer to disclose the vulnerability. The manufacturer threatens a lawsuit against the hacker unless they sign an NDA about the vulnerability, and the hacker has an attorney, but can't really afford to resist the lawsuit. So the hacker can reach out to the Security Research Legal Defense Fund and ask for help. The defense fund will hear the background of the threats and the board will vote on whether or not to help the hacker push back on the threat of lawsuit. If the board votes yes, then it will help pay security and court fees for the hacker. So our vision is that the Security Research Legal Defense Fund will help deter unfounded or over-aggressive legal threats against hackers that are acting in good faith. We also expect that this will help cut into the chilling effect that security researchers face if they know that this resource is out there to potentially help them if they're acting in good faith. And then lastly, we view the defense fund as encouraging hackers to model good behavior because you will not qualify for the funds unless you are acting out in good faith and doing good faith security research. So a note on the status and how the community can help and then we'll see if we can take questions if we're allowed. So that the Security Research Legal Defense Fund has launched, it is operational. You can visit the website now at securityresearchlegaldefensefund.org or if that's too much, srldf.org. We have applied for 501c3 charitable status with the IRS. And of course the Legal Defense Fund is a fund and so the funding model for the defense fund is driven by community donations and so the community is in a position to help itself. Those donations are tax deductible and I believe Google has an announcement to make on the donations to the fund. Sure, yeah. So I actually have kind of two PSAs and one announcement. So first is a public service announcement for fellow corporate overlords in the audience, different companies consider finding a way to donate to the program. Second PSA is for researchers that if you are inclined to donate bug bounty winnings for any reason either for its own sake or because maybe by the terms of your employment contract you're not allowed to accept winnings consider donating to the funds. And I'm happy to announce that any researchers in our Google bug hunters program that opts to donate to the fund, Google will quadruple that donation. That's amazing. So beyond donations, the community can also help just by letting other people know that this resource is out there. We need awareness in order for this to best serve the community. So that's it, I hope that you enjoyed this panel and I hope that you find it inspiring that the security community has these champions like Kurt, like Hannah, like Marsha Hoffman and others who have been defending security researchers for so many years and hope that you find it inspiring that you have these assets like the Coders Rights Project or the Security Research Legal Defense Fund and key supporters like Google who are out there trying to ensure that good face security research helps the community. I think we should take pride in knowing the progress that the community has made that together we're strong and we will continue to secure the world. If we can take one or two questions before dissipating, is that not sure if that's, can I get a thumbs up or a thumbs down? I think I have a thumbs up. All right, two thumbs up. Let's take questions, I will say though, please don't discuss a personal legal situation in your question. Privilege does not extend to the DEF CON floor. We have a question. It appears we do not have a microphone for this fine gentleman. So you're going to have to scream. First of all, you sound like you have a really cool job. Second, whether we take it in Bitcoin, I don't see why not, but that's going to have to be something that will be discussed at the board level. I think right now the, I don't think that we have the mechanism for that, but I think that cryptocurrency, I mean, EFF also takes donations in- We do take cryptocurrency donations. So yes, I think eventually, now whether we want to take it from a shadowy quasi-person who has been collaborating with people who are possibly under sanction, that's a different matter. But thank you. All right, I think we need to go to make room for the next panel. Thank you all so much. We really appreciate you being here. Thanks everybody. Let's take a group picture. All right.


The wildcard round of the playoffs didn't fail to entertain. The Titans made an 18-point comeback and the Jaguars won their first playoff game since the 2007 season. Eight teams remained and here are our picks for each game of the divisional round of the playoffs. The Atlanta Falcons vs the Philadelphia Eagles. The last time the Eagles on the Falcons faced in the playoffs, the Eagles won 27-10 and advanced to Super Bowl 39. Now, it seems as though the Falcons have become the favorites in this week's game. What many people overlook is that the Falcons boast a top 10 defense, which means trouble for a questionable Philly offense. We're picking the Falcons to win this one on the road, 23-10. The Tennessee Titans vs the New England Patriots. Call it luck, call it a fluke, but you can't deny that the Titans came to play this past Saturday. Even being ridiculed as the worst team in the playoffs this year, Tennessee carries a chip on their shoulder going into Foxboro. The Patriots have been to the AFC Championship every year since the 2011 season, and to advance to the AFC Championship that year in 2011, the Patriots defeated the Tim Tebow led Denver Broncos who, just like the Titans, will label the worst team in the playoffs. Deja Vu perhaps? Give me the Patriots to win, 31-17. The Jacksonville Jaguars vs the Pittsburgh Steelers. When the Jaguars and Steelers faced in week 5 earlier this season, Ben Rothesberger threw 5 interceptions and a 30-9 loss against the AFC South Champs. It would be shocking to see that kind of performance again from Big Ben, though I wouldn't expect him to breeze through Saxonville's defense. Many expect a more offensive output from Pittsburgh, but the Jaguars' defense will still do enough damage to allow Blake Bortles to keep up. Expect a Jaguar's upset, 24-20. The New Orleans Saints vs the Minnesota Vikings. Minnesota comes into this weekend as one of the most balanced teams in the NFC. With a chance to play a Super Bowl in their home stadium, their defense has a tough task against the best running back duo in this league. The Vikings defense is second in the league against both the run and the pass, so it seems that the big easy offense will be limited. Defense will rule this game as the Vikings win, 20-16. Do you agree with our picks? Let us know by leaving a comment down below. Also subscribe to this channel for more NFL and college football content, and make sure to follow us on all social media sites.


Hello, Alexis. You're on the stage now. Hello. Hello, everyone. Can you hear me clearly? Yeah. Can you hear me as well? Yeah. Great. You voice is clear. I'm going to add your presentation as well on the screen. Are you able to see that? Yeah. Great. Great. So, stage is yours, Alexis. Thank you very much. Well, hello, everyone. I'm really happy to be at Python India. So, in this talk, I will detail Cassandra and Silla, low-level architecture, and explain how it's used by Python Cassandra driver, and show you how we extended it to write a Python driver for Silla. There will be diagrams, emojis, Python code, and hopefully amazing performance graphs. Let's start with a bit about myself. As you may have guessed from my accent, I'm living in Paris, France, so that's where I'm broadcasting from, actually, at no moment. I'm CTO at Numberly, and I have different lives in the open-source world. I'm a Gen2 Linux developer, where I focus mainly on packaging cluster-related stuff, distributed databases such as MongoDB and obviously Silla.  Then, on the open-source side, I'm also a contributor. I've been contributing to MongoDB, Silla, obviously, as well, Apache Airflow, and I'm a PSF contributing member, which means that I spend a fair amount of my time creating or contributing to Python open-source projects. In this talk, I will suppose that you are familiar with the basics of consistent hashing and Cassandra. If that's not the case, or you simply want to know more or even use it in your Python applications, check out the talk that I gave on the subject in a previous EuroPython edition. But Fiornot has still worked on not making this a problem for this presentation, so everything should be all right. Let's get started now and let me introduce you to Cassandra and Silla token ring architectures. We'll see all they have in common, but also what Silla has done that makes it special and worth a dedicated Python driver. First of all, since I will be using their logos in diagrams, let me introduce them to you. The eye on the upper left is the logo of Cassandra and the little sea monster with also only one eye is Silla. When you see both of them on the same box, it means that the presented topic or logic applies to both of them. When you will see only one of them present in a box, it means that it's specific to either Cassandra or either Silla. A Cassandra or Silla cluster is a collection of nodes or instances visualized as a ring. All of the nodes should be homogeneous using a shared nothing approach. This means that there's nothing special about a node in this topology. A node has no special role or anything. They are all equal on the ring. This ring is called a token ring in which the positions of the nodes on the ring define token ranges or partitions. A partition is a subset of data that is stored on a node. This data is usually replicated across nodes thanks to a setting that is called replication factor. The replication factor defines how data is replicated on nodes. For example, a replication factor of two means a given token or token range will be stored on two nodes. This is how high availability is achieved and how Cassandra and Silla favor availability and partition tolerance in the cap theorem. They are labeled AP. This kind of token or ring architecture is sensible to data distribution among the nodes. We could get an unbalance of data and query load in the above scenario where we store data in three big partitions and each node holds one range from the previous one and one range from the next one. You see 1, 2 on node X, 2, 3 node Y, 3, 1 node Z. This could lead to something that we call hot nodes or hot partitions. We need to add more variance in partition to node allocation. This is done by introducing the concept of virtual nodes. Instead of placing physical nodes on the ring, we will place many virtual instances of them called virtual nodes. A virtual node represents a contiguous range of tokens owned by a single node, so it's a smaller slice of a partition. A physical node may be assigned multiple non-contiguous V nodes. This is it for Cassandra's data distribution, but Silla goes one step further. On each Silla node, tokens of a V node are further distributed among the CPU cores of the node that we are called shards. This means that the data stored on Silla, on the Silla cluster, is not only bound to a node, but can be traced down to one of its CPU cores. This is the feature that we will leverage on the Python Silla shadowware driver later on, and we'll get into more details about this. But now that we understand how data is stored and distributed on the cluster, let's see how it's queried by clients. On the physical layer, a partition is a unit of data stored on a node and is identified by a partition key. A partition key serves to identify the node in the cluster that stores a given partition, as well as to distribute data across nodes in the cluster. The partitioner, or partition hash function, using a partition key, determines where data is stored on a given node in the cluster. It does this by computing a token, which is a number for each partition key. So if we look at the diagram, we have column ID, which is set up as the partition key. We would take the value of it. We will apply the partition hash function, which by default is murmur hash3. And then we will get a token, which is a number that we will place on the ring. And from this position on the ring, we will know which nodes it belongs to. So let's recap. On Cassandra, the hash of the partition key gives you a token telling you which node has the data that you are looking for.  On Silla, the same hash of the partition key gives you a token, not only telling you which node has the data, but also which CPU's core is responsible for handling it. So we can call Silla architecture a sharp pair core architecture. Now, how does a client driver query a Cassandra or Silla cluster? Well, since the partition hash function is known, our client libraries can use it to predict data location on the cluster and optimize their query routing. But let's first explain what a naive client would do if not using the partition hash function. When a client connects to a Cassandra or Silla cluster, it opens a connection to every node of the cluster. Then when it wants to issue a query, naive clients would pick one of its connections randomly and issue the query to the node. This node is called the coordinator for the client's query. It takes the ephemeral responsibility of routing the query internally to the right replicas, gathering their responses and responding to the client. But if the coordinator is not a replica for the query data, it has to issue the queries to all replicas itself. This is suboptimal as it consumes network and processing power on the coordinator node for something that the client could have guessed in the first place. And this is what we call token aware clients. Token aware clients applies the partition logic to select the right connection to the right node and make sure that its coordinator node is also a replica of the query data. As a result, we save network hops and processing, allowing for a lower cluster internal load and reduce query latency. Let's see how Cassandra driver does it. In the Python Cassandra driver, token awareness is achieved thanks to the token aware policy. The Python Cassandra driver defaults to token aware and the data center aware round robin load balancing query routing policy. It's a bit long to say and it looks complicated and all, but it's not that much. But fear not, it works even if your cluster is not spread between multiple data centers. It will just pick a default one for you. But by doing so, query routing will not only hit the right node holding a copy of the data that you are seeking, but load balance queries evenly between all its replicas. So if we look at the diagram, you see that if we were to issue a query that would hit partition number one that lives in node X, the first one would go maybe to hit this one. Then if we were to issue the same query again, we see that partition one is also living on node Y. So the load balancing strategy would then hit node Y and then node X and then node Y, et cetera, et cetera. This is how load balancing is achieved. From the point of view of the Python Cassandra driver, the partition key is seen as a routing key, which is used to determine which nodes are replicas for the query. To allow our Python driver to know about the partition key of a query, the query itself must be prepared as a server-side statement. Cassandra's NCLAS-prepared statements can be seen like stored procedure in the SQL world. It is the recommended and most optimal way to query data because you declare your query once and then only pass a reference to it and the needed parameters. It is also the safest as it prevents query injections, so please only use prepare statements even more in production. So I've put on an example of how it's done. You see the session.prepare where we prepare our statement and then we just execute the query with the reference to the statement object and the partition key, which will act as a routing key. This is awesome and optimal. One config that we cannot do better than this. That's true on Cassandra cluster, but not with a SILA one. Why? Well, if you remember, because SILA shards the data one way further down to a node CPU. So that means that we can extend a token-aware driver and token-aware client to become a shard-aware client, which is able to route its query not only to nodes, but to their right CPU cores. And you can note that it will be achieved with exactly the same code, which is pretty cool. So you just have to switch from Cassandra driver to SILA driver and obviously run a SILA cluster. And then you will have core CPU core query routing. So such driver already existed as forks of Datastax Cassandra drivers except for the Python one and it made me sad and angry at the time. So when I attended SILA submit last year in San Francisco, I did some lobbying and found some friends on the SILA dev team. We promised each other to make a Python shard-aware driver as a matter of fact, we did. So what are the expected structural differences between the Cassandra driver and its SILA driver fork? The main one, as you can see, is how we connect to the cluster and to the nodes. When in Cassandra, you have one connection per node because the node is the main and only point that you will be using to route your queries. You need to go further to the core in SILA. So that means that you will have to open one connection per core per node on the SILA shard-aware driver. Then the token calculation that selects the node is the same because this is the same logic, but then you go one step further again on SILA because you have a shard-aware calculation that you will be using to select the right connection to the right core based on your query. Now, let's see what needs to be done on the Python code side. Remember that we want to retain compatibility with the Cassandra cluster so that even the SILA driver can work seamlessly with the Cassandra cluster. And Israel Foster, who is a SILA developer from Israel, I know it's a bit confusing, made the first pull request for this Python shard-awareness. All the words that I highlighted in green represent a class in the Python code. So all those classes, we will have to check. And one of the first things I contributed myself was aimed to solve the connection to every core problem. So that's the second bullet point here. When you need to make sure somehow to connect or to get a connection to every core so that any query that is coming in, you will have a connection to use and straight to the right core. It's easier said than done, actually. Because when I first looked at the initial PR from Israel, I found out that it was technically not possible for a client to select the shard it wants to connect to at the connection time. And after thinking about it, it sounds pretty obvious because the Cassandra protocol does not root queries to core. So there was no point in the protocol itself and there was no manner in the main protocol itself to do this. And since the SILA protocol and Cassandra protocol are fully compatible, SILA did not provide this as well. Which means that all SILA shard-aware drivers are affected by this as well. So I wrote an RFC to the SILA mailing list to find a solution and great news. One has been found and is now implemented. And it will be part of SILA 4.3. It takes the form of a new shard allocation algorithm that will be made available on the new listening port on the SILA server. It will, on the server side, use a modular of the client's source socket port to assign the correct shard to the connection. That means that the clients will then have to calculate the right source socket port to get a connection to their desired shard ID. Until then, I worked on implementing an asynchronous and optimistic way of dealing with this problem because when you connect, you don't know for sure which shard ID you will get a connection to. So you have to implement some logic to not slow down the connecting and the popping up of your initialization of your Python driver but still make out most of the chance to get the right connection to the right core. So let's see this logic that is implemented. This is where the connection selection happens and where everything is glued together resulting to a shard-aware query routing. So the first thing that we do is we get a token and we need to calculate the shard ID from the query routing key token. So we got this and then we will get the shard ID. So we know which core, which is the shard or core ID on the node that is responsible for this slice of data. Then we will try to find a connection. If we happen to have a connection to the right shard ID and core, if we do, victory. We use our direct connection to the right core to route the query. This is the ideal scenario. If we don't, we will just issue asynchronously a new tentative, a new connection and maybe we will get lucky and this one will get us connected to this shard ID or any other missing shard ID. So this is the current version, an optimistic but non-deterministic way. The upcoming version when we will be able to use the source-based algorithm will be deterministic so we will be sure to always have a connection to every shard. So if we were not lucky this time, we will just pick a random one and just be as good as Cassandra Driver was. One important step also was to implement a way to know if we are connected to a Cassandra Orsila server. Detecting shard awareness is done by passing the message options set back by the server after we connected. In this example, you can see that the SILA shard information tells us which shard ID was assigned to the connection by the server and you get also some other interesting things from the SILA server side. Another important implementation was the famous token to shard ID calculation. So when the cluster class requests the connection from the pool, it passes the routing key. This routing key is then used by the shard ID calculation code to select the connection to the right core. But this calculation when it was implemented in pure Python was having a severe impact on the driver performance. So the first production results were not good at all. We were even slower than the Cassandra Driver so it was a bit disappointing at first. So Israel moved the shard ID computation to Cyton cutting down its latency impact by almost 7 and this made us faster than the Cassandra Driver. So now that we have seen the implementation details, does the SILA Driver live up to our expectations? And what do we expect when we push this SILA Driver in production? Well, from the one connection per core per node, there are two expectations from there. The first one is we expect to see an increase from the point of view of the cluster. We expect to see an increase of the number of open connections since instead of having one connection per node, we will have one connection per core per node. We expect to see it on the monitoring, right? And we effectively did as you can see on the first graph. The second one is since we have more connections open to handle, to keep alive, et cetera, we expected also to be more CPU hungry. So in our cases, we saw that indeed we had to adjust the resources of CPU to avoid CPU saturation on our Kubernetes cluster. So it's a small increase, but it's still an expected increase. So this one checked as well. But what about the major impact we wanted? Faster queries, lower latencies, right? Because these routine queries to the right core is what we expect we wanted to be faster. And this is what happened to our production workload queries max latency. We got immediately 15 to 25% performance boost. We were like, oh my God, this is amazing. And we are super happy. Please note that the graph that you're seeing is an actual production graph, and it's also the max processing time. So we like at numberly to look at our worst case scenario, right? So this one is the max. It's not the average or the minimum. It's the worst of what we do on this specific workload. So on the worst case, we win 15 to 25%, which means that we are 15 to 25% faster. What is interesting to note is that the performance boost is progressive since we connect to shards in the background in an optimistic fashion. When we just roll out the new driver, we sure don't have a connection to every core yet. We will happen to have it at some point, but since the first implementation is still an optimistic and nondeterministic way, it means that it will take some time. So the longer our application runs, the more chance to have a connection to all shards it has, the lower the latency gets. This is what you can see happening as well. And we expect this performance boost to be instantaneous when the new connection algorithm will be available. From another perspective, if we apply a moving median on another deployment, we see the major impact of the driver, which is pretty as well impressive, as you can see, and pretty stable as well, which was a very good thing to get. We also got an unexpected side effect of reduced latency plus lower cluster footprint. We could cut by half the pod replica requirements from a higher throughput application. So this one we didn't see coming, but since our workload was faster and easier on the cluster itself, it allowed us to actually save a lot of pod replicas on the Kubernetes cluster. So if you relate this to the small increase of CPU resources that it has been asking for, it's clearly a major win. We have done some enhancements as well. We have added some helpers to let you programmatically know if you are connected or not to a Cilla cluster. We have also added some shadowware statistics so that you can know if you have, I don't know, 50% only of connections to all the nodes and cores that are available or not. So that can be handy to have in your application logs. We are also working and we have an open PR for adding the new support of the new algorithm that will be available in 4.3. And we will merge and rebase the latest Cassandra driver improvements as well. So check it out. Contributions are very welcome. The driver is obviously available on PyPI. The documentation is there as well. If you see something missing or could be enhanced, feel free to tell us. And thanks for attending and making Python India a success. You can catch me online about everywhere with the handle Ultrabug. I've listed a quick link of my conference talks if any of them is of interest to you. And have a chat with us on the CillaDB user Slack. We have a Pythonistas channel where you can hang around and ask questions or give ideas, et cetera. Thank you very much for attending. Awesome, Alexis. Thanks a lot. We have a question from the audience. I'm just going to wait for that to pop up. So the question is, are shards on Cilla bring to the CPUs? Exactly. Shards are pin CPUs and pin cores of CPUs, actually. Yes. Great. Thanks. So Alexis will be with us on Zulip. So head to Zulip stream, daily stage. So I'll volunteer to share the link with you on the hopping chat as well. And thanks a lot, Alexis. Any closing words? Thank you very much to you. Thank you. Bye bye. Bye bye.


Hello friends welcome again to the session on quadratic equations now in the previous session we understood what is meant by quadratic equations right why the word quadratic is used we learned that in Latin the word quad is coming from the word quadratus which means means square and hence quadratic equations and we also understood that a general form of quadratic equation is ax square plus bx plus c equals zero this is what we learned right this is a quadratic equation and where a is not equal to zero and abc are real numbers are real numbers that is what we learned in this session we are going to understand what is meant by solutions of a quadratic equation what is meant by solution of a quadratic equation so solution is nothing but you can say they are also called roots of roots of quadratic equation okay what are roots of quadratic equation so those values values of variable those values of variable which when plugged in plugged in the equation right equation the equation is satisfied is satisfied that is what is called the solution of a quadratic equation what is meant by plugging in the values and the equation getting satisfied so let us take an example understand it so let us say we have a quadratic equation x square minus 3x plus 2 equals 0 right where here if you see a is equal to 1 clearly b is equal to minus 3 and c is 2 now let us try this value so what I'm saying is let us say putting x is equal to 1 in the equation so if you do that what will you get so x equals to 1 means 1 square minus 3 times 1 plus 2 which is actually equal to 0 that means we can say that x equals to 1 is a solution as a solution slash root whichever word you can use either of them sorry root to the equation given equation okay similarly let us say x is equal to 2 you put x equals to 2 in the same equation you will get 2 square minus 3 times 2 plus 2 which is again equal to 4 minus 6 plus 2 which is equal to 0 so this is also reduced to 0 so hence we say again x equals to 2 is a solution or root correct now let us take another value let us say x equals to 0 put x equals to 0 what will happen it will be 0 square minus 3 times 0 plus 2 which is clearly not equal to 0 so hence we say x equals to 0 is not a solution or root of x square minus 3x plus 2 equals 0 so if you see you try any other number but for x equals to 1 and 2 you will see that it is not getting reduced to 0 so all those values are definitely not roots to the or the solution of the given equation so please understand a quadratic equation quadratic equation can have can have at max at maximum how many roots only two roots it quadratic equation cannot have more than two roots yes it can have a quadratic equation so hence I can write a quadratic equation a quadratic equation can have can have either 0 roots that is no roots no roots or only one root or at max two roots it cannot have more than two roots at any cost right and why is this we can understand this by you know when you see when you when you see through this this particular problem from the angle of polynomials so hence what was a quadratic equation if you see a quadratic equation was nothing but px equals to 0 where px is a quadratic polynomial ax square plus bx plus c right and this was equated to 0 so what at what value of x this entire thing is reduced to 0 can be traced from the curve of x and px right so let us say if you plot x here and this is px here which is equal to y in you know you have studied this so hence if you draw the curve so it will be something like that right quadratic curves are like that so if you see there are two points here and here which is making or with which where the value of the value of px is 0 right so there are two values of x one is here one is here which is at which the value of px is getting reduced to 0 isn't it so hence these two values of x are called solution to the quadratic equation px equals to 0 now any quadratic curve you would have known that any quadratic curve can have three positions one like that so it is not intersecting the x axis at all or it just touches the x-axis or it touches the x-axis twice correct so this is the case where there is no solution no solution so it is not intersecting x-axis so there is no value of x if you see there is no value of x any anywhere in this line there is no value where px is reduced to 0 right there is no value of x where px is 0 why because if px was 0 then it would definitely touch the x-axis so in this case there is one 0 one root or one solution why because it just it is touching exactly at one point only one one value of x exists and this value of x is this which is you know making px 0 and here there are two values of x one here another one here where px is becoming 0 so there are two roots here two roots okay so hence and if you see a quadratic curve you know polynomial has only one change in direction that is so it either you know it has only one change in direction across the number line what does it mean so let us say if the quadratic curve is like that it is increasing it decreasing here and then it will hit its mean minimum value and then it will change the direction like that right so hence it changes direction only one once so hence there are there's a there's a possibility that it cuts the x-axis at max 2 at 2 locations right or it might not cut at all for example here it is not cutting at all right so what is this this is a graph of a graph of px where px is a quadratic polynomial so here it is not cutting at all in another case it could just touch once and in another case it could just cut it at two locations right so there only so at max it can cut at two locations and hence we say there are only two possible values or solutions for a quadratic equation correct so this is what is meant by solution to a quadratic equation let's take a few example and see whether what is meant by let's say solution to a quadratic equation so let us say we have an equation now we are dealing with examples let's say example 1 we have x square minus 7x plus let's say 6 equals to 0 okay so if you put x equals to 1 again so what will you see you'll see 1 minus 7 into 1 plus 6 is again 0 so x equals to 1 is clearly a solution right and what about x equals to 6 if I put x equals to 6 again you'll get 6 square minus 7 times 6 plus 6 which is again equal to 0 so hence the two roots are x equals to 1 and x equals to 6 how I am finding the roots is a different discussion altogether but what is meant by root you now understand let us take another example so let us say I'm saying x square minus 5x plus 4 is equal to 0 okay so if you see let us check x equals to 0 so what is x equals to 0 so if you put x equals to 0 it will become 0 minus 5 into 0 plus 4 which is not equal to 0 so hence x equals to 0 is not the solution solution of what solution of x square minus 5x plus 4 equals to 0 right that means you can you can you can think like this that if you have a polynomial px which is equal to x square minus 5x plus 4 this particular value will not be 0 at x equals to 0 okay so hence clearly the curve will not be 0 at x equals so this is x equals to 0 so hence at this point the curve will be somewhere here okay and and so hence it is something like that yes if you see x equals to 0 if I put x equals to 0 the value is not 0 px value is not 0 not 0 correct so but if we put x equals to 1 again if you see x equals to 1 what will happen it will become 1 square minus 5 times 1 plus 4 this is 0 fantastic so that means this is x equals to 1 at this point px if you see px px is coming out to be 0 at this point right and similarly if you check this point is x equals to 4 at x equals to 4 as well px is 0 right px is coming out to be 0 at x equals to 4 and x equals to 1 okay so this is what is meant by solution to a quadratic equation now in the next few sessions we'll learn what is meant by or sorry how to find out the solution of a given quadratic equation


Hello and welcome back to yet another GCSE revision lesson. Now with the English literature GCSE exams less than two weeks away, what I wanted to do was to give you a last minute revision for Christmas Carol. If you forget everything else, I wanted to show you the top three context points, the top five themes as well as the top 10 quotations. Remember, if you forget everything else on the day of the exam, you can use any of these context themes or quotations in any exam question and you'll be securing some really good marks as well as you can as long as you commit them to memory. Let's begin with context. What are the top three context points to remember if you forget everything else? The first most important context point is to do with the 1834 new poor law. Remember that this was a law that essentially punished poor people for being poor by telling them, look, if you are poor and you've lost a job, you don't have any kind of employment or income to avoid being put away in prison, okay? Because you can't just be homeless and just lounging about. You can get accommodation as long as you work for free in a workhouse. Dickens was incredibly critical of this law. And of course he eludes to this when Scrooge asks, are there no prisons? Are there no workhouses? And these words are echoed by the ghost of Christmas present. Dickens was intensely critical of this poor law because it basically punished poor people for being poor. The second context point to remember, of course, is more broadly when it comes to the Victorian era, there were very deep class divisions that Dickens wanted to highlight. A lot of rich upper class people, which were just a very tiny fragment of society at the time, were unaware that people like Bob Cratchit, the lifestyles were so difficult and they were unaware of children like ignorance and want. So he wanted to highlight the deep class divisions that existed in Victorian society. And the final really, really crucial context point is Dickens.  He was 12 when his father went to debtor's prison and for a few months he had to be put to work in a shoe blacking factory. So he speaks directly from experience. You can really empathize with poor children and the struggles and the suffering they face because he himself also had to work at a young age. Those are the three context points. If you forget everything else, make sure you use them in any Christmas Carol essay. Let's now look at themes. Now, in terms of the top five themes, remember, the first, of course, is charity. The main message within this story is the importance of charitable actions from rich people towards poor people. Okay, Scrooge becoming a patron for Tiny Tim. That's what Dickens envisioned for rich Victorian readers. The second theme is, of course, that of redemption. What Scrooge wanted to show to his very religious audience, remember that Victorian people were very religious and they believed in God in the afterlife. He wanted to show them that if they like Scrooge changed their ways, okay, they would alter what happened in the afterlife.  However, if they changed, then God would give them a second chance. They were capable of redemption much like Scrooge was redeemed. The third theme is to do with Christmas. Dickens, again, is trying to remind his religious audience of the sacrifice that God made for us as human beings by sending Jesus who was born on Christmas Day. The fourth theme is that of family. What Scrooge illustrates is he neglected his family and this is one of the things that contributed to his misery. However, people like Bell, people like Fred and even people like Jacob Cratchit or rather Bob Cratchit were incredibly happy because they placed family as the center of their lives. Remember that this story also is a very vivid reminder of the importance of family and this is something that Scrooge learned. The fifth and final quotation is that to do with class and social injustice. Of course, what Dickens was trying to illustrate is that rich business people, rich people like Scrooge contributed to the really extreme class divisions that existed in Victorian society because they were too greedy and that underpaid the workers. Obviously, the contributed to the social injustice that happened towards people like Bob Cratchit and Dickens wanted to change this. Those are the five theme points to remember when it comes to Christmas Carol. Now, let's go over the top 10 quotations to forget everything else. Make sure you commit these quotes to memory. The first quotations, of course, how Scrooge is described as a solitary as an oyster and this similarly illustrates how isolated and alienated he is from society because of his greed. The second quotation is to do with when Scrooge when the charity men come and ask for charity, he says, are there no prisons? Are there no workhouses? Now, this rhetorical question illustrates his support of the 1834 poor law, which Dickens was criticizing. The third quotation is when we can see the lives of poor people like the Cratchit family. We find that on Christmas Day, they had a small pudding ellipses for a large family. The oxymoron small and large illustrates the poverty but in spite of the poverty because they were together as a family that was still really happy and really jovial. In contrast to Scrooge who had so much, he had plenty, yet he was very miserable. The next quotation also relating to Tiny Tim is we can see that in spite of his disability, in spite of the challenges that he faces, he's still really, really thankful because he says, God bless us. And this is the time which the sentence shows his thankfulness. The next quotation is the fifth quotation is to do with Jacob Mali. He appears as a ghost to Scrooge and he tells Scrooge that he's going to face punishment. Okay, so he states, he wears the chain I forged in life. Now, of course, this metaphor is really powerful to show Dickens is rich readers that if they don't change their ways and if they're not more charitable, they too will end up like Jacob Mali in the afterlife. The sixth quotation is the really powerful description of the Ghost of Christmas past. It's described as looking like a child, but also like an old man.  Okay, so of course, it takes him back to his childhood. But of course, also the ghost looks like an old man representing Scrooge at the time he is showing him his past. The next quotation is the seventh quotation is of course to do with Belle, where she says another idol has displaced me now. Idol here is a metaphor for Scrooge's love of money which isolates him and also makes Belle his only love the love of his life break up with him. The eighth quotation is when the Ghost of Christmas present the Jolly Giant basically presents these two horrific looking children and says this boy ignorance and this girl is want. Okay, so this boys ignorance and this girls want and these two children represent the consequences of the actions of people like Scrooge. Okay, so of course, them underpaying the workers means that the workers can't look after the children and the children are that they produce are like ignorance and want that can't go to school like ignorance and they were even tattered ragged clothing like the girl want. The ninth quotation is how the Ghost of Christmas yet to come is described it this ghost for shadows Scrooge discovering how he dies. Okay, and this is shown through the description of its clothing it more a deep black garment and the final quotation which illustrates that Scrooge is capable of redemption he's been given a second chance and we can see that he changes so he represents the ideal that Dickens wants his rich readers to reach is when he says or rather when he says I was going to give another quotation where he wants to live in the past present and future. However, I'm going to change that because the final quotation here is actually to do with Fred. Okay, so guys, the other quotation probably be an 11th quote but the final final quotation which I do want to end off with is what Fred says to his uncle Merry Christmas uncle and of course here what the reason why she chose this quotation even more so than live in the past present and future is because obviously Fred illustrates the importance of family and also how much he keeps on forgiving and giving his uncle second chances. Okay, that's really it when it comes to the top 10 quotations. Of course, if you wanted to add an 11th quotation, you could also use the final quote when Scrooge says I will live in the past present and future. However, if you literally just want to have a quote for each character all the main characters in the story, they are completely covered within these top quotations. So I hope that helped and thank you so much for listening.