Clarifying potential contributions - focused on consent #3
Conversation
Also fixed broken links caused by a split across a newline, and malformed markdown.
|
This pull request has been mentioned on Jupyter Community Forum. There might be relevant details there: https://discourse.jupyter.org/t/jupyter-telemetry-system/1217/9 |
|
Thanks for adding this, I do think that having a standardized and solid approach to consent and transparency is important. We doing this, we need to address a wide range of deployment scenarios, some of which not only don't require consent, but can't legally offer it. A good example is Jupyter deployments where the "data being studied" is under HIPAA, FERPA, etc. These deployments are subject to auditing and compliance programs that dictate ongoing monitoring of user activity when those users are handling the sensitive data. If a user wants to "opt out" Because of this, I think we want to provide the best practices consent UI by providing extensible building blocks that can be assembled by different deployments based on their needs. |
design.md
Outdated
|
|
||
| Every application collecting data should have a way to make it | ||
| clear to the user what is being collected, and possibly ways | ||
| to turn it off. We could possibly let admins configure opt-in / | ||
| opt-out options. | ||
| opt-out options. In some cases, we may wish to store consent information | ||
| separately from event data (this is commondly done in human subjects research), |
There was a problem hiding this comment.
Thanks @Zsailer. While I'm here - have you tried using the suggestion feature? You can create a suggestion by clicking the "+/- in a stack of 2 rectanglish things" icon.
In these scenarios, it might still be a "best practice" to have a reference UI that warns the end-user that they are being audited. While they cannot opt-out, they would still be informed. Opting-out, in that case, just means not using the service at all. |
| integrated into a variety of views into Jupyter ecosystem products | ||
| (e.g., JupyterHub, JupyterLab, Binder) as well as "independent" | ||
| projects like Nteract, Stencila, or Gigantum, or even completely | ||
| distinct projects like Theia or RStudio. | ||
|
|
There was a problem hiding this comment.
Suggesting a minor changing of phrasing. If this changes the interpretation, feel free to ignore.
The "consent and information" API should provide a reference UI that can be integrated with various Jupyter-based applications (e.g. JupyterHub, JupyterLab, Binder, Nteract, Stencila, Gigantum, etc.) and non-Jupyter applications (e.g. RStudio and Theia).
There was a problem hiding this comment.
Took your suggestions with a minor "Jupyter-based" -> "Jupyter-related". I like the reduction in complexity.
|
@ellisonbg how do you currently inform folks who are working on a HIPAA / FERPA / etc. covered-system with logging / monitoring in place? |
|
@davclark consent for users working with sensitive data depends across the level of sensitivity. At the high end of sensitivity, access is mediated by humans signing legal documents that state very clearly the scope of data usage, its purpose, limitations, who it can be shared with, etc. Something along the lines of: "here is the data you will have access to, here is how you can lawfully use it; if you violate this, you may go to jail." In these situations, the access to workstations is often controlled, with the internet disabled, etc. Here, consent happens in multiple layers, long before the user is sitting on front of Jupyter doing work. Now an operator of such as system, may want to inform the end user in Jupyter that data is being collected - "we are watching you, and as a reminder, you signed a legal agreement and could go to jail if you violate that agreement." But I don't think those notifications are under the umbrella of consent. I think the GDPR is helpful to framing these questions. For example under GDPR, consent is one of six lawful bases for collecting personal data: https://gdpr-info.eu/art-6-gdpr/ For example, other lawful bases can be things like a contract or compliance with a law. In other words, consent is not a universal requirement. At the same time, GDPR does provide detailed requirements of how the user needs to be informed, both if personal data is collected or not: https://gdpr-info.eu/art-13-gdpr/ GDPR is also helpful in clarifying exactly what is mean by "personal data.": It is important for us to keep in mind that the telemetry system may be used to collect data is not personal data and can't be used to identify the individual (even when linked to other sources of information). And obviously reidentification is a serious concern. |
|
Thank you for continuing to add information here, @ellisonbg. We've been in crunch mode lately, but I'm hoping to return to this in mid-November. I will of course not be upset if others pick up the ball before then! |
|
Should I close this? It's hanging out in my list of active GitHub PRs... not sure how relevant the PR is at this point. |
Also fixed broken links caused by a split across a newline, and malformed markdown.