When I tried Seafile, they had some FUSE implementation that allows access to the chunked files as a virtual FS, but I couldn't get it to work, so I dumped the whole thing. Nextcloud was so much easier to set up.
Having it this way makes it much easier to verify everything is readable properly and easier to replicate it to external drives and backups, also ensure things are accessible there.
Having different open source implementations with different tradeoffs is great, isn't it. That being said, I don't love Nextcloud's performance and some of its other design decisions, but it's the best I've found so far.
If I setup a raspberry pi and follow basic security, why would I need all those encrypted bits to sit on someone else's server?
Infact, the cloud create a security issue just by aggregating everyone's stuff and exclaiming ,, Hey guys! We got all the juicy data here!
I know that's security through obscurity but the only reason apple has been secure from. Malware for a long time was it's limited attractiveness.
For example file names, modification dates, sizes, and other meta data is NOT encrypted. This is a big deal if you sync something like your home folder (things like your browser cache or even Downloads folder may leak a LOT of info).
The defaults on the (self-hosted) server are also very insecure and there's no mention of anything in the installation guide.
It's a shame because Seafile is so much better than things like nextcloud in my experience and there truly is nothing else like it; It really is just as convenient as using google drive!
Could you elaborate on this? Which defaults do you consider insecure? Are there ways to trivially change some values for more security?
Not pushing back on your statement, just curious to know more about it.
2. My other issue is that the installation guide doesn't tell you to create a user for seafile and manually start the service as this user. Most services are installed as root and started as root and I would expect most users to do just that. There is nothing inherently wrong with seafile not setuid()ing itself or its install script not creating a user, but it should mention it in the guide.
(To be fair they're really pushing the docker method now and I expect manual installation to be deprecated.)
It seems that although Seafile's implementation leaves something wanting (I think Option #1 of never sending the key to the server may be a superior option), the sheer fact of the feature's availability trumps the sub-optimality of its implementation. The author also implies that the implementation is "good enough" for his (and presumably most others') use cases.
Being able to browse on the web & also have encrypted files is an interesting challenge.
The option #2 here, of sending the key to the server but making it short lived, is hopeful. Ideally though, I guess I'd hope that the server would just send me a bunch of encrypted metadata, let my client decode it & browse the file tree, then requested encrypted chunks as it wanted. The Option #1, making the server oblivious, feels much better. Rather than trusting that the server will delete my key eventually.
And #1 should allow #2 like systems... we should be able to make separate apps, apart from the storage system, that can intermediate, if we need to.
