Web Component Consent

When end users are asked to consent to a third-party web component, and what makes them re-consent

web-componentsconsentprivacy

Third-party components never run silently. Before a web component loads for a user for the first time, the platform shows a consent overlay in the widget's place — comparable to the inline opt-in you know from embedded maps.

What the overlay shows

  • A notice that this is a third-party component that smallstack is not responsible for
  • The complete list of declared permissions, each explained in plain language (see the permission vocabulary)
  • An accept button — only after accepting does the sandbox load the component's code, and only granted data is forwarded

If the user does not accept, no third-party code executes at all.

Consent identity: user × bundle version × permission set

A consent is recorded per user, per registration, and is keyed to the registration's current bundle SHA-256 and its current permission set. That means consent is automatically invalidated — and every user re-prompted — when:

  • a new bundle version is uploaded (the code changed), or
  • the registration's declared permissions change (the data access changed).

Nothing less than the exact combination the user accepted keeps the consent valid.

  • Logged-in users: consent is recorded server-side in the project, so it follows the user across devices and sessions.
  • Anonymous application visitors: consent is kept in the browser's localStorage, keyed by the same registration/bundle/permission identity — a new version re-prompts anonymous visitors too.

Kill switch

Setting a registration to disabled in the backoffice immediately stops all placed instances from loading; users see a neutral placeholder instead. Re-enabling does not bypass consent — the recorded consents still apply under the same identity rules above.

Markdown | llm.txt