Jump to content

[TOPIC: topicViewTemplate]
[GLOBAL: userSmallPhoto]
Photo

Help understanding the gdpr window
Started by dodi_games Dec 17 2018 04:38 PM

11 replies to this topic
[TOPIC CONTROLS]
[/TOPIC CONTROLS]
[modOptionsDropdown]
[/modOptionsDropdown]
[reputationFilter]
[TOPIC: post.html]
#1

dodi_games

[GLOBAL: userInfoPane.html]
dodi_games
  • Contributor

  • 341 posts
  • Corona SDK

I have created my gdpr window for the user to give me his consent or not at the start of the game. I read that it is necessary to have an option to withdraw the consent from the game settings. The question is: does the function of withdrawing the consent be one-time or can the user give and withdraw the consent as many times as he wants?

 

For example, today I get up in a good mood and I want to have a personalized ad experience, ahh! so I'll give my consent in the settings of the game ... but on another day I'm sick of seeing ads and I decide to remove the consent.

 

Is it like a "yes" or "no" button to turn on and off the personalized ad experience?

 

Thanks in advance

DoDi



[TOPIC: post.html]
#2

richard11

[GLOBAL: userInfoPane.html]
richard11
  • Contributor

  • 294 posts
  • Corona SDK

From a legal stance, you're just not allowed to deliver personalised ads without consent, because the personalisation itself means reading tracking cookies which GDPR considers to be personal information.

In effect, you're allowed to deliver adverts any way you like, you're just not allowed to use tracking cookies to deliver better-targeted ads without explicit consent beforehand.

So step one - have something, somewhere, that by default is switched off but can be switched on by the user, and use that toggle to in turn switch personalisation on within your ad network integration.

Step two would be to pop something up on initial landing, explaining that this toggle exists and requesting consent. This step is what you've already implemented and would be entirely optional to have.

Much of the Internet has misinterpreted the compliance requirements and popped this open on landing with tracking cookies enabled and an accept button to just close the pop-up and continue - this is incorrect implementation because cookies have then already been used before the pop-up appears and the user will most likely just hit the close button without reading what they're accepting. For true compliance, the toggles MUST be disabled by default, otherwise consent isn't being explicitly given. Implied consent isn't acceptable any more, there has to be a literal action, by the user, that would be considered clear acceptance by a court.

You could choose to just not use tracking cookies full stop. I.e. leave your ad network delivering generic adverts. This approach means you don't need an acceptance toggle at all, or a landing pop-up, because you're never going to use that setting. But targeted adverts are proven to be better revenue generators so this would be a foolish approach really.

Now on to your original question - you could build your implementation in a way that the landing pop-up appears once, and if the user enables personalisation using it, the option to disable pops up in the settings. You could if you really wanted to, have this option disappear again when disabled and never show that pop-up again, thus resulting in an opt-out-once-only mechanic, but again this would be foolish.

Legally you just can't deliver those personal ads without consent, and you can't assume consent without the user at some point explicitly granting it. Beyond that, how you go about implementing is entirely up to you. Financially, you want to encourage personalised ads because they're generally going to result in more revenue so you'd be a fool to not make it easy to opt in to them at any time.
  • Markus Ranner and dodi_games like this

[TOPIC: post.html]
#3

XeduR @Spyric

[GLOBAL: userInfoPane.html]
XeduR @Spyric
  • Contributor

  • 432 posts
  • Corona SDK

GDPR is about all sorts of tracking and collecting of person information, not just concerning ads. Like you said, the user has the right to withdraw their consent at any point, but what that ultimately means is all up to you. For instance, I use the following simple and easy approach:

By default, all tracking and consent related variables are set to false. When the app starts for the first time, the user is directed to a consent.lua scene that states that in order to use the app, the user has to consent to the privacy policy and the terms of service. I also provide a brief explanation as to why. Apart from links to the privacy policy and the terms of service, there is only one button, to consent. The user is notified that if they don't consent, they can just stop using the app.

On all consecutive start ups, the consent is already given and the consent.lua scene is skipped. If your app needs to track the user, then this is the simplest approach. If you don't need to track your users, then you can have that "consent yes/no" option in your menus with default as no.

The fact is that users don't really care about this stuff. If they need to consent to play, then >99.99% of users consent, but if you say that they can play regardless of whether they consent to or not, then most will probably not consent.


  • Markus Ranner and dodi_games like this

[TOPIC: post.html]
#4

Markus Ranner

[GLOBAL: userInfoPane.html]
Markus Ranner
  • Contributor

  • 104 posts
  • Corona SDK

Great explanations!

 

Am I mistaken, or isn't there also a part of GDPR stating that the user must be able to delete all information that has ever been collected about him/her? If so, how do you handle that with 3rd party providers for ads, analytics etcetera?



[TOPIC: post.html]
#5

richard11

[GLOBAL: userInfoPane.html]
richard11
  • Contributor

  • 294 posts
  • Corona SDK

Yes, that's the "right to be forgotten" part.

If you're storing any data yourself, you're considered a data controller and as such responsible for securing that data, and for handling any requests to view or remove it. In the simplest form, to avoid breaking things like sales reports in an e-commerce platform, rather than deleting records you'd just anonymuse them. I.e. if you store customer details, replace those fields with something like the text "removed" but otherwise leave the data intact.

For your own sanity, you might want to write a function that loops through the appropriate database tables and wipes these values for you, in which case you can easily take it a step further and have an in-app / on-site link within the users account to action this automatically, but from a legal stance you can just include some text in your privacy policy offering the option by email.

For data stored by 3rd parties, such as ad networks, analytical services, or affiliates that you might share certain data with for say, order fulfillment, you need to provide a list of those parties within your privacy policy so that the user can get in touch separately with removal requests. Each of those parties is considered a data controller and has the same responsibility as you do, for the data that they store.
  • Markus Ranner likes this

[TOPIC: post.html]
#6

richard11

[GLOBAL: userInfoPane.html]
richard11
  • Contributor

  • 294 posts
  • Corona SDK

Also worth noting - in addition to the right to be forgotten, as a more general rule you're also only allowed to store data that's actually needed. Using the e-commerce example again, once an order is fulfilled, if you don't have say... A feature within the customers login that shows historical orders including billing/delivery addresses etc, that would require this data to be kept, then you don't have any legitimate reason for keeping it on file, so you should technically have an anonymisation function that handles the above automatically within an appropriate timeframe.

This is true for both digital and printed records, including emails.

Point being, if an attacker stole your database, hijacked your email account, or broke into your office and took printed files, and then leaked those findings, you would need to be able to explain in court why you needed to keep those records and if you can't, you could be in trouble.
  • Markus Ranner likes this

[TOPIC: post.html]
#7

thomas6

[GLOBAL: userInfoPane.html]
thomas6
  • Contributor

  • 853 posts
  • Corona SDK

We just did an audit about our own GDPR compliance where I work. Sheesh, the regulation for this is almost impossible to comply with. If you follow the legal rules 100% oercent you can't even put a client's (or a friend, for that matter) phone number in your cell phone with prior written permission and a whole host of documents and processes (and appointed responsibles) in place regarding data management. Crazy stuff.



[TOPIC: post.html]
#8

Markus Ranner

[GLOBAL: userInfoPane.html]
Markus Ranner
  • Contributor

  • 104 posts
  • Corona SDK

Richard, thanks for your awesome responses! Don't think I've seen anyone explain the essence of GDPR in a shorter and better way to make it actually understandable and managable.  :)

 

Just wanna check that I got everything you said about the "right to be forgotten part" regarding my own situation.

 

If:

 

* I don't store any user information myself outside of the user's own device.

* I use some 3rd party libs that may or may not store, handle and sell the user information that I provide them with.

 

Then:

 

* All I need to do is add a list of these 3rd parties to my privacy policy so that my users may contact them if they wish to be forgotten.

* I don't have any responsibility by myself to take care of users requesting to be forgotten and make sure that all 3rd parties take required actions to do so.

 

Correct?



[TOPIC: post.html]
#9

XeduR @Spyric

[GLOBAL: userInfoPane.html]
XeduR @Spyric
  • Contributor

  • 432 posts
  • Corona SDK

@Markus, that's right.

The important bits are 1) understanding whether or not you are collecting personal information, and 2) listing all data processors and controllers in your privacy policy so that a user can find out about them.

Personal data refers to any information that can be used to identify a particular person. It also doesn't matter if the data has been de-identified or encrypted if it can be reverted back to normal state. Since it is impossible to know what data any 3rd parties may collect and whether they are in compliance with GDPR, linking to their privacy policies in you policy is just an easy way to wash your hands from everything.

We track only non-personal information. This means that we use Google Analytics with anonymised IP for all general analytics purposes and we always create installation specific time based user IDs for our own databases. This ID is created based on the unix time the app was started and in the milliseconds that the app took to reach the ID generation phase. This means that there is little to no chance that any two users will have the same ID, but at the same time there is 0% chance of actually identifying anyone using that ID and so it isn't personal information.

This means that since we don't collect personal information, we couldn't even delete their information if they requested since we can't identify anyone based on the data that we have collected.

 



[TOPIC: post.html]
#10

Markus Ranner

[GLOBAL: userInfoPane.html]
Markus Ranner
  • Contributor

  • 104 posts
  • Corona SDK

@XeduR Thanks for the clarifications! Right now I don't feel as confused about GDPR as I used to.  :D



[TOPIC: post.html]
#11

richard11

[GLOBAL: userInfoPane.html]
richard11
  • Contributor

  • 294 posts
  • Corona SDK

Glad you're feeling less confused. I should point out that I don't work in legal, and these regulations are very much open to interpretation even by those who do, so my understanding is exactly that - my own interpretation.

That said, we have some very large clients who GDPR compliance is important to, and as well as development services we offer hosting and server management services for these clients so as you can imagine, I've spent a considerable amount of time on the run-up to GDPR trying to get my head around everything. While I can't make any legal gauarantees that there are no flaws in my advice, it should be pretty accurate.

Perhaps the most important thing to note, is that as scary and jargony as GDPR is, it's absolutely not expected that all of us small folk are 100% compliant any time soon. Its purpose is to prevent the big players from continuing to misuse the data that they have on us - Facebook, Google, Apple, Microsoft and so on. The threat of €20m fines is to make those companies take the regulation seriously, not to scare the rest of us into shutting down. No court is going to hit hard on any small business for failure to comply, knowing damned well that no SME can afford the time or legal advice needed for it. All they want to see, at least for the foreseeable future, is that you're trying your best. A reasonable privacy policy and a logical approach to data protection would be enough for the vast majority of businesses.

@XeduR, I'm going off topic now but ref your timestamp based approach to ID generation - I learned the hard way last week that as miniscule as a possibility seems, you should still expect it. One of our client stores generates an incremental order number during checkout, by basically looking up the last generated number, incrementing it, and performing another lookup to make sure it definitely isn't yet used (autoinc fields aren't an option on this occasion). This runs in a loop until a unique ID is generated, and then a new database record is created for the order, using that ID. The whole thing happens in nanoseconds, and you'd expect it to be pretty bulletproof, huh? Nope. 51,000 orders later, we found that 56 order numbers has been used twice! This is a store that receives approximately one order every 3 seconds during peak time (the run up to Christmas), so two people hitting the checkout button at precisely the same time is actually a common occurrence. Combine that with a web server that runs multiple simultaneous PHP threads and suddenly it's very possible for two threads to determine the same order number is available at precisely the same moment in time. Not good!

Our fix was to generate a second random 2-letter code when the user first lands on the website, so that when that user hits the checkout and the above system kicks in, the 2 letters that were already assigned to that user when they landed on the site can be appended to the resulting ID. Now when two users invoke checkout at exactly the same time, this can only result in the same order number generating for both customers if they also happen to have been generated the same 2 letter code when they both landed on the site, which reduces the likelihood considerably.

So learn from our mistake and always add something random into any algorithm that would otherwise produce the same result of executed twice at exactly the same time. As unlikely as the scenario sounds, with enough active users that chance is just too great.
  • Markus Ranner likes this

[TOPIC: post.html]
#12

XeduR @Spyric

[GLOBAL: userInfoPane.html]
XeduR @Spyric
  • Contributor

  • 432 posts
  • Corona SDK

@Richard, those are valid points. We used to have the first few characters of the deviceID (which then further scrambled into letters using string.byte() and a few other loops) a part of the ID as well, but we've since dropped that bit. Currently we simply generate the IDs using the following concept:

*Edit: Oh, right. This code runs only once when the app is started for the very first time (and generates a new ID upon reinstalling the app).

local userID = os.time()..system.getTimer()*10

While this doesn't 100% guarantee that no two users will have a duplicate ID, it still means that no two users will have the same ID in our apps unless they 1) start the app at the very same second, and 2) their apps reach the very same point in code at the same millisecond.

There are a lot of different things that could be added there to make it even more unique, but each additional step bring only a tiny fraction of additional guarantee of having no duplicates.




[topic_controls]
[/topic_controls]