Security Essentials for Fansub Teams

This is not a blog I wanted to write. Fansubbing is a volunteer activity, and I would like to believe that my fellow volunteers are trustworthy. However, there have been a number of attacks on fansub teams' archives and servers - not a huge number, but more than just one or two. These attacks have all been inside jobs. A disgruntled fansubber uses his or her credentials or a leaked password to get into a file repository and then proceeds to delete everything in sight, for the "lulz." The damage is severe, immediate, and often irreperable. For example, several years ago the Frostii archive was wiped by a smart-ass (who even boasted about it), and many of the scripts have never been recovered. Another major attack occurred just recently, impacting multiple groups.

Therefore, I reluctantly conclude that fansubbing, like any Internet-accessible project these days, must be run on a "zero trust" model. Today, fansub team repositories are typically wide open. For example, if an FTP server is used, everyone on the team uses the same login and password and has full read-write-delete access to everything. If DropBox is used, anyone on the shared folders can read or delete anything. (DropBox logs all actions, though, and allows the DropBox owner to undo spurious or unintended deletes.) Instead, a team's shared data repositories have to be treated like critical business data and protected from both outside and inside attacks. This is going to increase the administrative burden on the repository keepers, just as it does in the business world. The result will be that less fansubbing gets done, but I don't see an alternative.

So here are some tips for better security in fansubbing.

• Backup, backup, backup. As in business, there's no better palliative for a data disaster than having multiple copies. Ideally, the repository provider should have a backup service. If that's not feasible, fansub teams should designate multiple team members to keep local copies of scripts, work raws, and if need be, ISOs or BDMVs. This can run to terabytes of data, so splitting the work among multiple people helps. It's also possible to backup to public clouds like Amazon Web Services, usually at fairly low cost.
• Avoid common credentials. DropBox already requires individual logins. An FTP should have individual logins for each team member. In the worst case, this will identify (after the fact, alas) who misbehaved.
• Use access controls. Individual FTP users should have write/delete access only where needed. Archives should be read-only except for the FTP administrator. DropBox doesn't have access controls, but at least the DropBox owner can undo a mass delete.
• Consider using a source management system for scripts. Source control systems, like GitHub, allow illegitimate changes (including deletes) to be rolled back. They also support individual rather than common credentials.
• Keep your repository server up to date. Even though Linux is less subject to attack than Windows, it's just as vulnerable, as recent security issues such as ShellShock and BASHed demonstrate.

In short, as Herod said to the Emperor in the I, Claudius TV show, "Trust no one, my friend. No one." This has now become necessary, even among "friends."