From: blockedofcourse@foo.invalid   
      
   I collect sh*tloads of "personal data", video, audio, etc. in the normal   
   course of operation of my system.  This is used to train the various agents   
   and revalidate training updates that can evolve, over time.   
      
   The "data" never leaves the premises (the system is air-gapped, by design).   
      
   As the *user* never needs to "see" the data, there is no easy way to   
   export it.  Nor is there a way for the user to *decrypt* it -- because   
   he has no need to review it!  (Can a user review the samples from the   
   ADCs in your device -- for the past month??  Or, the changes in settings   
   you have made, over time?  Or, actions you've commanded it to perform?)   
      
   The "manufacturer" has no back doors, no private keys to expose the   
   data.  (Keys are generated locally on installation)   
      
   In light of the Guthrie incident, I am rethinking whether or not I   
   should include a provision to decrypt the data -- or at least portions   
   of it (surveillance video, telephone recordings, local audio, etc.)   
      
   But, how to provide that "key" to the user given that he will likely   
   never use it (and, thus, easily "misplace" it).  Would *you* remember   
   the passcode for a product installed a decade earlier??   
      
   Perhaps a physical token:  "Keep this in a secure place"?   
      
   Yet, it has to not *look* like a "key" in the sense that a bad actor   
   would know to use it.  But, "appropriate personnel" should have some   
   way of knowing how to USE it and what they can retrieve with it...   
      
   (  It is so much easier designing medical instruments,   
   process control systems, etc. -- none of these esoteric issues!)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)