[sclug] Personalised web content filtering

Neil Haughton haughtonomous at googlemail.com
Tue Jun 21 18:01:13 UTC 2011


Stuart,

Thanks for your thoughts, but you are misunderstanding what I have said
several times - I am not expecting to be able to prevent anything (I'm not
stupid). I'm seeking to find sufficiently robust technical deterrent to
reduce the risk to an acceptable level - vanishingly small in practice, if
that is possible.

Let me elaborate with an analogy. You CANNOT prevent an intruder from
gaining access to your home. You can shrug your shoulders and say, well it
can't be prevented so I shall save a bob or two by not fitting proper doors
or windows because there's no point in doing anything more, or you can say
I'm going to do my darnedness to make it jolly difficult to get unauthorised
access so that most potential intruders will not bother, by fitting good
doors, windows, strong locks on same, have a couple of nasty dogs in the
garden, dig a moat, put up a high wall with razor wire atop (I've seen this
done), hire armed guards and so on. At some point you will have done enough
to reduce the risk of an intruder to a very small level, and you will feel
safe. Are you actually absolutely safe? Of course not, but you are
acceptably safe.

Okay, I'm talking about keeping stuff in rather than out, but the principle
applies. So that's all I hoped to achieve.

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