Cookies and Local Storage

1. Scope

This notice applies to InterfaceKit-operated web properties, including interfacekit.io, blog.interfacekit.io, guides.interfacekit.io, legal.interfacekit.io, agents.interfacekit.io, and related API, Worker, and preview endpoints.

It describes technology controlled by InterfaceKit application code separately from technology an infrastructure provider may use to deliver or secure a request.

2. Current InterfaceKit practices

InterfaceKit application code currently uses a signed-in session record and three path-scoped copies of one protected-runtime session cookie on interfacekit.io. Each deployed InterfaceKit web application also uses local-storage records for an operational telemetry session and first-party product analytics identity and attribution. InterfaceKit does not currently include advertising cookies, cross-site tracking pixels, or third-party advertising scripts.

The authored Blog, Guides, Legal, and Status applications use the telemetry session and analytics identity records described below. They do not write account-session, advertising, or preference data to browser storage. The agents.interfacekit.io service returns authenticated resources to software clients and does not use browser storage for account sessions.

Local storage stays in the browser and is not automatically attached to web requests. A browser automatically attaches a cookie only to requests that match its domain and path rules.

3. Operational telemetry session storage

Each deployed InterfaceKit web application stores a randomly generated operational session identifier and its last-activity time under the local-storage key “interfacekit.telemetry.session.” The application includes this identifier with operational telemetry and first-party product analytics so activity in one session can be understood together.

The application replaces the identifier after thirty minutes of inactivity. The record otherwise remains until it is replaced or you clear site data. Blocking or removing it does not prevent public pages from working, but the application can create a new record when you use the site again. InterfaceKit does not use this identifier for advertising or cross-site tracking.

4. Product analytics identity and attribution

Each deployed InterfaceKit web application stores a randomly generated anonymous identifier under the local-storage key “interfacekit.telemetry.identity.” The same record can retain first-touch and last-touch referrer and campaign attribution, including UTM values and the allowlisted campaign click identifiers described in the Privacy Policy. Product analytics run by default and include this anonymous identifier and the current operational session identifier.

After successful sign-in, interfacekit.io associates the analytics record with the internal account identifier and current plan so earlier anonymous activity can be attributed to later account outcomes. Logging out removes the account association and campaign attribution and creates a new anonymous identifier. Clearing site data also removes the record. InterfaceKit does not use this record for advertising or cross-site tracking.

5. Signed-in session storage

After you successfully verify a passwordless code on interfacekit.io, the product stores an access token, token type, token expiry, email address, and internal account identifier under the local-storage key “interfacekit.auth.” This is used to keep you signed in, show account state, and authorize protected requests you choose to make.

The access token expires after seven days. The local record is removed when you log out, when the product detects that it is invalid or expired, or when you clear it through browser controls. Removing the record signs you out but does not delete your InterfaceKit account.

6. Protected-runtime session cookies

After the signed-in product checks your account access, it creates three cookies named “interfacekit_runtime_session.” Each cookie contains the same access token. They are scoped to “/protected-runtimes,” “/src/generated-runtimes,” and “/src/generated-blueprint-runtimes,” allowing requests under those paths to receive authenticated runtime content without placing the token in a public asset URL.

The cookies use the remaining lifetime of the access token, up to seven days. They use SameSite=Strict and use Secure on the production HTTPS service. The product clears all three cookies when you log out, when no valid session is available, or when an account-access check fails. The browser also removes them when they expire or when you clear site data.

These cookies support authenticated runtime requests. InterfaceKit does not use them for advertising or cross-site tracking.

7. Infrastructure technologies

Cloudflare and other infrastructure providers process request information needed to route, secure, rate-limit, and operate the service. Depending on provider configuration and the nature of a request, a provider may use strictly necessary cookies or similar security technology under its own documentation.

InterfaceKit does not use provider-generated security data for advertising. A provider’s independent sites, such as a dashboard or policy page reached through an external link, are governed by that provider’s own notices.

8. Your controls

Most browsers let you inspect and remove cookies and local storage for a site. Blocking or deleting the “interfacekit.auth” record signs you out and prevents signed-in features from working until you authenticate again. Blocking or deleting any “interfacekit_runtime_session” cookie prevents matching authenticated runtime requests until the product recreates it after an access check. Removing the “interfacekit.telemetry.session” or “interfacekit.telemetry.identity” record clears the matching local identifier and saved attribution, though the application can create a new record when you use the site again. Public pages remain available subject to ordinary security controls.

InterfaceKit does not currently use the advertising or cross-site tracking technologies that browser Do Not Track or Global Privacy Control signals are designed to address. If that changes, we will describe how we respond and provide controls required by applicable law.

9. Changes to this notice

If InterfaceKit changes its browser analytics, advertising technology, cookies, or consent-controlled preference storage, we will update this notice and provide notice, choices, or consent controls where required.

10. Contact

Questions about cookies, local storage, or similar technologies can be sent to humans@interfacekit.io.