Title: Web Component Consent Description: When end users are asked to consent to a third-party web component, and what makes them re-consent Tags: web-components, consent, privacy --- 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. Where consent is stored 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. Related Permissions — what the overlay discloses Security model — the boundary behind the consent Building Web Components — the authoring guide