Hello guys,
I have a big doubt about Kodular and the GDPR. I’ve already had the opportunity to exchange some opinions with a team member, but I’d like to make this argument public because maybe there is someone who can solve my doubts.
To start, I’d like to give it some context.
GDPR
As you know, on 25 May 2018 the GDPR law came into force. The GDPR applies to anyone – based anywhere in the world – who offers goods or services to people in the EU or monitors the behavior of people in the EU. The law aims to strengthen personal privacy in the digital age. By protecting the way in which users’ personal data can be collected and managed, the legislation should give back control over their own data to people.
GDPR has redefined the meaning of Personal Data: everything that can lead to the identification, direct or indirect, of an individual can be considered personal data: names, photos, emails, but also IP, IMEI, ID Number, etc.: What is personal data? | European Commission
The GDPR outlines numerous and detailed guidelines for the management of these data; the argument is too wide (and in my opinion a bit complex) to be discussed about it here, so I invite all those who are interested to inform themselves on the official documents of the European Community.
Fabric/Crashlytics
Fabric (or rather, its Crashlytics service) is a service that makes possible for app developers to automatically receive crash reports whenever an app has problems. The data are collected by Fabric and then are sent to the developer in a convenient Dashboard. To take advantage of Crashlytics you need to register at https://fabric.io and set up some things at code level
On its Privacy and Security page, Fabric informs us that
The services listed above need some amount of end-user personal data to function. As a result, it’s not possible to entirely disable data collection while using those services.
Basically they tell us that there is no way to prevent some personal data from being collected by their services.
On the other hand, the Crashlytics privacy policy:
What information does Crashlytics collect from End Users?
Summary
The Services automatically collect certain information that does not personally identify End
Users who access or use mobile applications that use the Services. This information includes,
but is not limited to, device state information, unique device identifiers, device hardware and OS
information, information relating to how an application functions, and the physical location of a
> device at the time of a crash.
Developers may also enable certain features of the Services that collect additional information
that does not personally identify End Users who access or use mobile applications that use the
Services. This information includes, but is not limited to, information relating to how an End User
uses that Developer’s application(s).
In addition, Developers may enable certain features of the Services that will allow Crashlytics to
collect some End Users’ personally identifiable information, as well as whether the End User
installed or used the Developer’s application and feedback that End Users voluntarily provide.
For example, (i) a Developer may provide Crashlytics with an End User’s email address so that
Crashlytics can invite the End User to test a particular version of the Developer’s application,
and the End User may download that application and submit feedback about it and (ii) a
Developer may choose to append custom metadata to crash reports that they send to
Crashlytics from their applications; Developers may choose to include personally identifying
information about End Users in this metadata, like name or email address, so that Developers
can, for example, contact such End Users to troubleshoot issues with Developers’ applications.
Crashlytics may also receive a confirmation when you open an email from us. Crashlytics
captures all of this information on Developers’ behalf so that they can understand and improve
their applications and communicate with users about their experience with the applications.
Crashlytics requires Developers to use Crashlytics to collect information solely for these
purposes, and to observe all applicable laws and regulations.
We require that all Developers maintain a privacy policy that fully and accurately discloses the
type of information collected, and that the information is shared with third party service providers
like Crashlytics. However, Crashlytics does not require Developers to disclose that information
is shared with Crashlytics in particular, so Developers’ privacy policies might not name
Crashlytics specifically.
tl;dr Crashlytics does not collect data that makes it possible to identify the end users, but the developers who use Crashlytics can set up the service in such a way that this data can be collected (in the text they refer in particular to the email and user name).
Although this is written in the privacy polycy, we are not given to know exactly what data Crashlytics collects. Ultimately, the above text says that it collects unique identifiers of the device and also the physical position of the device itself at the time of the crash that, turn out to be personal data. This makes me have many doubts 
Crashlytics even has a clause in their ToS that requires you to have a privacy policy at all times:
At all times during the term of this Agreement, Developer shall have in place a privacy policy (i) that is readily accessible to users from its website or within its service (as applicable)
You should therefore let your users know about the fact that you are sharing some of their data with a third-party to help you run your apps.
Kodular
All apps developed in Kodular automatically include the Crashlytics service. The team uses this service to receive aggregate reports of crashes of any app developed in Kodular. There’s no way you can currently avoid installing this service in your apps. One of the staff members assured me that no Fabric service is used that allows end users to be identified.
The Problem(s)
GDPR states that the Data Controller (“The natural or legal person, public authority or other body which establishes the purpose and method of data processing, alone of together with other actors”, in this case the developer) is responsible for the use of personal data by third party and must inform the end users that they (third party) will be able to manage their personal data and, unless Legitimate Interest is involved, must ask for the user’s consent before collect/send data to a Data Processor (“A natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller”, the third party).
What worries me is that I (developer), as data controller, have to inform the end users of the data I collect or send to third party services through my app, but in this case (with the app builded In Kodular) I have absolutely no control over this data, nor on the possibility to install or not to install the Crashlytics service in my apps. Moreover, this does not seem to me to be the case in which one can call the Legitimate Interest a cause, as I can achieve the same goal (the continuous improvement of the app) in other ways, so an opt-in (and relative opt-out) for the end users is absolutely necessary.
Assuming however that everything is ok (no need to opt-in or no opt-out, anonymous data collected etc.), if I wanted to be completely GDPR compliant I believe (and I repeat “I believe”) that I should put Kodular among the data processors together with Fabric. The problem is that Kodular’s TOS would not be compliant for this type of contract between the developer and Kodular itself.
In the end I think that currently no app that is developed in Kodular can be called GDPR compliant, because of the use of Fabric and the Crashlytics service.
Any opinion on that? Tell me where I’m wrong.
If I had written a lot of nonsense, I ask for forgiveness now.
P.S. About Kodular’s TOS. They are accessible only from this address:
https://docs.kodular.io/terms-of-service/
Other parts of the site, including the homepage, refer to this address https://docs.kodular.io/other/terms-of-service/
which returns a 404.
but, well see if one is willing to respond 
