I made this thread on reddit and odrive came up, it looks perfect but we are worried about how secure and maintainable the odrive File Server software is.
Are there any plans to make it open source in the future and get include in Ubuntu / Debians repositories?
Hi,
Thanks for pinging us. I saw your reddit thread earlier today and wrote a quick response there.
We have actually suspended development on the odrive file server in favor of focusing our efforts on our other integrations. This includes integrations that can be considered to be in the same category as the odrive file server, like WebDAV, SFTP, and FTP.
It is possible we may circle back to ofs at some point in the future, since it is a very slick piece of software and there are definitely compelling advantages it affords private storage users.
Can you share a little bit more about your use case and scale for the solution you are looking to implement?
Hi Tony,
I responded to you on reddit, but had a feeling you would see this sooner which is why I came here, looks like it worked!
We have a creative team of five, that work remotely and at the office, and a fileserver at the office which contains a few TB of project work, PSD’s mainly.
I didn’t realise you support FTP / SFTP that may actually be a better solution as then we don’t have to depend on your third party oFS (Which is a shame as it works seamlessly) which is the only thing really holding us back.
Thanks for highlighting this, I will try and test it out now!
Great! Supporting WebDAV/FTP/SFTP really lowers the barrier to implementing a solution on existing infrastructure with existing storage. SFTP, in particular, is very fast to get integrated and take for a test drive.
Just let us know if you have any questions.
Hi Tony,
We have looked into the SFTP option, it looks great, but as everything is configured via the web panel we are very hesitant to use SFTP, uploading a private key + passphrase to a third party is a big nono!
If the native client could use the ssh-agent, and bypass this step it would be a good solution. We are considering creating a locked down user group and generating users/keys for our creative team in that group to use the SFTP implementation.
Another area of hesitation is whether the native client is reporting back to the webservice the directory structure of our local SFTP server, we noticed when we shared a GoogleDrive link we were able to (as a non logged in user) see the drive directories.
Cheers,
Owen
Agree with Midasx that giving an external company SFTP credentials/key is a non-starter.
This is along the same topic that I brought up in the thread about where the Oauth refresh token is stored. If you want to get business customers, you need to store sensitive credentials on the client computer, not on your servers.
@Midasx @jared Thanks for the input. I really appreciate it and I completely understand your points. These are topics that we have discussed at great length internally, as well.
odrive was actually born from an enterprise storage product with the entire range of enterprise-level features: on-prem storage with encryption at rest, client encryption at rest, AD/LDAP auth, auditing, multi-level ACLs, device whitelisting, remote-wipe, etc. An IT dream. As you guys probably know, though, there is always a tradeoff. Striking that balance between usability and security is tricky. You can have the most secure system in the world, but nobody will use it.
With odrive, we have started with a very user-accessible system for storage access and sharing. We have taken great pains to reduce the amount of information we need to have/store while still offering the full-range of capabilities that users expect, across an ever-expanding storage landscape. The information that is stored is treated with the utmost respect and security.
Now, I could talk until I’m blue in the face (or type until my fingers are reduced to nubs 
) about our security measures, our encryption, SOC compliance, our philosophy, our devotion to our users, our commitment to security and privacy, etc…, but it really comes down to trust coupled with your own specific business requirements for security and access.
This all being said, we have an eye towards additional security capabilities, some of which were mentioned in the post that @jared linked to above. Our zero-knowledge encryption add-on is another example of this.
As you can probably tell, I like engaging in these type of discussions. It is one of the primary ways that we can make our product better and gain better insight into our diverse user base. Please feel free to continue sharing your thoughts.