Let's talk about how not to share! If you've got a Python model, an R model,
some sort of machine learning model, or even just a Python program in general, or R. How do
you let people make use of this and not give them free access to your plaintext code? So that they
could then take your model and do other things with it. Now I'm a YouTuber. I've got a GitHub
repository account. I share everything, and it's my goal, at least for code that I own personally.
I want to get those likes. I want to get those forks and branches. But, if you're working in
a startup company or you're working in a large Fortune 500 type industry, you probably don't
want to just share that code. You want people to use your code, because that's how you make
money with it, but you don't want them to just have free reign of it. To be able to modify it,
learn your secrets, do other things. I'm going to talk mainly about machine learning
and how you would deploy a model in such a way so that it is giving you some degree of protection.
Not just posting your code to GitHub so that everybody can take it and do with it
as they please. First of all, let's just talk about what is a model and what would be
deployed with it. I'm assuming you're going to have Python or R code. You're also going
to have libraries and packages that go along with it. You don't own these, they are third parties,
you're going to have binaries you're going to want to distribute your scoring code,
the code that gives you back the predictions from your model. You're not going to want to
distribute your training code, usually. So that's why it's very important in the beginning of the
project to just separate that. If you look at a top Kaggle solution, you'll see they usually
give you the training code, so that you could build it from scratch if you wanted to, and then
they also give you the scoring code that gives the submission. Deployment in the real world,
you're not giving people your training code that's the closest guarded of the IP,
typically. But you'll have this final model and the code necessary to take some raw input and put
out the results that you expect. So you'll have Python, R, code that's helping you do that. You're
going to have binary code, this is the trained model. If it's a neural network it is going to be
a pickle file or an RData file. Something like that, it could even be a TensorFlow or PyTorch
proprietary binary format, and you might also have like lookup tables that help you pre-process the
data. These might be CSVs or they could also be rRData or Python pickle type files as well.
Typically, it helps if you consolidate those all into one large pickle file, so the load quicker.
Now, you've got to look at how you're going to deploy this. Are you going to deploy it on the
cloud or at the edge? Cloud is easier you can truly, truly, protect your code that way. What
you're going to expose to your client, to the one who is actually making use of this, is an API,
they're going to send you JSON, if it's big data they're going to drop something in an S3 bucket.
You're going to kick off your code from possibly a Lambda function. I'm speaking in AWS terminology,
but the others would be similar, and you're going to process it give the results back. Your code is
hidden in the cloud, unless they exploit your root AWS credentials or something that has the
ability to see the code. They're never going to see it. They're going to get data in they're
going to get data put back out. However, you still need to worry about basic security here.
You want to have some sort of authentication token like an OAuth or something like that,
so that only the people that you want to have access to this can actually submit it. Think
of credit scoring, like in the United States. I'm sure other countries have equivalents. Let me know
in the comments. Do you do you use credit scores like the US does? This is basically just past data
that says how good of a credit risk are you. Do you pay your bills? Do you stiff your creditors?
Do they have to take cars and assets back from you because you don't pay your bills? You have all
your credit history and they give you a score for it. If that credit bureau had that API wide open,
I would just start sending all kinds of JSONs to it. All sorts of data and just see,
okay what gives you the best credit score and what things can you manipulate versus you can't
manipulate, and that's how we got all these credit repair books and other things they learn
they learn how to balance that model, and you gain the system you want to guard against,
that, and you guard against that two ways. One is authentication. You don't want to let
people that you don't know come in and score on your model. Because then they're going to
essentially reverse engineer it. Throttling, that's the other way, you can throttle one or more
ways. An easy way to throttle is a per transaction cost. That transaction cost means they're not
going to just hit it endlessly. The other way to throttle is physically saying... 100 requests a
day... or maybe you can only run a credit score on one person, one time, something like. That
prevents them from doing adversarial example attack. There's images that you've possibly seen
before, where one pixel causes the neural network classifier to misclassify it as something else.
The way that these adversarial example attacks work is by pinging the neural network with lots
of data and using machine learning against machine learning and coming up with the modifications that
you're going to do to the data to cause it to game the system. To give a result that you were not
expecting. That's why you throttle. That will make those algorithms much more difficult to write and
the authentication means that only your customers are the ones who are actually doing that. So
that's the cloud. That's the preferred way. That's the way that most of these models actually work if
you're using things on Google cloud or Azure or Amazon. Where they do OCR for you and they do all
these other various models. You don't download their code into your computer and run it. That
is edge deployment and edge deployment is a world more complicated. This is where you want to give
some compiled asset to your customer and they're going to execute it on their computer. You're not
going to get all the nice telemetry that you have, you might like that telemetry, but that is where
publishers get in trouble when video games phone the mothership. When they send a ping back to the
company that produced them. People don't like. That that's violating their privacy. But this
is what you handle contractually. You specify if you're you might be deploying it to an edge
device like a phone. You might be deploying it to an edge device like a personal computer. Like i
have sitting behind me. Think of Microsoft Word. They're deploying Microsoft owned code to run on
your computer. The sheer complexity of something like a Microsoft Word shields their algorithm
from exploitation. Say you wanted to exploit that really, really, annoying algorithm in Word that
somehow can detect source code and destroy it by putting capital letters and other things in there.
Say you wanted to capture that annoying thing. How would you ever even find that in Microsoft Word
that would take a long, long, time to actually try to find but you're moving code to the computer?
You want to prevent modification of it copying of it is even more difficult. Ask the video game
manufacturers about that one. So let's talk about how you would actually protect an executable that
you're sending out. You probably want to get your code to something more like a lower-level
language like C. If you write that code into C, you can compile it into executable then you can
also put noise in there to increase the amount of stuff that the person is going to have to
sift through. Just putting in a Docker image is not sufficient. If you put it in a Docker image,
docker is meant more to make an appliance. Where you've got all the stuff needed to actually run
a component. It doesn't really protect it fundamentally it's a hard drive it's an
image you can mount that image and just go look around, and if your plain text, Python or R is
sitting inside of a Docker image. It's that is really easy to get out of there. So you'd want
to compile it into something compiled like a C, use Cython on Python to do that, and that way,
your code is at least protected. You can also put decoys in there; you can put plain text code,
just to, I don't know, throw them off. Like maybe an earlier version, all sorts of things, believe
me, the video game industry I have not looked at video games and cracking them in a low level since
I was in high school. But you could, actually, a lot of those were very easy. They would put
sectors, bad sectors on the disk, and I didn't try to reproduce the bad sector. I would go and find
the code that was checking for that and commented out, NOP (no-op) it out. Basically, so be aware of
those things as well; they can go right into your Docker images. Modify them, do
things like that Cython can also be good because that sort of takes your Python to see for you
binary files are a bit more difficult. So you've trained this neural network,
you've got a TensorFlow neural network. That binary file is an industry-standard sort of thing,
and it's got unique signatures. So you can scan through the hard disk image. Even if you've
embedded that completely into some sort of a data file, you can still scan through. And find those,
and you'll see okay. Here's here's a standard TensorFlow neural network or PyTorch;
you're going to know the inputs; you're going to know the outputs. You've got
a huge chunk of your model now exposed. Encryption, you could encrypt the binary;
you definitely want to encrypt the binary so that it doesn't show up just on a
sector scan sort of thing. But the problem with encryption is your program has to decrypt it.
That's the problem that DVD manufacturers and all of those had at the end of the day.
You've got to unencrypt it. If I'm still hiding my personal records from you using PGP or something,
I can put the encrypted file in plain sight. You can download it you're never going to get
it because you don't ever have to have the ability to decrypt it. Now, if quantum computing comes on,
who knows? There's going to be some interesting things there for security. But in present day,
you're going to need to embed that private key into your executable somehow. So that
it has it to decrypt it. That's a very good idea, and it certainly should be done so that
the binary doesn't just show up as something else. Okay, thank you for watching this video,
and let me know have you tried to secure Python or our code. What worked for you, what didn't,
what were you trying to accomplish, and why. Thank you for watching this video and if you're
interested in seeing more about artificial intelligence and other applications of it,
please subscribe to my youtube channel; thank you for watching.