Revision of the agreement

[emanuele45]

Article 7:

1. Where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data.

2. If the data subject's consent is given in the context of a written declaration which also concerns other matters, the request for consent shall be presented in a manner which is clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language. Any part of such a declaration which constitutes an infringement of this Regulation shall not be binding.

3. The data subject shall have the right to withdraw his or her consent at any time. The withdrawal of consent shall not affect the lawfulness of processing based on consent before its withdrawal. Prior to giving consent, the data subject shall be informed thereof. It shall be as easy to withdraw as to give consent.

I think this requires few actions:

1. [x] log the when the agreement is accepted (even at registration)
2. [x] give the admins a way to force members to re-accept the agreement
3. [x] visually separate the general agreement from the consent for data processing (maybe just a specific section in the agreement is enough?)
4. [x] the revocation is the tricky part: if "we" request approval to register, when a member requests to withdraw the consent, then he should consequently request an account deletion, this can be a special action, but the removal of the tick, IMO should lead to that.
5. [x] it may be necessary to actually log also the agreement they have consented to

[emanuele45]

Related to this, article 13:

1. Where personal data relating to a data subject are collected from the data subject, the controller shall, at the time when personal data are obtained, provide the data subject with all of the following information:

(a) the identity and the contact details of the controller and, where applicable, of the controller's representative;

(b) the contact details of the data protection officer, where applicable;

(c) the purposes of the processing for which the personal data are intended as well as the legal basis for the processing;

(d) where the processing is based on point (f) of Article 6(1), the legitimate interests pursued by the controller or by a third party;

(e) the recipients or categories of recipients of the personal data, if any;

(f) where applicable, the fact that the controller intends to transfer personal data to a third country or international organisation and the existence or absence of an adequacy decision by the Commission, or in the case of transfers referred to in Article 46 or 47, or the second subparagraph of Article 49(1), reference to the appropriate or suitable safeguards and the means by which to obtain a copy of them or where they have been made available.

2. In addition to the information referred to in paragraph 1, the controller shall, at the time when personal data are obtained, provide the data subject with the following further information necessary to ensure fair and transparent processing:

(a) the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period;

(b) the existence of the right to request from the controller access to and rectification or erasure of personal data or restriction of processing concerning the data subject or to object to processing as well as the right to data portability;

(c) where the processing is based on point (a) of Article 6(1) or point (a) of Article 9(2), the existence of the right to withdraw consent at any time, without affecting the lawfulness of processing based on consent before its withdrawal;

(d) the right to lodge a complaint with a supervisory authority;

(e) whether the provision of personal data is a statutory or contractual requirement, or a requirement necessary to enter into a contract, as well as whether the data subject is obliged to provide the personal data and of the possible consequences of failure to provide such data;

(f) the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject.

3. Where the controller intends to further process the personal data for a purpose other than that for which the personal data were collected, the controller shall provide the data subject prior to that further processing with information on that other purpose and with any relevant further information as referred to in paragraph 2.

4. Paragraphs 1, 2 and 3 shall not apply where and insofar as the data subject already has the information.

[emanuele45]

I was looking into logging the acceptance of the agreement. As a bonus I was thinking to also store in the db a log of the changes to the agreement (in order to have a unique and stable reference the accepted agreement). The basic concept is easy, though there is something that makes it a little complex: multiple languages. This opens up a rainbow of possibilities and I'm unsure what's the best.

The easiest may be just not to care about multiple languages at all, always store the English one and be done with it. Though this would work only in case English is actually updated, and if only the language specific agreement is updated it would fail completely.

The second easiest would be to store whatever is changed (and marked to be stored since I added a checkbox to tick in order to force the members to accept the agreement). The drawback is changing a language may force every user to have to accept again the agreement irrespective of their language.

Another alternative would be to go for the full-language-oriented, so only force the request when a a certain language agreement is changed. But that would make things a little more complex at saving/checking time and in case the member changes the language (because it could be forced to have to accept the agreement in that different language).

Another alternative could be to store a "dump" of all the agreements when a "force accept" is requested. That could be saved in the filesystem without having to disturb the database. The advantage would be the reference is simply the date the agreement was accepted (e.g. the agreements are store in a directory whose name is 2018-05-07 for example and in the log, this date is stored as reference to the accepted agreement). Drawback: usual issues with having to have a directory writable.

Opinions?

[Spuds]

Just thinking how updated agreements are handled on other sites ... Maybe leave it up to the admin, if they update the agreement that alters how personal data is used/held then they can set a ACP flag to require a re-acceptance on next login. It leaves it in the admins hands but ultimately they are responsible.

[emanuele45]

In general is done. I think we can improve it a bit, but there is 2.0 for that.