So the topic for today is how to disclose or sell an exploit without getting in trouble.
I'm Jim DiNaro.
I'm an intellectual property attorney based out of Washington, D.C.
I focus my work exclusively on information security technologies.
Before I went to law school, I used to spend far too much time just tweaking around on
MaxBug on my PowerPC and figured that no better way to keep doing that than to do this.
So here we go.
Just because I'm an attorney and this does have some legal component to it, although
this is not a law talk, really, I have to give the standard disclaimer that this presentation
is not legal advice about your specific situation or your specific questions.
Even if you ask me a question, we're still talking about hypotheticals.
If we develop an attorney-client relationship, then we're talking about your specific problem
and giving specific legal advice.
So this presentation does not create an attorney-client relationship alone.
We can maybe do that later.
So just as a quick overview of what we're trying to accomplish here in the next 20 minutes,
I'm going to speak quickly to make sure we get it all in.
We're going to cover the types of risks that are being faced by researchers, some risk
mitigation strategies that researchers can take to try to reduce those risks, some of
your options for disclosing a vulnerability that may have less risk, and then some of the
risks that are being faced by researchers.
So we're going to cover the types of risks that are associated with selling an exploit.
The overall goal of this is to make yourself a harder target.
If someone ever asks you, well, can I be sued if I do this or if this happens?
The answer is always yes.
You can always be sued by anybody for anything at any time.
The only question is, who's going to win?
And the goal is to make it more likely that you will win, which disincentivizes someone
from actually suing you in the first place.
So let's start out with just some great examples of the kind of research activities that might
get somebody in trouble.
For example, some of these are generally real life cases.
You found out how to see other people's utility bills by changing the HTTP query string.
I talked to someone at a party the other night who had done just exactly that.
He was wondering what to do about it.
You discover your neighbor's Wi‑Fi is not protected.
How did you find that out?
You broke the crypto that's protecting some media that you had.
It's getting a little more serious now.
There's actual money at stake.
And maybe you wrote a better remote access tool.
That sounds like you might make a lot of money.
So many of the same risks apply, surprisingly enough, whether you're just, you know, looking
at changing HTTP strings or whether you're actually, you know, taking apart a DVD.
So you're going to have to do a lot of research.
So, in general, we're talking about techniques.
I've sort of defined it here, broad spectrum, everything from denial of service, a technique
that might be used for a denial of service attack to something that's just, you know,
more akin to sort of investigatory web browsing.
Okay.
First, when is there risk to a security researcher?
There are three general areas where we see the risk starting to show up.
One.
There can be a threat of legal action before you go to a conference or make this disclosure.
There are some examples listed here.
You might be the recipient of a legal action seeking an injunction barring you from disclosing
something before a conference.
So we now move from merely saber rattling to an actual lawsuit being filed against you.
And then there's the possibility of a legal action being initiated against you after you
make the disclosure.
And these are all real examples.
You can ‑‑ Declan McCulloch of CNET and his colleagues have written some very interesting
articles that go into more detail about some of these cases.
I would recommend them to you most definitely.
But you might notice that some of these seem to be around Black Hat and DEF CON on a pretty
regular basis.
So that's when it can happen.
Your number one concern is typically going to be the Computer Fraud and Abuse Act.
You've probably heard a lot about that lately.
Perhaps here.
At other conferences.
The main issue is that it prohibits access without authorization or exceeding authorized
access.
The two times when you're likely to run into possibly exceeding authorized access or acting
without authorization would be in the investigatory phase of working on your ‑‑ on whatever
technique it is that you've got.
And when you actually create a tool that performs whatever this technique is, you might
actually have a problem where that tool does the act that is prohibited.
So in light of ‑‑ you know, everyone's talked much about how vague this notion of
the Computer Fraud and Abuse Act is of authorization, I've created a handy checklist to figure out
if you might have a Computer Fraud and Abuse Act problem.
So here we go.
.
Okay.
All right.
So the first one is, are you connected to the Internet?
Probably.
Are you accessing a remote system?
Probably.
Do you have permission to access that system?
This is the real hard question.
It's really hard to know if you have permission.
If you saw a banner go by that said you don't have access, you probably don't have access.
But there are a lot of cases where it's not so clear.
And that's really where you have this sort of like the Andrew Ornheimer situation where
he's querying a public domain.
It's a public‑facing API on a repeated basis.
No one asked him to do that.
But there was no banner.
There was no clear prohibition of doing that.
It was a public‑facing API after all.
So there's some real risk in figuring out if you can ‑‑ whether or not you have
permission.
But that's really all it takes.
Unfortunately, it's not just about what you do.
The Computer Fraud and Abuse Act is about what your friends do.
And I believe the risk of being caught up in conspiracy.
Conspiracy to violate the Computer Fraud and Abuse Act is most certainly enhanced by
the prevalence of social media today.
So if you're on Twitter or some other easy, very easy to use social media platform, you're
talking to your friends about how you might do something or answering questions about
how you might do a certain thing with a technique that you've developed, you're starting to
head down the road of conspiracy.
Conspiracy typically does require an overt act.
Okay.
In order to really fulfill the conspiracy and typically just discussing something when
someone does not.
But if you start providing technical support for something that someone else is doing,
you're really definitely increasing the risk of being caught up in a conspiracy to violate
the Computer Fraud and Abuse Act, if not actually violating yourself.
So we've got some examples here where the Computer Fraud and Abuse Act has been applied.
I think it's helpful to look at some examples.
Because that's how we see how it's being applied.
And we can compare what we're doing to some of the things that have happened in the past
to other people and see how close those comparisons are.
And since we're in Las Vegas, we absolutely have to talk about the case of Nestor.
Nestor was really into video poker.
And he liked to play and play and play and play.
And he got really good at it.
And he played it so much that he discovered a bug in the video game.
It was video poker software that enabled him to play one type of game and bid up a bunch
of money into that game and then switch to a different game and a multiplier would be
applied to his bid.
So when he won, he got this enormous payout.
And he figured out how to reproduce this bug very efficiently.
So he was doing it and his friends were doing it and they were getting a lot of money.
And obviously eventually, how these stories always end, he gets caught.
And he was charged with, amongst other frauds, violating the Computer Fraud and Abuse Act.
And as we were just looking at the Computer Fraud and Abuse Act a few moments ago, we saw
it's really mostly about unauthorized access or exceeding an authorization that you had.
And it's hard to imagine how sitting ‑‑ he didn't access the firmware, he didn't take
the game apart.
He just sat there putting money in and pushing the buttons on the surface of the machine.
How you could exceed authorized access to a video poker machine is absolutely mind‑boggling.
But nonetheless, those charges were levied against him.
Ultimately, the Department of Justice ‑‑
Did not pursue those charges.
Those charges were dropped.
It went ahead with other fraud charges.
But nonetheless, for some period of time he was facing computer fraud and abuse act charges
for doing exactly that.
It's also worth looking at the tragic case of Aaron Schwartz who spoofed his MAC address
to download journal articles, that was Computer Fraud and Abuse Act crime.
Andrew Ornheimer who allegedly conspired to run, spoofed his death, but did not have
an automated script to plug in identifiers for iPads and get e‑mail addresses.
Didn't even do it himself.
He's doing several years in federal prison for that.
Also worth noting that the Department of Justice has said in their manual about the Computer
Fraud and Abuse Act that conspiracy to hack a honeypot can violate the Computer Fraud
and Abuse Act.
There's really no end to the sorts of things that could possibly violate the Computer Fraud
and Abuse Act.
So you're looking at a situation where the Computer Fraud and Abuse Act almost acts as
an ex post facto law where the Department of Justice is able to look at what you did
after the fact and if they don't like it or they don't like you for whatever reason, you
may be trollish for some reason, you are likely to be on the wrong end of a Computer Fraud
and Abuse Act prosecution.
There's also a civil cause of action provided by the Computer Fraud and Abuse Act.
So the company that ‑‑ wherever the target is of this exploit can also pursue who's
ever accessed the system without authorization.
So the question then is what can we ‑‑ is there anything we can do to try to reduce
our chances of being on the wrong end of this type of lawsuit?
Well, let's take a quick ‑‑ we don't want to go too far in the statute.
It's not a continuing legal education conference.
But let's just take a quick look at the statute.
And see if there are some key words we can at least identify.
Here we have whoever having knowingly accessed a computer without authorization.
Another part of the statute, whoever intentionally accesses a computer without authorization.
So one of the things you can do is to try to avoid unintentionally creating knowledge
and intent.
It's a little bit hard to do this for yourself.
If you intend to do something.
But at least you can avoid doing it in connection with other people.
So for example, I would suggest that you do not direct information about how to use
some kind of technique to someone that you suspect or have reason to know is likely to
use it illegally.
Be careful in providing technical support for some clever new technique that you've
developed.
So my advice, if I were your lawyer, I would advise you not to answer that tweet.
If someone is tweeting to you asking you about how to make something more effective, perhaps.
This slide is a little more detailed, some more approaches that you might take.
Don't provide information possibly directly to individuals, especially if you're not
sure who they are or what they might be up to.
Consider just posting things on a Web site only.
It's a little bit more complicated.
Do not post information to forums where you suspect or forums that are known to generally
promote illegal activity.
If you publish it on your own Web site or you have control of the post, consider disabling
comments so you don't have a situation of people discussing potentially illegal uses
of your technique.
And lastly, don't maintain logs.
So one of the things that we have seen happen, that's enough for the computer for now.
fraud and abuse act for now, there's not a whole lot you can really do about it beyond
just being careful. Let's move on to temporary restraining order.
This is particularly timely, actually, because you may have read the story about the VW group
and the encryption that was used on the vehicle immobilizers. So some European security
researchers had figured out how to bypass the ‑‑ or discovered a flaw in the encryption
that was used on the vehicle immobilizers that were used in VW group cars like Porsche
and Audi and Bentley. And they are going to present this at the USENIX conference in Washington,
D.C. in a few weeks and they got themselves slapped with a temporary restraining order
preventing them from making this disclosure at the conference. How did this happen and
how can we prevent this from happening again? We've seen this here at DEF CON and at the
Black Hat. The talks have been stopped by a temporary restraining order.
So take a quick look at the factors that the courts look at when deciding whether or not
to grant a temporary restraining order to prevent a researcher from disclosing some
information about a vulnerability. Number one, will the requester, so in that case it
would be the VW group, suffer irreparable harm if the TRO does not issue?
Who knows how this works?
NEW SPEAKER 1
يمhun
The new speaker?
Correct.
Mm-hmm.
All right, it's really hard to get accepted to speak at DEF CON. You should all be thinking
about how you're going to create talks ‑‑ I've been drinking all day. Talks to eventually have matters up here, right? But a big round of applause for Jim. All right, one more order of business. We need a new program. Korea.화
person who is first time at DEF CON, first hand up right there, red shirt, come on up
on the stage.
We've got a little extra.
Let's get one more.
We've got two people.
First hand up over there.
There we go.
All right.
Cheers to our new speaker.
Thank you.
Thank you.
Thank you.
Thank you.
All right.
Let's see if you can pick up where you left off.
We're going to work on new material for tomorrow.
Thank you.
Thanks, guys.
All right.
So that was great.
Thank you.
So all right.
Just a quick look at some of the factors that the Court is going to look at when deciding
whether or not to grant a temporary restraining order to someone like the VW Group who wants
to stop a presentation from happening at USENIX.
Will the requester, the VW Group, suffer irreparable harm if the TRO is not issued?
Pretty easy to imagine.
You've got an embedded system and someone has figured out how to break it.
It's going to be almost impossible for them to update it in any reasonable amount of time.
Usually expensive.
Probably some irreparable harm that basically means that money isn't going to fix it very
easily.
So that goes in VW Group's favor.
Will there be an even greater harm to the researcher if the TRO does not issue?
Your paper got delayed.
You couldn't put in some part of the algorithm maybe.
You had to pare it back.
Hard to see that as a huge harm to the researcher.
We might feel really bad about that.
But in terms of the huge sums of money VW Group is going to have to pay to fix this,
it's not really going to look too good for the researcher there.
The public interest.
This is kind of a fun one because we might think that, well, the public interest clearly
favors disclosing.
The vulnerability.
So it can be fixed.
Of course, it's probably going to go the other way on that and see that really the risk to
all these BMWs or rather Porsches and Bentleys and things being stolen is much greater ‑‑ is
much more in the public interest than having, you know, your really obscure crypto talk
go forward.
The last factor is the likelihood a requester will ultimately prevail.
Okay.
And this is really the one we need to focus on because the VW Group has to have a cause
of action.
They can't just say we don't like it.
They have to say, here's why you need to stop.
And it's because you did something bad to us.
And in the case of the VW Group, the Megamos case, and also in the case of the Cisco disclosure,
what we had was the use of copyrighted material.
And that's really what ‑‑ that was the case.
That was the hook that got the TRO to issue.
So the obvious advice then is to avoid the use of copyrighted material.
So if you include source code or object code from whatever it is that you're working on,
that gives leverage to whoever it is that wants to stop you from disclosing it.
There is a fair use exception if you use little bits and pieces of code.
But that's a case‑by‑case analysis and you can't just say, well, this is going to be
fair use.
It depends on how much you use and other factors that are very specific to what's actually
going on in your case.
So just try to avoid it if you can.
It may not be possible.
But to the extent you can, do that.
Also avoid dark net sources for wherever you're getting this stuff.
In the Megamos case, the court actually talked about the fact that the researchers obtained
some information about how the Megamos system worked through some sort of security system.
I don't recall it saying exactly where they got it.
But it was some sort of BitTorrent P2P type thing, wherever they got it.
It wasn't from VW Group or Megamos.
So another thing you want to do is be aware of pre‑existing contractual relationships
that you as a security researcher might have with the target of whatever it is you're working
on.
These contractual agreements could come in the form of a term of service, end‑user license
agreements, nondisclosure agreements.
So an end‑user license agreement might very well have provisions in it that prohibit
reverse engineering software, for example.
And that's something that you might very well be doing as part of your exploration into
your technique.
And that could give leverage to someone to try to stop using, oh, you breached this.
Nothing is for certain.
It's just an argument that they have.
It's something ‑‑ there's not much you can do about it.
I mean, pretty much every piece of software you get is going to have some kind of license
agreement that's going to ‑‑ assuming you came to it legitimately, right, you've
agreed to this license that may prohibit you from doing certain things with that software.
And there's not a whole lot you can do about that.
But you at least can be aware of the risk, if nothing else.
So how far you need to go.
In trying to mitigate the risk, somewhat depends on the techniques that you've used
in your research.
If you've done things that are clearly ‑‑ that clearly look like some of the examples
of, you know, what people have done that's gotten them prison time, that's something
you need to be careful of and maybe take more aggressive mitigation techniques in order
to perhaps hide some of the information about what you're doing.
So for example.
If in the Megamos case.
Yeah.
No one had identified that it was the VW group that was ‑‑ where this crypto system
had been compromised, VW group would not have been able to issue ‑‑ to go after
a temporary restraining order against the researchers, so perhaps there's an opportunity
here for the conference‑going community to create a track where people could present
things.
That are ‑‑ sort of get like a little asterisk or something next to it and we all
recognize that this is something that had to be kept quiet.
It's sort of like a confidential disclosure, trust the review board, this is going to
be really cool, but we just can't really tell you about what it is because then you
won't get to hear it.
So maybe that's one approach.
So I'd like to talk about some of the ways that you might make a disclosure that are
relatively less likely to get you in trouble.
Okay.
All right.
So you've obviously disclosed to the responsible party.
That's what we'd like to do, that's sort of what the responsible disclosure paradigm
is all about.
You found a problem with the system, you tell who's running the system.
This is actually unfortunately relatively high risk and that risk scales with the questionableness
of whatever technique it was that you used to find out about this vulnerability.
So if you're connected to the Internet and you access a remote system and you didn't
have permission, that's how you did it.
It may not be a great idea.
It's a great idea to go tell them about it because if they don't like it, they've got
an action against you.
If you're inconvenient, that's a problem for you.
You might think you're doing them a favor.
They might not agree that you're doing them a favor.
If you're able to submit it anonymously to whoever the vendor is or the responsible party,
that's great.
Depends how good your OPSEC is, I suppose.
A lot of times you think you're maybe anonymous, but you're not as anonymous as you thought
you were or hoped you were.
So that's a risk in itself that you need to consider.
If you submit to a bug bounty, presumably they've invited it, maybe you're at less risk.
You can disclose to a government authority, perhaps.
Maybe you don't really believe it will ever get to the vendor.
But again, if your techniques were perhaps questionable, you might not necessarily want
to be submitting it to a government, a governmental authority.
You may want it separately.
You may have an interest in keeping your own identity anonymous.
Again, you can try to submit anonymously to the government, but I don't know how much
we can really trust that anymore.
Fortunately, you know, this is a legal talk, somewhat legal talk, and you can almost never
get to a legal talk where someone will actually tell you something for sure.
Like absolutely, 100 percent, you will not get in trouble if you do this.
But fortunately we are in a case here where there is one group of people.
A group of people who really don't have to worry about getting in trouble with the Computer
Fraud and Abuse Act when they disclose a vulnerability.
And here they are.
Okay to disclose if you're one of these people.
Although she really should not have been hacking the palace computer.
We're not going to hold that against her.
So we're thinking about ways that we might be able to leverage opportunities for security
researchers.
Make disclosures while keeping the risk as low as possible.
So we're working on creating a pilot program where attorney-client privilege can be leveraged
to hide the identity and the techniques used by a security researcher in making a disclosure.
So the concept works like this.
The researcher would disclose a vulnerability.
The vulnerability to a trusted third party, which would be an attorney, only to the attorney.
It's critical that this be a completely confidential disclosure to maintain that attorney confidentiality
of that disclosure so that other entities on the outside can't get to it.
The trusted third party does not publish the vulnerability on behalf of the researcher.
However the trusted third party does disclose the vulnerability to whoever the affected
party is.
Whoever has this vulnerability.
The researcher remains anonymous during the entire process.
This is possibly of use if there's no better option.
It's a little bit cumbersome and there are some side effects, chiefly that the researcher
remains anonymous, doesn't get public credit for whatever the research was.
But it is one possible way for the researcher to be able to disclose and re-discover the
vulnerability.
So this is a pilot program.
We're currently working on it.
We're kicking out the bugs right now.
So if anyone is interested in talking to us further about this, we definitely welcome
your input and please see me afterwards.
We should now turn to selling very quickly.
Right now there is no law in the U.S. that prohibits the selling of an exploit.
And that is a situation that is problematic.
probably likely to change in the not too distant future, but for now, there's really not too
much to worry about unless the techniques, of course, going back a few slides, if your
techniques in developing your exploit have some problem, then you still have a problem.
But the fact of the sale itself is not something that's going to get you in trouble.
However, there's a lot of focus on this market now, and here are some recent articles from
May of 2013, booming zero day trade as Washington experts worried, and my favorite, the U.S.
Senate wants to control malware like it's a missile.
Stuff is dangerous.
So every year, the Congress has to pass a national defense authorization act that sets
the budget for DOD and includes a bunch of other stuff that gets stuck in there.
And this year, well, for 2014, the Senate version
hasn't passed yet, it's still in Congress.
The Senate version has provisions that seek to begin the process of regulating the sale
of exploits.
The bill, the House version doesn't have this, it's just in the Senate.
But I think this is where it's headed.
The bill notes that the President shall establish a process for developing policy to control
the proliferation of cyber weapons.
It happens through a whole series of possible actions, right?
Export controls, law enforcement, financial diplomatic engagement, and so on.
The Senate Armed Services Committee that had the bill before it was passed to the rest
of the Senate, to the rest of the Senate, said they had some commentary on this.
And they referred to the dangerous software, a global black market, a gray market.
It starts to look really bad but they know that there is ‑‑ we need to have a carve
out for dual‑use software and pen testing tools.
In Europe, the European Parliament recently passed a directive.
They are a little bit ahead of us.
This prohibition on the sale of tools, as they call it, basically exploits, is ‑‑
will be required to be enacted by all of the member states in short order.
And this ‑‑
prohibits the production, sale, procurement for use, import, distribution of these tools
that could be used to commit these enumerated offenses, which is pretty much all the bad
things that you can think of doing with a computer.
However, there's an exception.
It's a very important exception.
For tools that are created for legitimate purposes, such as to test the reliability
of systems and further notes that there needs to be ‑‑ in order to violate this law,
you need to have ‑‑ you need to show a direct intent that the tools be used to
commit some of the offenses.
So in both cases, both in the U.S. and in Europe, we're seeing this trend, it's really
going back to the definitional problem.
How do we define what an exploit is and how do we make sure that, you know, legitimate
tools are ‑‑ can still be bought and sold?
So it's this kind of perspective.
We don't know what the laws are actually going to look like.
But I would start thinking like this.
Think about dual‑use tools.
If you write something, don't put it together as the next greatest hack.
This is ‑‑ you're creating pen testing tools.
This has gone on for a long time.
If you look at software, I'm sure you've all used it, copy 2 plus on the Apple II or locksmith.
Backup software.
And the manuals for these softwares have these very elaborate disclaimers.
This is strictly being used to back up your floppy.
This is not being used to make illegal copies.
And that is really the conundrum, and I think that's where software ‑‑ that's where
exploits will go.
And some exploits will never be able to be looked at as a dual‑use tool for sure.
I mean, if all ‑‑ if, you know, sort of like if you have a nuclear missile equivalent
of an exploit, I mean, it's hard to justify the pen testing value of that.
But for a lot of tools, they will fall into it.
Into this area.
And that's where perhaps they should go.
Some other things you might do if you are selling, know your buyer to the extent you
can.
I think regulation is just one bad outcome away.
What's going to happen is someone in the U.S. is going to sell an exploit, it's going
to go through some channel, and it's going to come back and get used against some U.S.
interest.
We may not hear about it.
It may be a matter of, you know, maybe secret.
But this will happen.
And then there will be a huge drive to stop this from happening very quickly.
It's the same reason, you know, as soon as ‑‑ you know, if someone is murdered with a certain
type of weapon, that weapon has to be banned, that's going to happen here.
The laws are ‑‑ the way laws are created in this country is very reactionary.
And I expect that trend to continue here.
So maybe you can prevent that from happening.
So know your buyer.
If you're selling something, don't sell it to a channel where it's likely to go to some
country that's under an embargo with the United States.
Maybe your best bet is just to sell it to the U.S.
Ask for assurances from your buyer so you don't have knowledge that it's going to some
place where it's not supposed to go.
You could be lied to, but you can't control, you know, everything, right?
But at least you can get an assurance that you're ‑‑ you know, it's not going to
be used in some illegitimate way.
And also you can always use disclaimer language.
So I have some nice examples of disclaimer language here.
This ‑‑ you don't have to use disclaimer language.
Huge chunk of text on the top is actually from a software product that many of you have
probably used many times.
It's good stuff.
I've highlighted probably the best of the operative language in it.
But if you're selling something, be sure to use some disclaimer language about ‑‑ that
kind of flows along these lines that would help you from being charged with being complicit
in any sort of illegal use to which the software might eventually be put.
And lastly, I'd just like to highlight this bottom little paragraph, which is actually
from the Apple iTunes store.
It's the end user license agreement that comes with that.
And it requires that you agree that you will not use these products for any purpose prohibited
by United States law, including without limitation the development, design, manufacture, production
of nuclear missiles or chemical or biological weapons.
Thank God.
Words with friends.
That is dangerous stuff.
So thank you for ‑‑ thank you for coming.
This is my contact block.
So I think we have some time here for questions.
So if people want to line up, I'm happy to entertain them as best we can.
There are definitely free speech issues, especially in the temporary restraining order
context.
Second amendment.
Second amendment, sorry.
Second amendment challenge?
Come see me after about that.
Question back here.
I'm not sure if we have a question.
How long is this going to take?
If you're interested, you can ask.
I'm in the middle of a meeting.
All right.
Have a great day.
Have a great day.
Have a great day.
Bye-bye.
Bye-bye.
Bye-bye.
Bye-bye.
Question?
Let's connect on that.
Let's connect on that.
Thank you.
What about using a corporation to limit your liability for disclosure or selling?
Has that been utilized?
Corporations can be held liable in many cases.
In fact, even under the Computer Fraud and Abuse Act, it hasn't happened yet, but a corporation
could be held liable.
Question regarding full disclosure versus responsible disclosure.
So when we do it, we do it via responsible disclosure.
We contact the vendor.
We give them 30 days.
And we tell them our intent to publish.
And we publish everything, so the actual vulnerability and how to do it so that people can replicate
and do whatever they want.
In most cases, the vendors get a hot fix within a week.
Yeah.
And if within 30 days they provide the hot fix, then we credit them and say, you know,
to fix it, install hot fix, whatever.
Sometimes vendors will say we need more time.
Maybe we'll negotiate a couple of days.
But sometimes they'll say we're not going to fix it and you can't publish it.
So I won't explain what we do for that.
But Google recently published the fact that they plan to disclose vulnerabilities within
seven days.
All right?
To have a seven-day turnaround.
So what happens if a company like Google, I don't want to use the word threaten, but
intends to publish a vulnerability within the seven-day turnaround period, and that
company says to Google, don't, if you do, we'll sue you.
What happens in Google versus that vendor company?
Well, Google is at risk if Google has some kind of obligation not to.
I mean, if ‑‑ it would depend on the specific circumstances of it.
Yeah.
But in this case, I mean, if no law has been broken, then Google could e‑publish
that without any repercussion.
But in the case for me, for example, where I contact a vendor and I say I've got the
following ten vulnerabilities which I plan to publish, and they come back to me and say,
if you publish those, we'll sue you.
Right?
Yeah.
And the same thing happens when Google say, well, we're not going to give you 30 days.
We're going to give you seven days.
And the company comes back and says, Google, we're going to sue you if you publish.
It doesn't carry the same weight where they're trying to sue Google as they're trying to
sue me, for example.
That helps as well, man.
I mean, that's the unfortunate part.
Yeah.
I mean, as a ‑‑
But is it just a case of how good your legal team is or how expensive your legal team
is?
Exactly.
How much do you charge?
Where do you want to meet them at?
Oh, let's go ‑‑ I don't know.
Where is good.
Wherever you want to meet them at, to carry on, because there's about five or six other
people that's going to be there.
Yeah.
So this talks over with.
We've got to get it ready for the evening.
Now in the hallway, we'll answer the rest of your questions.
Unfortunately, there's not a Q&A because it's been this simple, too.
So thank you all.
Thank you.
Thank you.
Thank you.
Thank you.