|Subject||Re: [firebird-support] Re: Undocumented internal encrypt/decrypt in FB|
>>>> In my case, I'm not trying to prevent some agency of aHi Geoff - I agree with you - technically.
>>>> national government from reading my stuff, I'd just like to
>>>> make it a little harder for an unscrupulous competitor to
>>>> make off with my specialized database unbeknownst to me.
>>>> Swapping the security database is trivial and well
>>>> documented (moving the stone), but most wouldn't bother with
>>>> DLLs and hacking, because the return isn't worth the effort
>>>> they'd have to exert and because it's apt to leave tracks
>>>> and if they're caught they're guilty of a serious Federal
>>>> (US, anyway) crime. Without the "cheap padlock" I'm likely
>>>> down to arguing a civil suit about a copyright violation.
>>> I have to agree completely with everything you wrote.
>> I would like to add my voice to this view also.
> It would be really nice if some simple hooks could be used to
> achieve a worthwhile level of deterrent, but it is not likely.
> If we are talking about conventional theft then you already
> have real locks on the doors to the office. Firebird already
> has reasonable security against remote attack. What we have
> been discussing is how to protect the database from attack by
> those that do have direct access to the server, and so can
> copy the database directly if desired - and if that is possible
> you have to assume that they can do pretty much anything they
> want on the server. The client to which you have supplied the
> software is in this position, as is anyone that that client
> allows to access the server.
Without wanting to get drawn in too far - I was responding to the
introduction of non-technical reasons for having some facility. I also
agree that providing false-expectations is a *significant* negative. So I
would frame consideration in terms of - 'OK there is no silver bullet -
now what is the balance between IP law requiring "reasonable efforts to
protect" and loading a gun to shoot your friends in the foot'.
We don't face this issue - we consider Client Data theirs - incl DB schema.