Update to GDPR Right-to-be-Forgotten Messaging

If you haven’t read the GDPR, don’t comment on it. All you are doing is making things more difficult for people to understand.

Article 17.1 of the GDPR alone provides 6 separate grounds under which a data processor can refuse a request.

Article 12.2 might actually make it a crime to comply with the request.

One of the key things is that the right to erasure requests we receive are not actual right to erasure requests. For them to be actual right to erasure requests, they have to be made by the user directly to you, they cannot come from Roblox. What Roblox is doing is complying with Article 17.2, which limits the scope of the requirements under the law.

2 Likes

Thank you for elaborating where I couldn’t.

I’ve read the GDPR and I know how it works, I just don’t remember all the articles off the top of my head.

I don’t think anyone remembers all 99 articles of the GDPR. The only reason I can cite the relevant sections is I made a mega post awhile back outlining what I believe to be several flaws in Roblox’s right to erasure requests that I can quickly reference.

Good to see people who actually read the GDPR posting though. Unfortunately I think the vast majority of the conversation here is from people who have never done so.

I’m unsure of that.

I made a Subject Access Request to Roblox a few months ago, had to use a portal to provide passport info to verify ID.

This was prefaced with the description of “To confirm your request as a user based in the European Economic Area (EEA) or as a California resident and to protect the privacy and safety of our users, please visit the following link to confirm your real life identity”

which would suggest to me that they are only doing it on a minimal basis.

1 Like

Nope, I only store UserIDs, because if a player changes their username, I can’t make a bridge between old & new them.

You are expected to clear usernames, by the way.

You seem a bit biased in wanting to define what is/isn’t PII and on that basis deciding whether or not to delete data.

Companies tend to go very heavy handed on wanting to make sure they delete everything, even if not strictly required to because the fines for breaching GDPR are so large (up to 4% of global turnover/€10 million max). That it to say it is usually safer/cheaper to delete everything rather than have a legal battle on weather it is PII or not.

It might be worth mentioning the DevEx terms of use which 4.C “Providing assistance to Roblox for legal and compliance reasons.”

If Roblox policy is that all data attributed to a user be deleted upon receipt of a right to be forgotten request, rather than strictly PII then… At least if you want to DevEx, you really need to comply as a contractual obligation without concern of GDPR legislation.

:+1: Roblox, helpful update.

2 Likes

I am willing to agree with you up to a certain point.

Yes, Roblox could make it there policy for developers to delete UIDs from their games. However, they have not. When you get a right to erasure message from Roblox, it stipulates that you are required to comply under data protection laws, not under Roblox policy. I’m no lawyer, but I am willing to bet this is intentional as making it policy could have some interesting legal quandaries for Roblox.

Roblox also has no reason to make it there policy. The developers are the data controllers, not Roblox (otherwise Roblox would be required to delete the information for us). As such, they face zero legal liability.

There is also the question of whether or not it is even legal to honor the erasure message. Unfortunately the requirements under article 17.2 are super vague, and the legal requirements around it are unclear. If we are still required to comply with Article 12.2, then deleting the information would actually be against the law. However complying with Article 12.2 is against Roblox’s TOS.

There are a lot of problems with how Roblox is currently handling right to erasure requests, both legal and logistical. Whether or not the UID is PI is just one small but easily explained portion of it. While this update is a great step in fixing these problems, it does not in any way solve the issues entirely.

Thank you lord, so much!

I have been waiting for this update so much, this year I have gotten a GDPR notice from ROBLOX, didn’t provide a place ID, it made it super confusing!

That’s why I am suggesting an API for example:

game:GetService("Privacy").RightToForgetRequest:Connect(function()
  ---......
end)
2 Likes

A lot of people are requesting this, and the reason I withdrew my post to suggest this was my realization that it most likely won’t be possible. I don’t think we will see this since it doesn’t only apply to DataStores alone, but also as refers to:

(e.g. games, data stores, etc.)

And furthermore:

Please note that you must delete the User ID from all of your records, and not just from your data stores.

This means you would still manually have to remove all pictures, all models and other data associated / stored of that player that were manually saved by you, your friends, or the person themselves or automatically somehow saved by other means on external sources through HTTPService.

It also wouldn’t be an ‘event’ to listen to but would need a long term API integration because you can’t expect all games to be publicly open at a given time. All this has proven that they keep logs of all the games you visit. This means storing the UID of a player who has made a GDPR request in their database, and this new feature which associates all game ID’s with that GDPR requested user. If Roblox decided they want to erase this data, which they probably do after sending the requested UID to all users, would mean developers will have no idea how to remove that players data if they simply rely on a service which only cover erasure of some of the data but not necessarily all of the data. And what about cases where developers have not been active for months and decide to re-open their game?

With the introduction of this new suggested service, it also would likely become mandatory for all users who use DataStores or store players data externally to use this, and that would require all users to update their DataStore scripts. But if obligatory, you would still rely on the messages being sent to your inbox because they won’t assume all users use the service. So introducing this service would be a bit problematic because not only would they be releasing something that is either forced, or obligatory, which means using extra resources to create a service that only does partial job in some cases.

Roblox doesn’t track / collect ALL data made by users when they are in a game or working on a game in studio, nor are they willing to manually do the cleanup job for you because it’s your game, you have that information, and you should deal with it manually.

2 Likes

Does deleting any data apply to older datastores that have not been used in a very long time? This would make it nearly impossibly to delete all data.

Plus, I live in the US, so I don’t think this even applies to me unless it’s in a Roblox TOS or something.

1 Like

On this, the law is rather clear. I cant find the relevant articles right now, but deletions include all copies of the data, including physical archival copies.

While the EU sanctioning you for non compliance is difficult, assuming the erasure requester is a EU citizen the law still applies to you. Whether or not it applies to you in the capacity that Roblox says it does is up for debate, of which can be seen in the post above so you can make your own informed decision.

The fundamental root of the GDPR, a necessary requirement for it to apply is simply:

From the GDPR directly:

“‘Personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.”

See Definitions, also from the GDPR:

Roblox has not provided the one missing element which is not surprising due to Roblox’s history with transparency (or lack of).

We as developers retain the right to maintain our Robux purchase logs and references as these are required for proper accounting and tax purposes. Simply put, the source of where Robux come from on a payout is equally as important as the payout itself and Roblox does not have the right to remove our tax data.

This makes how Roblox is handling their own handling of GDPR very relevant to us and IF due to lack of transparency they force us into a position that violated GDPR I will 100% guarantee you the end result will be them defending themselves in court and ultimately being liable.

You see IF Roblox deletes corresponding information then our data can no longer be deemed identifying as it was only ever identifying via proxy through Roblox if at all. We as developers do not handle identifying information ourselves. A datastore reference to a player ID that no longer exists and represents Nil is not personally identifying information if it cannot be linked to a tangible person.

Now if Roblox is exercising some right such as accounting to retain that information and somehow that is required in order to identify transactions in their system, that’s important to us.

However I will say I’m not going to operate on assumption. I’ve actually submitted a request for clarification to the GDPR myself as I have no faith that Roblox is even capable of properly legally translating this information and it’s requirements let alone if they would properly relay it to developers.

When I obtain clarification myself, I assure you I will share what I discover.

I have spent many years of my life working in data security as well as business law. I know exactly what I need to ask to get proper legal clarification and if it came to it I would subpoena missing legally required information from Roblox if I have to.

Most of us have learned through leaked information the kinds of data Roblox’s back end system keeps on people. What we haven’t learned is how Roblox handles the link between the player and the internal player ID.

Speculation beyond that is pointless and any claims that this information is known is nothing more than speculation.

The smart legal choice for Roblox would be to delete all information from the user account and only keep their financial records necessary for accounting.

IF that is what they are indeed doing, our information is not personally identifying.

IF through HTTP service a developer is collecting additional information, including certain analytics data, social media account information, etc. that is a whole different subject.

Datastore references to a Roblox ID however should not be identifying unless Roblox is doing something very wrong.

The way their business model operates, if they are legally retaining identifying information under any grounds that can link to that player ID they are also legally obligated to provide that information to us so that we ourselves can evaluate our legal position.

Thus far to my knowledge, this has not happened.

Edit: I would like to add that if you are collecting information through 3rd party sources such as http services you have more to worry about than Right-to-be-Forgotten requests. You need to ensure the data you are keeping and how it is being stored comply with GDPR as well. If you’re not prepared to do this then you have no business running a game that stores such information.

You’re not even protected if you are a minor nor are you through ignorance. Your parents or legal guardians would simply bare the burden of liability for violations.

On that note, Roblox really should have long since put out notifications towards such and should be clarifying Roblox’s terms of service and what is allowed through such services to reflect the current law.

Edit #2: Regardless of any of this, especially if required to maintain the integrity of a datastore system. The option to pseudonymize the player ID would also exist. Absolute worst case you could replace the player ID # with a fictitious alias that wouldn’t break the datastore.

I would also make sure player names are not stored, those could be identifying.

Some random progress within your game is not identifying.
The player ID # is most likely not, though I don’t think Roblox provides enough information to determine this in regards to how they handle their end, which is far more important than ours.
User names are too risky, people often re-use those and have that linked to other outlets.
(even though this is dicey and not necessarily a guarantee).
Something to note, even a person’s name, as given in the example in GDPR publications such as “John Smith” may not necessarily be considered identifying as there are may John Smiths out there.
The question exists in the “when combined with other information”. Could the fact that they play on Roblox be used? That’s a big? but not one I’d risk.

So “IF” player ID’s are even at question, which I sincerely doubt, pseudonymizing them would eliminate any threat or risk as there is no question at all that whatever remains could never be linked to a natural person.

So just replace all datastore references with 000000’s or something safe of that nature if you’re uncertain.

Last edit then I’m done:
Depending on how Roblox handles their end, which assuming since they seek to go public it’s fairly certain they are trying to become fully compliant themselves, then it’s entirely possible the ID reference could not be considered identifying information (as mentioned, I’m seeking legal clarification on this).

In the unique scenario of how our systems work in conjunction with Roblox’s, if we pseudonymize the ID and keep no record of what the original one was, no one, not even Roblox themselves would ever be able to link that information and therefore it could never in any way meet the requirements to be able to be used to identify a natural person.

You would “probably”, and I say probably because there’s some unknown factors, be safe even with a player ID but would 100% be safe pseudonymizing or deleting it.

That said, we are legally allowed to require Roblox to verify the identity within our limitations and us requiring Roblox to tell us the game in which said data is connected to, the player ID, and any relevant information we may need to ensure it’s removed properly.

By operating as a proxy link, Roblox has just as much requirement to provide us necessary information as the player is required to provide Roblox. I would suggest holding them to that any time you have any concerns.

3 Likes

As the UK leaves the EU, the British government is putting into law an equivalent of GDPR dubbed ‘UK GDPR’, which is mostly the same, and gives UK citizens the ability to make the requests they’re currently allowed to make under the EU’s GDPR.

Whilst some details have not yet been confirmed, the following from the Information Commissioner’s Office makes clear Roblox will probably also have to comply with these requests:

The UK government intends that the UK GDPR will also apply to controllers and processors based outside the UK if their processing activities relate to offering goods or services to individuals in the UK or monitoring the behaviour of individuals taking place in the UK.

TL;DR: UK citizens will probably be able to continue making GDPR requests if they wish.

Contains public sector information licensed under the Open Government Licence v3.0.

2 Likes

Haha, now this wont take literally forever

2 Likes

I mean, yea not bad. To be honest this update well be good.

1 Like

I’m happy to see Roblox is aware of some of the previous lack of clarity with these messages, but I feel like they could go a step further. If Roblox offered developers some way of automating this process, such as implementing API that can allow developers to script GDPR protocol directly into the game to fill out these types of requests without manually going through them.

While smaller scale developers can keep track of these requests, I feel that it would be more practical if we could just integrate this stuff with Lua and not have to worry about it.

6 Likes

This will greatly help as i have a lot of games with datastore enabled.

Many people have requested a way of automation, but it’s not that simple. I’d like to touch on why this will not happen under any circumstances in the current landscape.

There’s two scenarios that many people have proposed:

  1. If roblox did it on their end, they would have to either scan the entirety of all datastores when a GDPR request is made, or make a giant manifest of every (potential) user ID in your datastores (which would be determined when you set the data, and for old data potentially when you fetch it). The issue with this method becomes the mere scale of the operation. The amount of data that would need to be parsed, and the amount of processing power it would take to do it.
    This method is simply not realistic, and there would be an absurd amount of old data that is not indexed as containing a UserID.
    Not to mention, UserIDs are incremental. What about 123? 1234? 12345? What if hundreds of thousands of players have the same amount of cash as someone’s UserID who submitted a GDPR? All of those user’s data is just gone because it happened to contain that number?

  2. A lua based automated system. Either by specifying a DataStore entry contains X UserID when you use SetAsync/UpdateAsync, or alternatively an event/callback you subscribe to. Neither of these are a good idea. The first requires changing the DataStore API itself to supply UserID(s) assosiated with that DataStore entry. The latter requires the user to receive a UserID and then delete it from their data via lua code.
    How would you account for old DataStore entires?
    What if the game has no active servers at the time?
    What if a server is shutdown as the event is fired?
    What if the datastore request fails? Even if you have a system to retry, what if the server ends before it ever gets a chance?
    What if the event is not fired at all due to an internal roblox server issue?
    Sure, you could treat it like ProcessReceipt, but that isn’t good enough either. What if only one server pops up after months, and there’s hundreds - maybe even thousands, or tens of thousands of uncompleted GDPR requests when that server is created? How should they handle firing the event? Incrementally? All at once?
    What if you store the UserID in a value, and that DataStore entry can’t be easily indexed via the key to know that their UserID is somewhere inside that value? Do you just parse every datastore entry in lua by hand hunting down the UserIDs in the value? What if the server ends as your looping through potentially millions of entries? Must you create a manifest of every UserID and DataStores/Keys it’s within? How do you parse said manifest once you have 1 billion visits?
    Quick Edit: an additional honorable mention, how do you possibly handle timestamp based backups? You don’t, as you can’t, not even manually (in a realistic amount of time) let alone automated by a lua event. The server would be shutdown before you can guarantee you got rid of every backup between their account being created and now.

Logistically, it’s not possible without totally remaking DataStores as we know it. That will never happen. This raises dozens of questions, but not enough solid answers on a way to 100% deal with it, accounting for user errors, datastore errors, Roblox server errors, and potentially other areas I didn’t think of.

GDPR requests will never be automated on Roblox. Echoing the same shot in the dark idea with no real way to actually handle all of these various scenarios is not realistic.

(@Zeezy2204 this was not directed towards you specifically, however I replied to you as you were the latest person to suggest such an idea. My intentions are simply to inform people of some logistical problems they may not have considered when pitching said ideas)

3 Likes

While I agree with your first point, the issues raised in your second are fairly trivial to overcome if existent at all.

Roblox could start with a new event that when called returns an array of UIDs, and a function that takes a UID.

We know that Roblox can analyze the code in our games, so it should be rather trivial for them to detect if someone has made use of said API in a game. In that case, they can simply spin up a special version of the server (similar to test mode) when that game was played by a user filing a right to erasure request.

Now obviously Roblox does not want the server spooled up and doing nothing for a extended period of time, and that is where the function comes into play. When the game finishes deleting a UID, it calls the function with a UID. This tells the Roblox that that UID has been deleted. Once all the UIDs are deleted, Roblox can spool down the server. If for some reason the devs deletion script did not work, Roblox can then return a helpful list of UIDs that were not automatically processed to the developer.

Anything related to datastore formatting is on the developer, and is no different between a automated system and the manual one we currently have. If you are using timestamp based backups, you are on the hook for figuring out how to delete the information. If its not realistically feasible to delete them, then you shouldn’t be using them.