N20 What a plugin may send, and what it may never run
- Area
- N — Companion
- Audience
- operator
- Kind
- feature
- Status
- accepted
- Maturity
- built
- Labels
- mobile, security, ux
The feature in the specification · Read at
Requirements
A value a plugin would send to an external host MUST be stated as what it is and where it would go, in terms the operator can judge.
Such a value MUST be agreed to as itself, and MUST NOT be agreed to as a consequence of agreeing to an installation; one agreement MUST NOT cover both.
A destination MUST be shown as the name the manifest gave, and MUST NOT be shown as a resolved address.
Where a call was refused because an external name answered from inside the network, the app MUST show that refusal and its reason, and MUST NOT render it as a network error to retry.
A rehearsed recipe MUST show every step in the order the recipe gives, labelled as a rehearsal (N6-R1), and MUST NOT be summarised into an outcome.
Where a plugin names an adapter, the app MUST show which one, and that it is lemonfiber's rather than the plugin's.
The app MUST NOT execute content a plugin supplied, MUST NOT offer to, and MUST NOT present any opt-in, sandbox or capability grant that would (F3-R6).
A plugin declaring native or executable content MUST be shown as refused with the reason, and MUST NOT be offered for installation (F3-R7).
A refusal the core gave about a plugin MUST carry the core's own reason (N5-R10).
Recipes, pairs, destinations or adapters that could not be read MUST be told apart from there being none.