Feature request: Update One Signal implementation to enable GDPR compliance

[AmigoDeluxe]

Is your feature request related to a problem? Please describe. It is a feature request

Describe the solution you'd like I would like to be able to chose if IP addresses and location will be collected by OneSignal when I add that capability to my app. This is going to make my GDPR live soooo much easier. You will find this helpful: https://documentation.onesignal.com/docs/sdk-reference#section-location-data

Describe alternatives you've considered I can send a request to OneSignal to disable IP collection but this is something the can't do for the location. According to their feedback, this can only be done on SDK level.

Which platform are you asking for? Thunkable X

Additional context I do understand by disabling location collection I will not be able to send push notifications based on the devices location. However, some may be fine with this as being GDPR compliant is far more important to some plus, it may not be a capability they need in first place and they might be fine with just being able to push notifications to the app as it is.

[josmas]

That makes sense @AmigoDeluxe thanks for the request. We need to figure out a few things though, first if we can make the change without affecting other functionality, then how can we show this in the interface (maybe a couple of properties), and finally how does this affect permissions (as the library might requests them anyway, even if the functionality is disabled).

[AmigoDeluxe]

Hi @josmas

I think that adding two True/False switches in the SDK options should be enough. When implemented, they should be set to True by default to prevent breaking any existing apps using OneSignal. Then in the SDK implementation, a couple of "Ifs" should be added to check the state of the two options. And don't worry about the permissions. They should remain as they are today as later on, we could enable or disable these features at will.

K

[josmas]

hey @AmigoDeluxe just looking into this at the moment.

Location is only collected by default if the app has Location permissions; are you seeing values in LOCATION POINT when you go to Audience --> All Users? I only see it if I go to my phone's permissions (on Android) and add Location permissions to the app.

We could create a switch but if we set it to true by default, then we have to prompt the user for Location permissions, so probably the default value should be false, cause I think that is how apps work at the moment, unless you are using an additional component that prompts for location such as Location or Maps.

[AmigoDeluxe]

"...unless you are using an additional component that prompts for location such as Location or Maps."

Bingo! That's exactly my scenario. I use the Maps component to show the device's location on the map so the GPS permission gets granted but not for the purpose of using the location on OneSignal ;-) You got it right! That's why I would like to be able to switch the location collection for OneSignal only and I know that this is available through the SDK so if you could add a switch to enable/disable this ( or any other SDK features ;-) ), it would be great.

Just to explain my situation, the only reason I need to spend time to include a Privacy Notice for my app is the OneSignal location collection. My app does not collect any other personal information so its a bit of a hassle to have to include a Privacy Notice because of that :-).

Would such an option be easy to implement?

[josmas]

I am not a lawyer but I am not sure if that switch will exempt you from adding the Privacy Policy to your app.

If you use Location through Maps, are you already subject to the Personal and Sensitive information policy? According to this, it seems like it.

Having said that, if you do not collect the info through OneSignal, the privacy policy could be simpler? It would just be: I store nothing.

[AmigoDeluxe]

Hey Jos

Yes and no. The GDPR defines the "Data minimization" principle which means that we should only be processing personal information that we absolutely need to and in this case, OneSignal collecting location is not needed; I cannot justify it based on my app's functionality. Also, the fact that I am using the GPS to display the device's location on screen but not storing it anywhere means that I am not even collecting it which is the first step of the personal data lifecycle. In any case, I don't need OneSignal to collect location and since it is an option to or not to in the SDK, it would be nice to have that option in Thunkable.

Thanks for your help K

[AmigoDeluxe]

@josmas so I came across a blocking point that makes me have to completely remove One Signal from my app and here is why:

According to the GDPR, I have to get the consent of the user before I can process any of his information. So logically, what I would do would be to create a screen which would appear when the application is run for the first time to get the user's consent, right? Well... the problem with Thunkable's One Signal implementation is that the pop-up to request permission to receive push notifications in the app appears even before the first-run consent screen appears! So if the user clicks "Allow", I immediately see the device's entry created in my One Signal console even if the user then rejects the consent message.

What I tried to do as a workaround was to delete the App ID string in the One Signal component in my app and tried to manually set it in the app using the corresponding block. Unfortunately, that did not seem to trigger the device account creation in the One Signal console as it appears that this only happens the first time the app runs and prompts the user to enable push notifications in the app.

The issue described above is also the reason why One Signal implemented the "setRequiresUserPrivacyConsent", "provideUserConsent" and "userProvidedPrivacyConsent" which delay the SDK initialization until the user has provided his consent:

https://documentation.onesignal.com/docs/handling-personal-data#getting-user-consent

Until these options are added to Thunkable's One Signal implementation, I just can't use it. If these options can be added to your roadmap, it would be great. If not, it is a privacy violation in the form of a component (for data subjects in the European Economic Area).

[josmas]

hey @AmigoDeluxe thanks for the info. I will need to look into it, not certain how much work we can do before initialising the component.

I guess it depends on how you intend to distribute your app; I've never used the stores to distribute so we've always asked participants to sign consent before installing the app (before even sharing the app with them), but that might not work in your case.

I will do some experimenting and let you know what happens.

[josmas]

hey @AmigoDeluxe I've looked at this and, although it is technically possible, it is a lot more complicated (within Thunkable) than it initially looks.

The initialisation properties work well, but they are set once per app, and there's no way to change them. If you mark an app as requiring consent, there's no way to reinitialise that property. This conflicts with the idea of having a switch to turn something on and off; it just wouldn't work and then users would be very confused. This is especially tricky when working with the companion.

We could make all apps require privacy and then have a switch to automatically set consent to true for folks that do not need consent, but this adds complexity for users that are not concerned about privacy. So we have to think about this one carefully with regards to the UI; I'll ask our design colleagues though.

[AmigoDeluxe]

I understand. How about having a "Consent-enabled" and a "Consent-disabled" version of the OneSignal plugin? Like, a pick-your-flavour kind of approach... Because in Europe, consent is a must and I am sure it will become the norm for other geographies (Brazil, USA, Australia, Thailand and South Korea already have GDPR-like laws...)

Thanks K

[AmigoDeluxe]

4 months later...

[AmigoDeluxe]

Aaaaany update?

[josmas]

Hi @AmigoDeluxe There are two outstanding issues with regards to one signal, this one and https://github.com/thunkable/thunkable-issues/issues/759 As per the latter, we need to do a full upgrade of the library so should be a good time to take care of this one too, but it has not been scheduled yet.