Design

Designing for privacy

Updated: Oct 6, 2025

Keeping the metaverse safe and private is a responsibility shared by Meta and developers. The requirements and recommendations we outline here are meant to assist in making users feel safe, build trust in apps, and ultimately help developers succeed. As you develop immersive experiences, it’s vital to provide users control over who they interact with, give them agency over who uses their data.

Our devices have many novel sensors that store or process multiple data types, so it’s essential to protect data that users provide and be transparent when you request data from users.

Requirements

Every developer must provide a Privacy Policy to Meta as part of our VRC Privacy Policy requirements:

VRC.Quest.Privacy.1	Privacy Policy URL links to a privacy policy statement managed by the app team.
VRC.Quest.Privacy.2	Privacy Policy clearly explains what data the app is collecting about the user.
VRC.Quest.Privacy.3	Privacy Policy clearly explains how the app is using user data.
VRC.Quest.Privacy.4	Privacy Policy clearly explains how the user may request that their user data that has been collected or stored can be deleted.
VRC.Quest.Privacy.5	Team and app must clear data protection checks.

In addition, apps may only request the minimum number of permissions required to function, and may not include permissions that are unsupported on our platform. (VRC.Quest.Security.2).

To request certain features, you will need to complete a Data Use Checkup to affirm that API access to certain Platform SDK features complies with the Developer Data Use Policy (DDUP).

To help users make an informed decision about if they should download your app, your app’s store page will list any permissions you use, Platform SDK features that you access, and your privacy policy.

Example of how App privacy labels appear on a Store listing

Best practices

Don’t ask for more user data than your app really needs. Each API a developer accesses increases the length of the Data Use Checkup and will need to be recertified each year. In addition, if users see your app accessing data that they think is unusual for your app type, they may not trust your application.

Give users context when asking for their data, even if it may be necessary for an app to function properly. Being open with users about the purpose of data collection and how their data will be used creates trust and helps users make informed decisions. If optional features require additional data from a user, wait until they try to use the feature to ask for that data.

Provide quick controls once your app has permission. For example, once an app has the microphone permission from a user, make it simple and quick for them to mute or un-mute themselves in the app.

Create app-specific privacy controls. For example, if your app has multiplayer lobbies, give users controls around if those lobbies are public or invite-only. Create controls that make sense for your app that aren’t provided at the OS level.

Avoid deceptive design patterns. Don’t have interactions in your app that trick users into doing things that benefit you, or design elements that make it tough for users to do things you don’t want them to do. Some examples include:

Tricking users into sharing more information

Using shame or guilt to convince the user to do something;

Using distracting or confusing user interfaces

Making it more difficult for a user to cancel for a service than it was to sign up

Respect user choice. Don’t lock users out of features for not granting a permission if that feature doesn’t rely on the permission. For example, don’t lock users out of multiplayer features if they don’t grant the microphone permission. Some players may choose to use the app silently and developers should respect that decision.

If a user doesn’t grant a permission that is critical for your application to work, you can direct them to your app’s permissions page from your application by leveraging the following code:

   val intent = Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS)
   val uri = Uri.fromParts("package", activity.getPackageName(), null)
   intent.data = uri
   context.startActivity(intent)

Provide context around why you are asking the user to grant the denied permission and provide an explicit entrypoint for them to open the settings page, instead of triggering it without user input.

Do’s and don’ts for permissions

Below is a list of our recommended practices when requesting permissions from a user:

DO Provide context if triggering a permission prompt that explains why your app requests this data from a user.

DON’T Ask for permissions right after launching an app, since users don’t have context about why your app wants this data.

DO Render permission requests in-situ, so users keep the context of the app asking for their data.

DON’T Have permissions render in the gray void.

Resources

The Meta Quest Channel on Data Protocol helps you navigate Meta’s compliance requirements, prepare for a successful app submission, and complete the initial and ongoing review processes with confidence.

Did you find this page helpful?