Making TYPO3 GDPR-ready


(Fedir RYKHTIK) #21

Here’s an article about CMS & GDPR.

The author shows 4 Ways a CMS can support site owner GDPR efforts :

  1. Managing consents
  2. Records of given consents and processing activities
  3. Data portability
  4. Handling ‘right to be forgotten’

(Dan Untenzu) #22

Besides all possible extra tools and loops, like encryption or generic archives, there is one main concept, which is summarized perfectly by Rachel

the site owner must make a list of the personal datas he has stored in the platform, why, and for how long (no longer than necessary).

When the duration of a personal data storing is over, it is necessary to:

  • remove it
  • or archive it (i. e. outside the website)
  • or anonymize it

We therefore should start by showing integrators where TYPO3 stores data. This is not obvious at the moment. For example: When I install TYPO3 I just don’t know where TYPO3 stores IP addresses. The »sys_log« table may be obvious, but where else? Without this information I can’t provide a proper privacy statement.

Next step: Create tools to remove/anonymize the data. It is for example okay to temporarily store session data, such as the IP address of frontend users, which is stored in the database subsequently. When the session ends, all session data should be destroyed and removed from the database. This is already the case, but not documented in some privacy note.

Third step: Create a guideline on how to handle user data and urge developers to follow this guideline. It should be part of the coding guidelines, that extension developers instruct integrators whether an extension stores personal data, why and for how long.
The core could support this with tools as well, for example by providing a core method to retrieve and store an IP-address. Example: Extension »acme-news« uses a core method to retrieve and store an IP-address, by using this method the TYPO3 core automatically knows about this data usage & processing and could list this extension in an overview. We could also extend the »Table garbage collection« scheduler task, and provide an easy but required method to set an expiry date for records or fields with personal data.

In general I propose that the CMS itself faces all challenges of the GDPR and provides solutions and best practices for developers and agencies, instead of the other way around. I support Fedir’s proposal to create a working group and organize a dedicated TYPO3 Code Sprint related to the preparation to GDPR (and I would like to join this group).


(Dan Untenzu) #23

Regarding the issue, that I don’t know where TYPO3 stores IP addresses and want identify all the possible places and maybe even the code which is responsible for this: In preparation of the GDPR I assigned this task to a student of mine.

TYPO3 CMS:

  • field »log_data« in table »sys_log«
  • field »IP« in table »index_stat_search«
  • field »ses_iplock« in table »be_sessions«
  • field »ses_iplock« in table »fe_sessions«

As mentioned above the session data in the user tables are okay, since this field is cleared as soon as the user is logged out. EXT:indexed_search stores all searchwords and which users typed them into a table (why?). The »sys_log« is used by various methods to log exceptions, login actions, content editing etc… It is not quite obvious which parts of the core or extensions write into this table. So a information for the user why his IP address is stored in the log is not conclusive yet. This would be the next step. But as explained above, it is an expensive task to reverse-engineer all the places. Instead the CMS should provide an interface for this (which needs a concept, guideline, etc…).

Extensions:

  • field »IP« in table »tx_formhandler_log«

The formhandler extension is one example were integrators should be made aware of, that they store personal data in the database. It has a logger controller, which is active by default. This stores the IP address of the user filling out a form. It also offers a custom method to cut of parts of the IP address. This is not active by default however.


(Markus Klein) #24

I agree with what @pbtypo3 said.


(system) #25

This topic was automatically closed after 28 days. New replies are no longer allowed.