QUOTE (DMiller @ Feb 18 2014, 08:10 PM)
Honestly the only problem I’ve seen so far with the SR5 matrix is that you can not steal data without alerting the host. There is no more “in and out undetected”. Protecting a file is a Data Processing action and is legal to do (and even a novice user should be able to buy 1 hit on the test) there is no reason that any file of interest shouldn’t be protected. Removing that protection is an Attack action which automatically alerts the system as soon as it succeeds. So it is impossible to get data undetected.
We have created a house rule that allows for a Sleaze action to remove file protection without alerting the host, and so far it has worked pretty well. We are still play-testing the house rule though.
File Protection a little bit worse than that if you want to play RAW.
Page 239 notes that: "A protected file cannot be read, changed, deleted, or copied until its protection is broken." You'll note that there is no exception for the owner, nor is there any listing for how a person can legitimately remove the protection, like there is for a Data Bomb. By RAW, once a file is protected, no one can access it again until it's been cracked, which is an illegal action that only someone with an Attack rating can try.
I doubt this is how the game was intended to be played, and is another example of the Matrix section having been written with the perspective of hacking, and not much thought towards "legitimate" use.
The question then, is how does protection work for normal people, and how does that effect how hackers encounter it?
A) A Protected file can be accessed by it's owner (4 marks). If this is the case, then files on a host that are protected and still owned by the host would only be accessible by the Security Spider... which is extremely limiting. Files still owned by a user could not be accessed by anyone else, which makes it hard for team projects or shared files to be protected as only one person could open them. It also means that a Protected file owned by a user would alert the user, not the host, when the protection is cracked. Note that a file still needs to be re-protected when a user is done using it, as protection, unlike a data bomb, is removed to access the file.
B) Protection carries a password like Databomb does. Anyone with the password can remove the protection without setting off any alerts. This makes it possible to grab a file if you can get the password first. It also still limits the amount of protection you're likely to encounter for a simple use reason: Every time you access or edit a protected file, you have to take the Protect File action again to re-protect it once you're done. That extra step of effort is enough to keep the average user from protecting everything they have (because it will require them to memorize a password for every file, and take the extra time to unlock and relock files every time they use one.) You'd probably only see important files being protected.
I do still agree that Crack File Protection should have a Sleaze option, but I'll suggest that fewer files, especially on a Host, are protected. The Host itself protects the files inside from access by hackers on the outside, and the standard system of MARKs limits what legitimate users can do with a file inside the host. The Average wage slave can not edit a file if he lacks a mark on it, and if the file is running silent, he would have a hard time even knowing it's there. Meanwhile the users with permission to use the file have a mark on it, and you can always see an icon you have marked.
Really, however, I wish they had put better details into how marks and file icons work. Something like: 1 mark to view a file, 2 marks to edit it, 3 marks to delete or copy it. In fact, at the moment, there is no "open file" action. Actually viewing a file isn't defined anywhere and may or may not even require a mark.