Of course you don’t. Why would you want to help out a friend if it means you have to admit you are wrong? You can keep a myopic focus on a single point of contention for a single product among a handful mentioned, stomp your feet, and insist you are right in defiance of all reason. That’s a good plan. Stick with it. Keep on truckin’ there albill and let that freak flag fly.
1 Like
Why should I suggest a “solution” that some random guy on the Internet says is the solution when I’m not convinced it is? Suggesting it to her is an endorsement and, sorry, I don’t endorse your solution.
Keep making it about me though. You think it works? Go tell those security folks. Don’t expect people to do it for you, especially if they aren’t buying what you’re selling.
Hi there!
I wrote the piece in question; let me explain a couple of things.
First, when I say decentralized, in this case I don’t just mean “you can run your own server”, I mean “runs entirely without centralized servers”, because we run into a lot of situations where having a machine that’s not physically present with folks on the team (and which also has access to the data) is an unacceptable risk. Having a secure physical location where you can leave a server is, sadly, a luxury. In many cases, teams aren’t able to have commercial relationships with cloud providers, either; AWS isn’t always an option. Likewise, when your connection to the outside world is bad enough, getting to AWS or a non-local server isn’t really compatible with getting work done.
When I say “offline-friendly”, I don’t just mean “you can save the documents locally”, I mean that a team of folks can coordinate and work together on an entirely local, ad-hoc network without needing a connection to the outside world, and then see changes synced and merged with folks who are working elsewhere when they get connectivity back. This property (with modifications) is also a critical prerequisite for stuff that can only be worked on on airgapped machines.
When I mean “metadata-sensitive”, what that ends up coming down these days is “plays nicely with Tor”, because even if all your adversary can get is IP address pairs and timestamps, that’s still sometimes too dangerous.
Getting key management right is hard, too – while I’m perfectly happy to rely on AES256-GCM, picking a reasonable algorithm is the easy part; the hard part is making sure all the right people (and no one else) have the keys. Also, encrypting documents on a server also isn’t good enough – bits can never leave a local device unencrypted.
It’s cool that there are more options that are taking on bits of these, and I’ll definitely take a look at OnlyOffice at some point to see if there’s anything there organizations I work with can use under some circumstances, but it’s also definitely not the solution I see teams needing. In addition to the security issues, this is because organizations don’t just need document-oriented solutions, they need tools which are lighter-weight and more focused on specific problems. If office docs were enough, we could solve a lot of this with just sparkleshare. Beyond this, I’m also pushing every organization I work with very hard to move away from office and from PDFs, because between them, they represent the most likely ways for folks to get spearfished.
Thanks for reading!
3 Likes
Then don’t suggest that one product you have a problem with. Just let her know that some people think they have located tools that do what she is looking for. Or don’t. I really don’t care who or what you endorse or do. I don’t endorse or use OnlyOffice. I just found it and saw it fit the stated needs in the article. Like I said, it’s not the only one either.
This is why I mentioned secure P2P document collaboration tools earlier. They exists. Groove was an excellent project but MS bought it in 2005 and now it’s gone. There are others which should be considered.
Again, AWS is only one option with OnlyOffice and OnlyOffice is not the only thing out there.
Groove did that very well. I’m not sure who is filling that need right now but this looks promising http://www.se.rit.edu/content/distributed-peer-peer-research-paper-collaboration-utility
Interesting. So the application needs to be resilient to being proxied. That doesn’t sound too difficult. Anything operating on standard http ports like 443 should be ok.
There may be more of an endpoint risk here than an application one
You just responded to her…
Yes, I understand that there are a number of different tools out there that solve bits and pieces of it. This doesn’t mean there’s anything that hits everything, all together, in a way that works for teams. Groove was cool, but AFAIK was never open source, and still didn’t handle everything folks need – and at best, that’s a framework to build tools on, not a finished solution.
2 Likes
I’m a huge fan of open source myself but I do think it’s important to give closed source product providers a fair shake. In other words, I won’t dismiss a closed source product simply for being closed source. I do think reputable third party review is important for these sorts of vendors but simply being open sourced seems less of a security issue than one of vendor lock in my view.
You know, I have never found a single piece of software (heck single OS for that matter) that covers all of my needs. I’ve always had to work with a mix of products from a mix of vendors in order to meet my computing requirements. I suppose that might be why having a single solution would have never occurred to me. Is that what’s really needed - a single software package that covers backups, collaboration, location co-ordination, contact management, project management, ticketing, etc as in the SAP approach? That seems very ambitious for an open source project but doable with the right backing.
If the issue of having all of these tools in a single location is important to you, perhaps you could volunteer yourself or someone else as a project manager and get going with a kickstarter to gather the developers of the individual projects out there together to being working on a single project.
Unfortunately, very few closed-source providers are willing to provide any kind of open-access security reviews, and given the issues we’ve see with things like Microsoft automatically escrowing bitlocker keys unless you pay for the enterprise versions, it’s not appropriate to use closed systems in high-risk environments unless you’ve got the money to compel openness.
For the environments I’m talking about (and it’s a lot of them, mind you – I’m talking about a number of different classes of organization, not just one or two instances), it’s important that we have tools that can provide these security properties in a coordinated manner. It obviously doesn’t have to be the same tool, and I’d be shocked if it was – really, I think most teams would prefer to have sets of tools that can work together, so they can swap in and out the pieces they need. Clearly, trying to develop all of them together would be unlikely to work, and that’s fine.
I’m already working on my part of this – I’m the security architect and (for lack of a better phrase) strategy adviser for the Briar Project, which I mentioned in that piece, which is trying to build out the framework that other tools can build on to create systems with the properties we need. Once we’re at the point where other systems can build on it, I’ll definitely be looking for folks to take up different banners. That said, it’s a different enough way of thinking about application development that there’s not a lot of point in trying to move projects over at much above the library scale – it’ll need to be new development. I’m hoping that this piece will spur folks to start thinking about the actual environment their tools work for, and to stop thinking so narrowly about the rich, western, always-connected, low-risk Internet, which represents a pretty small minority of the folks in the world who need tools.
3 Likes
This topic was automatically closed after 5 days. New replies are no longer allowed.
