[sclug] Personalised web content filtering

Neil Haughton haughtonomous at googlemail.com
Tue Jun 21 18:10:37 UTC 2011


Stuart,

Further to my previous.

Obviously, developers have to have access to the source code. That is not
the point. The point is to prevent them making off with it - or at least to
make it as difficult as possible. They can work on it at work. They can't
take it anywhere else, or it's too difficult for them to bother. That's my
aim (or I should say, my employer's aim).

By the way there's nothing patentable in the code, so that isn't an option
even if it did offer some legal protection in various nefarious corners of
the world.

I mentioned your thoughts on not understanding their own business model.
They have asked me to thank you. :-)

Neil.


On 21 June 2011 09:31, Stuart Ward <stuart.ward at bcs.org> wrote:

> Neil
>
> Precisely my point. You cant prevent that!! All you can do is make
> sure you will know it has happened and who did it.
>
> I think there is something seriously wrong in your premise that you
> CAN prevent a data breach by an internal malicious entity. You CANNOT.
> This is not to say you should not have reasonable protections in
> place, but the sort of protections that you are talking about would
> prevent your developers from effectively doing their job. If you still
> need developers to work on the code, then they must have access to it
> so so could abscond with it.
>
> I also think that your company misunderstands their own business
> model. If the program was breached, this would not mean that all your
> sales targets would then start using the exposed version of your
> software. It may mean that a bunch of people who would never have
> bought your software will start using it, but these are not lost
> sales, they would never have been sales.
>
> Managed correctly this could be the best marketing you ever have, in
> that as these users start to grow and need support they would be
> inclined to buy support from you. This is how the Open Source business
> works, you sell support not the product, and in return you get a lot
> more usage, bug reports, feedback etc for free.
>
> No matter how good your implementation is software patents are not
> valid in Europe, and so anyone is free to re-implement your system and
> compete.
>
> Stuart
>
>
>
> -- Stuart Ward M +44 7782325143
>
>
>
> On 21 June 2011 08:49, Neil Haughton <haughtonomous at googlemail.com> wrote:
> > Stuart,
> >
> > Thanks for the idea, although if a developer absconds with the source
> code
> > logging would probably turn out to be akin to shutting the door after the
> > horse has bolted. We'd know what had been done and who had dunnit, but if
> he
> > was on a plane by then that would be cold comfort. Neither would a code
> of
> > conduct be much good. The deliberate thief knows he is doing wrong and
> isn't
> > going to be deterred by a stern piece of paper.
> >
> > Neil.
> >
> >
> >
> >
> > On 20 June 2011 09:39, Stuart Ward <stuart.ward at bcs.org> wrote:
> >>
> >> Neil
> >>
> >> A technical solution to this is not possible if you also want to allow
> >> your people to have access to the source code for development.
> >>
> >> But what you should do on a technical level is ensure that you are
> >> logging events from your source repository, web proxies, Firewalls,
> >> emails etc. That this logging is robust and everyone is aware that
> >> these events are being logged. The rest of the problem is to make sure
> >> that all the developers are aware of their responsibilities, a written
> >> down code of conduct, internet use policy is essential.
> >>
> >> Any technical means that you use to lock down internet access and be
> >> overly restrictive on filtering will just be seen as frustrating
> >> developers in their role.
> >>
> >> Stuart
> >>
> >>
> >> -- Stuart Ward M +44 7782325143
> >
> >
>



More information about the Sclug mailing list