Security and performance

Documentation index

Trust boundaries

There are three distinct inputs: authored document content, host configuration/callback code, and native bridge messages. Document content is data. Host code is trusted application code. Bridge messages must come from the trusted editor page/window. Feature policy alone is not a security boundary against a host with direct model access.

The editor's HTML importer and preview sanitizer are designed for its supported schema and isolated rendering environment. They are not offered as a universal HTML-sanitization library for arbitrary output elsewhere in your application. If saved content is published outside the editor, that publishing pipeline has its own security responsibilities.

HTML and preview isolation

Supported rich HTML is converted into allowed document structures and marks. Unsupported content can be preserved as opaque source, rejected, or explicitly converted according to policy. Preserving literal source is not the same as executing it.

Custom handled preview HTML keeps selected semantic elements, classes, IDs and safe attributes. Active elements including scripts, frames, forms, SVG and embedded media are removed; event attributes are not allowed. Stylesheet elements are removed in favor of host-supplied PreviewCss. Safe inline style attributes can remain, constrained by the preview CSP.

The preview iframe uses a restrictive CSP with default/script restrictions, no arbitrary base/form/object behavior, and image origins controlled by editor settings. Parent same-origin access exists for measuring/scrolling the frame, but scripts are not allowed. Do not add allow-scripts or weaken the CSP casually: the design assumes both sanitization and isolation are present.

PreviewCss is trusted host stylesheet text. It can radically change layout and hide content, so it should represent application styling rather than unreviewed user instructions. Resources referenced from it remain subject to CSP. The iframe does not provide a fully interactive copy of a website.

URLs and images

URL helpers reject dangerous schemes, control characters and unsupported reference forms. Image URLs are distinct from links and do not accept mailto. Durable image references cannot be arbitrary data or JavaScript URLs; temporary blob URLs are used only internally for pending previews.

AllowRemoteImages broadly allows HTTP(S) image fetching. Prefer a limited ImageOrigins list when practical. Remote image fetches can reveal that a document was viewed to the image server; origin selection is therefore an application decision. A remote-import callback also needs an appropriate host fetch policy; the editor does not authorize arbitrary server-side network access.

Native file imports use bounded chunks and validation before raising the storage event. MIME/signature checking and limited decoding do not replace every asset-storage safeguard your application already needs. The ASP.NET/Photino samples are evaluation integrations, not authenticated multi-tenant asset services.

Native integration

The WinForms wrapper serves its own embedded assets, restricts navigation, denies unexpected permission requests, and uses an operation allowlist. The host should handle OpenLinkRequested according to its navigation policy. Do not use arbitrary evaluation of scripts built from user content to extend the protocol.

UserDataFolder and LocalImageFolder are application-controlled paths configured before initialization. Use generated asset filenames and a dedicated directory. The Photino adapter requires the application to establish that messages came from the trusted editor window; its trusted-origin argument is not self-verifying.

Current bounds

These are limits, not responsiveness or throughput guarantees. In particular, 100 history snapshots of a large document can cost substantial memory. A document under the text limit can still contain expensive structures or images.

Performance expectations

The current model/rendering approach is suitable for notes and modest documents. It does not virtualize the viewport. Some operations reparse, rerender or measure large portions of a document; lexical coloring is not incremental language analysis. Large table counts, long unwrapped lines, deeply structured input, and frequent custom preview requests should be measured on target devices.

Keep host event handlers short. Debounce persistence and external preview data requests where appropriate. Honor cancellation; avoid doing the same expensive server query for every obsolete request. Cache application data where its freshness rules allow it, and explicitly refresh preview when the data changes.

No performance SLA is asserted by the existing automated test counts. Benchmark realistic note sizes and pathological examples before raising limits. If large-document performance becomes a product requirement, prioritize incremental text storage/parsing and viewport rendering as an architectural milestone rather than only increasing numeric caps.

Data retention and AI

The core does not automatically send document text to an AI service. A future AI feature should be implemented through explicit host UI and guarded edits. The host owns user consent/policy, provider configuration, logging and retention. Browser demo draft storage is opt-in local storage; production persistence and recovery remain application responsibilities.