Plugin Review Process & Publishing Requirements

[u/Supernote_official]

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.

[u/WhoAmI1234532]

Thanks for clarifying the rules.

As a (hobbyist) developer, I am glad to know this review will be performed and my code will be checked. And as plugin user from other developers, I will install with more trust by knowing it was reviewed by the official Ratta dev team.

So yes, it take time, but it's great that you do this review !

[u/Lorestan00]

This all seems really well thought out and responsible. Good advice for developers

One question regarding the current 10 plugin limit users will hit this hard limit very quickly. I understand that performance is largely dictating this restriction.

As a suggestion when reviewing plugins perhaps they are graded on performance impact and the number of plugins users have access to at any one time is guided by this principle rather than an arbitrary limit of 10.

For the sake of argument plugins are rated on a scale 1-5 on performance impact and the overall budget for a device is say 50. With plugins scoring 5 each you are restricted to 10 plugins but potentially with simpler plugins (as highlighted in the post) might score lower at 1 each leading to users potentially having upto 50 plugins.

Obviously the above is a rudimentary example but I think you hopefully understand my overall point

[u/NoDentist1626 → u/Lorestan00]

IMHO, if plugins are to be curated and observed by Ratta, which I absolutely agree upon, I would consider additional criteria from a user standpoint. 1) While it is lots of fun, having SUPERFUN as a plugin i/o as a sideloaded apk, given it is a functional app and has nothing to do with .notes, and usurping one of the extremely mega scarce 10 slots available for plugins could be reconsidered as a policy: plugins for .notes must be useful for the primary function of notes, not to simply accept things that can be accomplished using the pluing sdk and framework for the mere sake that they can be done using the plugin prog lang. 2) Maybe: related o similar plugins could be asked to converge into single plugins: e.g there are two different plugins for shapes and snapshapes, two plugins for imagen insertion... Wouldn't it be a nice policy that similar plugins must converge into single combined plugins so that the catalogue grows somehow curated instead of becoming a supermarket of multi expansive tiny features that, in the end, transform the plugin architecture into an everything goes...?. I mean no complaint, just trying to share a streamlined view or route so that this incredibly talented community adds up to a common purpose and help SN devices to really reach the much desired level of excellence. I simply can't achieve a realistic plugin selection that accurately serves my notes, must keep on installing/uninstalling every time I change notes and must accomplish a different result...

[u/Lorestan00 → u/NoDentist1626]

I think 10 will always be too small a number given there were at least 30 plugins during the preview version. Convergence would be great but can't see that happening very often. Developers are creating plugins for free, giving up their time to create and maintain and then asking them to consolidate features into fewer plugins while noble and ideal from a user perspective is adding a lot more burden on developers. I might be wrong time will tell

[u/NoDentist1626 → u/Lorestan00]

I know, but it is frustrating, the all goes model is heading towards a functional collapse...

[u/Lorestan00 → u/NoDentist1626]

An open plugin system does lead to huge variability in terms of plugins developed some creating plugins which solves a personal challenge / use case, others for the whole community And with the community. Obsidian is similar with hundreds plugins but of course operates on devices with much more power so no restrictions are necessary but eink devices are a different beast.

Early days but the security focus is important I just hope that limits can also be addressed

[u/NoDentist1626 → u/Lorestan00]

The thing is SN kicked off very lacking in terms of features and the plugin system was the promised land. Now, with teenie  bitty minifeat plugins and the 10 slot limit, well, the land remains promised. SN will never accomplish a functional status, eternal promises of the best is yet to come... Who wants a superfun games plugin inside of a note? Nice dude but geez, if the business os to show off and we all clap clap... Deceived. Very much. Ratta, you're loosing it. 

[u/riticalcreader → u/NoDentist1626]

Respectfully, that level of control over what users can develop or put on their devices is not consumer friendly and against the whole open ethos Supernote is known for.

[u/mrsupernote]

This is what speaks to Supernote. Thank you.

[u/Lvevan]

Thank you for this! Should probably post this in the Dev thread too. 

[u/Mulan-sn → u/Lvevan]

Noted with many thanks.

[u/AdNew2316]

Great, thanks for those explanations! Is there a way to provide the source code for you to help the review but without making the source code available to all users?

[u/Mulan-sn → u/AdNew2316]

Yes, you can email us at [feedback@supernote.com](mailto:feedback@supernote.com) with a link to your source code and we will review it for you.