Criminal Liabilities for Disclosure of IT Security Vulnerabilities

[00:00] Hello everyone. My name is Peter Robinson. This is the Ethereum Engineering Group Meetup. Today, I've got Adrian here, who is going to tell us essentially the cost of helping someone from a criminal liability perspective. Next week it's going to be civil; this week it's criminal. So, Adrian, before you dive into your slides, can you please introduce yourself? [00:28] Yeah, sure, Peter. Um, uh, I'm a lawyer and have been for 32 years now. Uh, I have a computer science degree. But my PhD was actually in cryptography, um, digital signatures and hash algorithms. And I've been an IT security lawyer for at least 30 years, one of the early people involved in this area. I'm a member of the American Bar Association's IT Security Committee and also the AI the American Bar Association's AI Trust Committee. And I'm on the Law Council of Australia's E-Commerce Committee. I'm on too many damn committees, and I'm also a member of the International Standards Organization, Technical Committee 307 looking at smart contracts and CBDCs and stablecoins. [01:25] Okay, you are a busy, busy person there, Adrian. With a long career in IT law. Um so that's awesome. So you are very well-placed for this talk. So please, um yeah, lead away. And I know that Daniel here, he's an information technology come blockchain lawyer. So it's going to be he's going to be listening hard and ready to hammer you with really tricky questions, I'm sure. [01:53] Fine. Very much not a criminal lawyer, in mind. Oh, I know, Daniel. We were on the uh The Law Council committee together. The Law Council committee. Hi, Daniel. Yeah. G'day. Uh good. Um hello. Look, as being a lawyer, I always have a disclaimer. Um this is not legal advice. It's not professional services advice. Um if you have an issue, then go and have a chat to a person who has the expertise that you're looking for in this area. [02:27] Um it is a fast-moving area, even in this uh uh perspective of um responsible disclosure of IT vulnerabilities. Um I take no responsibility for any errors. This is a as Daniel will say, he's trying to do a um uh Hedley Byrne & Heller disclaimer. Um and uh that's about Let's Let's just proceed. [02:54] Okay, um I'm going to This is generally the agenda. I'm going to talk about the genesis of voluntary disclosure policy, um the genesis of criminal liability, industry standards like um the NIST SP 800-216, Google's Project Zero, Red Hat's 45-day disclosure policy. Now, there is a paper that I've given um uh Peter, and he can distribute that to anyone who that's interested. Uh there are other industry standards. Um Trend Micro, for instance, has a standard on dealing with voluntary disclosure. Then you look at what are the factors influencing disclosure timelines, um liability upon disclosure processes, uh the Australian Cyber Security Centre's voluntary disclosure program, which is really centered on federal government, um looking at criminal liability, and also looking at foreign jurisdiction liability. [03:55] Now, the Don't discount the foreign jurisdiction liability too easily, because when you do discover, if you are a security researcher and you discover a vulnerability, the most likely method that you are going to utilize to publicize that is through the internet. And as um there's there's an early case called Griffiths against the United States. It's a Australian Federal Court um Court of Appeal case, I think it's 2005, and it talks about um It was the very first case where someone committed a crime in the US, but they did it from Australia. And it was the very first case where there was an extradition and the Court of Appeal. And he Griffiths did try to appeal to the High Court, but the High Court um declined to accept that appeal. So the Court of Appeal is the leading judgment at this point in time. Um you and then what are the extradition issues that a researcher should be aware of. [05:08] Okay. So, it's a Responsible disclosure of IT security issues has evolved substantially over the last three decades. Um in the early days, there was this huge debate. I found a vulnerability. I must go and tell everyone so that they can um take appropriate action in uh warding off or or uh hardening the security around what they've got. Then there were responsible disclosures working privately with vendors before public disclosure. This tension reflected competing values. Obviously, um the security community at initially wanted to rapidly dispense uh disseminate defensive information. And it also gave a bit of a kudos to various IT security researchers um so that they could show, "Oh, aren't we clever? This is what we've discovered." And then you have vendors' interest in having adequate time to develop and deploy patches, um noting that commercial systems are complex. [06:20] I remember look, my computer science degree, and I graduated in 1980, so that's 46 years ago, okay? And I can remember the only absolute program that I could guarantee had no security issues was in Algol: PRINT 'A', and lo and behold, it printed 'A'. And that was it. No complexity involved. But the moment you start putting logic involve these things, and humans aren't real good at managing logic, believe it or not. You can ask um, oh no, he's dead now, I was going to say uh the guy with the teacup around the the the around the world. Uh Lord He was a Cambridge logician. Never mind. That's just um being digress. [07:11] Okay. Um now uh it's now coalesced around what's called coordinated vulnerability disclosure, which attempts to balance these interests through structured processes. Under um coordinated uh voluntary disclosure, security researchers report vulnerabilities privately to affected vendors, provide reasonable time for remediation, and then assist in the coordination of deployed solutions. Now, the importance of effective vulnerability disclosure frameworks really can't be overstated. [07:54] Um there are there's a report that came out I think in November last year by IBM that monitored when a vulnerability is publicized and how long it takes the Russians, Chinese, or whoever they are um to try to exploit that vulnerability, and it's less than 24 hours. So that's they're monitoring these things. Um and in there's a report from NIST that identified that just in 2021, which is 5 years old, I know, I I tried to find some updated versions of the report, but um I didn't have time. There was 20,000 new vulnerabilities reported in the National Vulnerability Database, which is operated by NIST. [08:42] So then comes the vexing question: when premature disclosure So you've got a security researcher, does premature disclosure of some vulnerability that leads to criminal exploitation of the disclosed Can a security researcher be held criminally liable as an accessory or for aiding and abetting criminal conduct, even though the security researcher did not directly participate in the criminal hacking? So you've got a vulnerability discovered, prematurely discloses that, and someone takes advantage of it. [09:24] Now, I was at an IT security meetup about 8 weeks ago, and one of the speakers um did an example of where this actually occurred. Uh there was an organization He tells me that this is actually did happen. Organization discovered a vulnerability in a particular um application. Uh they disclosed it to the vendor. The vendor then created a patch, deployed the patch. The problem with the security researcher is that he publicized the vulnerability 17 hours after the deployment of the patch. And certain people took advantage of that um because there was there wasn't a sufficient time for the end users to actually take advantage of the patch and implement it. So there's there's a problem there. [10:25] So the rise of industry standards and their compliance to assist researchers from are there to assist researchers from criminal liability. Further, compliance can enhance the trust that the market holds in respect to that research or the organization they're related to. So what we've got here These are the parties that are involved: We have a security researcher, the party who identifies the security vulnerability in some software application, which we'll call X; the vendor, the party who is the manufacturer developer of the application X; you have an end user, a party who is licensed to utilize, legally licensed to utilize the software application; and then you have a hacker, a third party who exploits the vulnerability in software, which causes the end user to suffer some damage. [11:17] Now, as I said earlier, it's highly unlikely that a security researcher will ever know the identity of the hacker. Very unlikely. Um so can a prosecutor, based on a set of facts, successfully bring an bring against a security researcher an action against that for disclosing the security vulnerability? The last slide um gives you the answer to that, okay? So you need to stay on. [11:43] Um now, NIST, the National Institute of Standards and Technology, US agency, has issued Special Publication 800-216. Now when you're doing pen testing, um you might want to uh include certain provisions in the agreement that addresses this type of um uh provisioning. Recommendations for fed Now, this is a federal US government document, and it's recommendations for federal vulnerability disclosure guidelines. It is only guidelines, but it does have the force of law when it comes to US government. And there are some very interesting provisions in this um 800-216 document. It establishes a framework for vulnerability disclosure within the US government, federal government, and has become highly influential in shaping industry practices more broadly. A lot of organizations actually follow this guideline. And when you read the Google um Project Zero, you will see that there is overlap in the terminology used with 800-216. [13:14] So what does the framework envisage? Well, this is it directs it at organizations like agencies. Um the military has its own, so with the the used to be called Department of Defense, it's now the Department of War, um has its own very special, but you look at Treasury, um the SEC, they are organizations, and they have to develop capabilities to receive vulnerability reports, determine the scope of what they're going to do, and establish contact systems. [13:46] Now, you should have under this um guidance note, uh it says whatever you do, have a single connection repository position. Don't have multiple, because then, as um NIST identifies, the left hand won't know what the right hand's doing. If you have a single funnel coming in to monitor all of these um vulnerability reports, then internally of the agency, they can then disseminate who's going to deal with it. So source for vulnerability reports are received through established channels with secure communication mechanisms. The reports are prioritized based on ease of exploitation, what is the exposure to the agency, and technical severity using a scoring methodologies. [14:40] And this I don't know too much about this scoring methodology. Um I haven't looked into it greatly, but it's called the Common Vulnerability Scoring System. I do know one thing is that it looks at um uh aspects of how prevalent is the vulnerability. And as is it other agencies that that utilize this application, and so do we need to use a concerted effort? How severe is that vulnerability? What would be the impact of it? And this is where um you might want to look at such things as And this was developed at the University of Queensland, of all places, the Bowtie Risk Management System. Bowtie Risk Management System was a um system developed by a PhD student in 1970 at the University of Queensland. [15:35] And what it does, it says identify a hazard. So what could be a hazard? Um um a ransomware um implementation inside. Then on the right-hand side, you write what are all the causations that could um actually activate that hazard? Then in between all the causations and the actual hazard, you write in: How do you treat them? How do you reduce the risk associated with that hazard? Then on the right-hand side of the hazard, you write what are all the impacts that if this hazard did occur So the first the left-hand side is looking at how do I reduce the risk, the threat, right? On the right-hand side, you look at what are the impacts. And in between all of the various impacts, you then put in mitigation strategies. Like, for instance, do you have an offline backup system so that if there is a ransomware or there is an encoding or there's some sort of failure, that you can as quickly as possible resurrect the environment? So what's the resilience of the environment? [16:55] Identification: the potential vulnerable systems and softwares must be identified. Remediation: this is where you start looking at the mitigation strategies. Um on the with the bowtie, I never use the word mitigate on the left-hand side. You treat risk; you mitigate impact. And thereby you get a better understanding of when you're treating the causation, you're trying to reduce the risk. When you're mitigating, you're trying to um reduce the impact. You know that the um hazard has occurred, and you're reducing the impact. [17:36] And then determinations are made about whether to publish the advisories. There are NIST um identified that there may be certain um vulnerabilities that they won't publish openly uh what the vulnerability is. They'll keep it internally. And that could be for national security, or it could be for critical infrastructure protection mechanism. The interesting thing that NIST standard doesn't specifically impose a timeframe concerning security disclosures obligations, and which is different um from what you'll find with the Google um Project Zero. [18:14] It emphasizes that organizations should provide safe harbor to security researchers who report vulnerabilities in good faith. And this is really important because if you follow the guidelines in the NIST 800-216, the recommendation from the affected agency or the US government is that they won't prosecute. But you have to make sure you follow the guidelines letter for letter. So the document actually says, "If you make a good faith effort to comply with this policy during your security research, Treasury will consider your research as being authorized, work with you with your with you to understand and resolve the issue quickly." Now, this is known as the safe harbor mechanism that substantially protects security researchers from criminal prosecution in the US. Only in the US, okay? You can't rely upon the uh 800-216 if it's in the UK or even in Australia. [19:35] Safe harbor language is now common in federal agency vulnerabilities. Um if you go to if you did a Google on um say SEC and vulnerability disclosure policy, it'll come up with that language available to you. Google's Project Zero is really it started in around about I If I remember correctly, 2013 um was the start of the Project Zero. It's been highly influential. And it takes a very common um uh uh realistic disclosure for deadlines. It says that if a security researcher identifies a vulnerability and notifies the vendor, the vendor has, under the policy, 90 days to rectify, to find a patch, to correct it. And under the policy, it's for the vendor to communicate with the researcher continuously. [20:47] Now, if they the moment they find a or have developed the uh the patch to the vulnerability, um then the researcher will wait 30 days after that to give a timeframe for end users to have sufficient time to implement the correction. Now, if within that 90 days, the vendor notifies the researcher that they're not going to meet the 90-day um timeframe, uh under the Project Zero, the researcher can grant another 14 days um to the vendor to so that there's a continuous a ability to get this um resolved. Now, organizations like the Red Hat, for instance, um prefers a 45-day uh embargo um regarding the security guidelines and timeframes. [21:50] So what could be the issue? Why can't I see? Wait a minute. I have to go back a bit. Okay. Um simple What What can affect the timelines in respect of the vendor? Uh simple vulnerabilities can be addressed with straightforward code changes. But if there's an architectural change um and it's widely deployed, and also the market that it is deployed, like for instance, if it was deployed in critical infrastructure um environment, uh gas pipelines or electricity providers, uh then they have to do extensive testing. [22:39] And one of the things in the um Project Zero is that uh you have to do extensive testing. It's a waste of time if solving a vulnerability for X introduces a vulnerability to Y, okay, because of the solution or the patch that's created. Um if the vendor uh immediately acknowledges receipt of the vulnerability reported to them, and assigns resources with regular status updates, uh it's according to Google, researchers are more likely to accommodate extension requests. Conversely, if the vendor is unresponsive and there might be shortened terms, uh the researcher may become um impatient. [23:25] So SP 800-216 and many policies provide for accelerated disclosure. Um Google Project Zero, for instance, provides only 7 days for actively exploited zero-days. So if you have remember um the Heartbleed uh issue that arose 2014, or was it earlier? Peter, 2014? Yeah, I'm pretty sure that's earlier, more like 2012, 2010. Oh, right. But, yeah. In that situation, uh there needed to be an all-out effort, and uh you really should only look at 7 days to to actively exploit that, to to overcome that. [24:16] Um so, severity and impact: critical vulnerabilities affecting large user populations or sensitive systems may warrant different treatment than low severity. Um and availability of mitigation: if effective workarounds um can mitigate the exploitation risk before patches are available, um this may support extending uh disclosure timelines. [24:41] Now we're getting on to Australia's criminal framework. Um Vulnerability disclosure is coordinated primarily through the ASD, Australian Signals Directorate, and the Australian Cyber Security Centre. Um both of those or ASD has been around a very long time, um uh it used to be called Had a prior name than ASD. DSD. DSD, that's right. Defense Signals Directorate. Yeah, Defense Signals Essentially part of the military before then. Exactly, exactly. Yes. Um that they were um moved into more like a holistic um structure established in 2014. The Australian Cyber Security Centre serves as Australia's lead agency for cyber security and integrates capabilities across multiple government departments. [25:33] Um the relevant statutes I I'm not going to list all of the um the states, like I haven't listed section 408 of the um uh Criminal Code, Queensland Criminal Code, uh which deals with um uh cybercrime. Um we have the uh Criminal Code Act, particularly um computer offences, which was enacted in 2001 under the Cyber Security um Act. Uh we have the Crimes Act and the Telecommunications (Interception and Access) Act are the principal, major uh provisions that you have. [26:13] Now, the ACSC has developed the vulnerability disclosure programs. And these provide guidance for organizations of all sizes and scope to develop and implement um VDPs. The Australian Cyber Security Centre operates a coordinated vulnerability disclosure allowing security researchers um Oh, I might add that, uh Peter, can you just um distribute that paper that I've done so that um cuz you'll have the who that Or they can contact me directly. No, I what I'll do is I'll provide a link to the paper in the description of the YouTube video. That's the easiest way. Then people can just um get a copy of the slides and get a copy of the paper. Yeah, the paper is about 32 pages, if I remember correctly. Um [27:12] Uh the According to the uh ACSC uh website, it says, "The disclosure will give vendors and developers more time to mitigate the vulnerabilities and enable affected systems of national interest to reduce exposure." Now, one of the clear issues in Australia is that there is no safe harbor mechanism, not like the United States with um the NIST SP 800 uh-216. So, unlike Australia sorry, unlike the United States, Australia doesn't have a comprehensive statutory safe harbor for security researchers. Um and this really comes down when would something occur that could expose a researcher to some sort of liability? [28:05] Um If you go to like the ACCC's policy site, it says, "To encourage responsible reporting, we will not take action against security researchers in relation to the discovery and reporting of a potential security vulnerability." Unfortunately, these are policy commitments by individual agencies. The other thing is that various agencies use different language. And that's a problem. There's no consistency in language across all of the agencies. I looked at um I think about six, maybe seven uh agencies, and they all use slightly different language. [28:48] Um security researchers must rely on the expectation that prosecutors will exercise discretion not to prosecute good faith security research. If there is a prosecution, then the principal liability would most likely involve a claim by a prosecutor that the security research, in disclosing the security vulnerability, was aiding, abetting, counseling, or procuring the commission of an offense by another person. Now, then we've got to look at what do we mean by aiding, abetting, counseling? Well, I think we can easily um discount counseling, because most security researchers will have no idea who the hacker is, especially as, you know, a lot of them will be um external to Australia. [29:39] We have to look at um the Criminal Code, um section 11.2 provides for It's actually a a a definition of complicity and common purpose. A crucial element is that must have the requisite intention. This is the hard point for a prosecutor. They would have to show that there was the necessary intention that the disclosure would aid a third party to take advantage of the vulnerability. They've got to establish Oh, and the other thing is there is actually a a court case dealing with reckless disregard, and the High Court said reckless disregard is not sufficient to sheet home um the requisite intention. So you have to have much more than just reckless disregard or negligence in doing this. [30:36] The prosecution must establish that the accomplice, namely the researcher, meant to aid, abet, counsel the principal, or the procurement, the commission of the offense. Excuse me. Um this issue is fatal to the prosecution's case. It's very difficult for a prosecution to for a prosecutor to establish the relevant intent to assist a third party, especially as the researcher won't even know who that third party is. So, consequently, the it, you know, there will not necessarily be sufficient evidence to support um the requisite intent. [31:18] For a security researcher to be held liable as a necessary as an accessory to hacking offenses committed by that, they would have to disclose the The prosecutor have to basically need to prove that the security researcher intentionally aided, abetted, counseled, procured the principal offense uh offense, um and they had knowledge that the principal offense was going to be committed. They can guess these things, obviously, but they won't have direct knowledge, most likely. Uh where am I up to? Ah. How am I going for time, Peter? Uh very well. It's 8 past 1, you know, I think if you aim to be finished at 1:30, so that's 22 minutes. So, I think you're doing pretty well. [32:09] Um now, it's highly unlikely that any attack involving a disclosure Sorry, it's highly likely that it'll be a remote attack, okay? Um consequently, a security researcher should take into account the possibility of foreign jurisdiction prosecution. Now, the USA, as I've said, is the safest jurisdiction that there exists simply because of the safe harbor mechanism to protect um security researchers. And this is very important. Um but there's also a very strong extradition treaty between Australia and the US. [32:54] Now the problem that we've got is that um the internet transcends geographical borders, um and so therefore, the illicit conduct will most likely be committed remotely. Now Australia currently has entered into 40 extradition treaties with foreign jurisdictions: UK, US. Um the list of jurisdictions are actually noted in the regulations. And you I think you have to look at regulation 3, if I remember correctly. The US and the UK are included in the list. [33:29] Now, there's a 2005 full court of Australia, Federal Court, in Griffiths against the United States of America, where the Full Court upheld an extradition of an Australian man, Hugh Raymond Griffiths, to the US to face criminal copyright and conspiracy charges. The decision was a major precedent in transnational digital crime enforcement. And it one of the interesting things about it is that it literally was the first case that I could identify The Federal Court certainly identified it for Australia, but it was the first case that I could identify I had a look in the US and the UK, and I couldn't find any um cases prior to 2005 um that dealt with a crime being committed in one jurisdiction when the um perpetrator was residing in another jurisdiction during the entire time that the crime was actually being committed. [34:41] Um now these are serious issues before the court, but it cannot be taken out of the question that an extradition application could raise security uh should be raised against a security researcher. So this is the opening two paragraphs of the Griffiths case by the Full Court: "If there if there is apparent novelty in this appeal, it lies in the nature of the extradition offenses the appellant is alleged to have committed. And for this, his surrender is sought by the United States of America when at all relevant times, he was residing in Australia. Hugh Griffiths is claimed to have conspired to engage in, and to have in fact engaged in, internet software piracy in the United States in violation of federal criminal copyright laws of that country." [35:39] This is a very interesting um And the other thing to note is that if you publish there there's there's um a High Court decision in Australia called Gutnick and Dow Jones. And that that case is very important, because even though it's a defamation case, Dow Jones challenged the jurisdiction of the Australian courts to hear the defamation case in Australia. And they argued that because all of the servers were located in New Jersey, that that was where the jurisdiction for the case should have been held. The High Court said, "No. If the defamatory material is accessible in Australia, then you have a publication in Australia. And if you have a publication in Australia, then Australia has jurisdiction to hear that case." [36:40] So now let's think about that with a researcher who publishes some security vulnerability too early, okay, or does something that allows or arms third parties to take advantage of that action. It's where the publication is received that would have capability of jurisdiction. Now, that the Gutnick and Dow Jones case has been cited with approval in foreign jurisdictions. Um the UK Supreme Court, for instance, has cited it with approval. So has various courts um uh district courts, federal district courts in the United States. [37:29] So now in Australia, an extradition application is to be taken serious. The process to be followed are detailed in the Extradition Act and the corresponding regulations. So the application: When would an when when could we see um a problem for a security researcher where a prosecutor may actually get up? Well, if the security researcher not only discloses the vulnerability, but also discloses how to exploit the vulnerability. I don't think too many researchers would do it, um but if they start explaining how to exploit that vulnerability, then they are exposing themselves to um a possible extradition application. [38:25] The security researcher, in publicizing the vulnerability, has also published some code or even pseudo code that could take advantage of the vulnerability. So, my advice to researchers: don't do it. Okay, very simple. Don't overstep the mark when it comes to um just disclosing a vulnerability. The researcher would need to do more than disclose the existence of the vulnerability to be held accountable for a um uh an extradition application. Um if you're interested, have a look at the Griffiths case. You can see the um our Full Court. It's a very interesting judgment on how the court goes about There's a four four-part test that needs to be satisfied. Um and so if you make sure that you don't fall within those um uh ambits of that test, then you should be okay. [39:24] Researchers should be aware of industry standards when disclosing IT vulnerabilities. You might want to look at the NIST 800 um SP 800-2 216. Google's Project Zero is establishing itself as a prominent industry standard. Look at the 90-day period. Look at the 30-day period for deployment. Look at creating a communication channel between the vendor and the research uh researcher. Make sure there's open communications. If the vulnerability could impact Australian government agency, then it is highly recommended that the security researcher also follow the ACSC guidelines. [40:12] Um it's recommended that the researcher should identify whether the disclosure would impact foreign entities, and as such, try to understand how best to publish the vulnerability. That's my presentation. Um next week, I will be talking about civil liability. And civil liability is um a different um kettle of fish, because you now look at um uh what's called proximity and causation actions at civil within the torts of negligence and some other torts that I um uh refer to in that uh presentation. Thank you very much. [40:57] Uh well, we should be thanking you. That was a thank you for a great talk. Are there any questions that people have? Come on, Daniel. You're on mute. Well Well Whilst people are having a think about what their questions are, I've got I've got one that I'd like to pose. [41:20] So, um recently there was a the Tornado Cash thing. Yep, Roman Storm. The Roman Storm. Yeah, and so and you know like so you have developers who develop some software, and they're sort of encouraging people to use it, and knowing that say North Korea is using it to launder billions of dollars. So, let let's flip it around slightly. You've got um a application that can be used for, you know, normal things, and then um I already know the answer to this. And and then and then you've got say a security researcher, or someone says, "Hey, we could use that for You know, people could use that for money laundering," and, you know, like quite loudly promotes the fact that, "Hey, you could use this thing for money laundering." Yeah. And then suddenly North Korea and everyone else is using it for money laundering. [42:22] And you're in Australia. So, it's a bit of international software, not written in Australia, and and Tornado Cash is an example it was written in the Netherlands. But imagine the person who is kind of the security researcher-come-marketer for this new capability of the software, which is money laundering. Does that how I mean it's feels nearish How how do you view that, and how how do you think that would go in Australia? [42:53] Well, I mean, as I have explained to clients, um if you have You can think of dual-purpose. There's the good purpose, and there's the bad purpose. Okay? Um if you look at the motor car, for instance, the motor car can be used for legal transportation of people from point A to point B, but it can also be used as a getaway car. It can also be used by terrorists or um to mow down people in um various uh uh jurisdictions, as has happened. Does that mean that you should be prosecuting the directors of the manufacturer of the car? No. Okay. [43:44] Now, it's interesting with the Tornado Cash, because, yes, Roman Storm um uh was prosecuted, and I believe is still in a US prison. But the Department of Justice, earlier this year, I think it was in January this year, basically published a report saying that the utilization and development of um what are called tumblers um is not illegal, and they shouldn't be prosecuted because you've developed a piece of software that has a legitimate use, but can also be used for nefarious activity. Now, I believe in that, right, that if um you have a piece of software that can do, what you say, dual-use, very legitimate privacy, that cuz that was originally the whole point of it. It wasn't designed for um uh necessarily criminal activity. It was designed to obfuscate the follow the the the ownership of a piece of uh crypto asset, mix it around in the tumbler, come out as something else in favor of the original owner. And that was for privacy reasons. [45:10] But, you know, you could say with um uh uh Zcash, or um uh there's another one uh starts with M, I've forgotten what it's called, where there's privacy built in crypto, where it's not like Bitcoin, which is a pseudo uh privacy-enabled um uh system. Uh you can do tracing and everything, whereas when you start looking at uh uh Zcash, uh um it it does create a a much more difficult uh positioning. So, no, I don't I don't believe that you should be um uh going against uh programmers simply because they have developed a piece of software that can be used legitimately, but also used by um criminals. [46:08] You're on mute. Yeah, I am on mute. All right, that that makes sense. That makes sense. Uh, Daniel. Um, look, as I said at the start, very much not a criminal lawyer, so enjoying hearing about this from a different angle. I'm thought I might check in um To the extent that a software vendor has a bug bounty, some sort of program for reporting vulnerabilities, does that give any sort of comfort to the security researcher that to say that they're, you know, what they've done is not unauthorized or not, you know, unsolicited sort of because there's some invitation for you to poke and prod and find these things? [46:48] Um absolutely, totally. But you would need to look at the rules. Um when you If you look at the Microsoft bug bounty, they have a set of rules that you must comply with um if you want to click. Google's bug bounty also has a set of rules. So, you need to, if you're going to go down that track, um yes, it does provide evidence that the vendor But also note one thing: we're talking about criminal liability. It doesn't matter what the victim thinks; it's what the law is. [47:25] So, but you can create a situation whereby through the bug bounty, you can use that as a mitigating circumstance to say, "Wait a minute. Um this vendor actually has and pays for uh third parties to identify the vulnerabilities, right, and provided I'm following the um uh let's say the Google Project Zero procedures, I won't be held accountable." But, yeah, um it's very If there is a bug bounty situation uh in play, then yes, that can be used as evidence. And the other thing is it uses the evidence to support that the researcher did not have an intent in the first place. They're trying to do it to earn brownie points and cash for finding the vulnerability and disclosing it to the vendor. [48:26] Mhm. Yeah, I think I wasn't you that's a good point. I wasn't thinking about the intention element of the offense. I was probably thinking more about the elements of some of the offenses that talk about whether your access to data or systems or something is unauthorized, or those sorts of things. Well, the other thing is is that you'll find that majority of these won't be um remote testing. A lot of these things they download an app, and then they start testing. Um but if there is a bug bound Some of these bug bounties um uh operations, they create a sandbox for it to be tested. And that's that's another um advantage, if they create a uh a sandbox environment so that you can test and uh and then identify the vulnerability and disclose it to the relevant um uh vendor. [49:21] The The one other thing actually I was thinking So in in slide 26, um you were saying that you know, you shouldn't you can say to everyone, "Hey, there's a bug," but you shouldn't say how to exploit the bug. And yet Well, well if you start going into exploitation, you're then undermining your intention. Well, yeah. Well, it it's a really interesting one, because typically with vulnerability disclosure, you need to explain how to exploit the bug, cuz otherwise people go, "Ah, there's no real bug there. You've You've got it wrong." And so it's only when you get to the point of explaining in great detail, which is at the point then that you pretty much say, "Here's some example code um on how to do it." [50:12] Oh yeah, but but the problem with that um your your argument is that the first thing you've got to do is you can explain and provide code to the vendor. Yeah, okay. No problems with that. The issue then comes about if you go to the wider public, which is then monitored by these hackers, and they then utilize the exploitation. Yeah. You can certainly You can certainly disclose code in You can even disclose your testing code. You can disclose how you've identified that vulnerability. But you should only disclose that type of information to the vendor, not to the wider public. Yeah, okay. Mhm. All right. Makes sense. [51:01] All right. Are there any more questions? Okay. Okay, then. I think with that then, let's call it a day, and we will see you next week, Adrian, for the civil liability uh version of this. Uh thank you. And I I I actually think that the civil liability one is more relevant, because the last thing you want to do is be held accountable because then it becomes you're personally liable for damage. Whoa. What a nightmare. What a nightmare. Okay, I'm going to stop sharing, Yeah. and um thank you for listening to me. Oh, not a problem at all. It was a pleasure, as always. All right, talk later. Bye, guys. Thank you. See ya. Bye.