Managing Complexity and Privacy Debt with Drupal by Janne Kalliola, Exove 2nd November at DrupalCamp Baltics

1. Janne Kalliola
Exove
Managing Complexity and
Privacy Debt with Drupal
Tallinn, November 2, 2018

2. Agenda
§ About Exove and myself
§ Complexity in modern software
§ Privacy debt
§ Drupal to rescue

3. About Exove
§ Digital design and development
company in Finland, Estonia, the
UK, and Singapore
§ Full service portfolio from
business consulting and service
design to development and care
§ We serve both multinational giants
and new start-ups alike
We deliver digital growth
More about us:
§ www.exove.com
§ www.exove.com/gdpr
§ @exove

4. About Janne Kalliola
§ Founder and CEO of Exove
§ Continuent, First Hop, SSH,
Helsinki University of Technology
§ Been coding since 1983, first web
stuff in 1994
§ Worked with web publishing and
content managements systems
since 1999
§ I’ve written three CMS in the past
§ Worked with open source since
1998, with Drupal from 2007
More about me:
§ www.kallio.la
§ linkedin.com/in/jannekalliola
§ @plastic

5. Complexity and Privacy

6. Complexity and Modern Software
§ Modern software development practices, the fast pace of the industry,
and changing demands cause software platforms to be layered,
multifaceted and complicated systems
§ A systems consists of numerous interconnected subsystems created with
various technologies, deployed with different tools, and hosted in several
places
§ The complexity of the system is easily hidden under number of layers and
facades

7. Privacy Aspect
§ GDPR requires companies to specify how they manage private data
§ If the system is complicated – as they typically are – understanding the
management is hard
§ Besides, there are number of places were private data is stored
temporarily of permanently during processing
§ Log files, etc.
§ This is not the focus of today’s discussion, but it is good to know

8. Documentation Can Mislead
§ A typical IT system documentation is non-existent
§ If it does exist, the documentation is typically somewhat simplified view of
the architecture
§ Sometimes very simplified
§ Finally, it is most probably also outdated
§ If the system’s documentation is from era before GDPR, it does not focus
on data privacy much or at all

9. Example Architecture Diagram

10. The Same System, Zoomed in

11. § Varnish or CDN in the front
§ Web server logs
§ Platform logs
§ Local caches
§ Uploaded binary files
§ Maillog of all the sent emails
§ Backups of the servers

12. § SQL logs
§ Binary logs on all servers
§ Backups of binary logs
§ Database dumps made by
developers
§ Production dumps to staging
environment

13. § Integration platform logs and
local caches
§ Integration platform document
DB oplogs
§ SaaS messaging platform logs
and internal database

14. § Finally the actual data master,
its logs, backups and
development environment

15. And That Was Just Data Flows and Storages
§ The previous example was just about data flows and storages
§ It was the physical architecture of a modern platform
§ The logical architecture should reflect the desired functionality of the
system
§ To save time, we do not go through it right now for that system
§ The logical architecture can be easily even messier – as the requirements
of the system change during years, new features are added, and old ones
are deprecated

16. Debt
§ Every change that is not done “perfectly” creates debt
§ Bad architecture, wrong components, and features hacked in create
technical debt
§ Non-uniform ways to manage private data and distributing / spreading
out private data create privacy debt
§ Payment is due – sooner or later
§ Debt is paid in refactoring
§ Interest is paid when new features take longer to implement or cannot be
done in an optimal fashion

17. Privacy Debt
A concept in software architectures that reflects the implied cost of
additional work caused by choosing a non-uniform solution to handle
private data instead of using a commonly used or more centralised
approach.

18. Privacy Debt in Practice
§ Every time a new way to deal with private data is added to the system,
the complexity – and privacy debt – increases
§ And vice versa, if something is centralised or made more uniform, the debt
decreases
§ The debt is paid every time an individual uses one of her rights
§ The right honouring process is more complex than it could be due to various
different ways how handling of private data is implemented

19. Reducing the Privacy Debt
§ Uniformity: Define and apply uniform ways to handle private data. The data itself is
typically mostly the same in most of the systems, and it can be handled using the
same procedures. If possible, define the data uniformly and use that definition in all
systems applicable
§ Reduction: Move data outside of the systems, such as using SSO solution, and
minimise the personal data stored in a business system
§ Encapsulation: Require all new systems to expose APIs to ensure the users’ rights on
that system
§ Centralisation: Create a centralised system that handles all – or the bulk of – users’
rights. Connect all your systems, one by one, to this centralised private data
management platform

20. Drupal and Privacy Debt

21. Drupal to Rescue
§ Drupal has numerous built-in tools to manage arbitrary content,
structured and unstructured
§ And more can be installed as modules
§ Private data is at the end just data, and it can be managed with the same
tools
§ Besides, Drupal has also a good user rights management subsystem
§ GPDR requires restricting access to private data to only those that need it
§ This can be achieved easily with Drupal’s user rights

22. API and Headlessness
§ Drupal has extensive REST API
§ It can thus be used also as a headless private data repository
§ The centralised solution to manage privacy debt
§ Authentication, authorisation, and user rights allow controlling external access of
private data
§ Thus every system does not get to see the full amount of data, but only the
relevant subset – this, of course, requires careful planning of the data structures
§ It can also be integrated with other systems to work as a consumer of private
data

23. Rules
§ Besides storage and connectivity, Drupal can be used also as a private
data automatic management platform
§ Private data can be altered and removed using Rules functionality
§ Of course, creating own modules to manipulate the data is also an option
§ Especially, if the business logic is hard to implement with Rules

24. Views
§ As Drupal is also a publishing platform, various end-user views can be
constructed easily
§ These can be either for viewing only or also CRUD operations for the data
§ Again, restricted and controlled by the user rights
§ Drupal admin ui provides quick and easy way to implement these
§ But implementing real end-user templates might make the system more
approachable to a common user
§ And the functionality can be different for people having access to the front-end
and those having access to the Drupal admin ui in its entirety

25. GDPR User Rights and Drupal
§ GDPR rights (right of rectification, right of removal, etc.) can be
implemented using Drupal’s admin UI
§ An user wanting to exercise rights contacts an operator with admin rights and
the operator makes the changes within admin UI
§ Another option is to provide users a self-service view to see their
information as a normal Drupal provided webpage
§ Depending on the business/use case, there might be also possibility to
remove and change the information as self-service
§ Or then a simple contact form or email address to send the requests to an
operator

26. GDPR Module
§ There is a specific GDPR module for Drupal
§ https://www.drupal.org/project/gdpr
§ The focus of the module is to provide support for handling GDPR
requirements and user rights in websites powered by Drupal
§ The module is not straightforwardly useful in this scenario
§ However, GDPR fields and GDPR tasks submodules could have benefits in
organising the information
§ As usual, your mileage may vary when using modules to something else than their
precise intended purpose
§ The future features look interesting – thus consider contributing

27. Caveat Emptor
§ Remember, that Drupal has a nasty habit of creating users automatically
when using external authentication service
§ Each external user ever logged in has a Drupal account
§ And this feature cannot be turned off
§ Thus, you will end up spreading your user information to a new platform –
whether you like it or not

28. Recap

29. Recap
§ Complexity combined with privacy requirements can make systems very
hard to manage
§ Concept of privacy debt allows you to think the future consequences of
bad choices made today
§ Drupal is an excellent tool to manage private data due to its versality,
readymade tools, and adaptivity in various scenarios

30. Thank You!
Questions? Comments?