Hi,
I’d love to see Devonthink adding secure WebDAV with OIDC support.
The standard Webdav uses simple authentication, which is antiquated and not very secure.
I’ve seen folks moving to adopt OIDC and there are OSX and there are open-source packages such as GitHub - openid/AppAuth-iOS: iOS and macOS SDK for communicating with OAuth 2.0 and OpenID Connect providers. available to add the support.
For sync? AFAICS, OIDC tokens expire eventually so I’m required to re-authenticate. Is that practical for WebDAV sync that is mostly an always-on service?
Yes for sync.
And not necessarily - one can implement the auto-renew function to keep the connection going.
Thanks for the suggestion, we’ll consider this for future revisions of the sync.
From page 60 of the DT manual I understand an AES256 encryption key is used to encrypt sync store content. Correct?
So if encrypted data is stored in a sync store that is accessible over WebDAV, possible vulnerabilities in WebDAV authentication would result in AES256 encrypted content getting compromised. It is difficult to predict what people can do to decrypt data in the future without the AES password, but currently no methods exists to do so as far as I know (beside perhaps brute forcing a simple password like ‘secret’ or ‘qwerty’). But obviously simple short password like dictionary words should be avoided in the first place.
Agree or am I missing something?
If so, my suggestion would be to (also) make encryption of synced data mandatory or opt-out instead of opt-in.
The encryption key of sync stores and e.g. WebDAV or Dropbox authentication are completely independent. Up/downloaded data is locally en/decrypted using salted hashes of the encryption key.
Perhaps you misunderstood my suggestion, because that was exactly my point: they’re independent. But they also use a different encryption method: symmetric AES vs. asymmetric encryption if WebDAV uses https. The latter is subject to various attacks only applicable to public key encryption.
Therefore breaches in WebDAV/https have a limited impact on loss of data if the sync store data is encrypted, though I’d welcome any enhancements in WebDAV security such as enforced https connections (if not already in use) or improved authentication as suggested.
Next to that, I’m not sure whether all users understand that a WebDAV password on itself doesn’t encrypt the data and that data might be visible to third parties that provide disk storage for example.
In the end, opt-in sync store encryption doesn’t make much sense to me. I think you would protect the data of your users in a better way if DT/DTTG uses an encryption switch (boolean) that is enabled by default and can be disabled on request (opt-out) displaying a warning that the data is stored unencrypted (which I wouldn’t recommend and is also discouraged in the manual on page 60). With the switch turned on by default, DT can require a (strong) password before it proceeds with creating a sync store.
Actually I just wanted to confirm this 
Enabling encryption by default is a good idea if it works automagically behind the scenes (like https). However, if a user-provided key is needed that can get lost, I’m not so sure.
Yes, but not using encryption because you might loose your key is the wrong justification to use an opt-in method in my opinion. Specifically because the data is primarily stored in DT and the sync store is merely a medium to sync between devices. As said, a user would be able to opt-out in my use case by turning the switch to ‘off’ or ‘don’t encrypt’.
What would be the purpose of leaving a sync store unencrypted anyway? There’ll be use cases undoubtedly, but do they outweigh skipping encryption?
What would be the purpose of leaving a sync store unencrypted anyway? There’ll be use cases undoubtedly, but do they outweigh skipping encryption?
How about if you don’t really care about the data?
I have plenty of data I could care less if it is encrypted or not.
And personally, anything important or private for me is synced only on my network between my machines and devices, and encrypted locally.