CODEWITHSUNDEEP
c#asp.net.netasp.net-mvc-3
IoC
IoC

Reputation: 307

Hiding parts of my code from a programmer employee

I am working on a C# project and have two programmers to help me on parts of the project. The problem is that I don't trust these programmers as they are joining recently and need to protect my company's property.

I need to hide some parts of the code from the two programmers so they don't see it and they should still be able to work on their parts and run the full application to test it.

Is there such thing ? :)

Upvotes: 2

Views: 3687

Answers (6)

Robert P
Robert P

Reputation: 15968

Know a few things:

You Can't Hide Code Users Compile Against.

C# makes it incredibly easy to see what you're compiling against, but this is actually true for all programming languages: if they are required to compile it, compile against a dll, or they can run it, either as a DLL or as raw C#, they can get access to the logic behind it. There's no way around that. If the computer can run the program and it all resides on your PC, then the human can look it over and learn how to do it too.

HOWEVER! You can design your program in such a way that they don't need to compile against it.

Use Interfaces.

Make the code that the other employees must write a plug-in. Have them write their code as an entirely separate project to an interface that the core part of your API loads dynamically at run time.

Take a look at The Managed Extensibility Framework for a tool to do this.

Use Web or Remote Services.

Components of particular secrecy can be abstracted away so the details of how it works can be hidden and then invoked via a web call. This only works in situations where the core details you want to protect are not time sensitive. This also doesn't protect the idea behind the feature: the employee will need to understand it's purpose to be able to use it, and that alone is enough to rebuild it from scratch.

Build Trust Through Code Reviews.

If you don't currently trust your employees, you need to develop it. You will not be able to know everything that everyone does always. This is a key skill in not just programming, but life. If you feel that you can't ever trust them, then you either need to hire new employees that you can trust, or build trust in them.

One way to build trust in their capabilities is through code reviews. First, make sure you're using a version control system that allows for easy branching. If you aren't, switch immediately to Mercurial*. Have an "integration" area and individual development areas, usually through cloned branches or named branches. Before they commit code, get together with the employee and review the changes. If you're happy with them, then have them commit it. This will consume a little bit of time on each commit, but if you do quick iterations on changes, then the reviews will also be quick.

Build Trust Through Camaraderie.

If you don't trust your employees, chances are they won't trust you either. Mutual distrust will not breed loyalty. Without loyalty, you have no protection. If they have access to your repository, and you don't trust them, there's a good chance they can get at the code you want anyway with a little bit of effort.

Most people are honest most of the time. Work with them. Learn about them. If one turns out to be working for a hostile entity, they've probably already obtained what they wanted to get and you're screwed anyway. If one turns out to be a pathological liar or incompetent, replace them immediately. Neither of these issues will be saved by "protecting" your code from their eyes.

Perform Background Checks.

A further way to improve trust in your employee, from a security standpoint, is a background check. A couple hundred bucks and a few days, and you can find out all sorts of information about them. If you're ready to hide code from them, and you're the employer, you might as well do due diligence before they steal the secrets to the universe.

Your Code is Not That Important.

I hate to break it to you, but there's almost a 100% chance that your code is not special. Trying to protect it through obscurity is a waste of time and a known, poor, protection method.

Good luck!

**Why Mercurial? Just because it's one option that's easy to get started with. Feel free to use any other, like Git, if it suits your fancy. Which one you use is entirely besides the point and irrelevant to this overall discussion.*

Upvotes: 16

Maciej
Maciej

Reputation: 7961

The only way I can see is to give them compiled and obfuscated assemblies to reference. Because you can only obfuscate private members you may possibly need to modify your code so that public methods do not do much if anything at all. If there is any interesting code in a public method you should rearrange your code like this:

public bool ProcessSomething()
{
    return this.DoProcessSomething();
}

private bool DoProcessSomething()
{
    // your code
}

Even obfuscator that comes free with VS will do some job to make it non-trivial to look into your code. If you require more protection you need better obfuscator of course.

But in the long run it is impractical and sends bad signals to those developers telling that you do not trust them. There can be nothing good coming out of this. If you're not the boss (or owner of the code) I would not worry that much - after all it's not your property. You can talk to your boss to express your concerns. If you are the boss you should have not employed people you do not trust in the first place.

Upvotes: 1

MrWuf
MrWuf

Reputation: 1498

Put your code into a DLL and use Dotfuscator to obfuscate the internal workings.

Upvotes: 1

kitti
kitti

Reputation: 14814

The complicated way: set up an application server with VS2010 and all the files they need, lock everything down so they cannot access any files directly and can only run VS2010 and the built application, and provide only DLLs for the protected code.

Theoretically, they would be able to work on the code they need to but would never have direct access to the DLLs, nor would they have the ability to install or use a tool such as .NET Reflector to disassemble the files... might still be some holes you'd need to look for though.

The right way: Hire trustworthy programmers. ;)

Upvotes: 1

IrishChieftain
IrishChieftain

Reputation: 15253

Keep a separate backup and submit dummy placeholders to source control.

Upvotes: 1

gdoron
gdoron

Reputation: 150263

You can't do it,

Even if you only give them a DLL with your code, they can extract the code with reflection tools, e.g. reflector.

Upvotes: 3

Related Questions