I intentionally avoided putting the encryption key into the INI file in order to make it impossible for configuration file settings to determine the encryption key. The only way set an encryption key or specify whether encryption is done or not is by invoking the '#' WI 'EncryptLog' method to set an encryption key. If we allowed the key to be specified by the INI file, it would allow anybody with a little knowledge of APL+Win to override the application defined encryption key and thus defeat the encryption.
You can specify the RestartCmd parameter in the INI file to define an application (not limited to APL+Win) to execute as the system is crashing. This does depend upon the crashing APL instance being at least healthy enough to invoke the restart sequence. So it could fail in extreme cases. But it has done a pretty good job in all of my tests. There are cases, such as C-stack overflow or extreme out of memory conditions (non-ws memory) where it will fail, however.
The name of the log file is passed to the restart app as a command line parameter. And you can do whatever you want with this, such as uploading the file, loading another workspace, etc.
There is NOT (in this release) a "recovery workspace" created. I had hoped to successfully do that. But it did not happen for v10 release. The only things we save are the log file, and optionally (and by default) a crash dump file (MiniDump). You are right that in theory client data could be captured in a crash dump. But since that resides on the client machine (either encrypted or not, as controlled by the EncryptLog setting) the vendor will not have access to it unless the client authorizes it to be uploaded. The default MiniDump settings save pretty minimal data in the crash. The only thing saved are the state of the C-stack and one level of pointers from things pointed to by stuff on the C-stack. So it is a pretty much "swiss cheese" view of the application's data. Similarly, the log file captures some amount of SI localization data. But again, since this resides strictly on the client machine, it is not automatically available to anybody but the client. By encrypting it, the contents are hidden from everyone (nobody on the machine can directly see the data and the data is not automatically uploaded to the vendor without the client's consent).
I'm hoping to be able to generate a crash recover workspace in the next major release. But it will NOT be a snapshot of the running application state. The idea would be to capture the development state including edit session content. The way I'm imagining this now is that we would periodically auto-save the whole workspace during a development session. We would also save the complete edit session content periodically (separate from the workspace snapshot). And each time a function is saved from edit session to workspace, we would also save edit session content. This would be similar in concept to the Word recovery model. It would strive to recover what you were editing if the system crashes during programming development. But it would NOT try to capture the running state of a deployed application.
Is there something you wanted to do via the EncryptionMethod, EncryptionKey, EncryptionModule, or EncryptionWS parameters you proposed that isn't supported by the RestartCmd parameter we've already supplied? If so, let me know because I'd like to better understand your requirements.