> Sure, that does prevent a competitor from reading our data.  But it
> doesn't prevent user tampering nor does it allow me to use the database to
> track licensing (as it can be tampered with).  There's no way currently
> around that then?

> On Monday, 30 April 2012 14:19:02 UTC+1, Oren Eini wrote:

>> Sean,
>> Encrypt the data, that should take you pretty far in only allowing access
>> from your own software.

>> On Mon, Apr 30, 2012 at 4:08 PM, Sean Kearon wrote:

>> The end users are electrical engineers as private engineers or companies.
>>>  The product is licensed to the PC itself and we do eperience a fair amount
>>> of end user tampering.  Part of the licensing and machine locking is
>>> tracked in the database itself, so it['s important that they cannot remove
>>> this.

>>> The other motivation is to prevent competitors from accessing our data.
>>>  To be able to upgrade from our data is an attractive selling point and I'm
>>> a small guy in a market where there are some very established players who
>>> have far more resources that I do.  That precise scenario happened to me
>>> about 10 years ago now, and it hurt!

>>> The encryption key is shipped, yes, but it's obfuscated.  Sure, you can
>>> never totally prevent access, but to raise the bar to the level that the
>>> attacker has to crack commercial obfuscation is good enough for our needs.
>>>  At least I then have legal recourse if that were a competitor.

>>> So, is there any way currently or in the fairly near future to prevent
>>> user tampering?  It sounds from your responses that there isn't, which
>>> would be a shame.

>>> On Monday, 30 April 2012 10:45:39 UTC+1, Oren Eini wrote:

>>>> At the end, it is a file on his machine.
>>>> Sure, you can encrypt that, but the encryption key also has to be on
>>>> the machine at some point, so that is pretty meaningless.

>>>> Who is the user? What is the data? How important is it to prevent
>>>> tampering? Are you likely to be dealing with devs / hackers or with
>>>> standard users?

>>>> On Mon, Apr 30, 2012 at 12:39 PM, Sean Kearon wrote:

>>>> Thanks, I'll look for Tobi or Justin's code.

>>>>> As for the user accessing the data - so there is no way that I can
>>>>> prevent the user from editing or deleting documents whatever lengths I go
>>>>> to?

>>>>> On Monday, 30 April 2012 10:34:19 UTC+1, Oren Eini wrote:

>>>>>> Sean,
>>>>>> If the data is on the user's computer, he got it.
>>>>>> Oh, you can make it awkward to get it, but they can do that.
>>>>>> There is literally no way to hide that if your are running on his
>>>>>> machine.

>>>>>> I think that there is some code around (Tobi or Justin wrote it, I
>>>>>> believe) that will work like the smuggler for the embedded version.

>>>>>> On Mon, Apr 30, 2012 at 12:31 PM, Sean Kearon  wrote:

>>>>>> Oren

>>>>>>> I'm going to be running on the user's desktop and I don't want to
>>>>>>> have the embedded http server running so that I can lock down the system so
>>>>>>> that users can't tamper with the data in any way.

>>>>>>> Is there any other way I can use to export documents and attachments?

>>>>>>> Also, I have just realised that even if I encrypt the documents in
>>>>>>> the database, the user could download and run Studio against the data.  Is
>>>>>>> there any way currently of preventing this, such as whole database
>>>>>>> encryption?  If not, will that be available with the encryption features in
>>>>>>> 1.2?

>>>>>>> Thanks

>>>>>>> Sean

>>>>>>> On Monday, 30 April 2012 05:04:53 UTC+1, Oren Eini wrote:

>>>>>>>> You cannot export from an embedded DB without enabling the embedded
>>>>>>>> http server.
>>>>>>>> Smuggler works over HTTP.