I recently heard about JungleDisk (hat tip: Ryan), and decided that might be the backup solution I’ve been looking for.
I’ve got thousands of pictures, hundreds of megabytes of source code, and documents dating back several years, all of which I’d like to ensure I never lose. So far I’ve shied away from all of the online backup solutions due to the expense. But JungleDisk uses Amazon’s S3 service for storage, complete with its rather inexpensive pricing model.
With that pricing model, JungleDisk has the potential to provide most of what I need, and some extras that are quite nice; all at a better price. So far, I’ve looked at two options:
- Use an online service. Much lower startup cost, but comes with a recurring fee.
- Build a backup server. This will require at least 1TB of fully redundant storage. I’ll also have to identify software that will meet my needs. Much higher startup cost, but only minimal maintenance costs after that.
JungleDisk has a few upsides, the biggest for me is that I can access it from anywhere that I can install the client, not just when I’m connected to my home network. With a low price, simple, but flexible interface, and a great storage system on the back-end – it certainly sounds like a winner.
Though, there are some features I’d like to see, that it doesn’t offer:
- Access to files without installing software.
- Incremental backups. This would make backing up PST and similar files far more reasonable.
- Store multiple versions of a file.
- Compress data before uploading. This would save a fair bit of bandwidth for me, as I backup things such as conversation and chat logs.
Will these missing features be enough to not use the service? I don’t know yet, I’ll give the service a couple of weeks to see how it goes. So far I’m fairly impressed, though wish it offered more features.
Once I hit the two week-mark, I’ll post a status update; and my final decision as to whether I’ll continue to use it.
In early December, about a month ago, I had the to perform one of the hardest tasks I’ve ever faced as a leader, letting my team know that a colleague had passed away. She was a friend to us all, and the glue that held the team together; telling them that she was gone was, without question, the hardest thing I’ve had to do in a work setting.
What made this so hard was not just what I was telling them, but my own feelings for her as a friend, and the opportunity I had missed.
It’s time for everyone from the industry, developers, and the government to declare war on ransomware and make it as hard as possible for them to ply their insidious trade. There have been false starts and baby steps, diligent fighters without enough resources, and vendors that have only given a nod to the issue. It’s time to use every tool reasonably available to stop this scourge.
For so many in the industry that have dedicated so much of their time and effort to this fight, this statement may seem to diminish their efforts, but that is not my intent.
Much has been said, especially recently, about that mess of dependencies that modern applications have – and for those of us working in application security, there is good reason to be concerned about how these dependencies are being handled. While working on YAWAST, I was adding a new feature, and as a result, I needed a new dependency – ssllabs.rb.
While most Ruby dependencies are delivered via Gems, ssllabs.rb is a little different – it pulls directly from Github:
Even as a child I was fascinated by cryptography – and often left the local librarians with puzzled looks thanks to the books I would check out. It’s so elegantly simple, and yet massively complex. There is one very unusual property of crypto though – it’s not about math or modes, it’s about trust.
Cryptography, especially as used today, has the most wonderful dichotomy of trust; on one hand crypto, by its very nature, is used in situations lacking trust.
So you hash your passwords? Good. Do you salt? That’s good. Do you use a strong hashing algorithm (PBKDF2/bcrypt/scrypt)? Great! But how do you store the hashes? What happens when you get hit with a SQL injection attack?
I’m a big believer in defense in-depth – not that marketing garbage about stacking layers of blinky-light boxes, but using techniques to add extra work for an attacker. You might not be able to stop every attack, but the more work they have to do, the better the odds they won’t get everything they want.
