Let me see if I can pull together some threads here.

> Jim wrote:
> Steve, could you take a few minutes to describe exactly what the
> problem is, what the requirements for a solution might be, what
> VARs are currently doing with InterBase, and if you happen to
> know, what VARs are doing about the problem with other database
> systems?

First, lets make a clear distinction between two scenarios.

Scenario 1: you're running the DB inhouse, and have full access to hardware,
OS, client application (maybe with sources because you wrote it), etc.

Scenario 2: you're either a VAR or into the shrink-wrapped business. Your
solution is sold through a chain of intermediaries. You don't even know who
the end-customer is, let alone what hardware, OS, configuration, other
client apps, other DBs might be at the end-customer site.

Scenario 1 is not a problem, because you have everything under control. So
lets drop that one, and focus on scenario 2.

In scenario 2 there are at least two kinds of problems: (1) you want to
prevent competitors to reverse-engineer your application, and avoid
revealing your data model, SPs, and other valueable information; (2) you
want to ensure the end-customer that ~his~ data is relatively safe. The
end-customer might be concerned about security, confidentiality and privacy
issues.

Today there's little that you can do, because the cost of getting to .GDB
information is zero. (The similarity was leaving the door open for neighbour
teens.)

> Tim wrote:
> Presuming that the need to keep data secure is a legitimate one we ought

to

> work towards a solution.

That's exactly the issue I'm trying to raise.

> Jan wrote:
> However, just because cryptography is used on the disk does not make is
> secure, nor does it mean that "due diligence" has been applied. It just
> means the problem has been obscured and people are lulled into a false

sense

> of security, at the expense of wasted developer and processor time. It
> would take a semi-competent developer a few seconds to recover the key

using

> a debugger and the source to Interbase, a little while longer if the

source

> wasn't available. You could probably even pick up the key using a packet
> sniffer and not even need to be on the same machine.
> [...] But whether the combined brainpower could be bothered or not is
> another question, and I still haven't seen a precise requirement stated.

Jan, what you say is true.

The problem is that 99.999% of customers (i.e. not developers,
semi-competent or otherwise) do not know this. And ~they~ don't bother to
know. They look at a feature-matrix, and see that IB has something missing
when compared to other products - even toys like Access. There are few
semi-competent developers (let alone good ones) around. Incompetent
customers outnumber developers any day. Unfortunately for developers,
customers are the ones who pay the bill.

Even a solution that lulls into a false sense of security could be good
enough (no matter how much it stinks). It raises the bar. Today the cost to
get into a GDB is zero. Even an incompetent customer can do it. So raising
the bar in such way that you need at least a semi-competent, or even
incompetent, developer to do so, would still be progress compared to the
current situation. This would exclude some 96-98% of all people that
currently can get into a GDB today. The remaing 2-4% are akin to the
professional burglars that would get into your house even if you lock it up
twice.

In terms of precise requirements, let us address problems (1) and (2) stated
above; (2) being more urgent than (1).

Cheers

-ST