>> Firebird itself could reasonably claim security ("we are using
>> as-yet-unbroken AES, with the key supplied by the user at connection
>> time")
>
> Will you hardcode the key into your executable? Do you think it's really
> robust?

It's certainly more robust than no encryption whatsoever.

Besides, you could as well argue that I could write a full export capability
into my application and that "encryption wouldn't prevent data leaks then,
either". It is not Firebird's place to argue about this - Firebird should
(IMHO) provide the necessary functionality and then let the developer worry
about the key storage. (You could compare it to data protection on today's
media. Hard drives are notoriously unreliable, but Firebird should not
"solve" this issue by e.g. forcing user to backup every day and refuse to
function if he didn't. Firebird should (and does) provide tools for creating
and restoring backups and tools for fixing corrupted databases, and let the
user/developer handle how, if and how often the backups are made)

> I agree that what you propose can be done easily but it would satisfy
> the fbembed users only. Those who has a standalone FB installation would
> prefer a server-side centralized key management plus network protocol
> encryption.

_This_ is the part which is handled by external applications (various VPN,
Zebedee etc.) well enough, so I don't see much reason for Firebird to
duplicate it. The actual encryption part is not handled by external
application, despite the claims to the contrary and thus would be nice if
Firebird stepped in. That is my whole point.

Pepak