Kodular, Crashlytics and GDPR

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.

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 (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?


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 :confused:

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.

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:
Other parts of the site, including the homepage, refer to this address https://docs.kodular.io/other/terms-of-service/
which returns a 404.


i asked this a few time ago. What should i write in my Term of use, bc i sm from austria and i have to be GPDR knform.
I have to inform user about Crashlytic if my app use that, if i do that not, it could be expensive for me.
And i dont know which things i should write about that.
It would be nice to know that.
Thanks for your nice post. I like that.

1 Like

Yes you’re required to add Crashlytics and Fabric (same thing now basically) to your GDPR notice. Take note that GDPR is only for EU users like Diego on the community for example… HOWEVER, people(s) in the US do have rights to data privacy and can request data be deleted at anytime from the collector. Let’s use an example where they don’t have to do this.

You’re using VPN for an illegal reason, causing harm to oneself, causing harm to equipment which may cause dysfunctionality of instruments which operate within itself… Logs are kept (most times) of the original IP that connected to the current IP, or your new IP. This is so law enforcement may catch who did this action to cause the event. You CANNOT request that logs be deleted, per some policies they shall be immediately deleted after 30/90 days of being kept.

More about US privacy can be seen here. EU people(s) are also supposed to be able to delete any of their data immediately WITHOUT needing request to the collector. I’m sure european people can tell you more about GDPR than I can :sweat_smile: but, well see if one is willing to respond :slightly_smiling_face:

For example currently my Site is not GDPR Compliant as I don’t allow EU users to delete their data WITHOUT request, so far only admins have access to this type of data, however I am working on that to find a new place instead of an old dialog :sweat_smile:. Btw, I reread some of what you were thinking and regret this whole reply :joy:


Thank you for your reply, MeteorCoder,
In fact, my doubts concern how GDPR applies to Kodular’s use of Crashlytics in the app I/we developed with their system.

Probably my poor English is not very understandable by a native speaker :slight_smile:

1 Like

I’ve read your topic. You were among the few, along with Cian, to raise the GDPR issue in more than one situation.

I think that in this context (I am not referring to Kodular in particular, but to all the alternatives to Appinventor) there is not enough talk about it.

Appinventor creators tend to ignore the GDPR and you can see things at the limit of legal. Just take a look at the apps available to make yourself aware that the GDPR (although I agree that it may represent a problem for small developers) is needed today more than ever. I would just like to understand how to apply it correctly :slight_smile:

1 Like

The most important aspect here is to understand how Kodular have set up their Crashylitics. The key to GDPR is being able to identify the end user. Fabric retains geolocation information for only 10 seconds as an example.

What additionally has Kodular added as part of their core setup?

In short, from my investigation, I do not see how the Crashlytics information contain enough information to identify an individual. I am curious as to what Kodular have setup, overall I am not concerned. I am very careful with what I build, what I ask for, and where I store it.

@hammerhai . You are wrong. Data deletion is not “immediate” . it is “without undue delay”.


Nothing, as confirmed directly by the team (I wrote it somewhere in my message). And I trust Kodular. But trusting Kodular is not enough, I think.

For me the point here is to understand how to make everything, including my the final app, GDPR compliant: if Kodular presents itself as a data controller or data processor and if it is possible to give up the opt-in/opt-out for end users for some reason. And finally, if you really want the cherry on top, if it is appropriate to include as an option the possibility to use Crashlytics :slight_smile:

Can I ask what you mean?

As you clearly say, GDPR affects to Personal Data
However, Crashlytics and Fabric Analytics never request/send/store such kind of data

They just log and report metadata, such us device information, location, events, etc., to their server, and stores them just in an analytical way
What is analytical way? It is anonymous and send in a massive/bulk packages

There is no way to track a single user from Fabric (which is what GDPR was designed for) or to log personal information
In our dashboard, we can only see Android Versions, real time locations (based from IP geolocation) and other useful information for developers only
I attach below some sample screenshots:

As you can clearly see, there is no way to point out a single user, or to better analyze that “bulk data”
Moreover, there’s no way in Fabric’s dashboard to go back in time and check, for example, which were the most active apps for the 4th January 2019

Also, I recommend reading this:
Privacy and Security — Fabric for Android documentation (docs related with GDPR and Fabric)
Privacy and Security — Fabric for Android documentation (Analytics and GDPR)
Privacy and Security — Fabric for Android documentation (Crashlytics and GDPR)
Fabric Blog | Build. Understand. Grow.

Also, if you are worried about Crashlytics, there’s no way to identify any user from there:


Hehe Samsung is first, :blush:

1 Like

There’s no more information, as we don’t need it though
We want to have some kind of analytical data in order to analyze which are the most used Android versions, phone brands, which Kodular Creator versions are running in our apps, etc.
But NEVER personal data, as we don’t need it

There’s actually no way
Fabric was intended for so, a way to get ANONYMOUS analytics for development usages

1 Like

My question is, are you seeing somewhere personalized content inside our platform/apps which may demonstrate the usage of personal data without any prior notification?
As I’ve said, if there’s no need, why would we do it?

We like Fabric as it provides all we need: general anonymous analytics
Also, in the links I’ve attached, you can see which information can Fabric store. And, as I hope you can see, there’s no way to track any kind of sensitive information with their platform

1 Like

The legal expression without undue delay does not mean immediate. Any delay needs to be with reason. i.e, having to go to backups to remove, or assessing if you are required to keep some information for other legal purposes, like taxes etc.


Of course there’s going to be delay, but what I meant is it being done within that same day :sweat_smile: of course, if it’s by request, they won’t be able to do it immediately.

1 Like

Maybe I should have written, “Trusting someone is not enough for the law.” I don’t know if the translation makes sense. It was certainly not an accusation. I’m sorry if it was misinterpreted. anyway
I never thought or written that Kodular could use illegally personal end-user data collected from our applications.

From what you write Fabric does not collect any user data, but the page you linked (and that I had also linked) clearly says that in certain contexts Fabric collects personal data. But if I understand correctly, they are encrypted (and therefore anonymized) both during sending and storage. Is this enough to allow us to avoid an opt-in/opt-out in our applications under the GDPR?

And, Diego: I’m not accusing anyone, I’m just trying to understand.

1 Like

You cannot avoid an opt-in opt-out. The location is captured, and while it is not retained it is still captured and used. Combine that with the device type, and you have an indirect way of identifying an individual, even only for a short period of time.

Thats my interpretation.

1 Like

That is my interpretation too (with some doubts, as always :slight_smile: ), but currently is not possible implement an opt-in/out.

1 Like

That’s not true
How many websites redirect you to your language/country subwebsite without asking?
Lots of webs just forward you to their respective country subpage, and you never get a consent screen to stop your IP geolocation, because it is not stored


But it also says that the unique “personal data” is a single UUID in order to identify and prevent double analytics
That UUID is never visible to anyone, and also it is not any kind of sensitive information, it’s a random string to prevent false analytics


I think Diego is right. Actually, it would seem that new versions of Crashlytics do not send to Fabric personal data that could identify a user, unless the developer using Crashlytics (in this case Kodular) uses custom keys/tags (we know that this is not the case). The change was made to make Fabric GDPR compliant.