First version of the guide

pull/1/head
LINC 2020-06-11 11:21:51 +02:00
commit a0a06aa417
23 changed files with 2844 additions and 0 deletions

View File

@ -0,0 +1,19 @@
# Sheet n°0: Develop in compliance with the GDPR
#### Whether you work alone, are part of a team developing a project, manage a development team, or are a service provider carrying out developments for third parties, it is essential to ensure that user data and all personal data processing are suffisiently protected throughout the lifecycle of the project.
The following steps will help you in the developing privacy-friendly applications or websites:
1. **Be aware of the GDPR core principles**. If you work in a team, we recommend that you identify a person responsible for monitoring compliance. If your company has a Data Protection Officer (DPO), then that person is a key asset in [understanding and meeting the GDPR obligations](https://www.cnil.fr/sites/default/files/atoms/files/guidelines_on_dpos_5_april_2017.pdf). The appointment of a DPO may also be mandatory in some cases, for example if your programs or applications process so-called "sensitive" data (see [examples](#Sheet_n°1:_Identify_personal_data)) on a large scale or conduct regular and systematic monitoring on a large scale.
2. **Map and categorize the data and processing in your system**. Accurately mapping the data processing performed by your program or application will help you ensuring that they comply with legal requirements. Keeping a [record of processing activities](https://www.cnil.fr/en/record-processing-activities) (an example of which can be found on the [CNIL website](https://www.cnil.fr/sites/default/files/atoms/files/record-processing-activities.ods)), allows you to have an overall view of these data, and to identify and prioritize the associated risks. Indeed, personal data may be present in unexpected places such as in server logs, cache files, Excel files, etc., and may be stored in a number of different places. Such record-keeping is mandatory in most cases.
3. **Prioritize the required actions**. On the basis of the data processing registry, identify the required actions to comply with the obligations of the GDPR in advance of the development and prioritize the attention points with regard to the risks for the data subjects by the processing. These points of attention concern in particular [the necessity and types of data collected and processed](#Sheet_n°7:_Minimize_the_data_collection) by your software, [the legal basis](#Sheet_n°15:_Take_into_account_the_legal_basis_in_the_technical_implementation) on which your data processing operations are based, [the information mentions](#Sheet_n°12:_Inform users) of your software or application, [the contractual clauses](#Sheet_n°5_:_Make_an_informed_choice_of_its_architecture) binding you to your contractors, the terms and conditions for [exercising rights](#Sheet_n°13:_Prepare_for_the_exercise_of_people_rights), the measures implemented to [secure your processing](#Sheet_n°6:_Secure_your_websites,_applications_and_servers).
4. **Manage the risks**. When you identify that a processing of personal data is likely to create high risks for data subjects, make sure that you manage those risks appropriately in the context. A [Privacy Impact Assessment (PIA) ](https://www.cnil.fr/en/privacy-impact-assessment-pia) can help you manage those risks. The CNIL has developed a [method](https://www.cnil.fr/sites/default/files/atoms/files/cnil-pia-1-en-methodology.pdf), [model documents](https://www.cnil.fr/sites/default/files/atoms/files/cnil-pia-2-en-templates.pdf) and a [tool](https://www.cnil.fr/en/open-source-pia-software-helps-carry-out-data-protection-impact-assesment) that will help you to identify those risks, as well as a [catalogue of good practices](https://www.cnil.fr/sites/default/files/atoms/files/cnil-pia-3-en-knowledgebases.pdf) that will assist you in implementing measures to address the identified risks. Furthermore, a privacy impact assessment is mandatory for all processing operations that are likely to create high risks to the rights and freedoms of data subjects. The CNIL proposes, on its [website](https://www.cnil.fr/sites/default/files/atoms/files/liste-traitements-aipd-requise.pdf), a list of types of processing operations for which a DPA is required or not.
5. **put in place internal processes** to ensure compliance during all development stages, ensure that internal procedures guarantee that data protection is taken into account in all aspects of your project and into all events that may occur (e.g. security breach, requests for rectification or access fulfillment, modification of data collected, change of provider, data breach, etc.). The requirements of the [governance label](https://www.cnil.fr/sites/default/files/typo/document/CNIL_Privacy_Seal-Governance-EN.pdf) (even if this one no longer granted by the CNIL since the entry into force of the GDPR) can constitute a useful basis of inspiration to help you set up the necessary organization.
6. **Document developments compliance** to prove your compliance with the GDPR at all times: the actions performed and the documents produced at each stage of development must be mastered. This implies in particular a regular review and update of the documentation of your developments so that it is constantly consistent with the features deployed on your program.
The CNIL website provides numerous practical files which will assist you in setting up law-abiding treatments according to your sector of activity.

View File

@ -0,0 +1,56 @@
# Sheet n°1: Identify personal data
#### Understanding the notions of "personal data", "purpose" and "processing" is essential for the development of law enforcement and user data. In particular, be careful not to confuse "anonymisation" and "pseudonymization", which have very precise definitions in the GDPR.
## Definition
* The notion of **personal data** is defined in the [General Data Protection Regulation](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679) (GDPR) as "[any information relating to an identified or identifiable natural person (referred to as "data subject")](https://www.cnil.fr/en/personal-data-definition)". It covers a broad scope that includes both directly identifying data (e.g. first and last name) and indirectly identifying data (e.g. telephone number, license plate, terminal identifier, etc.).
* Any operation on this type of data (collection, recording, transmission, modification, dissemination, etc.) constitutes **processing within the meaning of the GDPR** and must therefore meet the requirements laid down by that regulation. Such processing operations must be lawful and have a specified purpose. The personal data collected and processed must be relevant and limited to what is strictly necessary to achieve the purpose.
## Examples of personal data
* Where they relate to natural persons, **the following data are personal data**:
* Surname, first name, pseudonym, date of birth;
* photos, sound recordings of voices;
* fixed or mobile telephone number, postal address, email address;
* IP address, computer connection identifier or cookie identifier;
* Fingerprint, palm or venous network of the hand, retinal print;
* License plate number, social security number, ID number;
* Application usage data, comments, etc...
* **Identification of natural persons can be carried out**:
* from a single piece of data (examples: surname and first name);
* from crossing of a set of data (example: a woman living at such and such an address, born on such and such a day and member of such and such an association).
* Some data are considered **particularly sensitive**. The GDPR prohibits the collection or use of such data, unless, in particular, the data subject has given his/her express consent (active, explicit and preferably written consent, which must be free, specific and informed).
* These requirements concern the following data:
* data relating to the **health of individuals**;
* data concerning **sexual life** or **sexual orientation**;
* data revealing an alleged **racial** or **ethnic** origin;
* political opinions, religious beliefs, philosophical beliefs or trade union membership;
* **genetic** and **biometric data used for the purpose of uniquely identifying an individual**.
## Anonymisation of personal data
* An **anonymisation process of personal data** aims at making impossible to identify individuals within data sets. It is therefore an irreversible process. When this anonymisation is effective, the data are no longer considered as personal data and the requirements of the GDPR are no longer applicable.
* By default, we recommend that you **never consider raw datasets as anonymous**. Anonymisation results from processing personal data in order to irreversibly prevent identification, whether by:
* _singling out_: it is not possible to isolate some or all records which identify an individual in the dataset;
* _linkability_: the dataset does not allow to link at least, two records concerning the same data subject or a group of data subjects;
* _inference_: it is not possible to deduce, with significant probability, the value of an attribute from the values of a set of other attributes.
* These data processing operations imply in most cases a **loss of quality on the produced dataset**. The Article 29 Working Party (Art. 29 WP) [opinion on anonymisation techniques](https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf) describes the main anonymisation techniques used today, as well as examples of datasets wrongly considered anonymous. It is important to note that anonymisation techniques have short comings. The choice to anonymize or not the data as well as the selection of an anonymisation technique must be made on a case by case basis according to contexts of use and need (nature of the data, usefulness of the data, risks for people, etc.).
## Pseudonymization of personal data
* **Pseudonymization is a compromise between retaining raw data and producing anonymized datasets**.
* It refers to the processing of personal data in such a way that **data relating to a natural person can no longer be attributed without additional information**. The GDPR insists that this additional information must be kept separately and be subject to technical and organisational measures to avoid re-identification of data subjects. Unlike anonymisation, pseudonymization can be a reversible process.
* In practice, a pseudonymization process consists of **replacing directly identifying data (surname, first name, etc.) in a dataset with indirectly identifying data** (alias, number in a filing system, etc.) in order to reduce their sensitivity. They may result from a cryptographic hash of the data of individuals, such as their IP address, user ID, e-mail address.
* Data resulting from pseudonymization are considered as **personal data and therefore remain subject to the obligations of the DPMR**. However, the European Regulation encourages the use of pseudonymization in the processing of personal data. Moreover, the GDPR considers that pseudonymization makes it possible to reduce the risks for data subjects and to contribute to compliance with the Regulation.

View File

@ -0,0 +1,34 @@
# Sheet n°2: Prepare your development
#### The principles of personal data protection must be integrated into IT developments from the design phase onwards in order to protect the privacy of the people whose data you are going to process, to give them better control over their data and to limit errors, losses, unauthorised modifications or misuses of their data in applications.
## Methodological choices
* **Put privacy protection at the center of your developments** by adopting a [Privacy By Design](https://edpb.europa.eu/our-work-tools/public-consultations-art-704/2019/guidelines-42019-article-25-data-protection-design_en) methodology.
* If you use agile methods for your developments, consider **integrating security at the center of your process**. The ANSSI has made available a guide ["digital security & agility"](https://www.ssi.gouv.fr/uploads/2018/11/guide-securite-numerique-agile-anssi-pa-v1.pdf) (in French only) which indicates how to conduct your developments within the framework of an agile method while taking into account the security aspects. Don't hesitate to draw inspiration from it.
* For any development aimed at the general public, **consider the privacy settings**, and in particular the default settings, such as the characteristics and user content visible by default.
* **Conduct a [Privacy Impact Assessment (PIA)](https://www.cnil.fr/en/privacy-impact-assessment-pia)**. For [certain processing operations](https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/accountability-and-governance/data-protection-impact-assessments/) it is mandatory. In other cases it is a good practice that will allow you to identify and deal with all the risks upstream of your developments. The CNIL has a special section on its website and provides a [free software](https://www.cnil.fr/en/open-source-pia-software-helps-carry-out-data-protection-impact-assesment) dedicated to this type of analysis.
## Technological choices
#### Architecture and features
* **Include privacy protection, including data security requirements, at the design stage of the application or service**. These requirements should influence [architecture choices](#Sheet_n°5:_Making_an_informed_choice_of_architecture) (e.g. decentralized vs. centralized) or functionality (e.g. short term anonymization, data minimization). The default settings of the application must meet minimum security requirements and comply with the law. For example, the default complexity of passwords must comply at least with the [CNIL recommendation on passwords](https://www.cnil.fr/fr/node/23803).
* **Maintain control of your system**. It is important to keep control of your system, both to ensure proper operation and to guarantee a high level of security. Keeping a system simple allows you to understand precisely how it works and to identify its weak points. If a certain complexity is required, it is advisable to start with a simple, correctly designed and secure system. Then, it is possible to increase the complexity little by little, while continuing to secure the new features that are added.
* **Don't rely on a single line of defense**. In spite of all the steps taken to design a secure system, it may happen that some components added later may not be sufficiently secure. To minimize the risk to end users, it is advisable to defend the system in depth. For example, checking the data entered in an online form is part of the periphery defenses. If this defense is hijacked, database query protection can take over.
#### Tools and practices
* **Use programming standards that take into account safety**. Often, lists of standards, best practices or coding guides improving the security of your developments are already available. Ancillary tools can also be integrated into your integrated development environments ("**IDE**") in order to automatically check that your code complies with the various rules that are part of these standards or good practices. You can easily find lists of good practices for your favourite programming language on the Internet. For example [here](https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards) for C, C++ or Java. For web application development, specific good practice guides exist, such as those published by [OWASP](https://www.owasp.org).
* **The technological choices are critical.** A few parameters need to be taken into account:
* Depending on the field of application or functionality developed, one language or technology may be more appropriate than another.
* Time-tested languages and technologies are safer. They have, in general, been audited to correct the most known vulnerabilities. However, you should be careful to use the latest versions of each of the technology building blocks you will be using.
* You must avoid coding your final solution in a language you have just learned and not yet mastered. Otherwise, you expose yourself to an increased risk of a security flaw due to lack of experience.
* **Set up a secure development environment that allows versioning of the code** by following the [dedicated sheet](#Sheet_n°3:_Secure_your_development_environment) in this guide.

View File

@ -0,0 +1,25 @@
# Sheet n°3: Secure your development environment
#### The security of production, development and continuous integration servers as well as developer workstations must be a priority because they centralize access to a large amount of data.
## Assess your risks and adopt the appropriate security measures
* **Assess the risks** in the tools and processes used for your developments. Make an inventory of your existing security measures and define an action plan to improve your risk coverage. Appoint a person responsible for its implementation.
* Consider the risks on all the tools you use, including risks related to SaaS (Software as a Service) and collaborative tools in the cloud (such as [Slack](https://slack.com), [Trello](https://trello.com), [GitHub](https://github.com), etc.).
## Secure your servers and workstations in a homogeneous and reproducible way
* Lists of **recommendations** concerning the security of servers, workstations and internal networks are available in the [sheets n° 5 to 8](https://www.cnil.fr/sites/default/files/atoms/files/cnil_guide_securite_personnelle_gb_web.pdf) of the **security of personal data guide** of the CNIL.
* Write a **document listing those measures and explaining their configuration** to ensure that security measures are implemented uniformly on servers and workstations. In order to reduce the workload, **configuration management tools**, such as [Ansible](https://github.com/ansible/ansible), [Puppet](https://github.com/puppetlabs/puppet) or [Chef](https://github.com/chef/chef), can be used.
* Update servers and workstations, if possible automatically. You can set up a watchlist of the most important vulnerabilities, for example the [NVD Data Feeds](https://nvd.nist.gov/vuln/data-feeds).
## Put special emphasis on access management and traceability of operations
* Remember to document the management of your **SSH keys** (use of state of the art cryptography and key length algorithms, protection of private keys with a passphrase, key rotation). For examples of good practice, see [the document on the secure use of (open)SSH](https://www.ssi.gouv.fr/uploads/2014/01/NT_OpenSSH_en.pdf).
* Encourage strong authentication on the services used by the development team.
* **Trace** access to your machines and, if possible, implement **automated log analysis**. In order to keep reliable traces, the use of generic accounts is to be avoided.

View File

@ -0,0 +1,37 @@
# Sheet n°4: Manage your source code
#### Whatever the size of your project, it is highly recommended to use a source code management tool, such as a *version control system*, to track its different versions over time.
## Set up your version control system efficiently, thinking about its security.
* A version control system is a software program that allows you to store **all your source code and associated files**, while keeping the **chronology of all changes** that have been made. A simple FTP server is not a version control system.
* Set up your environment correctly using the features offered by your version control system. It is recommended that you implement strong **authentication** and/or **authentication with SSH keys** at the beginning of your project.
* In addition, assign *levels of access* to your project to the users of your version control system and define for each level the corresponding **permissions** (for example, a "guest" level with limited read rights, a "developer" level with write rights, etc.).
* Make regular **backups** of your source code management system. In particular, remember to back up your main server where all changes are saved.
* Set up development procedures to work efficiently even if **several people are developing at the same time**. For example, you may decide not to work on the same branch (_master_), but to set up feature-based branches, which will be merged into the main branch as development progresses. Such development strategies are already well documented, for example in [Git Flow](https://nvie.com/posts/a-successful-git-branching-model/). In addition, some version control systems offer to set up **protected branches** that prevent unauthorized changes to the files in these branches.
## Be aware of your source code content.
* Implement **code quality metrics tools** that will scan your code as soon as it is _committed_ to check its good quality. You can also add scripts to check these metrics in the [version control system configuration](https://git-scm.com/book/uz/v2/Customizing-Git-Git-Hooks): the _commit_ will be cancelled if the source code is not of sufficient quality.
* Keep your secrets and passwords out of your source code repository:
* in separate **files, which have not been _committed_**. Remember to use special files from your version control system (such as _.gitignore_ for _Git_) so that you don't _commit_ sensitive files by mistake.
* in **environment variables**, take care to check that environment variables are not accidentally written to *logs* or displayed when an application error occurs.
* using [**specific secret or configuration management software**](https://www.digitalocean.com/community/tutorials/an-introduction-to-managing-secrets-safely-with-version-control-systems#using-configuration-management-systems-for-secret-management).
Finally, if you need to include such data in your repository, consider **automatically encrypting/decrypting** the files using a *plugin* from your version control system (e.g. [_git-crypt_](https://github.com/AGWA/git-crypt)).
* After a _commit_ that contains personal or other critical data, don't forget to [purge](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History) [completely](https://help.github.com/en/github/authenticating-to-github/removing-sensitive-data-from-a-repository#purging-a-file-from-your-repositorys-history) the source code repository: even after modification, the data may still be available in your repository history.
* Be careful before **publishing your source code online**. Review **its entire contents** to make sure that no personal data, passwords or other secrets are present, including the entire change history.
## Examples of tools
* Unlike tools such as [Subversion](https://subversion.apache.org/), which need a central server to run, the main version control systems ([Git](https://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/) for example) are **decentralized**.
* For most of these tools, a **web interface and related tools** (bug management, wiki for your documentation, etc.) are provided. These solutions can either be accessible via the internet ([GitHub](https://github.com/), [Bitbucket](https://bitbucket.org/), etc.), or they can be integrated into your own servers.

View File

@ -0,0 +1,27 @@
# Sheet n°5: Make an informed choice of architecture
#### When designing the architecture of your application, you must identify personal data that will be collected and define a path and life cycle for each of them. The choice of supporting assets (local storage, server, cloud service) is a crucial step, which must be adapted to your needs, but also to your technical knowledge. The registry and conduction a privacy impact assesment can assist you in this choice.
## Examining life cycle of data and processes, from collection to erasure
* Represent and describe how the product generally works before starting your project, with a diagram of data flows and a detailed description of the processes carried out.
* When data is only **stored on the user's terminal** (local storage) or remains **confined on communication networks under the control of the user** (e.g. Wi-Fi or other local network), the main point of attention is data security. The duration for which data is stored and the actual deletion should be determined by the individuals.
* **When the data transits through online services**, the choice of hosting the data yourself or using a service provider must be made according to your security knowledge and the expected quality of service. Recognized cloud offerings may offer higher levels of security. However, they generate new risks that need to be mastered. [Recommendations for companies planning to use Cloud computing services](https://www.cnil.fr/sites/default/files/typo/document/Recommendations_for_companies_planning_to_use_Cloud_computing_services.pdf) can guide at this selection stage.
## In case of use of external hosting
* **Choose a service provider that ensures appropriate security and confidentiality measures and is sufficiently transparent**.
* **Make sure you know the geographical location of the servers that will host your data**. You may be required to transfer data outside the European Union (EU) and the European Economic Area (EEA). While data can move freely within the EU/EEA, transfers outside the EU/EEA are possible, provided that sufficient and appropriate level of data protection is ensured. The CNIL provides an on-site map showing the [different levels of data protection in countries around the world](https://www.cnil.fr/en/data-protection-around-the-world).
* **If you need to host health data**, make sure that provider used is [certified](https://esante.gouv.fr/labels-certifications/hds/liste-des-herbergeurs-certifies) or [approved](https://esante.gouv.fr/labels-certifications/hds/liste-des-herbergeurs-agrees) for this activity.
* Other points to be aware of include:
- the existence of an accessible security policy;
- physical security and safety measures at the hosting site;
- data encryption and other processes to ensure that the provider does not have access to the data entrusted to it;
- the management of updates, the management of authorizations, the authentication of personnel and the security of application developments;
- the easy reversibility/portability of data in a structured and commonly used format, on request and at any time.

View File

@ -0,0 +1,57 @@
# Sheet n°6: Secure your websites, applications and servers
#### Any website, application or server must incorporate basic state-of-the-art security rules, not only on network communications but also on authentication and infrastructure.
## Securing communication networks
* **Implement TLS version 1.2 or 1.3** (replacing SSL) on all websites and for data transmissions of your mobile applications, for example with [LetsEncrypt](https://letsencrypt.org/fr/), using only the most recent versions and checking its correct implementation.
* **Make the use of TLS mandatory** for all pages of your site and for your mobile applications.
* **Limit the communication ports** strictly necessary for the proper functioning of the installed applications. If access to a web server is only possible using the HTTPS protocol, only ports 443 and 80 of this server must be accessible, all other ports can be blocked by the firewall.
* **The OWASP has published on its website some cheatsheets** for exemple to [correctly implement TLS](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html) or to [secure a webservice](https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html).
## Securing Authentications
* **Follow [the CNIL recommendation on passwords](https://www.cnil.fr/fr/node/23803)**. In particular, remember to limit the number of access attempts.
* **Never store passwords in clear text**. Store them as a hash using a proven library, such as [bcrypt](https://en.wikipedia.org/wiki/Bcrypt).
* **If cookies are used for authentication**, it is recommended:
* to force the use of HTTPS via [HSTS](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security);
* to use the `secure` flag;
* use the `HttpOnly` flag.
* **Test the cryptographic suites installed on the systems** and disable obsolete ones (RC4, MD4, MD5 etc.). Encourage the use of AES256. [Read the OSWAP note on the subject](https://owasp.org/www-project-cheat-sheets/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html).
* **Adopt a specific password policy for administrators**. Change the passwords, at least, each time an administrator leaves and in case of suspected breach. Encourage strong authentication when possible.
* **Limit access to administration tools and interfaces to qualified staff.** Encourage the use of lower-privilege accounts for day-to-day operations.
* **Remote access to administration interfaces should be subject to increased security measures.** For example, for internal servers, implementing a VPN with strong authentication of the user and the workstation he or she is using may be a good solution.
## Securing infrastructures
* **Make backups, if possible encrypted and checked regularly**. This is especially useful in case of a ransomware attack on your systems as having backups for all your systems will be the only measure that will allow you to restore your systems.
* **Limit the size of the software stack used,** and for each element of the stack:
* **Install critical updates** without delay by scheduling an automatic weekly check;
* **Automate a vulnerability watch** by subscribing to the [NVD Data Feeds](https://nvd.nist.gov/vuln/data-feeds) for example.
* **Use vulnerability detection tools** for the most critical processes to detect possible security breach. Systems for detecting and preventing attacks on critical systems or servers can also be used. These tests must be conducted regularly and before any new software version is put into production.
* **Restrict or fordbid physical and software access to diagnostic and remote configuration ports.** For example, you can list all open ports using the *netstat* tool.
* **Protect the databases you make available on the Internet**, at least by restricting access as much as possible (for example, by IP filtering) and by changing the default password for the administrator account.
* In terms of database management, good practices include:
* **using nominative accounts** for database access and create specific accounts for each application;
* **revoking the administrative privileges** of user or application accounts to avoid modification to database structure (table, vues, process, etc);
* having protection against SQL or script injection attacks;
* encouraging at rest disk and database encryption.

View File

@ -0,0 +1,29 @@
# Sheet n°7: Minimize data collection
#### You shall only collect personal data that is adequate, relevant and necessary in relation to the purposes for which they are processed, as defined at the time of collection.
## Before collection, think about the different types of data you need to collect and try to limit your collection to what is strictly necessary.
* Think about the different **types of data** that will need to be collected before an application is implemented and **document** this thinking.
* If specific data is not **needed for a certain category of people**, do not collect it.
* Process and store data in a way that **reduces accuracy** (similar to pseudonymization). For example, store only the year of birth instead of a full date of birth if the application only needs the year.
* If collecting particularly sensitive data, such as health or criminal convictions data, be sure to collect only the **minimum required**. Due to the regulatory constraints, the simplest solution is still to **not collect them** if you can do without them.
* Minimize the amount of data collected also in the **log data** and do not store sensitive or critical data (health data, passwords, etc.).
* Some features may improve the user experience, but are **not strictly necessary for your application to work properly** (e.g. geolocation to simplify a geographic search). In this case, the end user must be able to **choose whether or not to use** this functionality. If he uses it, the data that you are led to collect for its operation must only be kept for the time strictly necessary for its operation and never be used for other purposes.
* Remember to associate **retention periods** for each category of data, depending on the purpose of the processing and the legal or regulatory obligations relating to their retention. Logs must also have a retention period. Document the defined retention durations. You will need to be able to justify them.
## Once the data has been collected, set up automatic deletion mechanisms.
* Implement an automatic **purge** system at the end of the shelf life. You can also implement manual reviews of stored data on a periodic basis.
* To ensure complete erasure, erase **physically** all data that is no longer needed using specialized tools or by destroying the physical media.
* If the data is still useful, you can reduce its sensitivity by using **pseudomisation** or even **anonymisation** methods. In case of pseudonymization, these data remain subject to the regulations on personal data (see [Sheet 1](#Sheet_n°1_:_Identify_personal_data)).
* Log the **automatic deletion procedures**. The corresponding logs can be used as a **proof of deletion** of a data item.

View File

@ -0,0 +1,28 @@
# Sheet n°8: Manage user profiles
#### The way to manage profiles of your collaborators and your end-users must be thought out upstream of your developments. It consists in defining different access and authorization profiles so that each person can access only the data he or she actually needs.
## Good practices for user management
* It all starts with the **use of unique and individual identifiers**, whether they are users of your application or collaborators in development.
* Make sure to **impose authentication** before any access to personal data, in accordance with the [recommendations of the CNIL](https://www.cnil.fr/en/passwords-minimum-security-recommendations-businesses-and-citizens).
* To ensure that each person (user or collaborator) can only access to **data he or she actually needs**, your system must provide **differentiated data access management policies** (read, write, delete, etc.) according to people and needs. A global user profile management mechanism will allow you to group different rights according to a role exercised by a group of users within the application.
* The management of user profiles can be used along with **logging systems in order to trace activities, and detect anomalies or events related to security**, such as fraudulent access and misuse of personal data. These devices must not be used for any purpose other than ensuring the proper use of the computer system. Logs must also not be kept longer than necessary. In general, a period of six months is adequate.
* You can also plan code audits or penetration testing within your development environment to **ensure robustness of your profile management system**.
## Streamline the management of clearance profiles
* Plan to **document or automate the movement of your collaborators**. For example, these procedures should lead the actions to be taken when people are no longer authorized to access a room or an IT resource, or at the end of their contract.
* Managing your users and collaborators implies **a regular review of the permission** according to the evolution of uses and organizational movements within your project. The use of directory services, such as _Lightweight Directory Access Protocol_ (_LDAP_), will help you monitor these changes and allow you to refine your access strategies, for example by assigning roles based on usage profiles. This allows you to better respect the principle of least privilege.
* The use of "supreme" accounts (type _root_, administrator, etc.) has to be avoided for conventional operations, as it constitutes the keystone of your system and a privileged target for a possible external attacker. We recommend that you associate a strong password policy with it (10 to 20 characters or multi-factor) and that you limit the number of people with knowledge of it to the strictest necessary.
* **Favour the use of a password manager within your project** and the transition to strong authentication when possible. Avoid generic accounts shared by several people.

View File

@ -0,0 +1,31 @@
# Sheet n°09: Control your libraries and SDKs
#### Do you use libraries, SDKs, or other software components written by third parties? Here are a few tips on how to integrate these tools while keeping control of your developments.
## Make an informed choice
* **Assess the value of adding each dependency.** Some commonly used software bricks are only a few lines long. However, each added element is an increase in your system's attack surface. In the case where a single library offers several functionalities, integrate only the functionalities you actually need. By activating the minimum number of functionalities, you reduce the number of potential bugs that could occur.
* **Choose maintained software, libraries and SDKs:**
* If you want to use free or open source software, try to choose projects or solutions with an active community, regular updates and good documentation.
* If you use other types of solutions with commercial support, contractually ensure that the code will be maintained and updated for the life of your project.
* **Take privacy into account.** Some SDKs or libraries pay for themselves by using personal data collected from the applications or sites on which they are integrated. Make sure that such third parties comply with applicable laws regarding personal data, including a mechanism for obtaining user consent.
* **If you use cryptographic mechanisms, it is strongly discouraged to implement cryptographic algorithms or protocols yourself**, but rather try to choose cryptographic libraries that are maintained, recognized and easy to use.
## Evaluate the selected elements
* **Read the documentation and change the default configurations**. It is important to know how your dependencies work. Third party libraries and SDKs often come with default configuration files, which are rarely changed due to lack of time, which causes many security holes.
* **Audit your libraries and SDKs.** Do you really know what all the libraries and SDKs you integrate do? What data is sent through these dependencies and to whom? This audit will allow you to determine the data protection obligations to be respected and to establish the responsibility of the actors.
* **Map you dependencies.** Third-party libraries and SDKs can also integrate other components: auditing their code will allow you to better map all your dependencies and to better act if a problem affects one of them. It is also recommended that you perform security audits of your third-party components and monitor them.
* **Beware of [typosquatting](https://en.wikipedia.org/wiki/Typosquatting) and other malicious techniques.** Check the names of dependencies, as well as their own dependencies to avoid attacks. Do not copy and paste command lines from unknown sites.
## Maintain libraries and SDKs
* **Use dependency management systems** (such as yum, apt, maven, pip, etc.) to maintain an up-to-date list of your dependencies.
* **Manage updates to your dependencies,** especially in the case of security updates that fix vulnerabilities. You must set up a documented procedure to manage and deploy them as soon as possible.
* **Be aware of the versions of libraries and SDKs at the end of support** that will no longer be maintained: try to find another solution (choose a new library, renew commercial support).
* **Check the status of open-source projects,** especially the change of domain or package ownership, some attacks using malicious updates of popular dependencies.

View File

@ -0,0 +1,27 @@
# Sheet n°10: Ensure quality of the code and its documentation
#### It is essential to adopt good code-writing techniques as soon as possible. Code readability reduce the effort of maintenance and bug fixes over time for you and your (possibly future)collaborators.
## Document code and architecture
* Documentation is sometimes left out during development, due to lack of time or visibility on the project. However, it is **crucial for the maintainability of your project**: it allows you to understand how the code works globally, and to know which parts of the code are affected by a modification.
* **Document the architecture, not just the code**: you need to be able to keep the big picture in mind when you write your documentation and help developers understand how all your components work together. Therefore, focus on diagrams and clear explanations when documenting your project.
* **Maintain the documentation along with the code**: The best way to keep your documentation up to date is to modify it as you go along with the code.
* If you use a source code manager, you can also include documentation changes for each "_commit_" that modifies your code (see in particular [the "Manage your source code" form](#Sheet_n°4_:_Manage your source code)).
* **Do not forget to address security in your documentation**. In particular, you can document the different configuration choices for your application, and explain which settings are the most secure.
## Check the quality of your code and its documentation.
* A quality code involves **adoption of good practices and coding conventions** applied consistently throughout the program. It is also best to refer to [existing conventions](https://github.com/Kristories/awesome-guidelines). Here are a few examples of good practice:
* **Using explicit variable and function names** makes it easier to understand what is going on at first glance.
* **Correctly indenting your code** allows you to see the structure of the code more quickly.
* **Avoiding code redundancy** reduces the correction efforts that have to be made in several places. An oversight is quickly forgotten.
* **Tools can help you control the quality of your code**. Once correctly set up, they will avoid re-reading the code to check the correct implementation of coding conventions. Example of these tools are:
* **Integrated development environments** ("_IDE_"), possibly using plugins ("_plugins_"), can be configured to respect code indentation rules, line breaks between different portions of code, or the position of braces and other parentheses.
* **Source code quality measurement software** can report code duplications, compliance with programming rules or potential bugs.

View File

@ -0,0 +1,29 @@
# Sheet n°11: Test your applications
#### Testing your product allows you to check its correct operation, to ensure a good user experience and to find and prevent defects before it goes into production. Testing your product also reduces the risk of personal data breaches.
## Automate testing
* The **development tests** (unit, functional, etc.) will verify the adequacy between the specifications and the functioning of the product. The **security tests** (random data tests also called "_fuzzing_", _scan_ of vulnerabilities, etc.), will check that the product continues to function acceptably when you move away from its normal use and that it does not present any vulnerability that could allow third parties to compromise its security. Both types of tests are important for the proper functioning of your application.
* Set up a **continuous integration system** to run the tests automatically after each change in your source code.
## Integrate testing into your business strategy.
* Add the implementation of the test environment into the company's strategy. The **acceptable metrics** must be defined jointly by all parties prior to development.
* Metrics to consider are for example:
* The **coverage rate** of tests and their type;
* the **duplication rate** of your code;
* the **number of vulnerabilities** (as defined by the tools) and their type, etc.
## Watch out for your test data!
* "Real" production data should not be used during the development and testing phase. Using personal data from your production database for testing purposes is tantamount to **diverting it from its original purpose**.
* If personal data is used outside of production, it should be noted that the **security risks** are also **increased**: access to the data by people who do not have a need to know, multiple storage locations, etc.
* So build a **dummy data set** that will look like the data that will be processed by your application. A dummy data set will ensure that disclosure of this data will not have any impact on people.
* If you need to **import existing configurations** from production into your test cases, consider **anonymizing the personal data** that may be present.

61
12-Inform users.md Normal file
View File

@ -0,0 +1,61 @@
# Sheet n°12: Inform users
#### The transparency principle of the GDPR requires that any information or communication relating to the processing of personal data should be concise, transparent, comprehensible and easily accessible in plain and simple language.
## Who to inform and when?
* Data subjects must be informed:
* both **in the case of direct data collection** i.e. when data are collected directly from individuals (examples: form, online purchase, subscription of a contract, opening of a bank account) or when they are collected via devices or technologies for observing the activity of individuals (examples: analysis of Internet navigation, geolocation and Wi-Fi analytics/tracking for audience measurement, etc.) ;
* and **in the case of indirect collection of personal data**, when data are not collected directly from individuals (examples: data retrieved from trading partners, *data brokers*, publicly available sources, or others).
* This information is needed:
* **during the data collection** in the case of direct collection;
* **as soon as possible in the case of indirect collection** (in particular at the time of first contact with the person) and no later than a month from the collection (with [exceptions](https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-to-be-informed/#exceptions));
* **in the event of a substantial change or a particular event**. For example: new purpose, new recipients, change in the way rights are exercised, [data breach](#Sheet_n°1:_Identify_personal_data).
## What information do I have to give?
* In all cases, you must specify:
* **The identity and contact details of the organization** that collects the data (who processes the data?) ;
* **The purposes** (what will the collected data be used for?);
* **The lawful basis** on which the data processing is based (find all the [**information on the lawful basis**](https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/));
* **The compulsory or optional nature of the data collection** (which implies an upstream reflection on the usefulness of collecting the data in view of the objective pursued - the principle of "minimisation" of the data) and the **consequences for the person** in case of failure to provide the data;
* **Recipients or categories of recipients of the data** (who needs to access or receive them for the defined purposes, including processors?) ;
* **The data retention period** (or criteria for determining it);
* **The existence of data subjects' rights and the means to exercise them** (the rights of access, rectification, erasure and restriction are applicable to all processing operations) ;
* **The contact details of the Data Protection Officer** of the body, if appointed, or of a contact point on personal data protection issues ;
* **The right to file a complaint with your local Data Protection Agency.**
* In certain specific cases, additional information must be provided, for example in the case of data transfers outside the EU, fully automated decision-making or profiling, or when the lawful basis for the processing is the legitimate interest pursued by the body collecting the data ( see the [guidelines on transparency](https://www.cnil.fr/sites/default/files/atoms/files/wp260_enpdf_transparency.pdf) for more information).
* In the case of indirect collection, the following must be added:
* **Categories of data** collected ;
* **The source of the data** (indicating in particular whether it comes from publicly available sources).
## In what form should I provide this information?
* The information must be **easy to access**: the user must be able to find it without difficulty.
* **It must be provided in a clear and comprehensible manner**, i.e. with simple vocabulary (short sentences, no legal or technical terms, no ambiguities) and information adapted to the target audience (with particular attention to children and vulnerable persons).
* **It should be written in a concise manner**. In order to avoid the pitfall of a flood of information drowning out the user, it is necessary to **bring the most relevant information at the right time**.
* Data protection related information must be **distinguishable from information that is not specifically related to privacy (such as contractual clauses or general terms and conditions of use).**
## What communication should be made when data security is compromised?
* **An organization may mistakenly or negligently suffer, accidentally or maliciously, a personal data breach, i.e. the destruction, loss, alteration or unauthorized disclosure of data**. In this case, the organization must report the violation to the local data protection agency within **72 hours** if it is likely to pose a risk to the rights and freedoms of individuals.
* If these risks are high, the organization must also inform the persons concerned as soon as possible and provide them with advice on how to protect their data (e.g. cancellation of a compromised bank card, modification of a password, modification of privacy settings, etc.).
* Notification of the violation to the CNIL must be made via the [CNIL website](https://www.cnil.fr/fr/notifier-une-violation-de-donnees-personnelles).
## Useful resources
* The [Data & Design](https://design.cnil.fr/en/) site developed by the CNIL's Digital Innovation Laboratory develops these concepts and contains [interface examples](https://design.cnil.fr/en/concepts/information/).
* The CNIL site also contains [many examples of information notices in French](https://www.cnil.fr/fr/rgpd-exemples-de-mentions-dinformation).
* The [personal data violations](https://www.cnil.fr/fr/les-violations-de-donnees-personnelles) page on the CNIL website (in French).

View File

@ -0,0 +1,43 @@
# Sheet n°13: Prepare for the exercise of people rights
#### The persons whose data you process have rights on his or her data: right of access, to rectification, to object, to erasure, to data portability and to restriction of processing. You must give them the means to effectively exercise their rights and provide in your computer systems the technical tools that will allow their rights to be properly taken into account.
#### Preparing in advance how they will contact you and how you will deal with their requests will enable you to manage the exercise of these rights effectively.
## Minimum measures to be put in place
* All organisations that use personal data have **the obligation to indicate where and how** individuals can exercise their rights in relation to this data. For example, you can mention an e-mail address or a web form when informing individuals, as well as in your privacy policy.
* In order to facilitate the exercise of people's rights, these rights may also be **implemented**, in whole or in part, directly in **the application or software you develop**. This specific implementation is not mandatory, but it allows you to meet users' expectations and reduce the time and complexity of processing this type of request.
* Above all, in case of access or operations directly performed by a person who exercises his or her rights, do not forget to manage his **authentication** in a secure way. Overall, **trace** also all operations that have an impact on his or her personal data.
## Here are some examples of rights and their possible implementation
* **Right of access**: people have the right to obtain a copy of all the information you have about them. This allows, among other things, a person to know whether data concerning him or her is being processed and to obtain a readable copy in an understandable format. In particular, it allows the accuracy of the data to be checked.
**_Possible implementation_**: Provide a functionality to display all data relating to a person. If there is a lot of data, you can split the data into several displays. If the data is too large, offer the person to download an archive containing all his or her data.
* **Right to erasure**: Persons have the right to request the deletion of all the data you hold on them.
**_Possible implementations_**:
1. Provide a functionality to erase all data relating to a person.
2. Also provide for automatic notification of processors to also erase the data relating to that person.
3. Provide for data erasure also in backups, or provide an alternative solution that does not restore erased data relating to that person.
* **Right to object**: individuals have the right to object in certain cases to their data being used for a specific purpose.
**_Possible implementation_**: provide a functionality allowing the data subject to object to the processing. When the data subject exercises his or her right to object in this way, the controller must delete data already collected, and must not subsequently collect any more data related to that person.
* **Right to data portability**: Individuals have the right to retrieve their data in a machine-readable format for their own use or for transfer to another organisation.
**_Possible implementation_**: Provide a feature that allows the data subject to download his or her data in a standard machine-readable format (CSV, XML, JSON, etc.).
* **Right to rectification**: Individuals have the right to request the modification of their data when it is incorrect in order to limit the use or dissemination of erroneous information.
**_Possible implementation_**: Allow to directly modify data in the user account.
* **Right to restriction of processing**: individuals have the right to request that the processing of their data be blocked for a certain period of time, e.g. the time to examine a dispute on their part regarding the use of their data or a request to exercise rights.
**_Possible implementation_**: Allow administrators to put data about a person in "quarantine": this data can then no longer be read or modified.
## In conclusion
* The [Data & Design site](https://design.cnil.fr/en) developed by the CNIL's Digital Innovation Laboratory develops these concepts and contains [examples of interfaces for exercising rights](https://design.cnil.fr/en/concepts/exercising-rights/).
* Finally, be **inventive**! (In case of doubt, ask the CNIL for advice).

View File

@ -0,0 +1,29 @@
# Sheet n°14: Define a data retention period
#### Personal data cannot be kept for an indefinite period of time: this must be defined according to the purposes of the processing. Once this purpose has been achieved, the data should be archived, deleted or made anonymous (e.g. in order to produce statistics).
## Data retention cycles
* The personal data retention cycle can be divided into **three distinct successive phases**:
* The active database;
* Intermediate archiving;
* Final archiving or deletion.
* The mechanisms for deleting personal data from the active bases ensure that the data are kept and accessible by the operational services only **for the time necessary to achieve the purpose of the processing operation**.
* Ensure that **data is not kept in active databases** by simply noting them **as being archived**. The archived data (intermediate archive) must be accessible only to a specific service responsible for accessing and removing them from the archive if necessary.
* Please also ensure that you have **specified access modes** for the archived data, as the use of an archive must be on an ad hoc and exceptional basis.
* If possible, use the same implementation when implementing the **data purging or anonymisation** as the one managing the **right to erasure** (see [sheet on the exercise of rights](Sheet_n°13:_Prepare_for_the_exercise_of_people's_rights)), in order to guarantee a homogeneous operation of your system.
## Some examples of shelf life
* The **data relating to payroll management or employee time control** can be kept for 5 years.
* The **data in a medical file** must be kept for 20 years.
* The **data of a prospect not responding to any solicitation** can be kept for 3 years.
* The **log data** can be kept for 6 months.

View File

@ -0,0 +1,59 @@
# Sheet n°15: Take into account the legal basis in the technical implementation
#### Processing of personal data must be based on one of the "legal basis" mentioned in [Article 6 of the GDPR](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=FR#d1e1888-1-1). The legal basis of a processing operation is in a way the justification of the existence of the processing operation. The choice of a legal basis has a direct impact on the conditions for implementing the processing operation and [the rights of individuals](#Fiche_n°13_:_Preparing_the_exercise_of_persons_rights). Thus, anticipating the legal basis of the processing operations prior to any development will help you integrating the necessary functions to ensure that these processing operations comply with the law and respect the individuals rights.
## Definition of the legal bases in the RGPD
* In the context of a development for a private organization (companies, associations, etc.), the legal basis often used are:
* **The contract**: the processing is necessary for the performance or preparation of a contract between the data subject and the body carrying out the processing operation;
* **The legitimate interest**: the organization has a "legitimate" interest in carrying out the processing and it is not likely to adversely affect the rights and freedoms of the data subjects;
* **Consent**: the data subject has given his or her explicit consent to the processing.
* If you are a public authority or a body pursuing tasks in the public interest, other legal bases may also be used:
* **The legal obligation**: the processing is imposed by regulatory texts.
* **The public-interest mission**: the processing is necessary for the performance of a task carried out in the public interest.
* Finally, in very specific cases, **protect of vital interests** may be used as a legal basis, for example when processing is necessary to monitor the spread of epidemics or in cases of humanitarian emergency.
## Choose the appropriate legal basis
* First of all, check on the CNIL website that **a text does not impose any particular constraints** (for example: [cookies and other trackers](https://www.cnil.fr/sites/default/files/atoms/files/draft_recommendation_cookies_and_other_trackers_en.pdf)).
* **Only one legal basis must be chosen** for a given purpose. Legal basis cannot be cumulated for the same purpose. The same data processing operation may pursue several purposes and a legal basis must then be defined for each of them.
* As mentioned above, if you are a **public authority**, the legal obligation and the public interest mission will be the most relevant in most cases.
* If your processing operation is part of a contractual relationship and its purpose is objectively and strictly necessary for the provision of the user's service (e.g. name, first name and address to create an account on an e-commerce site) then **contract should be appropriate**.
* If your processing is not part of a contractual relationship with the user, then **the legal basis of consent or legitimate interest** may be invoked. If your processing is potentially intrusive (profiling, collection of geolocation data, etc.) then **consent is likely to be the appropriate legal basis**.
* If your processing contains **sensitive data** (health data, data concerning life or sexual orientation, etc.), then you will need to identify, in addition to the legal basis, an exception provided for by [Article 9 of the GDPR](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=FR#d1e2051-1-1).
## Rights exercises and modalities of information to be provided according to legal basis
* The following table summarizes the exercises of rights to be provided in accordance with legal basis:
| | Right of access | Right to rectification | Right to erasure | Right to restriction of processing| Right to data portability | Right to object |
|:---------------------:|:-------------:|:----------------------:|:--------------------:|:-----------------------------------:|:----------------------:|:---------------------------:|
| **Consent** | ✔ | ✔ | ✔ | ✔ | ✔ | **Withdraw of consent**|
| **Contract** | ✔ | ✔ | ✔ | ✔ | ✔ | ✘ |
| **Legitimate interest** | ✔ | ✔ | ✔ | ✔ | ✘ | ✔ |
| **Legal obligation** | ✔ | ✔ | ✘ | ✔ | ✘ | ✘ |
| **Public interest** | ✔ | ✔ | ✘ | ✔ | ✘ | ✔ |
| **Protect of vital interests** | ✔ | ✔ | ✔ | ✔ | ✘ | ✘ |
* The legal basis used must **always appear in the information transmitted to the person**.
* **Where your processing is based on legitimate interest**, you must also indicate the legitimate interests pursued (fight against fraud, system security, etc.).
* It is recommended to **document your choice of legal basis**. As an example, these choices can be indicated in a processing map or associated with your technical documentation.
## The specific case of cookies and other trackers
* The European ePrivacy Directive requires the user's consent before any action is taken to store information - via cookies, identifiers or other tracers (software fingerprints, pixels) or to access information stored in the user's terminal equipment.
* However, an exception is made when cookies are for the sole purpose of carrying out electronic communication, or are strictly necessary to provide a service requested by the user.
* Furthermore, the use of a single tracer for multiple purposes does not exempt from obtaining consent for the purposes that require it. For example, if an authentication cookie is also used for advertising targeting purposes, consent must be obtained for the latter purpose, in the same way as for a non-logged site.

View File

@ -0,0 +1,49 @@
# Sheet n°16: Use analytics on your websites and applications
#### Audience measurement tools are used to obtain information about the navigation of visitors on a website or mobile application. In particular, they make it possible to understand how users arrive at a site and to reconstruct their journey. Using cookies, they are subject to the rule of consent, except in one particular case. Please note that this section is relative to the ePrivacy directive and may be subject to national variation. Contact you local data protection agency to know its position.
## Obtaining consent
* Generally speaking, **before depositing or reading a cookie or tracer,** editors of sites or applications must:
* inform Internet users of the purpose of cookies;
* obtain their consent;
* provide them with a means of refusing them.
* Unless they fall exactly within the perimeter defined below, **this obligation applies to tracers used for audience measurement**.
## To benefit from the exemption from consent
* **Subject to a number of conditions**, cookies used for audience measurement are exempt from consent.
* **These conditions, as specified in the [guidelines on cookies and other trackers](https://www.cnil.fr/en/cookies-and-other-tracking-devices-cnil-publishes-new-guidelines), are**:
* To inform users of their use;
* To give them the ability to object to their use;
* To limit to the following purposes only:
* audience measurement;
* A/B testing;
* Not to cross-check the data processed with other processing (customer files, statistics on visits to other sites, etc.);
* To limit the scope of the tracer to a single site or application editor;
* To truncate the last byte of the IP address;
* To limit the lifetime of the trackers to 13 months.
* Provided that the conditions are met, **we therefore switch from an opt-in to an opt-out regime**.
* It is also possible for the same third party (subcontractor) to provide a comparative audience measurement service to multiple publishers, provided that **the data is collected, processed and stored independently for each publisher and that the trackers are independent of each other**.
## In practice
* **Most large audience measurement offerings do not fall within the scope of the exemption, regardless of their configuration**.
* In order to benefit from this exemption, please contact your solution provider or use open source software such as Matomo that you can configure yourself.

673
LICENSE Normal file
View File

@ -0,0 +1,673 @@
GNU GENERAL PUBLIC LICENSE
Version 3, 29 June 2007
Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The GNU General Public License is a free, copyleft license for
software and other kinds of works.
The licenses for most software and other practical works are designed
to take away your freedom to share and change the works. By contrast,
the GNU General Public License is intended to guarantee your freedom to
share and change all versions of a program--to make sure it remains free
software for all its users. We, the Free Software Foundation, use the
GNU General Public License for most of our software; it applies also to
any other work released this way by its authors. You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
them if you wish), that you receive source code or can get it if you
want it, that you can change the software or use pieces of it in new
free programs, and that you know you can do these things.
To protect your rights, we need to prevent others from denying you
these rights or asking you to surrender the rights. Therefore, you have
certain responsibilities if you distribute copies of the software, or if
you modify it: responsibilities to respect the freedom of others.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must pass on to the recipients the same
freedoms that you received. You must make sure that they, too, receive
or can get the source code. And you must show them these terms so they
know their rights.
Developers that use the GNU GPL protect your rights with two steps:
(1) assert copyright on the software, and (2) offer you this License
giving you legal permission to copy, distribute and/or modify it.
For the developers' and authors' protection, the GPL clearly explains
that there is no warranty for this free software. For both users' and
authors' sake, the GPL requires that modified versions be marked as
changed, so that their problems will not be attributed erroneously to
authors of previous versions.
Some devices are designed to deny users access to install or run
modified versions of the software inside them, although the manufacturer
can do so. This is fundamentally incompatible with the aim of
protecting users' freedom to change the software. The systematic
pattern of such abuse occurs in the area of products for individuals to
use, which is precisely where it is most unacceptable. Therefore, we
have designed this version of the GPL to prohibit the practice for those
products. If such problems arise substantially in other domains, we
stand ready to extend this provision to those domains in future versions
of the GPL, as needed to protect the freedom of users.
Finally, every program is threatened constantly by software patents.
States should not allow patents to restrict development and use of
software on general-purpose computers, but in those that do, we wish to
avoid the special danger that patents applied to a free program could
make it effectively proprietary. To prevent this, the GPL assures that
patents cannot be used to render the program non-free.
The precise terms and conditions for copying, distribution and
modification follow.
TERMS AND CONDITIONS
0. Definitions.
"This License" refers to version 3 of the GNU General Public License.
"Copyright" also means copyright-like laws that apply to other kinds of
works, such as semiconductor masks.
"The Program" refers to any copyrightable work licensed under this
License. Each licensee is addressed as "you". "Licensees" and
"recipients" may be individuals or organizations.
To "modify" a work means to copy from or adapt all or part of the work
in a fashion requiring copyright permission, other than the making of an
exact copy. The resulting work is called a "modified version" of the
earlier work or a work "based on" the earlier work.
A "covered work" means either the unmodified Program or a work based
on the Program.
To "propagate" a work means to do anything with it that, without
permission, would make you directly or secondarily liable for
infringement under applicable copyright law, except executing it on a
computer or modifying a private copy. Propagation includes copying,
distribution (with or without modification), making available to the
public, and in some countries other activities as well.
To "convey" a work means any kind of propagation that enables other
parties to make or receive copies. Mere interaction with a user through
a computer network, with no transfer of a copy, is not conveying.
An interactive user interface displays "Appropriate Legal Notices"
to the extent that it includes a convenient and prominently visible
feature that (1) displays an appropriate copyright notice, and (2)
tells the user that there is no warranty for the work (except to the
extent that warranties are provided), that licensees may convey the
work under this License, and how to view a copy of this License. If
the interface presents a list of user commands or options, such as a
menu, a prominent item in the list meets this criterion.
1. Source Code.
The "source code" for a work means the preferred form of the work
for making modifications to it. "Object code" means any non-source
form of a work.
A "Standard Interface" means an interface that either is an official
standard defined by a recognized standards body, or, in the case of
interfaces specified for a particular programming language, one that
is widely used among developers working in that language.
The "System Libraries" of an executable work include anything, other
than the work as a whole, that (a) is included in the normal form of
packaging a Major Component, but which is not part of that Major
Component, and (b) serves only to enable use of the work with that
Major Component, or to implement a Standard Interface for which an
implementation is available to the public in source code form. A
"Major Component", in this context, means a major essential component
(kernel, window system, and so on) of the specific operating system
(if any) on which the executable work runs, or a compiler used to
produce the work, or an object code interpreter used to run it.
The "Corresponding Source" for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities. However, it does not include the work's
System Libraries, or general-purpose tools or generally available free
programs which are used unmodified in performing those activities but
which are not part of the work. For example, Corresponding Source
includes interface definition files associated with source files for
the work, and the source code for shared libraries and dynamically
linked subprograms that the work is specifically designed to require,
such as by intimate data communication or control flow between those
subprograms and other parts of the work.
The Corresponding Source need not include anything that users
can regenerate automatically from other parts of the Corresponding
Source.
The Corresponding Source for a work in source code form is that
same work.
2. Basic Permissions.
All rights granted under this License are granted for the term of
copyright on the Program, and are irrevocable provided the stated
conditions are met. This License explicitly affirms your unlimited
permission to run the unmodified Program. The output from running a
covered work is covered by this License only if the output, given its
content, constitutes a covered work. This License acknowledges your
rights of fair use or other equivalent, as provided by copyright law.
You may make, run and propagate covered works that you do not
convey, without conditions so long as your license otherwise remains
in force. You may convey covered works to others for the sole purpose
of having them make modifications exclusively for you, or provide you
with facilities for running those works, provided that you comply with
the terms of this License in conveying all material for which you do
not control copyright. Those thus making or running the covered works
for you must do so exclusively on your behalf, under your direction
and control, on terms that prohibit them from making any copies of
your copyrighted material outside their relationship with you.
Conveying under any other circumstances is permitted solely under
the conditions stated below. Sublicensing is not allowed; section 10
makes it unnecessary.
3. Protecting Users' Legal Rights From Anti-Circumvention Law.
No covered work shall be deemed part of an effective technological
measure under any applicable law fulfilling obligations under article
11 of the WIPO copyright treaty adopted on 20 December 1996, or
similar laws prohibiting or restricting circumvention of such
measures.
When you convey a covered work, you waive any legal power to forbid
circumvention of technological measures to the extent such circumvention
is effected by exercising rights under this License with respect to
the covered work, and you disclaim any intention to limit operation or
modification of the work as a means of enforcing, against the work's
users, your or third parties' legal rights to forbid circumvention of
technological measures.
4. Conveying Verbatim Copies.
You may convey verbatim copies of the Program's source code as you
receive it, in any medium, provided that you conspicuously and
appropriately publish on each copy an appropriate copyright notice;
keep intact all notices stating that this License and any
non-permissive terms added in accord with section 7 apply to the code;
keep intact all notices of the absence of any warranty; and give all
recipients a copy of this License along with the Program.
You may charge any price or no price for each copy that you convey,
and you may offer support or warranty protection for a fee.
5. Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these conditions:
a) The work must carry prominent notices stating that you modified
it, and giving a relevant date.
b) The work must carry prominent notices stating that it is
released under this License and any conditions added under section
7. This requirement modifies the requirement in section 4 to
"keep intact all notices".
c) You must license the entire work, as a whole, under this
License to anyone who comes into possession of a copy. This
License will therefore apply, along with any applicable section 7
additional terms, to the whole of the work, and all its parts,
regardless of how they are packaged. This License gives no
permission to license the work in any other way, but it does not
invalidate such permission if you have separately received it.
d) If the work has interactive user interfaces, each must display
Appropriate Legal Notices; however, if the Program has interactive
interfaces that do not display Appropriate Legal Notices, your
work need not make them do so.
A compilation of a covered work with other separate and independent
works, which are not by their nature extensions of the covered work,
and which are not combined with it such as to form a larger program,
in or on a volume of a storage or distribution medium, is called an
"aggregate" if the compilation and its resulting copyright are not
used to limit the access or legal rights of the compilation's users
beyond what the individual works permit. Inclusion of a covered work
in an aggregate does not cause this License to apply to the other
parts of the aggregate.
6. Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms
of sections 4 and 5, provided that you also convey the
machine-readable Corresponding Source under the terms of this License,
in one of these ways:
a) Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by the
Corresponding Source fixed on a durable physical medium
customarily used for software interchange.
b) Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by a
written offer, valid for at least three years and valid for as
long as you offer spare parts or customer support for that product
model, to give anyone who possesses the object code either (1) a
copy of the Corresponding Source for all the software in the
product that is covered by this License, on a durable physical
medium customarily used for software interchange, for a price no
more than your reasonable cost of physically performing this
conveying of source, or (2) access to copy the
Corresponding Source from a network server at no charge.
c) Convey individual copies of the object code with a copy of the
written offer to provide the Corresponding Source. This
alternative is allowed only occasionally and noncommercially, and
only if you received the object code with such an offer, in accord
with subsection 6b.
d) Convey the object code by offering access from a designated
place (gratis or for a charge), and offer equivalent access to the
Corresponding Source in the same way through the same place at no
further charge. You need not require recipients to copy the
Corresponding Source along with the object code. If the place to
copy the object code is a network server, the Corresponding Source
may be on a different server (operated by you or a third party)
that supports equivalent copying facilities, provided you maintain
clear directions next to the object code saying where to find the
Corresponding Source. Regardless of what server hosts the
Corresponding Source, you remain obligated to ensure that it is
available for as long as needed to satisfy these requirements.
e) Convey the object code using peer-to-peer transmission, provided
you inform other peers where the object code and Corresponding
Source of the work are being offered to the general public at no
charge under subsection 6d.
A separable portion of the object code, whose source code is excluded
from the Corresponding Source as a System Library, need not be
included in conveying the object code work.
A "User Product" is either (1) a "consumer product", which means any
tangible personal property which is normally used for personal, family,
or household purposes, or (2) anything designed or sold for incorporation
into a dwelling. In determining whether a product is a consumer product,
doubtful cases shall be resolved in favor of coverage. For a particular
product received by a particular user, "normally used" refers to a
typical or common use of that class of product, regardless of the status
of the particular user or of the way in which the particular user
actually uses, or expects or is expected to use, the product. A product
is a consumer product regardless of whether the product has substantial
commercial, industrial or non-consumer uses, unless such uses represent
the only significant mode of use of the product.
"Installation Information" for a User Product means any methods,
procedures, authorization keys, or other information required to install
and execute modified versions of a covered work in that User Product from
a modified version of its Corresponding Source. The information must
suffice to ensure that the continued functioning of the modified object
code is in no case prevented or interfered with solely because
modification has been made.
If you convey an object code work under this section in, or with, or
specifically for use in, a User Product, and the conveying occurs as
part of a transaction in which the right of possession and use of the
User Product is transferred to the recipient in perpetuity or for a
fixed term (regardless of how the transaction is characterized), the
Corresponding Source conveyed under this section must be accompanied
by the Installation Information. But this requirement does not apply
if neither you nor any third party retains the ability to install
modified object code on the User Product (for example, the work has
been installed in ROM).
The requirement to provide Installation Information does not include a
requirement to continue to provide support service, warranty, or updates
for a work that has been modified or installed by the recipient, or for
the User Product in which it has been modified or installed. Access to a
network may be denied when the modification itself materially and
adversely affects the operation of the network or violates the rules and
protocols for communication across the network.
Corresponding Source conveyed, and Installation Information provided,
in accord with this section must be in a format that is publicly
documented (and with an implementation available to the public in
source code form), and must require no special password or key for
unpacking, reading or copying.
7. Additional Terms.
"Additional permissions" are terms that supplement the terms of this
License by making exceptions from one or more of its conditions.
Additional permissions that are applicable to the entire Program shall
be treated as though they were included in this License, to the extent
that they are valid under applicable law. If additional permissions
apply only to part of the Program, that part may be used separately
under those permissions, but the entire Program remains governed by
this License without regard to the additional permissions.
When you convey a copy of a covered work, you may at your option
remove any additional permissions from that copy, or from any part of
it. (Additional permissions may be written to require their own
removal in certain cases when you modify the work.) You may place
additional permissions on material, added by you to a covered work,
for which you have or can give appropriate copyright permission.
Notwithstanding any other provision of this License, for material you
add to a covered work, you may (if authorized by the copyright holders of
that material) supplement the terms of this License with terms:
a) Disclaiming warranty or limiting liability differently from the
terms of sections 15 and 16 of this License; or
b) Requiring preservation of specified reasonable legal notices or
author attributions in that material or in the Appropriate Legal
Notices displayed by works containing it; or
c) Prohibiting misrepresentation of the origin of that material, or
requiring that modified versions of such material be marked in
reasonable ways as different from the original version; or
d) Limiting the use for publicity purposes of names of licensors or
authors of the material; or
e) Declining to grant rights under trademark law for use of some
trade names, trademarks, or service marks; or
f) Requiring indemnification of licensors and authors of that
material by anyone who conveys the material (or modified versions of
it) with contractual assumptions of liability to the recipient, for
any liability that these contractual assumptions directly impose on
those licensors and authors.
All other non-permissive additional terms are considered "further
restrictions" within the meaning of section 10. If the Program as you
received it, or any part of it, contains a notice stating that it is
governed by this License along with a term that is a further
restriction, you may remove that term. If a license document contains
a further restriction but permits relicensing or conveying under this
License, you may add to a covered work material governed by the terms
of that license document, provided that the further restriction does
not survive such relicensing or conveying.
If you add terms to a covered work in accord with this section, you
must place, in the relevant source files, a statement of the
additional terms that apply to those files, or a notice indicating
where to find the applicable terms.
Additional terms, permissive or non-permissive, may be stated in the
form of a separately written license, or stated as exceptions;
the above requirements apply either way.
8. Termination.
You may not propagate or modify a covered work except as expressly
provided under this License. Any attempt otherwise to propagate or
modify it is void, and will automatically terminate your rights under
this License (including any patent licenses granted under the third
paragraph of section 11).
However, if you cease all violation of this License, then your
license from a particular copyright holder is reinstated (a)
provisionally, unless and until the copyright holder explicitly and
finally terminates your license, and (b) permanently, if the copyright
holder fails to notify you of the violation by some reasonable means
prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is
reinstated permanently if the copyright holder notifies you of the
violation by some reasonable means, this is the first time you have
received notice of violation of this License (for any work) from that
copyright holder, and you cure the violation prior to 30 days after
your receipt of the notice.
Termination of your rights under this section does not terminate the
licenses of parties who have received copies or rights from you under
this License. If your rights have been terminated and not permanently
reinstated, you do not qualify to receive new licenses for the same
material under section 10.
9. Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or
run a copy of the Program. Ancillary propagation of a covered work
occurring solely as a consequence of using peer-to-peer transmission
to receive a copy likewise does not require acceptance. However,
nothing other than this License grants you permission to propagate or
modify any covered work. These actions infringe copyright if you do
not accept this License. Therefore, by modifying or propagating a
covered work, you indicate your acceptance of this License to do so.
10. Automatic Licensing of Downstream Recipients.
Each time you convey a covered work, the recipient automatically
receives a license from the original licensors, to run, modify and
propagate that work, subject to this License. You are not responsible
for enforcing compliance by third parties with this License.
An "entity transaction" is a transaction transferring control of an
organization, or substantially all assets of one, or subdividing an
organization, or merging organizations. If propagation of a covered
work results from an entity transaction, each party to that
transaction who receives a copy of the work also receives whatever
licenses to the work the party's predecessor in interest had or could
give under the previous paragraph, plus a right to possession of the
Corresponding Source of the work from the predecessor in interest, if
the predecessor has it or can get it with reasonable efforts.
You may not impose any further restrictions on the exercise of the
rights granted or affirmed under this License. For example, you may
not impose a license fee, royalty, or other charge for exercise of
rights granted under this License, and you may not initiate litigation
(including a cross-claim or counterclaim in a lawsuit) alleging that
any patent claim is infringed by making, using, selling, offering for
sale, or importing the Program or any portion of it.
11. Patents.
A "contributor" is a copyright holder who authorizes use under this
License of the Program or a work on which the Program is based. The
work thus licensed is called the contributor's "contributor version".
A contributor's "essential patent claims" are all patent claims
owned or controlled by the contributor, whether already acquired or
hereafter acquired, that would be infringed by some manner, permitted
by this License, of making, using, or selling its contributor version,
but do not include claims that would be infringed only as a
consequence of further modification of the contributor version. For
purposes of this definition, "control" includes the right to grant
patent sublicenses in a manner consistent with the requirements of
this License.
Each contributor grants you a non-exclusive, worldwide, royalty-free
patent license under the contributor's essential patent claims, to
make, use, sell, offer for sale, import and otherwise run, modify and
propagate the contents of its contributor version.
In the following three paragraphs, a "patent license" is any express
agreement or commitment, however denominated, not to enforce a patent
(such as an express permission to practice a patent or covenant not to
sue for patent infringement). To "grant" such a patent license to a
party means to make such an agreement or commitment not to enforce a
patent against the party.
If you convey a covered work, knowingly relying on a patent license,
and the Corresponding Source of the work is not available for anyone
to copy, free of charge and under the terms of this License, through a
publicly available network server or other readily accessible means,
then you must either (1) cause the Corresponding Source to be so
available, or (2) arrange to deprive yourself of the benefit of the
patent license for this particular work, or (3) arrange, in a manner
consistent with the requirements of this License, to extend the patent
license to downstream recipients. "Knowingly relying" means you have
actual knowledge that, but for the patent license, your conveying the
covered work in a country, or your recipient's use of the covered work
in a country, would infringe one or more identifiable patents in that
country that you have reason to believe are valid.
If, pursuant to or in connection with a single transaction or
arrangement, you convey, or propagate by procuring conveyance of, a
covered work, and grant a patent license to some of the parties
receiving the covered work authorizing them to use, propagate, modify
or convey a specific copy of the covered work, then the patent license
you grant is automatically extended to all recipients of the covered
work and works based on it.
A patent license is "discriminatory" if it does not include within
the scope of its coverage, prohibits the exercise of, or is
conditioned on the non-exercise of one or more of the rights that are
specifically granted under this License. You may not convey a covered
work if you are a party to an arrangement with a third party that is
in the business of distributing software, under which you make payment
to the third party based on the extent of your activity of conveying
the work, and under which the third party grants, to any of the
parties who would receive the covered work from you, a discriminatory
patent license (a) in connection with copies of the covered work
conveyed by you (or copies made from those copies), or (b) primarily
for and in connection with specific products or compilations that
contain the covered work, unless you entered into that arrangement,
or that patent license was granted, prior to 28 March 2007.
Nothing in this License shall be construed as excluding or limiting
any implied license or other defenses to infringement that may
otherwise be available to you under applicable patent law.
12. No Surrender of Others' Freedom.
If conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot convey a
covered work so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you may
not convey it at all. For example, if you agree to terms that obligate you
to collect a royalty for further conveying from those to whom you convey
the Program, the only way you could satisfy both those terms and this
License would be to refrain entirely from conveying the Program.
13. Use with the GNU Affero General Public License.
Notwithstanding any other provision of this License, you have
permission to link or combine any covered work with a work licensed
under version 3 of the GNU Affero General Public License into a single
combined work, and to convey the resulting work. The terms of this
License will continue to apply to the part which is the covered work,
but the special requirements of the GNU Affero General Public License,
section 13, concerning interaction through a network will apply to the
combination as such.
14. Revised Versions of this License.
The Free Software Foundation may publish revised and/or new versions of
the GNU General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the
Program specifies that a certain numbered version of the GNU General
Public License "or any later version" applies to it, you have the
option of following the terms and conditions either of that numbered
version or of any later version published by the Free Software
Foundation. If the Program does not specify a version number of the
GNU General Public License, you may choose any version ever published
by the Free Software Foundation.
If the Program specifies that a proxy can decide which future
versions of the GNU General Public License can be used, that proxy's
public statement of acceptance of a version permanently authorizes you
to choose that version for the Program.
Later license versions may give you additional or different
permissions. However, no additional obligations are imposed on any
author or copyright holder as a result of your choosing to follow a
later version.
15. Disclaimer of Warranty.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. Limitation of Liability.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
17. Interpretation of Sections 15 and 16.
If the disclaimer of warranty and limitation of liability provided
above cannot be given local legal effect according to their terms,
reviewing courts shall apply local law that most closely approximates
an absolute waiver of all civil liability in connection with the
Program, unless a warranty or assumption of liability accompanies a
copy of the Program in return for a fee.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
state the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
Copyright (C) 2017 CNIL
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
Also add information on how to contact you by electronic and paper mail.
If the program does terminal interaction, make it output a short
notice like this when it starts in an interactive mode:
PIA Copyright (C) 2017 CNIL
This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, your program's commands
might be different; for a GUI interface, you would use an "about box".
You should also get your employer (if you work as a programmer) or school,
if any, to sign a "copyright disclaimer" for the program, if necessary.
For more information on this, and how to apply and follow the GNU GPL, see
<http://www.gnu.org/licenses/>.
The GNU General Public License does not permit incorporating your program
into proprietary programs. If your program is a subroutine library, you
may consider it more useful to permit linking proprietary applications with
the library. If this is what you want to do, use the GNU Lesser General
Public License instead of this License. But first, please read
<http://www.gnu.org/philosophy/why-not-lgpl.html>.

100
README.md Normal file
View File

@ -0,0 +1,100 @@
<p align="center"><img src="https://github.com/LINCnil/GDPR-Developer-Guide/raw/master/templates/BANNIERE-EN.JPG" width="100%" align="middle"></p>
# GDPR Developer Guide
#### In order to assist web and application developers in making their work GDPR-compliant, the CNIL has drawn up a new guide to best practices under an open source license, which is intended to be enriched by professionals.
This guide is published under [license GPLv3](https://www.gnu.org/licenses/gpl-3.0.html) and under [open license 2.0](https://www.etalab.gouv.fr/wp-content/uploads/2017/04/ETALAB-Licence-Ouverte-v2.0.pdf) (explicitly compatible with [CC-BY 4.0 FR](https://creativecommons.org/licenses/by/4.0/deed.fr)). You can freely contribute to its redaction.
The [French version](https://github.com/LINCnil/Guide-RGPD-du-developpeur) is the authentic version of this guide.
#### Is this guide for developers only?
This guide is mainly aimed at developers working alone or in teams, team leaders, service providers but also at anyone interested in web or application development.
It provides advice and best practices, and thus gives useful keys to understand the GDPR for every stakeholder, regardless of the size of their structure. It can also stimulate discussions and practices within the organisations and in customer relationships.
#### What does the guide contain?
This guide is divided into **16 thematic sheets** which cover most of the needs of developers at each stage of their project, from the preparation of the development to the use of analytics.
The General Data Protection Regulation (or GDPR) specifies that the protection of the rights and freedoms of natural persons requires that **"appropriate technical and organisational measures be taken to ensure that the requirements of this Regulation are met"** (Recital 78).
The determination of these measures is necessarily **related to the context of the processing operations put in place**, and the controller (the public or private entity processing personal data) must therefore ensure the security of the data it is called upon to process.
The good practices in this guide **are therefore not intended to cover all the requirements of the regulations nor to be prescriptive**, they provide a first level of measures to take into account privacy protection issues in IT developments that are intended to be applied to all data processing projects. Depending on the nature of the processing carried out in certain cases, additional measures will have to be implemented in order to fully comply with the regulations.
## Table of contents
0. [Develop in compliance with the RGPD](#Sheet_n°0_:_Develop_in_compliance_with_the_RGPD)
1. [Identify personal data](#Sheet_n°1_:_Identify_personal_data)
2. [Prepare your development](#Sheet_n°2_:_Prepare_your_development)
3. [Securing your development environment](#Sheet_n°3_:_Securing_your_development_environment)
4. [Manage your source code](#Sheet_n°4_:_Manage_your_source_code)
5. [Make an informed choice of architecture](#Sheet_n°5_:_Make_an_informed_choice_of_architecture)
6. [Securing your websites, applications and servers](#Sheet_n°6_:_Securing_your_websites,_applications_and_servers)
7. [Minimize data collection](#Sheet_n°7_:_Minimize_data_collection)
8. [Manage user profiles](#Sheet_n°8_:_Manage_users_profiles)
9. [Control your libraries and SDKs](#Sheet_n°09_:_Control_your_libraries_and_SDKs)
10. [Ensure the quality of the code and its documentation](#Sheet_n°10_:_Ensure_quality_of_the_code_and_its_documentation)
11. [Test your applications](#Sheet_n°11_:_Test_your_applications)
12. [Inform users](#Sheet_n°12_:_Inform_users)
13. [Prepare to exercise people's rights](#Sheet_n°13_:_Prepare_for_the_exercise_of_people_rights)
14. [Define a data retention period](#Sheet_n°14_:_Define_a_data_retention_period)
15. [Take into account the legal basis in the technical implementation](#Sheet_n°15_:_Take_into_account_the_legal_bases_in_the_technical_implementation)
16. [Use analytics on your websites and applications](#Sheet_n°16:_Use_analytics_on_your_websites_and_applications)
## How can I contribute to this guide?
**This guide is available in two versions**:
* A [web version on the CNIL website](http://www.cnil.fr/en/rgpd-developers-guide) and in the tab [the "Releases" tab](https://github.com/LINCnil/GDPR-Developer-Guide/releases) of this repository;
* This [GitHub version](https://github.com/LINCnil/GDPR-Developer-Guide), which offers the possibility for everyone to contribute.
**The contribution is done in a few steps**:
* Register on Github;
* Go to the project page;
* You can:
* Use the "Issue" tab to open comments or participate in the discussion
* Use the "Fork" option to make your own modifications and propose their inclusion via the "Pull Requests" button.
**Your contribution proposal will be examined by the CNIL before publication**. The web version of the RGPD developer's guide will be regularly updated.
## Usage
To release this repository yourself, you can use the **Pandoc** tool. This tool will allow you to convert the records into a docx file or an HTML document.
You can find the instructions to install this tool [here]( https://pandoc.org/installing.html)
* **To generate a .docx file**:
```bash
pandoc -s --toc --toc-depth=1 -o Guide_RGPD_developper.docx [0-9][0-9]*.md
```
* **To generate an .html file**:
```bash
pandoc -s --template="templates/mytemplate.html" -H templates/pandoc.css -o index.html README.md [0-9][0-9]*.md
```

1016
index.html Normal file

File diff suppressed because it is too large Load Diff

BIN
templates/BANNIERE-EN.JPG Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 42 KiB

126
templates/mytemplate.html Normal file
View File

@ -0,0 +1,126 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"$if(lang)$ lang="$lang$" xml:lang="$lang$"$endif$$if(dir)$ dir="$dir$"$endif$>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<meta name="generator" content="pandoc" />
$for(author-meta)$
<meta name="author" content="$author-meta$" />
$endfor$
$if(date-meta)$
<meta name="date" content="$date-meta$" />
$endif$
$if(keywords)$
<meta name="keywords" content="$for(keywords)$$keywords$$sep$, $endfor$" />
$endif$
<title>$if(title-prefix)$$title-prefix$ $endif$$pagetitle$</title>
<style type="text/css">code{white-space: pre;}</style>
$if(quotes)$
<style type="text/css">q { quotes: "“" "”" "" ""; }</style>
$endif$
$if(highlighting-css)$
<style type="text/css">
$highlighting-css$
</style>
$endif$
$for(css)$
<link rel="stylesheet" href="$css$" type="text/css" />
$endfor$
$if(math)$
$math$
$endif$
$for(header-includes)$
$header-includes$
$endfor$
<script>
document.addEventListener('DOMContentLoaded', function() {
TableOfContents();
}
);
function TableOfContents(container, output) {
var toc = "";
var level = 0;
var container = document.querySelector(container) || document.querySelector('#contents');
var output = output || '#toc';
//Inspiration from here: https://stackoverflow.com/questions/187619/is-there-a-javascript-solution-to-generating-a-table-of-contents-for-a-page
container.innerHTML = container.innerHTML.replace(/<h([\d]) id=".*">([^<]+)?<\/h([\d])>/gi, function (str, openLevel, titleText, closeLevel) {
console.log(str,openLevel)
if (openLevel != closeLevel || openLevel>2) {
return str;
}
if (openLevel > level) {
toc += (new Array(openLevel - level + 1)).join('<ul>');
} else if (openLevel < level) {
toc += (new Array(level - openLevel + 1)).join('</li></ul>');
} else {
toc += (new Array(level+ 1)).join('</li>');
}
level = parseInt(openLevel);
var anchor = titleText.replace(/ /g, "_");
if(level ==2){
toc += '<li class="level'+level+'"><a class="greyed" href="#' + anchor + '">' + titleText
+ '</a>';
}else{
toc += '<li class="level'+level+'"><a href="#' + anchor + '">' + titleText
+ '</a>';
}
return '<h' + openLevel + '><a href="#' + anchor + '" id="' + anchor + '">'
+ titleText + '</a></h' + closeLevel + '>';
}
);
if (level) {
toc += (new Array(level + 1)).join('</ul>');
}
document.querySelector(output).innerHTML += toc;
};
</script>
</head>
<body>
<div class="line">
<div class="tableofcontent">
<div style="overflow-y: scroll; height: 100%;">
<div id="toc">
</div>
</div>
</div>
<div id="contents" class="content">
$for(include-before)$
$include-before$
$endfor$
$if(title)$
<div id="$idprefix$header">
<h1 class="title">$title$</h1>
$if(subtitle)$
<h1 class="subtitle">$subtitle$</h1>
$endif$
$for(author)$
<h2 class="author">$author$</h2>
$endfor$
$if(date)$
<h3 class="date">$date$</h3>
$endif$
</div>
$endif$
$if(toc)$
<div id="$idprefix$TOC">
$toc$
</div>
$endif$
$body$
$for(include-after)$
$include-after$
$endfor$
</div>
</div>
</body>
</html>

289
templates/pandoc.css Normal file
View File

@ -0,0 +1,289 @@
<style type="text/css">
body {
font-family: Helvetica, arial, sans-serif;
font-size: 14px;
line-height: 1.6;
padding-top: 10px;
padding-bottom: 10px;
background-color: white;
color: #333;
text-align: justify;
margin: auto;
}
* {
margin: 0;
padding: 0;
align-items: baseline;
background-size: cover;
background-repeat: no-repeat;
background-position: center;
}
body > *:first-child {
margin-top: 0 !important;
}
body > *:last-child {
margin-bottom: 0 !important;
}
.line {
display: -webkit-box;
display: -moz-box;
display: -ms-flexbox;
display: -webkit-flex;
display: flex;
-webkit-flex-flow: row wrap;
flex-flow: row wrap;
}
.tableofcontent {
position:fixed;
width:25%;
height:100%;
}
.greyed{
color:#555;
}
#toc{
padding-right:30px;
padding-bottom: 50px;
text-align: left;
}
.level2{
font-size: 90%;
margin-top: 0px !important;
margin-bottom: 0px !important;
}
.level1{
margin-top: 15px !important;
}
@media all and (min-width: 1000px) {
.content{
margin-left: 25%;
padding:5%;
width:65%
}
}
@media all and (max-width: 1000px) {
.content{
padding:6%;
width:88%;
margin-left: 0%;
}
.tableofcontent {
display:none;
}
}
a {
color: #4183C4;
text-decoration: none;
}
a.absent {
color: #cc0000;
}
a.anchor {
display: block;
padding-left: 30px;
margin-left: -30px;
cursor: pointer;
position: absolute;
top: 0;
left: 0;
bottom: 0;
}
h1, h2, h3, h4, h5, h6 {
margin: 20px 0 10px;
padding: 0;
font-weight: bold;
-webkit-font-smoothing: antialiased;
cursor: text;
position: relative;
text-align: left;
}
h2:first-child, h1:first-child, h1:first-child + h2, h3:first-child, h4:first-child, h5:first-child, h6:first-child {
margin-top: 0;
padding-top: 0;
}
h1:hover a.anchor, h2:hover a.anchor, h3:hover a.anchor, h4:hover a.anchor, h5:hover a.anchor, h6:hover a.anchor {
text-decoration: none;
}
h1 tt, h1 code {
font-size: inherit;
}
h2 tt, h2 code {
font-size: inherit;
}
h3 tt, h3 code {
font-size: inherit;
}
h4 tt, h4 code {
font-size: inherit;
}
h5 tt, h5 code {
font-size: inherit;
}
h6 tt, h6 code {
font-size: inherit;
}
h1 {
font-size: 2em;
color: black;
padding-top:50px;
}
h2 {
font-size: 1.7em;
border-bottom: 1px solid #cccccc;
color: black;
}
h3 {
font-size: 1.3px;
}
h4 {
font-size: 1.14em;
}
h5 {
font-size: 1em;
}
h6 {
color: #777777;
font-size: 1em;
}
p, blockquote, ul, ol, dl, li, table, pre {
margin: 15px 0;
}
hr {
border: 0 none;
color: #cccccc;
height: 4px;
padding: 0;
}
body > h2:first-child {
margin-top: 0;
padding-top: 0;
}
body > h1:first-child {
margin-top: 0;
padding-top: 0;
}
body > h1:first-child + h2 {
margin-top: 0;
padding-top: 0;
}
body > h3:first-child, body > h4:first-child, body > h5:first-child, body > h6:first-child {
margin-top: 0;
padding-top: 0;
}
a:first-child h1, a:first-child h2, a:first-child h3, a:first-child h4, a:first-child h5, a:first-child h6 {
margin-top: 0;
padding-top: 0;
}
h1 p, h2 p, h3 p, h4 p, h5 p, h6 p {
margin-top: 0;
}
li p.first {
display: inline-block;
}
ul, ol {
padding-left: 30px;
}
ul :first-child, ol :first-child {
margin-top: 0;
}
ul :last-child, ol :last-child {
margin-bottom: 0;
}
blockquote {
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777;
}
blockquote > :first-child {
margin-top: 0;
}
blockquote > :last-child {
margin-bottom: 0;
}
table {
padding: 0;
}
table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0;
}
table tr:nth-child(2n) {
background-color: #f8f8f8;
}
table tr th {
font-weight: bold;
border: 1px solid #cccccc;
text-align: left;
margin: 0;
padding: 6px 13px;
}
table tr td {
border: 1px solid #cccccc;
text-align: left;
margin: 0;
padding: 6px 13px;
}
table tr th :first-child, table tr td :first-child {
margin-top: 0;
}
table tr th :last-child, table tr td :last-child {
margin-bottom: 0;
}
img {
max-width: 100%;
}
</style>