Security & Vetting

Security in the plugin system operates at two levels: structural protections that are enforced by the browser and the runtime regardless of what a plugin does, and the vetting process that reviews a plugin's code and behaviour before it reaches the marketplace.

Built-In Protections

These protections require no action from you — they are enforced automatically for every plugin.

Sandboxed Iframe

Every plugin runs in a sandboxed <iframe> with no same-origin access to the internote page. At the browser level this means:

• The plugin cannot read or write the parent page's DOM, localStorage, sessionStorage, IndexedDB, or cookies
• The plugin cannot read the authenticated user's session token or any other credential stored in the host application
• The plugin cannot redirect the top-level browser window or open popups
• The plugin cannot submit forms to external targets

The sandbox attribute applied is sandbox="allow-scripts allow-pointer-lock". Everything not in that list is denied by the browser, not by application code.

Scoped Storage

Plugin storage is enforced at the database level via row-level security. The storage API only ever reads and writes rows matching the current (user_id, internote_id, element_hash) composite key. There is no API surface through which a plugin can read another user's data, access a different internote's stored state, or enumerate stored keys across plugins.

Message Protocol

The host only honours a fixed set of message types from the plugin (ready, storage.*, error). Any other message type sent via postMessage is silently discarded. A plugin cannot trigger host-side behaviour by crafting arbitrary messages — the SDK is the only supported channel.

Code Signing

Approved plugins are cryptographically signed by the Internote team before being pushed to the live registry. When the internote runtime fetches a plugin, it verifies the signature against the manifest before loading the iframe. An unsigned or tampered plugin will not load.

Rate Limiting

Storage and network-adjacent API calls are rate-limited server-side. A plugin that attempts to make excessive storage writes or trigger abnormal call volumes will be throttled and flagged for review.

What Is Not Restricted

Understanding the boundaries helps you design appropriately:

• External network requests — plugins may make fetch and WebSocket connections to external servers. This is intentional (many legitimate plugins need live data), but must be declared in the manifest's permissions field. Undisclosed external requests are grounds for rejection.
• Canvas and WebGL — unrestricted within the sandbox. GPU-intensive plugins are permitted but are subject to the performance requirements in the vetting checklist.
• Web Workers — plugins may spawn Workers within the sandbox for computation. Workers are bound by the same sandbox origin and cannot communicate with the host page directly.
• User interaction — the plugin receives pointer and keyboard events from the student. It cannot capture input outside its own frame unless the host explicitly forwards events via the SDK.

The Vetting Process

Before a plugin appears in the marketplace it is reviewed by the Internote team. The review is not automated — a person reads the code, runs the plugin, and tests it against the criteria below.

How Review Works

1. Submission     — plugin bundled and uploaded to staging; automated static scan runs
2. Queued         — team notified; developer receives a confirmation email
3. Under Review   — team audits the source code and runs the plugin in the editor
4. Feedback       — team requests changes via email if issues are found
5. Approved       — plugin code is signed and pushed to the live registry
6. Live           — plugin is visible in the marketplace

First submissions typically take two to five business days. Updates to approved plugins are usually reviewed faster.

Security Checklist

The team looks for:

• No attempt to break out of the sandbox — no exploit of postMessage to inject content into the parent page, no attempt to access host-page APIs
• No undisclosed network requests — every external endpoint the plugin communicates with must be declared in permissions: ["network"]
• No collection, storage, or transmission of student data beyond what the plugin's stated purpose requires — student responses or interaction data must not be sent to external servers without explicit disclosure
• No malicious, deceptive, or phishing content — this includes hidden redirects, misleading UI, and social engineering patterns

Performance Checklist

• First render and internote.ready() call complete within two seconds on a mid-range device
• No unbounded memory growth during a 60-second run — the team checks memory profiles
• No synchronous blocking of the main thread — heavy computation belongs in a Worker
• If the plugin runs a requestAnimationFrame loop, frame time stays consistently below 16 ms at 60 FPS

Content & Quality Checklist

• The manifest description accurately represents what the plugin does
• The plugin is functional across all valid combinations of its declared attributes
• Optional attributes that are omitted fall back to their declared defaults without errors
• The plugin handles invalid or unexpected input gracefully rather than crashing silently

API Compliance Checklist

• Only the public SDK API is used — no undocumented postMessage message types, no attempts to reach internote internals
• internote.onUnload() releases all resources — animation frames, timers, observers, open connections
• All permissions used are declared in the manifest

Status Badges

• verified — reviewed and approved by the Internote team
• beta — approved but flagged as under active development; breaking changes may still occur

Responsible Disclosure

If you discover a security vulnerability in the plugin system or in a published plugin, contact the Internote team directly rather than publishing the finding publicly. Do not attempt to exploit a vulnerability beyond what is necessary to confirm it exists.