Hacker News Reader

> RocketChat I don't know and I should look into but I do feel that XMPP should be the chat replacement for all

Agreed. Given that there are multiple, open source servers, several good open source Web clients and literally hundreds of native libraries/clients, XMPP seems like the obvious choice here.

What irks me even more - Rocket Chats homepage: > Native client applications available for download on Linux, Windows and OSX.

Rocket Chat's GitHub Repo for the "Native" desktop Apps: https://github.com/RocketChat/Rocket.Chat.Electron

Call it a desktop app, sure. I won't use it, but I won't begrudge you the term desktop app. If you're bundling NodeJS and using a webview, your app isn't native.

I don't get this. Why does the language it's written in make it "not native"?

Firefox is pretty "native", yet practically all of the UI is powered by JS.

Hell some of the built in programs in windows 10 are using html/js/css and if you are going to argue that the built-in "part of the OS" programs aren't native, then what is?

If you can see performance issues or problems with how it works then point those out, don't just blanket knock an entire application because you don't like the languages it uses.

Well, that's just the issue. I have no problem with Electron apps as an idea, but they're often coupled with extremely slow rendering. You can tell immediately.

For instance, in Slack, which is more or less an Electron app / browser in a box, I can easily get it down to <5 fps just by posting a snippet or going too far in scrollback. Resizing the window is beyond painful, etc., etc. It all seems unbelievably unnecessary - why should a chat program, literally text on a screen, perform like this on a top-of-the-line quad-core i7 system?

Having a problem with the performance is perfect criticism, but the commenter i was replying to was bashing it because of it's choice, not because of it's performance. He won't even try it before saying that.

web rendering doesn't automatically make an app slow. And in my experience choosing a "common" platform like the web allows an app to run everywhere. I'm not suddenly going to be able to triple my development speed, so without the common platform that means that i'd only be able to support one major platform, or all platforms but with a small fraction of the development speed, and most likely many more bugs.

And to be fair, saying slack is nothing more than "text on a screen" is really oversimplifying it. There are tons of formatting options, code highlighting, embedded HTML, embedded video and images, attachments, coloring, emojis, and more.

It seems like a pretty obvious choice to go with a web rendering engine seeing as it supports almost all of that "natively".

Performance, usability, conformance to platform standards, you name it, packaged web views are terrible for it.

Electron apps package a web view and show it on a desktop. They're explicitly using a browser window without the browser chrome.

Firefox honestly is a terrible choice to defend non-native UI conventions. You might as well have picked Java apps as your argument.

Fully based on XMPP there's also Movim which bring social network features on top of it https://movim.eu/ . P.S.: I'm the author of the project.

So how does it relate to XMPP? Is Movim a XMPP server like ejabberd? Or is it something else?

It looks like it uses xmpp more like the way Google wave did than regular im but I can't tell for sure, I signed up but wasn't able to login with a browser and they only have Linux-ish native apps.

I've installed and abandoned ownCloud several times, mostly because it is far too heavy for what I need and I had concerns about its security. I also had to set up EncFS on my local machines for client-side encryption of sensitive files because there was no way I was trusting that to ownCloud server-side.

It took more work to set up but I have Seafile self-hosted on the smallest DigitalOcean VPS and it works beautifully. $5/month, plenty of space for the amount of files I need to sync across machines, and my data is in Germany which is great (I'm in Europe). Native client-side encryption is built-in to the client so I have an easier configuration on local machines, and it does most of what I need.

I'm still looking for a good self-hosted CalDAV/CardDAV option that doesn't require PHP or MySQL, but as this data is less sensitive I'm happy to trust it to FastMail for now.

> I also had to set up EncFS on my local machines for client-side encryption of sensitive files because there was no way I was trusting that to ownCloud server-side.

Did you host OwnCloud yourself? But you didn't trust the software with your files? In what way is the SeaFile solution you are running now more trustworthy?

> I'm still looking for a good self-hosted CalDAV/CardDAV option that doesn't require PHP or MySQL, but as this data is less sensitive I'm happy to trust it to FastMail for now.

http://radicale.org/ is exactly what you are looking for.

> Did you host OwnCloud yourself?

Yes, I prefer to self-host anything I can. I'm lucky to have a gigabit FTTH connection and moving lots of data around is no problem. I still prefer to use a remote VPS because some things are best left to the pros.

> But you didn't trust the software with your files? In what way is the SeaFile solution you are running now more trustworthy?

Seafile has a much smaller attack surface (no PHP, MySQL not required, etc) and handles the client-side encryption itself. We are discussing degrees of trust here, so while I was happy to trust ownCloud and the VPS to be there for a request, and to not corrupt my data, I didn't trust that my sensitive data was safe if the server was compromised. EncFS was a workaround, but it cluttered up Nautilus with extra drives since every encrypted directory had to be mounted as a drive. Now I'm comfortable trusting Seafile to do all that because an attacker would need to compromise both my VPS and my local machine to gain access to sensitive data. This is orders of magnitude less likely and for me is an acceptable risk, especially considering the simpler software stack.

And I'm definitely checking out radicale, thanks for the tip. If it does contact photo sync (annoyingly not currently supported my FastMail CardDAV) I'll give it a try.

When I was reviewing alternatives, syncany's web page claimed that seafile has a poor security record: https://github.com/syncany/syncany/wiki/Comparison:-Syncany-...

I'm not sure how seriously to take this.

I nearly went with Syncany, they were a very close second but they are still in alpha, plus they have no mobile apps (yet). I really like being able to take a photo with my phone and have it sync to my computer.

Development on Seafile is very active and they are transparent about security issues. I don't think it is poorly written but maybe a third-party audit like Truecrypt did is a good idea.

Here's their 'Records of security issues' page: https://seacloud.cc/group/3/wiki/security-records/

> Here's their 'Records of security issues' page: https://seacloud.cc/group/3/wiki/security-records/

Just take a look who reported their recent issue allowing a lot of attack vectors. (more than they mentioned though) :)

Actually if somebody had a local user account themselves they could bruteforce the secret key in seconds. And SeaFile has additionally modified the default Django components making it more insecure: https://github.com/haiwen/seahub/commit/7cdb70368aa7acbf0546...

By the way, ownCloud does run a Bug Bounty: https://hackerone.com/owncloud

On mobile so please excuse me if I missed something subtle, but what's more insecure about this change? From what I know constant time compare protects against timing side channel attacks, so isn't it improving security here?

That was actually the part where they partially mitigated the vulnerability with. So before it was more insecure. The green one is the "fix" :)

The constant time comparison is pretty irrelevant here. Check https://github.com/haiwen/seahub/commit/7cdb70368aa7acbf0546..., basically a valid password reset token in default Django requires an attacker to know:

- Primary Key of the user (User ID)

- Hashed version of the user password

- Timestamp of the last login (1 second accuracy)

- Number of days since 2001-1-1 converted to base 36

- The configured SECRET_KEY

Basically except the configured SECRET_KEY and the hashed version of the password everything is known to an attacker. And even if an attacker knows the SECRET_KEY they would not be able to generate a valid token as the old password hash is required.

However, Seafile has removed the hashed password out of their version of "tokens.py". This means that if somebody knows the SECRET_KEY they could create valid password reset tokens. That the initial SECRET_KEY was basically generated by `str(random.randint(0,100000))` did make this all much more worse… (https://github.com/haiwen/seahub/blob/b6f8935c0f355cc70145f9...)

Bad thing about this is that this basically makes a lot of old Seafile instances insecure unless they get a new SECRET_KEY. They did somewhat tell users to regenerate it within a forum post and some wiki page (https://seacloud.cc/group/3/wiki/whats-new-in-the-next-versi...) but that's not really a good way to spread awareness…

Thanks for taking the time to explain... Sorry to nitpick, but I'm trying to get things clear.

your original comment pointing to the commit said

> And SeaFile has additionally modified the default Django components making it more insecure

So I was under the impression that this commit was making things worse, not better. Thanks for clarifying that this was already fixed in this commit, rather than introduce a vulnerability. It looks like they added the hashed password on the diff to mitigate this issue - unless I am missing something here? Can you explain why they "partially mitigated the vulnerability" here? is there still some gap that they've missed?

I'm not underestimating the vulnerability, or the fact that it was there in the first place. Just trying to get a full(er) picture.

I've had a read through this, and some other places where insecurity of Seafile is exposed/discussed/fixed. I agree that the overall impression I'm getting is that they're not security experts, and security could have definitely been better designed or taken into account in the first place.

I still think they're trying to do their best, and fix problems and improve. I hope for their and their users' sake that they can get some security-dedicated contributors (mostly to prevent bad things in the first place rather than fixing them later on). There's always more that can be done, but I'd like to give them the benefit of the doubt here and have faith that things will be better in the long run. Having a (robustly) secure, open-source dropbox replacement is a good thing. I think that's their aim, even if they are some times misguided.

disclaimed: I'm not even a user of Seafile, let alone know much about its codebase. It's the first time I hear about it. I was just curious about the security aspects of their product in light of some criticism here and on github etc.

> Seafile has a much smaller attack surface (no PHP, MySQL not required, etc)

ownCloud does run a successful Bug Bounty program and is paying for security bugs: https://hackerone.com/owncloud

Also I have published a blog post elaborating why CVEs are not everything when it comes to comparing the security of products: https://statuscode.ch/2015/09/ownCloud-security-development-...

Furthermore please take a look at https://seacloud.cc/group/3/wiki/security-records/. Not using PHP doesn't make everything more secure magically, neither does using PHP make things more secure.

Thanks, good to know.

The ownCloud Android client required duplicate copies of all the photos & videos (the original plus a copy in the ownCloud folder) which filled up storage on my phone too quickly. Once this is sorted I might try it again, even if only for the calendar and contacts. It has many features but I just don't need most of them.

There is a pull request with a fix for the Android issue you describe: https://github.com/owncloud/android/pull/1168 Would be very helpful if you can test it! :)

Thanks for radicale! I switched to it from Google Calendar and Contacts. The git integration is amazing.

How do you update Seafile? I've found the manual update process to be somewhat unwieldy. (I'm spoiled by package managers)

You update manually via SSH. It's a bit more tedious than a package manager but not too bad. It took me a while to wrap my head around their file layout and how they do things, but I have it figured out now and updating takes a couple minutes. I can have two SSH terminals open on the same machine and by the time the first one completes `apt-get update && apt-get -y upgrade` I'm nearly done with the Seafile update. I really don't like adding third-party PPAs so I'll probably stick with this method for a while even if someone manages to package it up.

I run ownCloud, despite some reservations about its security. I'm not too concerned about the data in ownCloud itself (if it's private, then I encrypt it client-side, but most things I put in ownCloud are not very private). I'm more concerned about it being used as a launching point for an attack on my home server. As a kind of compromise, I'm running it in a VM.

> I run ownCloud, despite some reservations about its security. I'm not too concerned about the data in ownCloud itself (if it's private, then I encrypt it client-side, but most things I put in ownCloud are not very private). I'm more concerned about it being used as a launching point for an attack on my home server. As a kind of compromise, I'm running it in a VM.

ownCloud does run a bug bounty program (https://hackerone.com/owncloud) and the company supporting the project also employs internal security experts.

You might also want to read https://statuscode.ch/2015/09/ownCloud-security-development-... which covers why comparing CVEs is not a reliably way to compare the security of products.

> I'm still looking for a good self-hosted CalDAV/CardDAV option that doesn't require PHP or MySQL

Baikal is PHP, but can run on sqlite instead of MySQL : http://baikal-server.com/

I feel the same way about owncloud and most of the currently available webdav/filesync self-hosted options.

My compromise for the most part is having all of those services walled off behind vpn.

ownCloud designer here – thanks a lot for the kind words! We’re also about to improve the web interfaces for Calendar and Contacts in coming ownCloud versions.

Also, I’m glad you like the Mail app although it’s in a very early stage! If you experience any issues or have feature requests, please let us know at https://github.com/owncloud/mail/issues :)

I have a question about owncloud if you don't mind: Is there any way to run owncloud modularly? For example: I'd like just the calendar setup. I don't want to sync files, or share pictures with it, etc.

Is there any way I can set up just the features I want, and disable the rest? I have very briefly looked over how to do this, but haven't found anything.

You can enable and disable pretty much everything – except Files. That’s because it’s the core app and others like Gallery, PDF viewing, Music etc of course rely on there being files. There have been requests to even make it possible to disable the Files app, but we don’t really see that as priority and rather focus on keeping ownCloud rock stable and secure while still driving features forward. We are a very small team and an open source project, so I guess that’s understandable. :)

As a really dirty hack, meanwhile you could just hide the Files icon from the menu via CSS. But, well … ;)

> Ampache is cool but I found the installation to be too fiddly and easy to break. It could be my incompetence with that product but I prefer subsonic. A java product which just runs and it runs well. The webinterface desperately needs a good UIoverall but it works and it doesn't get in the way.

I use ampache, but you are absolutely correct: it is fiddly, and breaks easy. Subsonic also does "just work". I personally like ampache because it's much less resource-intensive on my webserver, and easier to fiddle with (I'm also a java-hater), but Subsonic is much more approachable.

What doesn't work well with XMPP is history on all my devices. I want to use it on my work computer, then when it's time to go I'd like to change to my phone on the way to the train station, then on the train I'd like to keep on chatting on my laptop and when I'm home I'd like to end the discussion on my iMac. I still want to be able to scroll up and to read what I or anyone else in that chat room said before. This seems to be a feature where XAMPP and IRC fail me.

My 2 cents re Ampache - it's pretty cool but doesn't play all media types, where as Kodi (XBMC) plays more media types and has a couple of great Android clients (that play locally).. I did get localplay up and running on Ampache but it's less flexible than Kodi Android clients.

Another subsonic user here...for a very long time as well. You'd have to have a very good product to get me to switch.

I donated years ago to the project and I'm grandfathered into the 'premium' app.