Security documentation and update needed for v2

[jwildfire]

Let's chat about how we are going to discuss the various "security concerns" that have been raised.

I think we need a good vignette called "Data Pipelines and Security" (or something like that). I think some of this is pretty straight forward and other pieces still pretty blurry (especially the database sections). Hopefully that will clear up a bit as we work on the deployment pipeline in the coming weeks. Here's a draft outline for the vignette:

• Data Pipelines and Security Vignette
  • Intro
  • Common Safety Graphics Workflows
    • Use Hosted Test App - on rstudio.io using sample data
    • Use Charts Exported by the App - list some ways to use the exports
    • Run App using process created in Create Custom Workflow to help users initialize the app #427 - point and click to identify data and config
    • Run App Locally with RStudio - pass in your own data and config
    • Deploy App to Rstudio connect - And other server technology?
    • Others?
  • Data Sources
    • Data loading overview
    • Notes on specific data sources
      • data frames - pass them to safetyGraphicsApp()
      • Other flat files (SAS files, CSV, tab-delimited) - convert to data frame with {haven} then pass them to safetyGraphicsApp()
      • Database
        • DB snapshots - Talk about server configuration concerns/strategy. maybe link to some useful packages
        • Live DB connections - data is not reactive in the app, so this is probably not going to be supported in v2. We should say this.
  • Security/Validation/QC FAQ - answer any questions and link to useful documentation for R and Shiny. refer to the various workflows above as needed.

@xni7 @SRenan @MayaGans @elimillera What do you all think? I've pasted this outline in to the wiki here so feel free to edit that directly and then comment here to discuss.

[xni7]

@jwildfire , this looks like a great start! Edited the wiki with some additional thought. I think we need to provide some general guidance around validation status, warranty, use cases, data sources etc. Also maybe emphasize user's responsibility in validation and protect the security and privacy of patients data. Given the different deployment methods and data backend across different organizations, they need to consult with their IT and QA, and be cautious with patient data handling.

[jwildfire]

Looks good, Xiao - thanks for the updates.

[elimillera]

I think we could write a couple of actual scripts for a local and a cloud deployment of this stuff. Writing a dockerfile that spun this up would be a really cool deliverable.

@xni7 I would definitely agree about the responsibility of the user/organization on this being very important. This is a substantial topic and we might want to focus on R specific trouble you might run into when designing a shiny application specifically opposed to more general guidance.

Things like making sure R sessions don't bleed into one another, how to trust the package repository you're pulling from, making sure your R sessions run unprivileged, and the things I don't know yet are topics I would find really helpful in this space.

[jwildfire]

All of this makes sense to me. Some example scripts would definitely be good to add to the vignette. I'd also really like to set up a github action that automatically deploys a demo version of the app whenever a new build is created - probably a topic for a different discussion though :)

I wonder if R validation hub would be interested in collaborating on for some of the technical topics that apply more broadly to R package usage. The validation overview that Xiao added to the wiki is great, but doesn't really get in to technical details.