Are there any downsides to using an encrypted database in DevonThink 3, apart from the possibility of losing the encryption key?
Does Spotlight search work on the content as well?
Is there anything else that does not work with encrypted databases, e.g. on the mobile DevonThink To Go, which would otherwise work with “normal” non-encrypted databases?
This would BTW be a great support / knowledge base article. I looked for such an explanation, but could not find anything.
Hi there 
There are a couple of threads on this general topic here in the forum. From my point of view, the answers are:
Downside: you will need to enter a password each time you open the database in DT3.
Neutral: Spotlight can still search the content if you want it to; but do you really want it to? The Spotlight index is not encrypted AFAIK, so whilst it might look as though you had protected your data by encrypting your database, it would be openly available in the Spotlight index.
Downside: if you forget your password you data is toast. Don’t forget that you could fall off your bicycle and not be able to remember your password afterwards, etc.
Neutral: DTTG will sync with any database you have on DT3, regardless of whether it is encrypted or not; the same caveat re. Spotlight is valid in DTTG too, though. To my knowledge, data associated with a specific app is not available to other apps on iOS, unless you specifically make it so, and stored encrypted. Another caveat: in DTTG data can be set to backup to iCloud or not to. Again, if data protection is necessary (and why else would you encrypt), you need to consider via which routes your data might disseminate regardless of encryption.
Upside: even if you use full disk encryption (File Vault) the additional encryption of your databases means that if you copy your database anywhere, it will remain encrypted. For example: once a month I copy my databases to WORM media; whilst I have no tools for setting up an encrypted WORM medium, my databases are already encrypted, so I’m safe. The same goes for backing up to a cloud provider - my databases never leave my Mac unencrypted, so I don’t have to trust the cloud provider to be encrypting properly (as much, anyway).
So, basically consider why you want to encrypt your databases, and don’t do so if you’re going to disseminate the contents anyhow. Encryption is less important on a Mac which you don’t share and which uses full disk encryption. It is more important if you are sharing the database files in any way (e.g. by backing them up).
Do wait for others to chime in here; my opinion on this is mine only - I am not a security expert, and I’m only reiterating what my considerations (and decisions) are, based on my use case.
All reasonable points. There is however the question of using cloud service providers. Do you trust Dropbox, for example, to be able to have access to your database? Personally, I encrypt the sync store but not the databases within it. Depends on your threat model, i.e. what worries you about who can access your data and where.
No.
(note I mentioned backup to a cloud provider, but did not mention sync to a cloud provider; thanks for your addition: database encryption is not in any way related to sync)
Your database isn’t stored in a sync location. It is raw, chunked, and optionally encrypted DEVONthink-specific data unsable only be DEVONthink and DEVONthink To Go. This is true regardless if you’re using an encrypted database or not.
So even if you didn’t trust Dropbox, they wouldn’t find much useful if you didn’t encrypt the sync store and they certainly wouldn’t find anything even sensible if you did encrypt the sync store.
An encrypted database is created at a fixed size. From the Help > Documentation > Getting Started > Building Your Database…
I didn’t know that; thanks. What then is the point of an encrypted sync store?
Presumably if you have knowledge of the inner workings of DT(TG) you would - given time - be able to extract data from an unencrypted sync store. That risk would be mitigated by encryption. Quite apart from which, I’d be surprised if there aren’t users of DT who per policy cannot use (ie are prohibited from using) any unencrypted cloud service.
A general point to take into account with encryption, is that you cannot know what might be the impact of unintended dataloss in the future.
It’s usually easy to understand some specific data types obviously shouldn’t fall into the wrong hands, but inversely it’s very difficult or impossible to envision what might happen with data you currently don’t consider to fall into that category. But lack of imagination isn’t necessarily a good way to assess a risk.
I don’t think it’s a comfortable thought someone got hold of your sync store and uses it for who knows what. To me, that alone should be a good reason to encrypt, but that’s me.
Na, that’s me 
but then again I worry about things like forward secrecy or falling off my bike, hitting my head and forgetting my password, so perhaps I’m a little paranoid.
Using practical terms, encryped databases can be a little extra comfort with data you’d prefer to remain private.
This may be any thing from financial records to personal/family health records to client data, etc.
Remember, when the database is open the files are available and accessible. The encryption is applied at rest, so to add to the security, close the database when you’re not using it or when you get up from your seat to get your coffee or go to the restroom.
Also, you have the option of using Spotlight with an encrypted database… or not. But if you’re using Spotlight, realize that exposes some of the data to searches. In some cases, this may not matter; in some cases, it may matter a lot.
One should also make sure that DEVONthink either quits or explicitly closes any encrypted databases before Arq does a backup. See the comment by @cgrunenberg here.
Unless this has changed since that discussion?
I’m going to go out on a limb here - perhaps @cgrunenberg might please correct me if I am wrong. Arq makes a snapshot of files before backing them up. It does not back up the encrypted database as an open, decrypted file - it backs it up as an encrypted entity. The same happens if you copy the open file to an external SDD - you will not find the file to be open there. So I don’t understand why backing up the database when open would actually be a problem; I do understand that this would be quite different using a backup which did not take snapshots - the file could change numerous times during backup.
The way I do it is to have Arq backup regardless of whether the database is open or closed. Because the extension changes dependent on that state, open databases will never overwrite closed ones in the backup.
I have restored databases to test them, and to date had no trouble with that. But as I said, perhaps Criss - who I honestly have no doubt is significantly more knowledgable in these questions - might offer some additional feedback.
This shouldn’t make a difference as long as the backup processes the enclosing folder, not just the encrypted database file as its extension is different while open.
Thanks; you are quoted as saying “Especially in case of encrypted databases I would highly recommend to back up only closed databases, otherwise the backup might be corrupted”, which was what @avatar was referring to; and I was wondering whether any such corruption would be avoided by the snapshot mechanism used e.g. by Arq.
It’s hard to tell how that is exactly implemented in Arq, ideal are backups which don’t overwrite existing backups so that you can always go back to a working version (e.g. via Time Machine).
Arq provides versioning of that kind 
I thought that the potential issue was, when initially selecting databases for backup with Arq, you could either select a currently closed database with the extension .dtSparse, or a currently open database with the extension .sparseimage.
I had thought that, depending on which had been the case, if Arq sees these as different files, then it would forever only back up the one or the other, according to whether the database was open or closed when Arq began backing up (which might vary).
That is an issue which is, however, very simply solved: (I can’t remember whether you can simply select a whole directory; I chose not to for some reason) set up two backup plans - do the first with the databases closed, set up the second with the databases open. That way one of your two plans will always back up. (The problem is the knowledge: if you don’t know that the extension alternates, you wouldn’t think to set up two backup plans).
I thought we may have been talking slightly at cross-purposes when you mentioned snapshots, as I don’t see how they would mitigate that problem. Neither do I see how selecting the enclosing folder would change anything.
Yes I guess two separate backups as you describe would overcome all this, though it sounds a bit involved. For myself, I have Arq backup once nightly, so I have it run a pre-flight shell script which closes DEVONthink if it’s running (and thus ensures backed-up encrypted databases always have the originally selected .dtSparse extension). But I realise others may have quite different practices: Arq running on different schedules, and DEVONthink always open, or only sometimes, etc., etc.
No, I remember now why I didn’t do it - I wasn’t sure whether Arq would delete the backup of the file if it no longer found that file in the source.
And as you say, each to their own (methods): yours is the cleaner method. I work shifts and as such may be at my Mac at any time of day, so my solution works better for me (but thanks for your input - I love seeing alternatives routes - often times showing me something I didn’t think of myself).
