While rules for removing Copy Protection have been available for SR4 since the beginning, how copy protection got applied in the first place was never detailed until Unwired. Unfortunately, since it's detailed as a Program Option, those details only apply to copy protection for software. Stepping away from the whole controversy over copy protection and registration of software for a moment, I'd like to discuss other uses for copy protection, namely for datafiles.

Would it be unreasonable to allow the Copy Protection Option to be coded as a Stand-Alone Program capable of being applied to a file in the same way encryption and databombs are? (The Threshold and interval for coding a program option are both the same as they are for a standard use program.) I could see this being a very useful security tool for certain situations, as it's easier to secure a piece of data when you know that the data only exists in one place and that none of the dozens of wageslaves who interact with that data on a daily basis have squirreled away a copy of it in their rating 1 commlink that got left in their pants pocket when they dropped their dry cleaning off.

I don't see any reason why you shouldn't do this. There is some overlap with the Encrypt / Decrypt programs which can serve the same purpose in preventing data being copied. Conceptually, I'm not sure Unwired isn't a step back from SR4. I played it as there not really being anything as simple as pure data anymore, but that everything was a running process. Look at how things are going today. Half of the documents we share - whether Word files, ODF documents, PDF's, even some media files now that we have DRM - they have functionality in them that is half a program by itself. And virtualisation means we're not just sharing data, but half way to sharing the frozen state of an entire machine. So I always considered data files to be more than just data and Encrypt to cover the issue of protecting that data against unauthorised access / copying. But I think copy protection rules for data also work fine and I'd use the fluff I've just described to justify it.

HTH,

K.

DRM works in most cases with encryption, so I don't see the need for it. Of course, in a world where every encryption is unsecure, there are ne secure data files, but that's what you get for messing with logic

The reason datasofts are called datasofts, I've always thought, is because they're programs. Nobody bothers to actually read from storage, they load the datasoft into memory and call a method on it to get the data in a convenient format. This makes backwards compatibility trivial for the user, since the saved document can be viable in all versions of the program without losing functionality for the later programs. Saving becomes trivial as well, you send the datasoft your changes in a language your editor knows and the datasoft will handle its own internal format and then drop its state back into a file. It's probable that you can add new output formats to a datasoft trivially assuming you know the internal format.

DRM would mesh well with this model if it weren't for the fact that DRM is attempting to achieve an impossible task; letting you read something without being able to copy it. All it takes is someone to run the DRMed datasoft in a sandbox and pipe the output to another file to get a viable non-DRMed clone. You use a sandbox to avoid tricks like inbuilt music players wresting control of your soundcard, etc. Computers are fast enough in SR that running a sandbox is not all that difficult. Still, if you wanted to try to achieve the impossible, the fact that the internal data format is isolated from the outside and your data is a program makes using DRM all that much easier to apply to the unfortunates who don't have control of their electronic equipment.

In my last run (before Unwired), I actually attached a "Timer" program option to a data file. After 24 hours it erased itself. I like seeing that this is actually possible now.

I believe that could be considere to be the fluff behind the rules for cracking copy protection listed in the "Source Code and Piracy" section on p.228 of the main book.



So, the general consensus is that if I want a copy protected file, I should treat it as an Edit 1 program that has the program options Limited (limited to 1 specific file's worth of data that's stored interal to the program) and Copy Protection?