[gentoo-user] {OT} Deliberately obfuscating my code

[gentoo-user] {OT} Deliberately obfuscating my code

[Grant]

This is OT, but you guys have proven extremely insightful over the
years and I would love to hear what you think.

I've been working on a particular software project for a long time.
I'd like to hire a team of developers to take over the project, but I
consider the code to be valuable and I'd like to keep the whole of it
secure, even from my own developers.  I was thinking I could do this
by using some technique to obfuscate the true intention of the code
modules.  Maybe a recorded series of search/replaces for variable
names which are reversed once code editing is complete?  Has any
software been made available to aid in an endeavor like this?

- Grant

Re: [gentoo-user] {OT} Deliberately obfuscating my code

[Hilco Wijbenga]

On 8 November 2010 20:52, Grant <emailgrant@gmail.com> wrote:
> This is OT, but you guys have proven extremely insightful over the
> years and I would love to hear what you think.
>
> I've been working on a particular software project for a long time.
> I'd like to hire a team of developers to take over the project, but I
> consider the code to be valuable and I'd like to keep the whole of it
> secure, even from my own developers.  I was thinking I could do this
> by using some technique to obfuscate the true intention of the code
> modules.  Maybe a recorded series of search/replaces for variable
> names which are reversed once code editing is complete?  Has any
> software been made available to aid in an endeavor like this?

Not an answer to your question but how are those developers going to
work on your software if you obfuscate it first? Seems very counter
productive. Not to mention that it seems like a perfect way to
introduce bugs in your code base.

Wouldn't it be much simpler to have your developers sign an NDA? In
general, I would not worry too much about your idea being stolen, it's
the implementation that makes it worth something. And implementing an
idea takes a lot of hard work.

Cheers,
Hilco

Re: [gentoo-user] {OT} Deliberately obfuscating my code

[Grant]

>> This is OT, but you guys have proven extremely insightful over the
>> years and I would love to hear what you think.
>>
>> I've been working on a particular software project for a long time.
>> I'd like to hire a team of developers to take over the project, but I
>> consider the code to be valuable and I'd like to keep the whole of it
>> secure, even from my own developers.  I was thinking I could do this
>> by using some technique to obfuscate the true intention of the code
>> modules.  Maybe a recorded series of search/replaces for variable
>> names which are reversed once code editing is complete?  Has any
>> software been made available to aid in an endeavor like this?
>
> Not an answer to your question but how are those developers going to
> work on your software if you obfuscate it first? Seems very counter
> productive. Not to mention that it seems like a perfect way to
> introduce bugs in your code base.

The internal function of each code module wouldn't be obfuscated of
course, but the variable names and similar could be.  The idea is that
I would define a specific spec to which each module of code is
written.  This is very uncharted territory for me.  Is this something
that just isn't done?  Does everyone just hope each of their
developers are honest people?

> Wouldn't it be much simpler to have your developers sign an NDA? In
> general, I would not worry too much about your idea being stolen, it's
> the implementation that makes it worth something. And implementing an
> idea takes a lot of hard work.

The idea is nothing special, you're right, it's the implementation,
and the software is the implementation in this case so I need to
protect it.

- Grant

Re: [gentoo-user] {OT} Deliberately obfuscating my code

[Alan McKinnon]

Apparently, though unproven, at 07:56 on Tuesday 09 November 2010, Grant did 
opine thusly:

> >> This is OT, but you guys have proven extremely insightful over the
> >> years and I would love to hear what you think.
> >> 
> >> I've been working on a particular software project for a long time.
> >> I'd like to hire a team of developers to take over the project, but I
> >> consider the code to be valuable and I'd like to keep the whole of it
> >> secure, even from my own developers.  I was thinking I could do this
> >> by using some technique to obfuscate the true intention of the code
> >> modules.  Maybe a recorded series of search/replaces for variable
> >> names which are reversed once code editing is complete?  Has any
> >> software been made available to aid in an endeavor like this?
> > 
> > Not an answer to your question but how are those developers going to
> > work on your software if you obfuscate it first? Seems very counter
> > productive. Not to mention that it seems like a perfect way to
> > introduce bugs in your code base.
> 
> The internal function of each code module wouldn't be obfuscated of
> course, but the variable names and similar could be.  The idea is that
> I would define a specific spec to which each module of code is
> written.  This is very uncharted territory for me.  Is this something
> that just isn't done?  Does everyone just hope each of their
> developers are honest people?

Your average developer will look at that and say to himself

"Fuck that. I'm going somewhere else".

20 year olds might not. They don't have the experience to judge.

> > Wouldn't it be much simpler to have your developers sign an NDA? In
> > general, I would not worry too much about your idea being stolen, it's
> > the implementation that makes it worth something. And implementing an
> > idea takes a lot of hard work.
> 
> The idea is nothing special, you're right, it's the implementation,
> and the software is the implementation in this case so I need to
> protect it.

Protect it from what? From people you hired?

Simpler to change your hiring policies.

Look, you gotta trust someone in this world. As a boss, like every other boss 
out there, you gotta trust your staff.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] {OT} Deliberately obfuscating my code

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

Am 09.11.2010 05:52, schrieb Grant:
> This is OT, but you guys have proven extremely insightful over the
> years and I would love to hear what you think.
> 
> I've been working on a particular software project for a long time.
> I'd like to hire a team of developers to take over the project, but I
> consider the code to be valuable and I'd like to keep the whole of it
> secure, even from my own developers.  I was thinking I could do this
> by using some technique to obfuscate the true intention of the code
> modules.  Maybe a recorded series of search/replaces for variable
> names which are reversed once code editing is complete?  Has any
> software been made available to aid in an endeavor like this?
> 
> - Grant
> 

About what programming language are we talking? For Java and Javascript,
there is a range of obfuscators available. For C/C++, I don't think it
is really necessary. Can't you simply put your stuff into a binary-only
library?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

[gentoo-user] Re: {OT} Deliberately obfuscating my code

[Grant Edwards]

On 2010-11-09, Florian Philipp <lists@f_philipp.fastmail.net> wrote:
> Am 09.11.2010 05:52, schrieb Grant:
>> This is OT, but you guys have proven extremely insightful over the
>> years and I would love to hear what you think.
>> 
>> I've been working on a particular software project for a long time.
>> I'd like to hire a team of developers to take over the project, but I
>> consider the code to be valuable and I'd like to keep the whole of it
>> secure, even from my own developers.

You can't work on code you can't understand.  If you try, you just end
up breaking things.

>> I was thinking I could do this by using some technique to obfuscate
>> the true intention of the code modules.  Maybe a recorded series of
>> search/replaces for variable names which are reversed once code
>> editing is complete?  Has any software been made available to aid in
>> an endeavor like this?

> About what programming language are we talking? For Java and
> Javascript, there is a range of obfuscators available. For C/C++, I
> don't think it is really necessary. Can't you simply put your stuff
> into a binary-only library?

Read the OP again.  He wants to obsfuscate the code to make it
unreadable for the people he's hiring to work on it.

It would be simpler and cheaper to hire developers who don't
understand programming language in question, computers, programming in
general, or even english.

Then don't let them access any computers that have the source code.

You'll get better results that way -- far fewer bugs will be
introduced.

1/2 :)

-- 
Grant Edwards               grant.b.edwards        Yow! I think my career
                                  at               is ruined!
                              gmail.com            

Re: [gentoo-user] Re: {OT} Deliberately obfuscating my code

[Grant]

> Read the OP again.  He wants to obsfuscate the code to make it
> unreadable for the people he's hiring to work on it.
>
> It would be simpler and cheaper to hire developers who don't
> understand programming language in question, computers, programming in
> general, or even english.
>
> Then don't let them access any computers that have the source code.
>
> You'll get better results that way -- far fewer bugs will be
> introduced.

The idea isn't to make the code unreadable.  Obviously anyone working
on it needs to be able to read and understand it.

This idea was brought on while reading a Wikipedia page about modular
programming:

"Theoretically, a modularized software project will be more easily
assembled by large teams, since no team members are creating the whole
system, or even need to know about the system as a whole. They can
focus just on the assigned smaller task."

http://en.wikipedia.org/wiki/Modular_programming

I don't mind system administration but I don't want to be a programmer
any more.  I'd like to hire programmers to work in the manner
described above.  They would each work on modules and not know about
the system as a whole.  How can something like this be implemented?

- Grant

Re: [gentoo-user] Re: {OT} Deliberately obfuscating my code

[Hilco Wijbenga]

On 9 November 2010 09:14, Grant <emailgrant@gmail.com> wrote:
> "Theoretically, a modularized software project will be more easily
> assembled by large teams, since no team members are creating the whole
> system, or even need to know about the system as a whole. They can
> focus just on the assigned smaller task."
>
> http://en.wikipedia.org/wiki/Modular_programming
>
> I don't mind system administration but I don't want to be a programmer
> any more.  I'd like to hire programmers to work in the manner
> described above.  They would each work on modules and not know about
> the system as a whole.  How can something like this be implemented?

Okay, so this has nothing to do with obfuscation, not trusting people,
or protecting IP. This is normal software development.

One would want to break a large application into manageable pieces.
Usually, those pieces would be libraries (where the meaning of
"library" depends on your programming language of choice: SOs, DLLs,
JARs, etcetera). If your application is monolithic right now then you
(and/or your developers) will have to spend some time modularizing it.

So is your question really "how do I modularize my code"?

Re: [gentoo-user] Re: {OT} Deliberately obfuscating my code

[Grant]

>> "Theoretically, a modularized software project will be more easily
>> assembled by large teams, since no team members are creating the whole
>> system, or even need to know about the system as a whole. They can
>> focus just on the assigned smaller task."
>>
>> http://en.wikipedia.org/wiki/Modular_programming
>>
>> I don't mind system administration but I don't want to be a programmer
>> any more.  I'd like to hire programmers to work in the manner
>> described above.  They would each work on modules and not know about
>> the system as a whole.  How can something like this be implemented?
>
> Okay, so this has nothing to do with obfuscation, not trusting people,
> or protecting IP. This is normal software development.
>
> One would want to break a large application into manageable pieces.
> Usually, those pieces would be libraries (where the meaning of
> "library" depends on your programming language of choice: SOs, DLLs,
> JARs, etcetera). If your application is monolithic right now then you
> (and/or your developers) will have to spend some time modularizing it.
>
> So is your question really "how do I modularize my code"?

I'm most interested in the part about developers not knowing about the
system as a whole.  I'd like developers to work on my code, but
prevent them from selling the code or using it themselves.  I thought
a good way to accomplish this might be to modularize heavily and
change variable names.

It sounds like I'm really going against the grain here.  Is it
standard practice to hire a developer on the internet from any given
country, never meet him or her, have them fax a signed NDA, and turn
over your biggest asset to them?

- Grant

Re: [gentoo-user] Re: {OT} Deliberately obfuscating my code

[Mark Knecht]

On Tue, Nov 9, 2010 at 9:14 AM, Grant <emailgrant@gmail.com> wrote:
>> Read the OP again.  He wants to obsfuscate the code to make it
>> unreadable for the people he's hiring to work on it.
>>
>> It would be simpler and cheaper to hire developers who don't
>> understand programming language in question, computers, programming in
>> general, or even english.
>>
>> Then don't let them access any computers that have the source code.
>>
>> You'll get better results that way -- far fewer bugs will be
>> introduced.
>
> The idea isn't to make the code unreadable.  Obviously anyone working
> on it needs to be able to read and understand it.
>
> This idea was brought on while reading a Wikipedia page about modular
> programming:
>
> "Theoretically, a modularized software project will be more easily
> assembled by large teams, since no team members are creating the whole
> system, or even need to know about the system as a whole. They can
> focus just on the assigned smaller task."
>
> http://en.wikipedia.org/wiki/Modular_programming
>
> I don't mind system administration but I don't want to be a programmer
> any more.  I'd like to hire programmers to work in the manner
> described above.  They would each work on modules and not know about
> the system as a whole.  How can something like this be implemented?
>
> - Grant

Get ready to pay a lot more for the documentation and testing portions
of your costs.

If you write a clear spec for the modular block that the programmer is
developing or maintaining then they can follow that during
implementation. However, how do they test their code if they don't
understand the environment that it's being used in?

1) Write test programs that call the block they developed or
maintained. Ensure those test programs exercise _ALL_ the functions of
the block in all possible permutations with all possible initial
states that the module will see during it's life in the larger
product. That's a very difficult problem to _prove_ you've done. I
have worked on chip designs with hundreds of millions of transistors.
In a sense every transistor is a line of code somewhere and it's
simply very difficult to prove you've ever tested everything. I
promise you that the processor in your computer has bugs in the
hardware. They are there. Once in awhile you'll hit on and your PC
will crash. No processor is 'perfect'.

2) Pay the developer to 'Instrument' your module so that every time
it's called it saves some info that can be used to backtrace what has
been happening. When a problem arises have a way to read and
understand the implementation. This can slow down the performance of
the system terribly.

Keeping the software developers completely in the mushroom barn is
(possibly) a pretty expensive thing to try and do.

Hope this helps,
Mark

Re: [gentoo-user] Re: {OT} Deliberately obfuscating my code

[Jacob Todd]

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

Only expose the teams to what they need, give them prototypes and
discriptions to the other parts. Like a man page.
On Nov 9, 2010 12:16 PM, "Grant" <emailgrant@gmail.com> wrote:
>> Read the OP again.  He wants to obsfuscate the code to make it
>> unreadable for the people he's hiring to work on it.
>>
>> It would be simpler and cheaper to hire developers who don't
>> understand programming language in question, computers, programming in
>> general, or even english.
>>
>> Then don't let them access any computers that have the source code.
>>
>> You'll get better results that way -- far fewer bugs will be
>> introduced.
>
> The idea isn't to make the code unreadable. Obviously anyone working
> on it needs to be able to read and understand it.
>
> This idea was brought on while reading a Wikipedia page about modular
> programming:
>
> "Theoretically, a modularized software project will be more easily
> assembled by large teams, since no team members are creating the whole
> system, or even need to know about the system as a whole. They can
> focus just on the assigned smaller task."
>
> http://en.wikipedia.org/wiki/Modular_programming
>
> I don't mind system administration but I don't want to be a programmer
> any more. I'd like to hire programmers to work in the manner
> described above. They would each work on modules and not know about
> the system as a whole. How can something like this be implemented?
>
> - Grant
>

[-- Attachment #2: Type: text/html, Size: 1919 bytes --]

Re: [gentoo-user] Re: {OT} Deliberately obfuscating my code

[Hilco Wijbenga]

On 9 November 2010 10:08, Grant <emailgrant@gmail.com> wrote:
> It sounds like I'm really going against the grain here.  Is it
> standard practice to hire a developer on the internet from any given
> country, never meet him or her, have them fax a signed NDA, and turn
> over your biggest asset to them?

:-) No way. :-) That is a recipe for disaster.

Firstly, in general, when it comes to code: you get what you pay for.
And bad code will cost you much more in the long run than simply
paying more for good code.

Now that doesn't mean that by definition all cheap(er) developers are
bad (or that all expensive ones are good) but the odds are not in your
favour. So if you still want to pay less then go with a reputable
company that provides that service. (I don't mean IBM, I mean some
company in India or Russia.) You'll not only get your developers but
you'll also be guaranteed that they'll be "automatically" replaced
should they leave the company.

You still have to insist on talking to the developers. Make sure they
can code and know what they're talking about. I think you'll find that
it takes a *lot* of time and effort (and a teaspoon of luck) to create
a good team.

And handling a distributed team in different timezones is hard work
too. You'll need a lot more documentation which then will still be
interpreted incorrectly. Yes, I'm talking for experience. :-)

Re: [gentoo-user] Re: {OT} Deliberately obfuscating my code

[Alan McKinnon]

Apparently, though unproven, at 20:08 on Tuesday 09 November 2010, Grant did 
opine thusly:

> It sounds like I'm really going against the grain here.  Is it
> standard practice to hire a developer on the internet from any given
> country, never meet him or her, have them fax a signed NDA, and turn
> over your biggest asset to them?


You are posting to a list dedicated to a Free and Open Source distro.

Folks here won't even bother with an NDA, they'll mostly just give away the 
entire code base for free.

Come on Grant, you know the ropes. What kind of response did you expect?

I'll repeat my earlier question, which you didn't answer as yet. You want to 
keep your code away from your own staff. Obviously, you do not trust your 
staff completely (for whatever reason). Why did you hire them if you can't 
trust them?

You are also abusing code modularity for a purpose it was not intended. It 
improves code quality and reduces cohesion. It does not increase obfuscation.


-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Re: {OT} Deliberately obfuscating my code

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 2640 bytes --]

Am 09.11.2010 19:08, schrieb Grant:
>>> "Theoretically, a modularized software project will be more easily
>>> assembled by large teams, since no team members are creating the whole
>>> system, or even need to know about the system as a whole. They can
>>> focus just on the assigned smaller task."
>>>
>>> http://en.wikipedia.org/wiki/Modular_programming
>>>
>>> I don't mind system administration but I don't want to be a programmer
>>> any more.  I'd like to hire programmers to work in the manner
>>> described above.  They would each work on modules and not know about
>>> the system as a whole.  How can something like this be implemented?
>>
>> Okay, so this has nothing to do with obfuscation, not trusting people,
>> or protecting IP. This is normal software development.
>>
>> One would want to break a large application into manageable pieces.
>> Usually, those pieces would be libraries (where the meaning of
>> "library" depends on your programming language of choice: SOs, DLLs,
>> JARs, etcetera). If your application is monolithic right now then you
>> (and/or your developers) will have to spend some time modularizing it.
>>
>> So is your question really "how do I modularize my code"?
> 
> I'm most interested in the part about developers not knowing about the
> system as a whole.  I'd like developers to work on my code, but
> prevent them from selling the code or using it themselves.  I thought
> a good way to accomplish this might be to modularize heavily and
> change variable names.
> 

Well, there are two ways to go here:
1. Modularize what you have. Give every developer only the source he is
supposed to work on and binary interfaces (libs + header files for
C/C++) and documentation for everything else.

Then the devs will be able to run the software but no one will have all
the source code.

2. Do not give working code to anyone. Define specs, test cases,
prototypes and mock-ups. Then tell your devs to develop against these.

When they have finished their modules (classes, units, whatever), it is
your job to integrate these modules and see whether they work together
as expected. If they don't, improve your specs and tests and give the
code back to the devs for another iteration.

I favor the second approach, especially as there are tools available to
help you and it is safer against reverse-engineering.

I repeat myself but: It would help a lot to know more about the project.
What programming language? What basic structure? Object-oriented,
procedural, distributed (sockets, web services, RPC, ...)?

Hope this helps,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] {OT} Deliberately obfuscating my code

[Arttu V.]

On 11/9/10, Grant <emailgrant@gmail.com> wrote:
> I've been working on a particular software project for a long time.
> I'd like to hire a team of developers to take over the project, but I
> consider the code to be valuable and I'd like to keep the whole of it
> secure, even from my own developers.  I was thinking I could do this
> by using some technique to obfuscate the true intention of the code
> modules.  Maybe a recorded series of search/replaces for variable
> names which are reversed once code editing is complete?  Has any
> software been made available to aid in an endeavor like this?

Can you reveal a bit about the nature of the valuable secret in the
code? Is it some weights like with Coca-Cola's recipe and Google's
PageRank? Some entire algorithm, like some proprietary stock trading
scheme/plan implementation? Or something bigger? The entire thing?
Just ickyness over the quality of it, and the glaring holes that'd be
visible to outside devs? :)

You might be able to re-factor the whole codebase to use something
like Strategy Patterns from Gamma et al's book. Then you'd keep the
Strategy implementation parts to your own code base and development,
while the more generic "engine" part (which just calls the Strategy
when needed) might be developed a bit more freely and openly. Still I
doubt this is your case since you apparently already have some
functional code, so there hopefully is some designed structure in it.

-- 
Arttu V.

[gentoo-user] Re: {OT} Deliberately obfuscating my code

[Grant Edwards]

On 2010-11-09, Grant <emailgrant@gmail.com> wrote:

>> So is your question really "how do I modularize my code"?
>
> I'm most interested in the part about developers not knowing about
> the system as a whole.  I'd like developers to work on my code, but
> prevent them from selling the code or using it themselves.

Have programmers stolen a lot of code from you or somebody you know in
the past?

> I thought a good way to accomplish this might be to modularize
> heavily and change variable names.

I don't understand what changing the variable names accomplishes if
the source code is still readable and understandable by those working
on it.

> It sounds like I'm really going against the grain here.  Is it
> standard practice to hire a developer on the internet from any given
> country, never meet him or her, have them fax a signed NDA, and turn
> over your biggest asset to them?

You've got to do some due diligence.  Mostly to find out if they're
competent.  Also I suppose to find out if they're honest.  Personally,
I think the former is the big problem.

Maybe you should hire local developers whom you've interviewed and
whose references you've checked?

-- 
Grant

[gentoo-user] Re: {OT} Deliberately obfuscating my code

[Grant Edwards]

On 2010-11-09, Florian Philipp <lists@f_philipp.fastmail.net> wrote:

> Well, there are two ways to go here:

> 1. Modularize what you have. Give every developer only the source he
>    is supposed to work on and binary interfaces (libs + header files
>    for C/C++) and documentation for everything else.
>
>    Then the devs will be able to run the software but no one will
>    have all the source code.
>
> 2. Do not give working code to anyone. Define specs, test cases,
>    prototypes and mock-ups. Then tell your devs to develop against these.
>
>    When they have finished their modules (classes, units, whatever),
>    it is your job to integrate these modules and see whether they
>    work together as expected. If they don't, improve your specs and
>    tests and give the code back to the devs for another iteration.
>
> I favor the second approach, especially as there are tools available
> to help you and it is safer against reverse-engineering.

Both of these approaches are going to involve a lot of overhead (the
second more so that the first).  I would _guess_ than approach 2 will
add at least 50-100% overhead.  IOW, there's a pretty good chance that
writing the whole thing yourself would take less of your time than
designing, specifying, coordinating, integrating, testing and managing
approach 2.

I've seen it happen more than once when somebody decided to outsource
software development.  The in-house hours spent specifying, testing,
coordinating were more than it would have taken to just write the
program in-house.  I've seen than happen even when there were no
language or timezone barriers.  Throw in a 10-hour time difference and
a language barrier, and it's a minor miracle if the project ever gets
finished (even at twice the in-house cost of doing it).

-- 
Grant (the other one)

[gentoo-user] Re: {OT} Deliberately obfuscating my code

[Grant Edwards]

On 2010-11-09, Mark Knecht <markknecht@gmail.com> wrote:

>> I don't mind system administration but I don't want to be a programmer
>> any more. ??I'd like to hire programmers to work in the manner
>> described above. ??They would each work on modules and not know about
>> the system as a whole. ??How can something like this be implemented?
>
> Get ready to pay a lot more for the documentation and testing portions
> of your costs.

A lot more.

> If you write a clear spec

Anybody who thinks they can write a clear spec is deluded.

I've seen a _one_page_spec_ where the requirement was completely
re-stated three different ways (with examples!) -- and the programmers
in eastern Europe still mis-understood it.  Even after several days of
e-mails back and forth where the specification was re-explained in
several more ways, they still didn't understand.  After about a week
of daily e-mails back and forth, the light finally came on.

The implementation of that spec (adding a command to a protocol), took
15 lines on code on my end, and there's no way it could have taken any
more than that on the other end -- except they completely
misunderstood the requirement, and they simply couldn't understand
how what we were telling them was different than what they did.

-- 
Grant

Re: [gentoo-user] {OT} Deliberately obfuscating my code

[felix]

I haven't read the entire thread and I don't intend to.  The whole
concept is so bizarre that I could not read it without thinking of the
worst most evil bosses and environments I have worked on, and none of
them even come close.

It does remind me a bit of what I have read about "computers" back in
the 1930s, and especially on the atom bomb projects.  There would be a
project leader who would have to break some formula down into little
bitty steps which could be famed out to people running calculating
machines.  There would be a page of steps.  The first few numbers
would be filled in; each computer (being a human at this time) would
follow one specific line, say 17 being the sum of 10 and 6, and pass
the sheet on to someone else.  Presumably hard problems had many
pages, and someone would copy final numbers from one page to beginning
numbers on another page.

Not only did the steps have to be simple, they had to parallelize as
much as possible, so multiple sheets could start at once, only coming
together for the final calculations.

But what really made it fascinating was that for anything secret,
whether the atom bomb or mere commercial trade secrets, one of the
goals was to make sure that no one who worked on any single sheet
could have any idea of the overall project.  You never put units on a
sheet, never used familiar constants (5280 feet per mile), never ever
ever let anyone have any idea what they were doing other than
repeating line 6 + line 10 yields line 17.  I would imagine that if
you wanted to multiple miles by 5280 to get feet, you could split it
into two steps on different sheets; one multiplied by 264, the other
by 20, but probably more obfuscated.

That is what Grant wants here, and it requires that the people he hire
be mere mechanical monkeys.  Anyone with any intelligence will run
away from such a project faster than kryptonite diarrhea thru Superman.

Grant, you need to stop being paranoid.  I am surprised you even
worked up the courage to let slip on here, in public, that you even
have a sooper dooper sekrit project.

-- 
            ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
     Felix Finch: scarecrow repairman & rocket surgeon / felix@crowfix.com
  GPG = E987 4493 C860 246C 3B1E  6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o

Re: [gentoo-user] Re: {OT} Deliberately obfuscating my code

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 2241 bytes --]

Am 10.11.2010 06:56, schrieb Grant Edwards:
> On 2010-11-09, Florian Philipp <lists@f_philipp.fastmail.net> wrote:
> 
>> Well, there are two ways to go here:
> 
>> 1. Modularize what you have. Give every developer only the source he
>>    is supposed to work on and binary interfaces (libs + header files
>>    for C/C++) and documentation for everything else.
>>
>>    Then the devs will be able to run the software but no one will
>>    have all the source code.
>>
>> 2. Do not give working code to anyone. Define specs, test cases,
>>    prototypes and mock-ups. Then tell your devs to develop against these.
>>
>>    When they have finished their modules (classes, units, whatever),
>>    it is your job to integrate these modules and see whether they
>>    work together as expected. If they don't, improve your specs and
>>    tests and give the code back to the devs for another iteration.
>>
>> I favor the second approach, especially as there are tools available
>> to help you and it is safer against reverse-engineering.
> 
> Both of these approaches are going to involve a lot of overhead (the
> second more so that the first).  I would _guess_ than approach 2 will
> add at least 50-100% overhead.  IOW, there's a pretty good chance that
> writing the whole thing yourself would take less of your time than
> designing, specifying, coordinating, integrating, testing and managing
> approach 2.
[...]

Sure. But it will be fun! ;)
... Just kidding. Unless specifications, inline interface documentation
(doxygen, javadoc) and unit tests were already planned or even done
(kudos if you actually do this while developing), you are probably right
concerning the overhead.

Of course it all depends on your development environment. When you get
into the embedded, real-time, high-performance, high-security or
high-redundancy realm, specifications etc. tend to become less overhead
in comparison to actual coding and algorithmic effort. There are reasons
why in some environments it is even affordable to create two independent
implementations and then choose the better one.

I highly doubt that we are actually talking about such software here,
though.

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] {OT} Deliberately obfuscating my code

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 2163 bytes --]

Am 10.11.2010 17:44, schrieb felix@crowfix.com:
> I haven't read the entire thread and I don't intend to.  The whole
> concept is so bizarre that I could not read it without thinking of the
> worst most evil bosses and environments I have worked on, and none of
> them even come close.
> 
> It does remind me a bit of what I have read about "computers" back in
> the 1930s, and especially on the atom bomb projects.  There would be a
> project leader who would have to break some formula down into little
> bitty steps which could be famed out to people running calculating
> machines.  There would be a page of steps.  The first few numbers
> would be filled in; each computer (being a human at this time) would
> follow one specific line, say 17 being the sum of 10 and 6, and pass
> the sheet on to someone else.  Presumably hard problems had many
> pages, and someone would copy final numbers from one page to beginning
> numbers on another page.
> 
> Not only did the steps have to be simple, they had to parallelize as
> much as possible, so multiple sheets could start at once, only coming
> together for the final calculations.
> 
> But what really made it fascinating was that for anything secret,
> whether the atom bomb or mere commercial trade secrets, one of the
> goals was to make sure that no one who worked on any single sheet
> could have any idea of the overall project.  You never put units on a
> sheet, never used familiar constants (5280 feet per mile), never ever
> ever let anyone have any idea what they were doing other than
> repeating line 6 + line 10 yields line 17.  I would imagine that if
> you wanted to multiple miles by 5280 to get feet, you could split it
> into two steps on different sheets; one multiplied by 264, the other
> by 20, but probably more obfuscated.
> 


That reminds me of its modern successor: Secure computation [1]

In a nutshell: Do arbitrary computations with data from different
organizations who do not want to share their source data with each
other. They only want to share the final result.

[1] http://en.wikipedia.org/wiki/Secure_multi-party_computation


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] {OT} Deliberately obfuscating my code

[Grant]

> Grant, you need to stop being paranoid.  I am surprised you even
> worked up the courage to let slip on here, in public, that you even
> have a sooper dooper sekrit project.

This seems to be the general consensus.  You see, I don't have a
computer science degree and about 75% of what I know about Linux I
learned on this list.  Apparently this idea of mine is not a good one.

The "sekrit" isn't really a secret, it's just a mature piece of
ordinary software.  Most if not all of you wouldn't be interested in
receiving it for free, but people in the right industry would like to
have it and I'd like to keep it for myself.  Surely there is room for
private software even in an open source world.

So it's either trust your coders or do it yourself?  My budget is
small and the coders I can afford are outside of the US.  I'd be
working with them via chat, email, or phone.  Should I feel OK about
turning my source over to them?  Should I only hire coders I can sit
in the same room with?

- Grant

[gentoo-user] Re: {OT} Deliberately obfuscating my code

[Grant Edwards]

On 2010-11-11, Grant <emailgrant@gmail.com> wrote:
>> Grant, you need to stop being paranoid. ?I am surprised you even
>> worked up the courage to let slip on here, in public, that you even
>> have a sooper dooper sekrit project.
>
> This seems to be the general consensus.  You see, I don't have a
> computer science degree and about 75% of what I know about Linux I
> learned on this list.  Apparently this idea of mine is not a good
> one.
>
> The "sekrit" isn't really a secret, it's just a mature piece of
> ordinary software.  Most if not all of you wouldn't be interested in
> receiving it for free, but people in the right industry would like to
> have it and I'd like to keep it for myself.  Surely there is room for
> private software even in an open source world.
>
> So it's either trust your coders or do it yourself?

Yup, pretty much.

> My budget is small and the coders I can afford are outside of the US.
> I'd be working with them via chat, email, or phone.  Should I feel OK
> about turning my source over to them?

Yes, if you deal with reputable companies or individuals who's
references you can verify.  If you're dealing with random individuals,
then maybe.

> Should I only hire coders I can sit in the same room with?

That will probably work best, but it will cost more.

Have you ever managed a programming team before?

-- 
Grant Edwards               grant.b.edwards        Yow! Am I in Milwaukee?
                                  at               
                              gmail.com            

Re: [gentoo-user] Re: {OT} Deliberately obfuscating my code

[Grant]

>>> Grant, you need to stop being paranoid. ?I am surprised you even
>>> worked up the courage to let slip on here, in public, that you even
>>> have a sooper dooper sekrit project.
>>
>> This seems to be the general consensus.  You see, I don't have a
>> computer science degree and about 75% of what I know about Linux I
>> learned on this list.  Apparently this idea of mine is not a good
>> one.
>>
>> The "sekrit" isn't really a secret, it's just a mature piece of
>> ordinary software.  Most if not all of you wouldn't be interested in
>> receiving it for free, but people in the right industry would like to
>> have it and I'd like to keep it for myself.  Surely there is room for
>> private software even in an open source world.
>>
>> So it's either trust your coders or do it yourself?
>
> Yup, pretty much.
>
>> My budget is small and the coders I can afford are outside of the US.
>> I'd be working with them via chat, email, or phone.  Should I feel OK
>> about turning my source over to them?
>
> Yes, if you deal with reputable companies or individuals who's
> references you can verify.  If you're dealing with random individuals,
> then maybe.
>
>> Should I only hire coders I can sit in the same room with?
>
> That will probably work best, but it will cost more.
>
> Have you ever managed a programming team before?

I haven't.  Any pointers?

- Grant

Re: [gentoo-user] {OT} Deliberately obfuscating my code

[Paul Hartman]

On Wed, Nov 10, 2010 at 6:34 PM, Grant <emailgrant@gmail.com> wrote:
>> Grant, you need to stop being paranoid.  I am surprised you even
>> worked up the courage to let slip on here, in public, that you even
>> have a sooper dooper sekrit project.
>
> This seems to be the general consensus.  You see, I don't have a
> computer science degree and about 75% of what I know about Linux I
> learned on this list.  Apparently this idea of mine is not a good one.

I don't think it's a bad idea, I can certainly understand your fears.
It may not be a realistic idea to implement, but it's certainly
understandable. Since we have no idea about the nature of your program
or the work that you're hoping to have done it is hard to give any
kind of specific advice. If you're hiring someone to work on one
specific part, you may be able to split that off from the main program
(for example a UI designer or someone writing a file import function,
or whatever). If you're looking for someone to basically take over the
whole project then it'll probably be impossible to hide anything from
them.

I think any kind of owner/manager of a small business who is growing
to the point where 1 guy can't do it all himself anymore has these
same concerns and reservations about letting go some of the control
and trusting another worker to take over a part of it without stealing
or ruining it. Ultimately, I think it comes down to finding someone
that you feel comfortable with and whom you feel is trustworthy. Of
course, check references, check feedback online, etc.

> So it's either trust your coders or do it yourself?  My budget is
> small and the coders I can afford are outside of the US.  I'd be
> working with them via chat, email, or phone.  Should I feel OK about
> turning my source over to them?  Should I only hire coders I can sit
> in the same room with?

Workers sitting in the same room as you can steal your company data
just the same.

I think the odds are in your favor, most people in the world are
honest and hard-working.

Good luck! :)

Re: [gentoo-user] Re: {OT} Deliberately obfuscating my code

[Peter Humphrey]

On Thursday 11 November 2010 17:33:25 Grant wrote:

> > Have you ever managed a programming team before?
> 
> I haven't.  Any pointers?

Good grief! The literature is full of weighty tomes on the subject, and 
copious advice is available in multiple news groups - and no doubt e-
mail lists too by now.

This is not an enterprise to be embarked on lightly. People spend their 
entire working lives at it and are still learning at the end of it 
(counting project management as part of the subject).

-- 
Rgds
Peter.          Linux Counter 5290, 1994-04-23.

[gentoo-user] Re: {OT} Deliberately obfuscating my code

[Grant Edwards]

On 2010-11-11, Grant <emailgrant@gmail.com> wrote:

>>> Should I only hire coders I can sit in the same room with?
>>
>> That will probably work best, but it will cost more.
>>
>> Have you ever managed a programming team before?
>
> I haven't.  Any pointers?

Not really.  Just be prepared for the programmers to misunderstand the
specification at every turn.  And once they've understood the spec, be
prepared for them to just plain screw up the implementation.

Unless you're hiring programmers who have a very good understanding of
the problem space, they're not going to understand the spec.  They are
going to do the wrong thing in the first several iterations before
they finally understand what it is that you want.  Some of the "wrong
things" will violate the spec. Many won't.

It's like hiring to build a house carpenters who've never seen a
house, never heard of a house, and have no idea what a house is for.

The first version will look like the drawings, but they'll have
misunderstood the dimensions and the whole thing will be 3 feet high
an 5 feet wide.  When you ask how people are going to fit in that,
they're going to look at you completely dumbfounded because you never
told them people had to fit inside -- how were they supposed to know
that?

The second version will be the right size, but the doors and windows
won't open -- they'll be built solidly into the structure on all four
sides.  When you ask why, they'll say "it's a lot stronger that way!"
You'll say "but I told you people had to fit inside".  They'll reply
that people _do_ fit inside.  You'll ask how are they going to _get_
inside.  They'll say "the specification doesn't say that doors and
windows have to open, so we implemented it the strongest way, and now
people fit inside just like you said."

[Repeat until you're out of time and/or money.]

The only advice I've got is to do things in increments as small as
possible.  Don't do "big bang" integration.  Make sure there is a
runnable testable program after the first week of development. Maybe
it doesn't implement any significant features, but you must have
something runnable and testable at all times.  Otherwise, you can get
too far down the wrong road before you finally figure out that either
a) what you specified isn't going to work, or b) they didn't
understand the specification at all.

-- 
Grant Edwards               grant.b.edwards        Yow! Actually, what I'd
                                  at               like is a little toy
                              gmail.com            spaceship!!

[gentoo-user] Re: {OT} Deliberately obfuscating my code

[Nikos Chantziaras]

On 11/09/2010 06:52 AM, Grant wrote:
> This is OT, but you guys have proven extremely insightful over the
> years and I would love to hear what you think.
>
> I've been working on a particular software project for a long time.
> I'd like to hire a team of developers to take over the project, but I
> consider the code to be valuable and I'd like to keep the whole of it
> secure, even from my own developers.  I was thinking I could do this
> by using some technique to obfuscate the true intention of the code
> modules.  Maybe a recorded series of search/replaces for variable
> names which are reversed once code editing is complete?  Has any
> software been made available to aid in an endeavor like this?

Maybe you can find something useful by reading and following the links in:

http://en.wikipedia.org/wiki/Obfuscated_code

Re: [gentoo-user] {OT} Deliberately obfuscating my code

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

Am 11.11.2010 01:34, schrieb Grant:
[...]
> So it's either trust your coders or do it yourself?  My budget is
> small and the coders I can afford are outside of the US.  I'd be
> working with them via chat, email, or phone.  Should I feel OK about
> turning my source over to them?  Should I only hire coders I can sit
> in the same room with?

Can't you just hire a local CS or IT student? They're cheap and you can
have regular meetings with them to discuss issues.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] Re: {OT} Deliberately obfuscating my code

[Grant]

>>>> Should I only hire coders I can sit in the same room with?
>>>
>>> That will probably work best, but it will cost more.
>>>
>>> Have you ever managed a programming team before?
>>
>> I haven't.  Any pointers?
>
> Not really.  Just be prepared for the programmers to misunderstand the
> specification at every turn.  And once they've understood the spec, be
> prepared for them to just plain screw up the implementation.
>
> Unless you're hiring programmers who have a very good understanding of
> the problem space, they're not going to understand the spec.  They are
> going to do the wrong thing in the first several iterations before
> they finally understand what it is that you want.  Some of the "wrong
> things" will violate the spec. Many won't.
>
> It's like hiring to build a house carpenters who've never seen a
> house, never heard of a house, and have no idea what a house is for.
>
> The first version will look like the drawings, but they'll have
> misunderstood the dimensions and the whole thing will be 3 feet high
> an 5 feet wide.  When you ask how people are going to fit in that,
> they're going to look at you completely dumbfounded because you never
> told them people had to fit inside -- how were they supposed to know
> that?
>
> The second version will be the right size, but the doors and windows
> won't open -- they'll be built solidly into the structure on all four
> sides.  When you ask why, they'll say "it's a lot stronger that way!"
> You'll say "but I told you people had to fit inside".  They'll reply
> that people _do_ fit inside.  You'll ask how are they going to _get_
> inside.  They'll say "the specification doesn't say that doors and
> windows have to open, so we implemented it the strongest way, and now
> people fit inside just like you said."
>
> [Repeat until you're out of time and/or money.]
>
> The only advice I've got is to do things in increments as small as
> possible.  Don't do "big bang" integration.  Make sure there is a
> runnable testable program after the first week of development. Maybe
> it doesn't implement any significant features, but you must have
> something runnable and testable at all times.  Otherwise, you can get
> too far down the wrong road before you finally figure out that either
> a) what you specified isn't going to work, or b) they didn't
> understand the specification at all.

Great advice from everyone, thank you.  By hiring coders, the
intention is to save myself time and effort but it sounds like I would
only be replacing one problem with another.  I'm really not sure how
to proceed but you guys have saved me from hurling myself into
something I didn't understand.

Trying to figure it out,
Grant

[gentoo-user] Re: {OT} Deliberately obfuscating my code

[Grant Edwards]

On 2010-11-13, Grant <emailgrant@gmail.com> wrote:

>>>> Have you ever managed a programming team before?
>>>
>>> I haven't. ?Any pointers?
>>
>> Not really. ?Just be prepared for the programmers to misunderstand the
>> specification at every turn. ?And once they've understood the spec, be
>> prepared for them to just plain screw up the implementation.

>> [elided carpentry allegory]

> Great advice from everyone, thank you.  By hiring coders, the
> intention is to save myself time and effort but it sounds like I would
> only be replacing one problem with another.

I hope I wasn't too discouraging, but you're definitely replacing one
problem with another.

The questions are:

 1) The relative sizes of the problems?

 2) How much your time is worth?

 3) Do you prefer spec-writing and project management or writing code?

For me, I'd probably rather take a week off my without pay from my day
jobs and write the code myself rather than pay somebody else $2000 to
do it.  [And that's assuming I could find somebody competent to work
for $50/hour.]

> I'm really not sure how to proceed but you guys have saved me from
> hurling myself into something I didn't understand.

I don't know what language you're using, but my only other
recommendation might be to consider using a high level language like
Python instead of C.  Developing a large application in Python instead
of C can save huge amounts of time.  My guess would be that on average
Python development takes about 25% of the time that C would take.

-- 
Grant

Re: [gentoo-user] Re: {OT} Deliberately obfuscating my code

[Grant]

>> Great advice from everyone, thank you.  By hiring coders, the
>> intention is to save myself time and effort but it sounds like I would
>> only be replacing one problem with another.
>
> I hope I wasn't too discouraging, but you're definitely replacing one
> problem with another.

I don't need encouragement, I need advice. :)

> The questions are:
>
>  1) The relative sizes of the problems?

No problems really.  It's just kind of a never-ending project that
could go in many directions.  The more coders working on the project
the more directions can be explored.

>  2) How much your time is worth?

Even if I spend 80 hours a week coding, the rate at which I code will
be the project's limiting factor.  I'd love to fix the bottleneck and
make the limiting factor the number of coders I can hire.

>  3) Do you prefer spec-writing and project management or writing code?

If the choice is between 1 hour coding and 1 hour writing and managing
in order to accomplish 1 hour of coding, I'll code.

> For me, I'd probably rather take a week off my without pay from my day
> jobs and write the code myself rather than pay somebody else $2000 to
> do it.  [And that's assuming I could find somebody competent to work
> for $50/hour.]
>
>> I'm really not sure how to proceed but you guys have saved me from
>> hurling myself into something I didn't understand.
>
> I don't know what language you're using, but my only other
> recommendation might be to consider using a high level language like
> Python instead of C.  Developing a large application in Python instead
> of C can save huge amounts of time.  My guess would be that on average
> Python development takes about 25% of the time that C would take.

That's great advice but the language is already very high level.  I
guess I'm trying to take it one level higher at which point it becomes
English. :)

- Grant

[gentoo-user] Re: {OT} Deliberately obfuscating my code

[Francesco Talamona]

On Saturday 13 November 2010, Grant wrote:
> I don't need encouragement, I need advice. :)

In the end it isn't a technical problem, it is a question of trust.

> > The questions are:
> > 
> >  1) The relative sizes of the problems?
> 
> No problems really.  It's just kind of a never-ending project that
> could go in many directions.  The more coders working on the project
> the more directions can be explored.
> 
> >  2) How much your time is worth?
> 
> Even if I spend 80 hours a week coding, the rate at which I code will
> be the project's limiting factor.  I'd love to fix the bottleneck and
> make the limiting factor the number of coders I can hire.

So your project would definitely benefit if you hire someone else.

> >  3) Do you prefer spec-writing and project management or writing
> > code?
> 
> If the choice is between 1 hour coding and 1 hour writing and
> managing in order to accomplish 1 hour of coding, I'll code.

If it's 1:1 either your ability to make yourself clear or the coder's 
proficiency, or both, are incomplete.

You should try to give a little part of the project, a portion that 
doesn't require the knowledge of the entire code. 
Work with just one or two developer and see. 
You have to build trust. You'll have to trust them and believe that your 
project will benefit, they'll have to trust in you.

HTH
	Francesco
-- 
Linux Version 2.6.36-gentoo-r1, Compiled #3 SMP PREEMPT Sat Nov 13 
23:34:14 CET 2010
Two 1GHz AMD Athlon 64 Processors, 4GB RAM, 4021.84 Bogomips Total
aemaeth

Re: [gentoo-user] Re: {OT} Deliberately obfuscating my code

[Enrico Weigelt]

* Grant Edwards <grant.b.edwards@gmail.com> wrote:

> The only advice I've got is to do things in increments as small as
> possible.  Don't do "big bang" integration.  Make sure there is a
> runnable testable program after the first week of development. Maybe
> it doesn't implement any significant features, but you must have
> something runnable and testable at all times.  Otherwise, you can get
> too far down the wrong road before you finally figure out that either
> a) what you specified isn't going to work, or b) they didn't
> understand the specification at all.

ACK. And another important tip: split your big problem into smaller
and smaller generic sub-problems. Then you'll have great chance to
reuse an existing package or let some contractor develop/adapt one
without telling him about your actual project.

Movie tip: "The Cube" ;-)


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [gentoo-user] Re: {OT} Deliberately obfuscating my code

[Grant]

>> The only advice I've got is to do things in increments as small as
>> possible.  Don't do "big bang" integration.  Make sure there is a
>> runnable testable program after the first week of development. Maybe
>> it doesn't implement any significant features, but you must have
>> something runnable and testable at all times.  Otherwise, you can get
>> too far down the wrong road before you finally figure out that either
>> a) what you specified isn't going to work, or b) they didn't
>> understand the specification at all.
>
> ACK. And another important tip: split your big problem into smaller
> and smaller generic sub-problems. Then you'll have great chance to
> reuse an existing package or let some contractor develop/adapt one
> without telling him about your actual project.
>
> Movie tip: "The Cube" ;-)

That's a good movie and a very appropriate recommendation.  I think a
lot of people are saying that when it comes time to execute a plan
like that, it gets fouled up because the spec is hard to write and
it's hard for coders to test what they've written.

- Grant