Why "carnivore" type systems can't be (entirely) open source

[Richard D G Cox]

"Owen Lewis" <oml@eloka.demon.co.uk> appears to have said:
> PBXes can be as full of security holes as a Gruyere cheese.  It is not
> possible that these are there without the manufacturers' knowledge.

Actually it is possible: at least initially.  But unlike computer software
there is no "Bugtraq" for comms system software.  So while anyone can find
a security or other issue with, say, a PABX (and I've found plenty in my 
time!) it is customary for the supplier to practise plausible denial and
simply refuse to discuss it.  Their marketing people will, of course, tell
you that the product is "Approved" and that, therefore, there cannot be
anything wrong with it!  After that they stonewall.  The last thing (the
majority of them) want to do is to accept that a shortcoming even exists.

Once the product is in the marketplace, there is rarely any business case
for a fix (which customers would naturally expect to be free of charge)
although manufacturers often offer chargeable upgrades for new features.
The high cost of rolling out a fix is often blamed on the UK's archaic
approvals procedures but I'm not convinced that is as relevant today as
it used to be.  And there is little, if any return on such an investment,
simply because it is unusual for customers to make purchase decisions on 
the basis of a systems reputation: the majority of customers don't check.
(Clients of this and similar firms may have an advantage here but sadly
such clients do not yet form the majority of PABX purchasers in the UK!)

Even those customers who buy PABXs for more than one site will tend to
stay with a single manufacturer, despite shortcomings, simply because the
reliable operation of a multi-site voice network is often seen as needing
single-sourced equipment for proper operation - and manufactures often
lock customers in by ensuring that the facilities they need will only be
available if their kit is at both ends of the wire.  When configuring a
Meridian PABX, there is a setting to identify whether or not the public
exchange to which the PABX is connected, is a DMS (also made by Nortel!)
(And we get worked up about undocumented features in Windows.  Hah!)

Customer alliances - such as the CMA - used to be proactive in campaigning
for better security but their image these days appears to be more aligned
to MarComms than their membership.  Trading Standards and similar bodies
don't want to get involved because they have neither the internal skills
needed to pursue such an issue, nor the funding to hire in the necessary
expertise from outside.

> Neither should they be there.

Of course not.  But given that in many cases there are subsystems in PABXs
that the majority of people (even within the manufacturer) are not allowed
to know about, perhaps it's hardly surprising that debugging is difficult.
I expect most of you will know what I am referring to.

> Hear many complaints (present company excepted)? I don't.

I hear plenty of them - but perhaps that's hardly surprising!
And the same smokescreens prevent me from getting at the key
facts I need in order to try to resolve those complaints.

> Squidgygate was allegedly ETACS (NB FM) en claire earwigging. There
> are some grounds to think that it may have been rather more carefully
> stagemanaged than a casual intercept (i.e. the amateur earwigger was
> not intercepting the conversation in real time....)

Indeed so.  One of those grounds was that if it had been intercepted in
real time, only ONE side of the conversation should have been audible!

Ross had written:

>> I have a whole chapter on this in my book.

Well in that case the sooner we get it in the bookshops the better ...

Richard