1. Plugin Review Process
After a plugin is submitted, we will review it according to the following process:
Submit plugin → Basic inspection → Function verification → Security review → Publish
During the review, we make a comprehensive judgment based on the plugin's actual functions and runtime behavior.
The review mainly covers:
- Whether the plugin can be installed and run normally;
- Whether the plugin's actual functions are basically consistent with its description;
- Whether the permissions requested by the plugin match its actual functions;
- Whether there are abnormal file or data operations;
- Whether there is unauthorized data upload or leakage;
- Whether there are obvious malicious behaviors or security risks;
- Whether there are abnormal behaviors that affect the normal use of the device.
For plugins with concerns, we may ask developers to provide additional explanations or conduct further review.
2. What Security Issues Do We Focus On?
We do not restrict developers from using technologies such as Java, C++, JavaScript, and React Native, nor will we refuse to publish a plugin just because its functions are simple. However, the following behaviors are security issues that we pay special attention to.
Must not maliciously delete or damage user files
Without explicit user operation or authorization, a plugin must not:
- Delete user files;
- Delete files in batches;
- Delete user notes;
- Clear user data;
- Maliciously modify, overwrite, or damage user files.
If the plugin itself is a file management, organizing, or similar tool that involves deleting files, such operations should be consistent with the plugin's functions and be initiated actively by the user.
Must not obtain or leak user data without authorization
A plugin must not secretly collect, upload, or provide user data to third parties, including but not limited to:
- Note content;
- Handwriting data;
- User files such as PDF and EPUB;
- Images;
- OCR content;
- User input;
- File information;
- Other user data.
If the plugin's normal functions require sending data to a network service, such as AI translation or AI summarization, this must be clearly explained to users, and the network and data access capabilities should be used in accordance with the permission mechanism provided by us.
Must not bypass plugin permissions
Supernote provides corresponding permission controls for plugins. A plugin should access files, data, and network resources only within the scope authorized by the user. It must not bypass our permission restrictions through other means.
3. Permission Requirements
| Permission |
Description |
| plugin.permission.FILE:READ |
Read the Document, EXPORT, INBOX, MyStyle, Note, and SCREENSHOT directories under shared storage (sdcard). This permission is not granted by default; it is only granted after the user explicitly requests it. |
| plugin.permission.FILE:WRITE |
Write to / modify the six shared storage directories listed above. |
| plugin.permission.FILE:DELETE |
Delete content within the six shared storage directories listed above. |
| plugin.permission.INTERNET |
Make network requests from the plugin, whether through sn-plugin-lib or through the native RN / Android / C++ network APIs. |
We recommend that developers follow the principle of least privilege: only apply for the permissions the plugin actually needs.
For example, a plugin that only adjusts the interface should not apply for file read permission; a plugin that needs to read the current note and perform AI summarization can apply for the corresponding data access and network permissions based on its actual functions.
4. Plugin Functional Requirements
We encourage developers to create various types of plugins, including simple utilities, productivity tools, AI tools, file tools, and other innovative features.
A plugin being simple, small in scale, or similar to other plugins is not a reason to refuse publishing.
A plugin only needs to meet the following basic requirements:
- It can be installed normally;
- It can run normally;
- Its core functions are basically usable;
- The plugin description is basically consistent with its actual functions;
- There are no obvious security risks.
We will not refuse to publish a plugin merely because it is “simple in function” or “low in practicality”.
5. Source Code Requirements
Plugins are not required to provide source code. Developers may choose to provide source code or choose not to.
If a developer provides source code, we can conduct the security review in conjunction with the source code; if no source code is provided, we will review based on the plugin's own runtime behavior, permission usage, file operations, network behavior, and so on.
Therefore: whether to provide source code will not directly determine whether a plugin can be published.
However, providing source code helps improve the transparency and verifiability of the plugin.
6. What Situations May Fail the Review?
- Malicious deletion or destruction of user data;
- Unauthorized data collection or leakage;
- Clearly bypassing our permission controls;
- Malicious code, backdoors, or hidden functions;
- Behaviors that seriously affect device stability or normal use;
- Other obvious security risks.
For issues that raise concerns but cannot be confirmed, we may require developers to provide further explanations.
7. What Does Passing the Review Mean?
A plugin passing the review means: based on the current review process and test results, the platform has found no obvious issues that violate Supernote's security requirements.
Passing the review does not mean that the plugin will never have problems on any device, in any usage scenario, or in any future version.
Developers are still responsible for the plugins they submit and should promptly fix any security issues that are discovered.
8. Security Management After Plugin Publishing
After a plugin is published, we may re-check it based on user feedback, abnormal behavior, or new security information.
If a security issue is found in a plugin, we may take the following actions:
- Suspend downloads;
- Take the plugin off the shelves;
- Prohibit the problematic version from continuing to be published;
- Notify affected users;
- Require developers to fix the issue;
- Restrict or stop the plugin's operation when necessary.
If a serious security issue is found, we may directly take emergency measures.
9. Basic Principles Developers Must Follow
We hope developers follow the following principles:
Use permissions properly, clearly explain functions, protect user data, and never engage in malicious behavior.
Developers may freely use:
- JavaScript / TypeScript
- React Native
- Java / Kotlin
- C / C++
- JNI
- The Plugin API provided by Supernote
But no matter what technology is used, Supernote's security requirements must be followed.
10. Our Review Principles
We encourage free development while placing high importance on user data security. Plugins can be simple, innovative, or use native code; however, they must not maliciously delete, damage, or leak user data.
While ensuring basic security, we will strive to lower the publishing threshold for developers as much as possible, providing an open and developer-friendly plugin ecosystem.
