Greasy Fork

Greasy Fork permits the use of external code in specific cases. Any script found to be including external code outside of what is permitted is subject to be deleted. If you find a script violating these rules, please report it.

Note that these rules only apply to external, executable code. Loading non-executable code, for example JSON or CSS, is not restricted.

Rationale

User scripts have the technical ability to load and execute other scripts. This can be done in a few different ways, including:

• The @require and @resource metadata keys.
• XmlHttpRequest to download the script, then eval to execute.
• Adding a <script> tag dynamically.
• Webpack's externals option.
• Performing an update of the script, whether performed automatically or by directing the user to perform an action.

While this is a useful feature and most script authors use this for legitimate purposes, it can also be used maliciously. One of the core principles of Greasy Fork is that the user must be able to inspect the code in a script. External scripts can bypass this principle in a number of ways: they can change without warning or history, they can serve up different code to different people, and they can be used to hide malicious code in the middle of known libraries. Even if someone were to check an external script and determine it to be legitimate, that would be no guarantee that that script always has been or always will be legitimate.

Allowed external codes

The following are the ways external code is allowed on Greasy Fork. Unless otherwise specified, all other rules for code apply to the external code.

Content delivery networks (CDNs)

Code from CDNs is allowed. See a list of recognized CDNs. This code may be minified, but not obfuscated.

Scripts with subresource integrity hashes

Use of @require and @resource with URLs with subresource integrity in the Tampermonkey format is allowed.

Greasy Fork라이브러리

Scripts posted as libraries on Greasy Fork are allowed. Libraries can be created by choosing the option when creating a new script. These can additionally be set to sync from an external URL, like a GitHub repository.

Injection of scripts from the origin host

Injection of external scripts on the same domain as where they came from is allowed. If a script runs on https://example.com, and downloads https://example.com/script.js, modifies it, and injects back on https://example.com/, this would be allowed.

If https://example.com/script.js is injected onto https://differentsite.com, this would be disallowed.