then make it an optional solution gee? there’s all kinds of solutions and having a solution for this does not seem difficult at all, because you still have tons of other things you should worry about, but this needs to be done as a solution
Sorry, but I don’t understand what this feature is supposed to do then if you can’t make requests from in game
How about being able to access Roblox messages? to listen for Right to Erasure requests and the game automatically removes them? The owner just needs to register/opt-in on the game from the experience dashboard.
Amazing feature and very unexpected!
Future event types I would like to see are all data store actions. For a huge data migration I am working on we would like to externally mirror the data stores as the current Open Cloud rate limits are very limited and make a migration of this magnitude from an old data store directly to a new data store take days. It would be cool if we could set up a webhook to receive data updates so that we don’t have to embed HTTP calls in-game. This would still then take days but gives us a bit more control over the operation.
Other features for Open Cloud making migrations like this (it is a keyword in the Data Stores section on the Cloud API developer documentation) viable would also be welcome.
Essentially you define a webhook on Roblox.
Roblox will then send a HTTP request to that webhook whenever they detect something has to be done (in this case GDPR requests).
This webhook is a web server that lives on your own self hosted server which takes in the request and does something with it, in this case you want to access the datastore cloud API with it and remove the requested data.
Still does not adequately address the need for automatic GDPR requests. I shouldn’t need to host my own server in order to do this automatically, I should just be able to write some code telling Roblox what to delete, Roblox can then run that code whenever a GDPR request is received.
Okay, thanks! I basically know nothing about web development so this is helpful. One question, when you say it detects something has to be done, when is that?
Currently we don’t send the information on the retry-count in the header or inform that this is the last retry attempt. But you bring up a valid concern. We will look into this further and add this as a fast followup.
It’s really important that the retry method and path of failure is handled and explicitly documented, especially in the case of a GDPR request.
If my server is offline for a few hours and does not handle the webhook event, what exactly happens? In the best case, developers will have redundancy webhooks set up (to other services like Slack) and can process those requests when it goes back online.
Will Roblox still send a direct message through the current system, which allows for a guaranteed method of delivery?
A lot of times where automation is possible, people abuse platforms and then, those platforms react. By Roblox providing a structured & consistent gateway, it removes the need for abuse and opens the door for other things to take shape in the future.
It’s similar to github webhooks on Discord. You create a webhook, bind it to some sort of actionable url and there’s event triggers on that payload. That payload can be processed by an outside server or displayed as an incoming message (like Discord).
Great update.
I just want the ability to disable GPDR request notifications altogether makes Roblox messages significantly less useful
Some people are replying without reading the thread. Chances are that you don’t need to use or know anything about this feature if you have no business receiving notifications or payloads on external servers or have no idea what any of this actually is.
ELI5: New feature that lets you handle Roblox notifications on third party services.
If you don’t use third party services, probably not for you. If you use Discord/Guilded/Slack, then you just need to know how to input the webhook URL, which is in the video and documentation, only if you want to receive important notifications like erasure requests off your Roblox inbox.
Basically, Roblox internally knows when a GDPR request has been made (for example upon user deletion). When they detect this happened they can invoke the webhook to notify you that this happened.
It’s basically sort of like an event-based system.
I don’t think personally a redundancy webhook is needed.
The uptime should be a basic given, even if your system crashes you can have it automatically reboot within seconds.
Also what you can do is only write away the GDPR removal request to a database you have locally, that way you can immediately return a 200 OK response to Roblox, which finishes the webhook and pick up the GDPR request later by fetching it from the database.
I’m a bit lost here. For clueless people like me would somebody mind explaining how exactly you could automate a GDPR request using this? Using it through Discord for example, would people need to make a bot to read the content of incoming webhooks? If so this still feels like a very complicated solution only accessible to people proficient in bot development, web development etc.
I think this sums up my problems pretty well.
You can send it to any webhook you need. Roblox just made special integrations for Discord, Guilded and Slack.
If you send it anywhere else you get a default response body containing the user ID of whom to delete the data, you can then use the datastore open cloud API to automatically remove that data.
Assistance or tutorial for how we could use this for automatic GDPR erasure would really be appreciated. I have no idea how I would utilize it myself and I don’t feel like it’s fair that I have to learn it in order to handle a pain point that Roblox seemingly have all the tools to solve themselves.
I understand this will have more uses in the future, so I should definitely learn more about webhooks regardless. But for now it’s only GDPR which is a very niche case to learn to handle.
I don’t think I’m alone in feeling overwhelmed by the amount of GDPR messages we receive. While bigger studios might have automatic solutions in place already, I still think it’s in Roblox’ interest to make sure smaller studios can comply regardless of technical know-hows.
Let’s assume you have a very simple setup where you have an experience that stores some PII in player data in Datastores. (there may be experiences that have more complicated external systems where they need to remove data as well; this is just a simple example)
-
Create an Open Cloud API key that has datastore access for the specific universe.
-
Host a script somewhere (or use a third-party platform) that intakes the webhook event payload, parses the “gameIds” list in there, and then if “gameIds” contains your specific experience that you want to automate right-to-be-forgotten to, delete the respective Datastores key(s) for that userId via Open Cloud API with the API key.
-
Create a webhook that is set up for right-to-be-forgotten events on Roblox as per this announcement, and point it at your address where the endpoint that your script listens to is hosted.
I agree we can probably provide some example in the documentation like I just did above. I will take this feedback to the team.
It should be noted that GDPR is a complex topic, and many games store their data in many different ways (datastores, external systems, external analytics platforms, loggers that go to Discord/Guilded/etc that may contain PII). It is up to you as developer to properly erase the user data where needed, since we don’t have a way to find and delete relevant data in all the different systems you may be using.
(For specific questions and tailored recommendations, I recommend consulting our terms and/or a legal attorney if you are running an actual experience and have in-depth questions on what you should remove on a right-to-be-forgotten request.)
This is good feedback thanks. I have forwarded this internally.
For context we try to ship features in small iterations so that we can provide something useful to the community fast and get feedback more quickly on what we are releasing so that we can take that into account for future work.
This release today doesn’t mean this is the most we will ever do towards the ability to automate right-to-be-forgotten, it’s just a single step towards simplifying this problem (and many other problems as we onboard more event types onto webhooks).
Really helpful, thanks!
On another note in response to this:
It’s mentioned in the announcement of DataStore V2.0 that metadata could potentially be used to create a tool to automate right to erasure requests, is this still in consideration?