Design
Online safety and privacy
Updated: Sep 3, 2024
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, let them establish their boundaries for online interaction, and give them agency over who uses their data.
Developing for online safety
Providing safety controls in your application fosters a healthier community and makes it easy for people of all experience levels with 3D or 2D apps to use your app. Considering user safety throughout the development of your app can prevent problems that might be difficult or costly to solve later on, and build confidence in your brand. Check out our short video course on content moderation and reporting compliance to jumpstart your safety journey.
Requirements
As a baseline, apps with user-generated content must have a form for users to notify the developer about conduct in the application that does not adhere to the Code of Conduct for Virtual Experiences (VRC.Content.3).
This requirement ensures that all developers maintain responsibility for their community and fosters a positive environment.
As a developer, you’re expected to ensure adherence to the Code of Conduct for Virtual Experiences (CCVE) by acting on user reports. If you don’t act on CCVE violations, Meta will start to notify users on your Store listing that your app is not in compliance. If you continue to ignore CCVE violations, your app could be removed from the store.
Example of a Store warning for not acting on user reports
Best practices
Beyond Meta’s baseline requirements, some best practices for fostering a healthy community in an app include:
Tailor the experience
- The first time your app launches, show users the app’s code of conduct so they understand the rules to abide by and what user behavior isn’t tolerated. Include clear examples of good and bad behaviors.
- Explain to users how their behavior will be moderated. For example, by automatic voice moderation, community admins, a moderation team, or another method.
- Make your block and report features accessible by providing clear instructions.
- In your reporting flow include reporting reasons specific to your app so that users can clearly understand what type of behavior or conduct they should report within your application.
Enforcement advice
- Create enforcements that make sense in the context of the app.
- When you discipline a user, remove their access to features that are proportionate to the severity of the violation.
- Where possible, allow users to learn from their mistakes by starting with gentler enforcements, like warnings.
- Communicate the duration and reason behind the enforcement, and provide a way for the user to appeal.
- Make it clear to users that reports and enforcements are managed by you, the app developer, and not by Meta.
Platform features to use
- Create a native in-app reporting flow to match the visual look and feel of your app and connect it through the User reporting plugin. Or customize your report reasons within User Reporting Service to be tailored to the violating behavior in your app.
- Use the Blocking API, which lets you uphold user blocks across the platform, creating a safer experience and protecting people from bad actors they previously encountered and blocked.
Additional features to consider
- Muting: Allow users to mute other users so that they can self-remediate noisy or annoying players.
- Personal space management: In immersive space, allow people to set a small barrier around themselves to prevent unwanted close, physical interactions.
- Vote kick: Let users vote to remove troublemakers from a room without admin or developer involvement.
- Admin kick: If your experience has admins or moderators, give them the ability to warn or remove disruptive users.
- Evidence collection: Enable video or photo uploads in your reporting flow so users can provide better evidence of wrongdoing. If you are using our User Reporting Service, this is already included in the reporting flow.
Examples
Population: ONE uses the User Reporting Plugin to create a reporting flow that lists specific types of behavior they’d like users to report.
1. Native UI | Population: ONE’s reporting flow was made with the User Reporting Plugin so that the visual look and feel matches the rest of their in-game UI. This makes it clear to the user that this report will be handled by Population: ONE and not Meta. |
2. Tailored reasons | The reasons for reporting a user are tailored for the context of the user. For example, since Population: ONE is a synchronous multiplayer game, you can’t report a user for any content-based reasons, only conduct-based misbehavior. |
3. Freeform text entry | To provide more context, a user can enter additional details for any of the selected reasons. |
4. Other category | For reports that may not cleanly fit into any of the provided categories, there’s an “Other” category. |
Meta Horizon Worlds provides many additional features beyond reporting to help users manage their experience.
Muting controls
To mute another user in the same space with you, just hover over their nameplate.
To mute another user in the same space with you, just hover over their nameplate.
Moderator removal
Guides and moderators can remove disruptive individuals from a session.
Guides and moderators can remove disruptive individuals from a session.
Poll to remove
Users in a session can initiate a poll to remove a disruptive player by popular vote.
Users in a session can initiate a poll to remove a disruptive player by popular vote.
Personal boundaries
Users can set their own preference of how close others can approach them. Other users will disappear if they get too close.
Users can set their own preference of how close others can approach them. Other users will disappear if they get too close.
Developing for privacy
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’s Organization.
- 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: Organization 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).
If your app accesses user data, you will be required to complete a Data Protection Assessment which assesses how you use, share, and protect User Data and/or Device User Data as defined in the Developer Data Use Policy. If you are unable to complete the assessment by the deadline, your app will be removed from the Meta Horizon Store, and you risk losing access to the advanced platform features altogether.
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.
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.
Links
- Meta Quest Privacy Policy requirements
- Meta Quest Content requirements
- Data Protection and Privacy Guidelines
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?
