Open kauedesousa opened 2 years ago
Software development with Data Protection by Design and by Default https://www.datatilsynet.no/en/about-privacy/virksomhetenes-plikter/innebygd-personvern/data-protection-by-design-and-by-default/?print=true
Some tasks we could agree to work on could be:
- Establish API and data access protocols:
Develop and document the authentication process for accessing sensitive information, ensuring that users are informed about their responsibilities regarding data privacy. This may involve integration with tools like Google Authenticator for added security.
Monitor compliance:
Set up mechanisms for ongoing monitoring and auditing of data exports and API calls to ensure continued compliance with privacy regulations.
- Review legal implications:
Consult legal experts to confirm that the proposed methods for data access and liability transfer are compliant with GDPR and relevant regulations in SSA countries.
Document all procedures and changes clearly and communicate them to all stakeholders involved in data handling to ensure transparency and adherence to the new protocols.
- Train users on new processes:
Create user training materials or sessions to educate participants on the new anonymization techniques and protocols for handling sensitive data.
ClimMob should comply to the regulations on data privacy (EU and SSA Countries). For this we should make sure that sensitive information (farmer name, telephone, precise GPS coordinates, etc) are not shared or distributed by ClimMob. With @jacobvanetten we have discussed some possible approaches.
Omit precise location of GPS coordinates ClimMobTools has a function called
rmGeoIdentity()
which can be used to remove the precise location of coordinates by picking a random point around a buffer area of the original point https://agrdatasci.github.io/ClimMobTools/reference/rmGeoIdentity.html This function could be applied internally to all GPS coordinates and then the random points will be used in the report, API calls and ordinary downloads.Omit names and other ids Names, telephone, etc, should not be displayed in the API calls. We could add a variable when creating a question in the Library. Sensitive question (Y/N), explain what is a sensitive question and why it is important that the user indicates when a question is sensitive or not. Then all the sensitive questions are omitted in the API calls and can be only accessed via an authentication process.
Sensitive information is never published on Dataverse or BrAPI
If the user wants the original data In that case this data could be made available by an authentication process (password + SMS or e-mail? or maybe link to Google Authenticator API https://www.rfc-editor.org/rfc/rfc6238?). Then the data (or link to download the data) could be sent to the email (like GBIF?), with a message saying that the user is receiving a link to access the original data and that now they are responsible to comply with the privacy regulations (check whether handing over the liability is doable)