FAQs

Game onboarding

Q: How do the users play the game? Do they get into the game without a Terms of Service screen?

A: With Zero Permissions, Meta no longer shares user data that requires permissions from the user. As a result, users no longer need to consent via the “Terms of Service” screen. Instead, users set their preferences one time and afterwards directly enter into the game. The preferences they set include which profile they want to use (i.e. real profile or gaming profile) and their game visibility setting.

The Zero Permissions user experience has two scenarios: Users that have not yet onboarded to Zero Permissions that will need to set their Zero Permission Setting once for the platform.

User who have previously completed Zero Permission Onboarding will directly enter the game.

Q: Will games be able to access user identifying data? Or is it only accessible inside of the overlay view iFrames?

A: Game developers will no longer have direct access to the current user's profile picture or name, or their friends' profile pictures or names in the game session. Uploading or storing this data to your own servers is not allowed. All the aformentioned user identifying information is only accessible in Meta rendered overlay view iFrames. We do provide player IDs and context IDs in order to facilitate player progress, etc.

Q: What if the game needs user identifying information? Can we get user consent to get this data?

A: No, the Network Enabled Zero Permissions does not support requesting user consent in order to access user identifying information. Instead of directly accessing user information, this data should be rendered in the Meta Hosted iFrames via our new overlay APIs.

Q: Our Game has a lot of surfaces including friends list, invites, etc that uses names and profile pictures - would Zero Permission impact those features?

A: Yes, those features will be impacted. We will provide friend player IDs of the current user but to render their names and profile pictures you would need to pass this ID to the iFrames/overlay views which will render this information. You can have one iFrame for each friend of the current user, or you can have one iFrame containing all of the friends information. We will have different game use cases detailed soon.

Social Features

Q: How do we implement the friends list in our in-game UI? How can we implement corresponding actions to each friend?

A: You can fetch the current user's friends' player IDs using the `FBInstant.player.getConnectedPlayersAsync` API. You can then render the friends' information in separate overlay views. The corresponding buttons next to friend entries can then be hooked up to the corresponding player IDs in your own UI. More information here.
You can also render all the friends information in one single overlay view using control structures and the connected players directive. Buttons can be rendered inside the overlay view with callback events to your game's iframe.

Q: We have a complicated league/matchmaking/leaderboards system where we render numerous player entries that are not directly connected to the current player, how do we achieve that?

A: You can render an arbitrary player's profile picture and name in an overlay view given a player ID. With this, you can render the entries in one big overlay view by providing a set of player IDs passed in from the game or render separate overlay views per player. You can find more details here.

Migration

Q: We have instant games on the platform. How do we test and move to Zero Permissions without impact?

A: You can safely mark your instant game as Zero permissions, network enabled without impacting your current production bundle and users. You can switch between the models for your own testing, and control the rollout completely on your side for the Zero Permissions bundle that's separate from your production bundle. You can find more details here.

Q: My existing game is asked to delete user data before migrating to Zero Permissions, what exactly should be deleted?

A: Firstly, we are NOT requesting deletion of Player ID and ANY gameplay data. Player's progress with the game should be persistent before and after migration, and Player ID will stay the same.
Instead, we are asking developers to delete any copies you have saved for player's personal and social data that your game has acquired from Facebook, commonly this include the player's name, profile picture, and list of friends. The recommended practice is always call Instant Game API to get the names and picture for every session - because user's profile picture may change and this way you will always present the latest profile picture in the game. Similarly for friends list - you shoud always retrieve that data when game loads, instead of saving any copy on your servers, because players may have new friends joining the game. If this is how your game works, then there is nothing for you to delete.
If you have saved copies of player's personal social data mentioned above, you will have 14 days to delete after you begin migration of players of your game to Zero Permissions. This is for the use case of when you are displaying global leaderboards information to players and you have been storing this data on your end. You can always display unconnected player information in NEZP, but for the players in non-ZP sessions you would have to rely on your stored data and hence the 14 day buffer period. You can complete your migration on a longer timeframe, but you are required to delete player information within 14 days and would have to rely on alternate profile images/names for the non-ZP players till your migration completes.

Q: Why do I no longer need advanced permissions when I rollout the zero permissions experience to 100% of users?

A: Prior to the introduction of zero permissions, game apps needed to apply for access to certain advanced permissions (gaming_profile, gaming_user_picture, gaming_user_locale, user_friends, and email) to enable rich social play experiences. Under the zero permissions model, those social play experiences are enabled by Meta through rendered overlay view iFrames and the advanced permissions are no longer needed to enable the additional functionality. Because advanced permissions require developers to undertake compliance tasks to maintain access, certain compliance tasks will be reduced. Apps can re-apply for access to advanced permissions if they believe they still need access, though this is not recommended.