7.2 UGC: Common Items

Applications that exchange any type of UGC must comply with the rules in this chapter.

7.2.1 Cautioning the User

If your application exchanges UGC, you may be required to caution users to avoid offending other users, and to avoid engaging in illicit behavior. If both of the following conditions apply to your application, then the caution text below must be displayed within the application at least once before the first time UGC is sent. However, even if the following conditions apply, it is not necessary to display this caution text if the UGC is exchanged in local communication where the communication partner can be identified beforehand. If the following conditions do not describe your application, Nintendo simply recommends displaying the caution text, but does not require it.

  • Applications for the European market
  • Applications that exchange photos or video with other users.

Use the following caution text, localized as needed. You are free to reword this text, as long as the meaning is not changed. However, if there is no reason to do otherwise, Nintendo recommends using the text shown below without changing it.

Statement A: Do not send [content] that is illegal, offensive, or could infringe the rights of others. Do not include personal information and make sure you have obtained all necessary rights and permissions from third parties.

Add the following statements to the caution text for each case that applies.

  • When recipients can redistribute UGC they receive:
    Statement B: [Content] may be distributed by third parties.
  • When recipients can alter UGC they receive:
    Statement C: [Content] may be altered or reused.
    Note that it is not mandatory to include the above statement if altered UGC cannot be redistributed.
    In such cases, including the above statement is simply recommended.
Figure 7-6 How to Determine What Caution Text is Required

 

Note:

The most recent E-Manual Templates package includes an e-manual template ("Information-Sharing Precautions") intended for applications that exchange UGC. This template, depending on your application's region, may already include caution text that is applicable to all applications that exchange UGC, and use of this template is mandatory for all applications that exchange UGC. For details, see the Electronic Manual Creation Guide (also called the E-Manual Cookbook), included in the same package.

7.2.1.1 Supporting User Cautions

Guideline Item

Applications must display caution text about exchange of UGC before sending UGC for the first time, and must do this separately at least once per each save data slot.

Software to Be Tested

Applications that fulfill all the following conditions:

  • For the European market
  • Can exchange photos or video with other users
Exceptions

Implementations that correspond to any of the following:

  • Exchanging UGC via local communication where the communication partner can be identified beforehand.
  • Writing UGC to the SD card (see section 7.1.4 Exchange of UGC)
Test Method
  1. Prepare two Nintendo 3DS systems, system A and system B.
  2. On system A, create UGC.
  3. Send the UGC created in step 2 from system A to system B.
Pass/Fail Determination

All Applications:

Passes if the application displays either the following caution text or an equivalent message, localized into each supported language, on system A at least once per save data at an appropriate time prior to the exchange of UGC in step 3.

  • Do not send [content] that is illegal, offensive, or could infringe the rights of others. Do not include personal information and make sure you have obtained all necessary rights and permissions from third parties.

Applications that can redistribute received UGC:

Passes if, in addition to meeting the conditions for All Applications, the following or an equivalent statement is added to the caution text

  • [Content] may be distributed by third parties.

Applications that can alter and redistribute received UGC:

Passes if, in addition to meeting the conditions for All Applications, the following or an equivalent statement is added to the caution text

  • [Content] may be altered or reused.

7.2.2 Prior Explanation

If UGC is exchanged in an application without first notifying users, it may offend users who do not want to exchange UGC. To avoid this, you must explain at least once within the application before exchanging UGC for the first time what operations will trigger exchange of what UGC. You must also ensure that the application does not automatically start exchanging UGC after giving this explanation to the user.

Different types of UGC allow different degrees of expression. See the table below for which types of UGC require this explanation.

Table 7-2 Which Types of UGC Require Prior Explanation
Types of UGC Before sending UGC for the first time Before receiving UGC for the first time
Photos, video, audio Required Required
Text, images, animations Required Recommended

System user name

Mii nicknames (see section 7.1.1 Types of UGC)

Miiverse posts (text, handwritten messages, image data) sent by the Miiverse posting applet

Recommended Recommended

In cases where prior explanation is recommended, consider providing it based on your application's content and the degree of expression allowed in the UGC. Note that Nintendo recommends providing the prior explanation separately for each set of save data.

As long as the explanation conveys to the user what operations will cause what UGC to be exchanged, Nintendo sets no rules about the exact content of the explanation or how to give the explanation. If the name of a setting, menu option, mode, or similar label explains this in a self-evident way, it is acceptable to consider that to be a sufficient prior explanation, and your application is not required to display a separate message explaining it to the user. Below are some example implementations.

Example implementations using messages
  • Before sending the user name and comment on the user's profile card, along with gameplay information or other information, displaying the message "Okay to exchange your profile? Send / Don't send"
  • When the user creates a profile, explaining to them that "The user name and comment you enter are visible to your peers," and exchanging the profile via Internet communication or local communication.
  • Displaying a UGC artwork, its name, and any comment or other information attached to it as a complete set, and then ask the user "Do you want to post this artwork? Yes / No." If the user agrees, sending that complete set of UGC.
  • Before communication starts, explaining: "You can use text to chat with communication partners."
  • After each time the user creates a drawing, confirming: "Post to forum?"
  • In an application where users use avatars to battle each other online, explaining with "Enable Automatic Posting in the Settings Screen to automatically post replay data after a match." If the user then enables Automatic Posting in the Settings Screen, automatically posting replay data after every online match from then on. (See Note.)
  • Confirming with "Start game chat? Yes/No". Then, allowing game chat only if both users select "Yes."
  • Displaying a message asking, "Post your impressions to Miiverse? Yes/No" and launching the Miiverse posting applet after the user selects "Yes."
Example implementations where explanation is clear or self-evident from the name of a setting, menu option, mode, or similar label
  • Having a "Start Chat" button on the screen displayed during communication, and when the user presses it, displaying a "Start chat?" confirmation message to the other user. And if the other user then confirms, starting chat.
  • Making automatic posts only if an "Auto-posting" setting in the Options screen is turned ON. The default setting is OFF.
Note:

If you publish UGC on a server, then in addition to giving the prior explanation required by this section, Nintendo recommends displaying an explanation informing users that their UGC may be deleted by the server admins. See section 7.2.4 Publishing UGC on a Server for details.

Similarly, if your application publishes user data on a server, also see section 6.12.2 Extent of Data Disclosure.

7.2.2.1 Support for Prior Explanation

Guideline Item

Applications must convey what operations will trigger exchange of what UGC at least once within the application before exchanging UGC for the first time. This information must be conveyed to both the senders and recipients of UGC. In addition, applications must not automatically start exchange after simply conveying this explanation.

Note: For some types of UGC, conveying this information is recommended but not required. Applications must comply with Table 7-2 Which Types of UGC Require Prior Explanation.

Software to Be Tested

Applications that exchange UGC.

Exceptions

Implementations that correspond to any of the following:

  • Exchanging system user names
  • Mii nicknames (see section 7.1.1 Types of UGC)
  • Writing UGC to the SD card (see section 7.1.4 Exchange of UGC)
  • Miiverse posts (text, handwritten messages, image data) sent by the Miiverse posting applet

Test Method
  1. Prepare two Nintendo 3DS systems, system A and system B.
  2. On system A, create UGC.
  3. Send the UGC created in step 2 from system A to system B.
Pass/Fail Determination

Passes if all of the following conditions are satisfied in compliance with Table 7-2 Which Types of UGC Require Prior Explanation, at an appropriate time prior to the transmission of UGC in step 3.

  • The application conveys what operations will cause exchange of what UGC at least once within the application.
  • At least one of the following conditions is met.
    • The application gets the user’s consent to exchange UGC at the same time or after conveying the information above, and is only able to exchange the UGC if the user gives consent.
    • The application exchanges UGC only after an explicit user operation intended to start UGC exchange.

7.2.3 UGC Sender Name

Anonymous exchange of UGC between users could potentially encourage the exchange of offensive or illicit UGC. Furthermore, if by some chance a problem results from the exchange of UGC, then it would be difficult to come to any resolution if the sender of said UGC could not be identified. As a result, in the following cases, you must send information that can identify the sender of UGC and display it to the receiver. Alternatively you can embed information that can be used to identify the sender in the UGC, so that if there are any problems the receiver will be able to identify the sender. "Information that can be used to identify the sender" refers to the transferable ID obtained by the nn::cfg::CTR::GetTransferableId function, and also to any other ID that cannot be duplicated by another console or user.

  • Rich UGC exchanged during communication where the communication partner cannot be identified beforehand
    For example, this would apply to rich UGC downloaded via SpotPass, StreetPass, or local communication where the communication partner cannot be identified beforehand, rich UGC that is always available for download after being uploaded to a server, and similar situations. On the other hand, rich UGC sent by a sender who is clearly identifiable (for example, during P2P communication with a matchmaking partner) is exempt. However, be aware that specifications where the identity of the communication partner is not known (even during P2P communication) fall under the scope of this guideline.
  • Rich UGC exchanged with multiple unspecified users
    For example, this would apply to rich UGC that has been uploaded to a server which can be accessed by all users.

There are some exceptions. Even if the above conditions apply to your application, you are not required to comply with this guideline in the following cases.

You are not required to comply with this section when exchanging simple UGC, but Nintendo recommends compliance to the extent possible for your application.

Note:

Do not display the principal ID to users. It is not intended to be a user-facing ID. Do not use principal IDs to identify senders of UGC to the users who receive the UGC, because this entails displaying a principal ID to the user.

7.2.3.1 Implementing Identification of the Sender of UGC

Guideline Item

An application must implement a way for the recipient of rich UGC to identify the sender of the rich UGC if any of the following cases apply.

  • The rich UGC is sent via communication where the partner cannot be identified beforehand
  • The rich UGC is broadcasted to multiple unspecified users
Software to Be Tested

Applications which exchange rich UGC via at least one of the following methods:

  • Communication where the communication partner cannot be identified beforehand.
  • Methods to broadcast UGC to multiple unspecified users
Exceptions

Implementations that correspond to any of the following:

  • Exchanging UGC converted to graphical codes
  • Writing UGC to the SD card (see section 7.1.4 Exchange of UGC)
  • Using the OLV library to send or receive UGC

 

Test Method
  1. Prepare three Nintendo 3DS systems (system A, system B, and system C).
  2. On system A, create rich UGC.
  3. Send the UGC created in step 2 from system A to system B via the following methods.
    1. Communication where the communication partner cannot be identified beforehand.
    2. Methods to broadcast UGC to multiple unspecified users
  4. If the application includes a specification to display information which can be used to identify the sender of the rich UGC:
    1. On system B, display the UGC received in step 3.
  5. If the application includes a specification to embed information which can be used to identify the sender in the rich UGC:
    1. Check the source code.
  6. If the application contains a specification which allows the rich UGC to be redistributed:
    1. Transmit the UGC received in step 3 from system B to system C using the methods described in steps 3a and 3b.
    2. If the application includes a specification to display information which can be used to identify the sender of the rich UGC:
      1. On system C, display the UGC received in step 6a.
    3. If the application includes a specification to embed information which can be used to identify the sender in the rich UGC:
      1. Check the source code.
Pass/Fail Determination

All Applications:

Passes if at least one of the following conditions is met.

  • In step 4a, information which identifies system A is displayed.
  • In step 5a, information which identifies system A is embedded in the UGC received in step 3.

If the application allows rich UGC to be redistributed:

Passes if at least one of the following is met in addition to meeting the conditions for All Applications.

  • In step 6bi, information which identifies system B is displayed.
  • In step 6ci, information which identifies system B is embedded in the UGC received in step 6a.

7.2.4 Publishing UGC on a Server

If you upload UGC directly from a Nintendo 3DS to a server and make this UGC publicly available to third parties on the server or over the Internet, you must implement some means to rapidly respond to any requests from users or third parties to take down the UGC. It is prohibited to have an operational system from which it is not possible to take down UGC once it has been published. However, in the cases below it is possible to delete the applicable content directly within NMAS. In these cases you do not need to take any particular measure to comply with this requirement.

  • Descriptions associated with NEX matchmaking sessions
    Since it is possible to delete this UGC from NMAS, it is not necessary to handle this on the application side.
  • UGC uploaded to a server using NEX data store features or NEX ranking features
    Since it is possible to delete this UGC from NMAS, it is not necessary to handle this on the application side.

If you use the OLV library to send or receive Miiverse posts or application data, you must implement appropriate handling in compliance with section 6.18.5 Exchanging UGC via Miiverse instead of with this section.

Alongside implementing some mechanism to take down UGC, Nintendo recommends explaining the following in the application or the manual:

  • It is prohibited to post content that is clearly illegal or inappropriate.
  • Content may be deleted even after being published.

7.2.4.1 Supporting Publishing via a Server

Guideline Item

Developers must have a system to quickly respond to take down requests from users or from third parties.

Software to Be Tested

Applications that upload UGC directly from a Nintendo 3DS to a server and make that UGC publicly available on the server.

Exceptions

Implementations that correspond to any of the following:

  • Exchanging descriptions associated with NEX matchmaking sessions
  • Uploading UGC to a server using NEX data store features or NEX ranking features
  • Using the OLV library to send UGC
Test Method

Confirm whether or not currently published UGC can be deleted.

Note: Because this is a restriction on day-to-day operation, Lotcheck will not perform any tests on this item.

Pass/Fail Determination

Passes if the deleted UGC is no longer publicly available.

7.2.5 Profanity Checking

If your application exchanges text, you must check to ensure that the user does not include any unacceptable words in the text. Do not display any text that is determined to contain profanity to the communication partner. There are some exceptions; you are not required to check for profanity in the cases below.

  • Exchanging text in friend-to-friend communication.
  • Exchanging text via local communication where the communication partner can be identified beforehand.
  • Exchanging the Mii nickname or creator name of a Personal Mii linked with an NNID.
    This is because a Mii character cannot be linked with an NNID if its nickname or creator name contains profanity.
  • Using the OLV library to send or receive text.
    Note that you do need to comply if you exchange text as application data on Miiverse. See section 6.18.5 Exchanging UGC via Miiverse for details.
Note:

If your application uses Mii nicknames and creator names that it sends to other users as text data without using the CFL library, your application itself must check these names for profanity. For details, see "Mii nicknames" in section 7.1.1 Types of UGC.

If you need to set profanity in the nickname of a Personal Mii to use for testing purposes, follow these steps.

  1. Go to Mii Maker and create a Mii (Mii A) that is not the Personal Mii.
  2. Set Mii A's nickname to a word on the profanity list.
  3. Use CFLUtility (see Note 1) to set Mii A as the Personal Mii.

If your application uses the friends library to get Mii nicknames, also perform the following extra step to update the Mii on the friend server.

4. Disable wireless communication, enable wireless communication again, then leave the system idle for a brief time.

Note 1: CFLUtility is included in the SDK for CTR-SDK 11.5.2 and later.

 

How to implement the profanity check

Use one of the following functions to perform a profanity check. But if you are exchanging system user names, it is acceptable to check the profanity flag associated with the system user name instead of using the functions below.

  • nn::ngc::CTR::ProfanityFilter::CheckProfanityWords function
    This function can only check a maximum of 63 characters at a time, so if your application exchanges strings of 64 characters or more use the MaskProfanityWordsInText function below.
    Furthermore, if you are using this function, then the application itself must implement one of the following countermeasures in order to not display text which is determined to contain profanity to the communication partner.
    • Replace the text with alternate strings such as *** or ???.
    • Do not send the text, or discard it if it is received.
  • nn::ngc::CTR::ProfanityFilter::MaskProfanityWordsInText function: This function replaces any problematic portions of input text with *. This means that the application is not required to hide the text or replace the problematic character string.

 

When you use the functions above, check for profanity against the pattern list for the combination of the application’s market region and the language selected in the Nintendo 3DS System Settings. You must check against the pattern list for whatever language is currently selected in System Settings, even if the application does not support that language. Also note that for some markets you must check against the English-language pattern list in addition to the System Settings language. When the target market is North America, include a check using the English-language pattern list for the North American region, and when the target market is Europe, include a check using the English-language pattern list for the European region. See Table 7-3 Pattern Lists for which Profanity Check is Required for the specific pattern lists you are required to check against. As long as you first check against the pattern lists in Table 7-3 Pattern Lists for which Profanity Check is Required, it is fine to check against other pattern lists as well.

Note:

If you use the nn::ngc::CTR::ProfanityFilter::CheckProfanityWords ( bit32 *, bool, const wchar_t **, size_t ) and nn::ngc::CTR::ProfanityFilter::MaskProfanityWordsInText ( int *, bool, wchar_t* ) functions, they will check against all the required pattern lists. The profanity check performed by the software keyboard applet also checks against all required pattern lists.

Table 7-3 Pattern Lists for which Profanity Check is Required

Region

Language Selected
in System Settings

Pattern List 1 Required to be Checked

Pattern List 2 Required to be Checked

Japan

Japanese

JAPAN_JAPANESE

-

China

Simplified Chinese

CHINA_SIMP_CHINESE

-

Korea

Korean

KOREA_KOREAN

-

Taiwan

Traditional Chinese

TAIWAN_TRAD_CHINESE

-

Americas

English

AMERICA_ENGLISH

-

French

AMERICA_FRENCH

AMERICA_ENGLISH

Spanish

AMERICA_SPANISH

AMERICA_ENGLISH

Portuguese

AMERICA_PORTUGUESE

AMERICA_ENGLISH

Europe

English

EUROPE_ENGLISH

-

French

EUROPE_FRENCH

EUROPE_ENGLISH

German

EUROPE_GERMAN

EUROPE_ENGLISH

Italian

EUROPE_ITALIAN

EUROPE_ENGLISH

Spanish

EUROPE_SPANISH

EUROPE_ENGLISH

Dutch

EUROPE_DUTCH

EUROPE_ENGLISH

Portuguese

EUROPE_PORTUGUESE

EUROPE_ENGLISH

Russian

EUROPE_RUSSIAN

EUROPE_ENGLISH

Note: All pattern list names start with "PATTERNLIST_", which is not shown in the table.

 

The following terms have been added to the various pattern lists in order to test the profanity filter.

Table 7-4 Words Used to Test the Profanity Filter

Region

Language Selected
in System Settings

Profanity Test Word 1
(For use with pattern list 1 in Table 7-3 Pattern Lists for which Profanity Check is Required)

Profanity Test Word 2
(For use with pattern list 2 in Table 7-3 Pattern Lists for which Profanity Check is Required)

Japan

Japanese

bbwjja

-

China

Simplified Chinese

bbwczh

-

Korea

Korean

bbwkko

-

Taiwan

Traditional Chinese

bbwtzh

-

Americas

English

bbween

-

French

bbwefr

bbween

Spanish

bbwees

bbween

Portuguese

bbwept

bbween

Europe

English

bbwpen

-

French

bbwpfr

bbwpen

German

bbwpde

bbwpen

Italian

bbwpit

bbwpen

Spanish

bbwpes

bbwpen

Dutch

bbwpnl

bbwpen

Portuguese

bbwppt

bbwpen

Russian

bbwpru

bbwpen

 

You can perform the profanity check on either the sending or receiving side. There is no problem with performing this check even if it is possible to communicate with systems having different region or language settings. Furthermore, it is acceptable to check on both the sender and the receiver side. If the check is performed on the sending side, it can be done when the user inputs the text. Note that in doing so, there is a possibility that the language setting could be changed after the check but before the message is sent. However, no particular handling is required for such cases.

Contact support@noa.com if you would like to use a proprietary profanity-checking solution instead of the Nintendo profanity-checking library. It is also acceptable to perform a proprietary profanity check after performing one using the library provided by Nintendo.

 

7.2.5.1 Checking for Profanity

Guideline Item

Applications must check for profanity and take appropriate action when exchanging UGC which corresponds to any of the following categories:

  • System user name
  • Simple UGC text (including text contained in simple UGC)
  • Rich UGC text (including text contained in rich UGC)
  • Mii nicknames and/or creator names exchanged as text (See "Mii nicknames" in section 7.1.1 Types of UGC).
Software to Be Tested

Applications which exchange UGC corresponding to any of the following categories:

  • System user name
  • Simple UGC text (including text contained in simple UGC)
  • Rich UGC text (including text contained in rich UGC)
  • Mii nicknames and/or creator names exchanged as text
Exceptions

Implementations that correspond to any of the following:

  • Exchanging text between friends or via local communication where the communication partner can be identified beforehand.
  • Exchanging the Mii nickname and/or creator name of a Personal Mii linked with an NNID.
  • Using the OLV library to send or receive text (except if sending or receiving text as application data).
Test Method
  1. Prepare two Nintendo 3DS systems (system A and system B) with System Updater 0.16.9 or later applied.
  2. On system A, create a text message containing “Profanity Test Word 1” from Table 7-4 Words Used to Test the Profanity Filter using the list appropriate for the settings of system A (if the check is performed on the sending side) or system B (if it is performed on the receiving side).
  3. Attempt to send the text input in step 2 from system A to system B.
  4. On system B, display the text received in step 3.
  5. Applications for the North American or European market:
    1. Attempt to input "Profanity Test Word 2" from the pattern lists in Table 7-4 Words Used to Test the Profanity Filter, using the English-language pattern list for the North American region when the target market is North America, or the English-language pattern list for the European region when the target market is Europe.
    2. Attempt to send the text created in step 5a from system A to system B.
    3. On system B, display the text received in step 5b.
  6. Applications for regions which allow language selection in System Settings:
    1. In the System Settings, under Other Settings, select Language, and then repeat steps 2 through 5c under every language setting; do this on system A if the specifications call for profanity checking on the sender side, and on system B if the specifications call for profanity checking on the recipient side.
Pass/Fail Determination

Passes if at least one of the following conditions is met.

  • In steps 2 and 5a, the user cannot input the profanity.
  • The application cannot send the profanity in steps 3 or 5b.
  • In steps 4 and 5c, the profanity is not displayed.

7.2.6 Exchanging UGC via StreetPass

When StreetPass data is received, Notifications displays the icon and descriptive text configured for that StreetPass data. Using UGC for this icon or text cannot fully comply with some required guideline items that need to be supported by the receiving party. Consequently, it is prohibited to use the following types of UGC for the StreetPass data icon or text.

  • UGC affected by the blocked-user list
    This is because UGC from users registered to the blocked-user list cannot be blocked before being displayed in Notifications.
    However, if your application cannot perform StreetPass with any application using the SDK 4.x series or earlier, it is acceptable to allow UGC in the StreetPass data icon or descriptive text even if it is UGC affected by the blocked-user list. This is because system versions that support the SDK 5.x series or later are not capable of performing StreetPass at all with users on the blocked-user list. For details, see section 7.5.2 Removing UGC.
  • Rich UGC
    The Sharing Images / Audio / Video / Long Text Data restriction in Parental Controls can restrict the exchange of rich UGC. However, even when this setting in Parental Controls restricts rich UGC, rich UGC is still exchanged and new UGC appears on the notifications list so long as the application still has a StreetPass box.

7.2.6.1 Prohibition Against Creating StreetPass Data Using Certain Kinds of UGC

Guideline Item

For the icons and descriptive text of StreetPass data, the application must not use rich UGC or any UGC affected by the blocked-user list.

Software to Be Tested

Applications that support StreetPass and that exchange rich UGC and/or UGC affected by the blocked-user list.

Exceptions

Support for UGC received via StreetPass between applications both using the SDK 5.x series or later.

Test Method
  1. Prepare two Nintendo 3DS systems, system A and system B.
  2. If the application is designed to exchange UGC affected by the blocked-user list:
    1. On system A, create UGC that is affected by the blocked-user list.
  3. If the application is designed to exchange rich UGC:
    1. On system A, create rich UGC.
  4. All Applications:
    1. On both system A and B, activate StreetPass and register StreetPass data.
    2. On system A and system B, exchange data via StreetPass.
    3. On system B, launch the built-in Notifications applet, and check the icon and description for the data received in step 4b.
Pass/Fail Determination

Passes if the application in step 4c does not display any UGC affected by the blocked-user list, nor any rich UGC.

7.2.7 Download Play

If your application exchanges UGC with a Download Play client program, the client program is also required to comply with these guidelines. However, it is acceptable to treat communication between the host device and all client programs in Download Play as local communication where the communication partner can be identified beforehand.

No required guideline items.

 


CONFIDENTIAL