DAV servers support?

[bam80]

Hi @tasn, what do you think about this? Is it possible to implement?

[tasn]

As said there, this already exists, this is exactly what this repo is, a dav server, a proxy between etesync and dav clients.

Unless I'm missing something, and then please re-open.

[bam80]

Probably it was ambiguously formulated, sorry. I meant DAV server which proxy itself connects to. So it could contain encrypted data. That was idea

[tasn]

If I understand you correctly, you want this proxy to be installed on the server. This is already possible, just install this on a server (either the same as the etesync server, or a different one). However, this is quite pointless in the context of end-to-end encryption, because if the (or a) server can decrypt it, then it's not end-to-end encrypted.

[bam80]

If I understand you correctly, you want this proxy to be installed on the server

No. I mean, if possible, to implement possibility for this proxy to interact with usual DAV server, not EteSync one. This way we could achieve storing encrypted data on DAV server, while client would interface with proxy by plain unencrypted DAV protocol. This is the idea: https://github.com/owncloud/apps/issues/744#issuecomment-365007630

[tasn]

You can implement such proxies, though they won't share much code with this code base, as this one interacts with EteSync. Furthermore, the note in my previous comment about end-to-end encryption applies to your described scenario as well, it doesn't make much sense to have this over just a normal not-encrypted DAV server. Furthermore, if you are going to use a proxy, you're better off just using EteSync over an encrypted DAV implementation.

[bam80]

You can implement such proxies, though they won't share much code with this code base, as this one interacts with EteSync

This is what I was afraid of. Ok, thanks.

Furthermore, if you are going to use a proxy, you're better off just using EteSync over an encrypted DAV implementation.

While I appreciate your work, this last sentence doesn't look obvious for me. There are a lot of DAV implementations and the service instances, NextCloud is one of them. It's users could benefit from encryption also, only by adding the encryption proxy locally, instead of adding the whole custom EteSync service to their cloud(which is not always possible). I understand that all this "encrypted DAV" stuff is a hack. But in absence of proper standard, it seems we have no easy way here.

[tasn]

It's a hack that doesn't work that well. It leaks a crazy amount of information and opens a lot of opportunities for the server to tamper with your data. Not to mention that it doesn't work that well. Flock (by openwhispersystems) failed partially because of the running costs associated with this hack (according to its creator).

On a related note, I gave a talk at FOSDEM two weeks ago about exactly this and why servers can't be trusted. Coincidentally I even gave encrypted CardDAV as an example. My talk: Servers can't be trusted, and thanks to tamper-proof journals EteSync doesn't need to!.

[bam80]

Thanks, very interesting. Will see the video of your talk. The main problem I see here is the lack of standardization. So, maybe it worth to apply RFC, or something.

[tasn]

I agree it's a problem, but in my point of view it's too early for that, I think EteSync would need to get more mainstream before it'd be worth the time and effort to compile an RFC.