SLICC Privacy Policy

Last updated: 2026-05-06

This Privacy Policy describes how the SLICC project (the "Self-Licking Ice Cream Cone," referred to below as "SLICC," "we," "us," or "our") handles information across three distinct contexts:

1. The www.sliccy.com website,
2. The SLICC applications (Chrome extension, command-line / Node.js distribution, macOS desktop build, iOS build, and any other officially released SLICC client),
3. The optional Adobe LLM Provider that SLICC users may choose to configure inside the applications.

SLICC is an open-source project published at https://github.com/ai-ecoverse/slicc under the Apache 2.0 license. The project is a browser-based AI coding agent that runs primarily on the user's own device. By design, the great majority of data created or processed by SLICC stays on the user's device and is never transmitted to a SLICC-operated server.

This policy applies only to the website, applications, and provider integrations identified above. It does not cover third-party services that a user may choose to integrate with SLICC (for example, the Anthropic API, AWS Bedrock, Azure AI Foundry, Cerebras, GitHub, or any custom OAuth provider). Each such third party is governed by its own terms and privacy policy.

1. The www.sliccy.com Website

1.1 Purpose

www.sliccy.com is a static informational website that describes the SLICC project, links to documentation and releases, and serves marketing content. It does not require an account, does not host user content, and does not provide any logged-in functionality.

1.2 What we collect

The website itself does not set tracking cookies, does not use localStorage or sessionStorage for analytics purposes, does not load third-party advertising or analytics scripts, and does not collect form submissions.

The only data collection on the website is Adobe Experience Manager Operational Telemetry, as described at https://www.aem.live/docs/operational-telemetry. Operational Telemetry on www.sliccy.com operates as documented by Adobe, with the following characteristics:

• Sampling. Data is collected on a sampled, per-page-view basis (under normal circumstances, approximately 1 in 100 page views). The decision to collect for any given page view is independent of the visitor and independent of any prior page view.
• No client-side identifiers. Operational Telemetry does not use cookies, localStorage, sessionStorage, fingerprinting, or any other persistent client-side identifier. There is no concept of a visitor, a user, or a session.
• What is sent. The full list of fields is documented by Adobe at the link above. In summary: site host name, a coarsened user-agent class (for example, desktop:mac or mobile:ios), a timestamp rounded to the previous hour, the URL of the page (without query parameters), the referrer URL (without query parameters), a randomly generated per-page-view ID, the sampling weight, named "checkpoints" for events such as page load or media visibility, the DOM source and external target associated with a checkpoint, and Core Web Vitals performance metrics (LCP, INP, CLS, TTFB).
• What is not sent. No personal information, no IP address (persisted), no full user-agent string (persisted), no URL parameters, no form values, no cookies, and no content from the page beyond the structural fields above.
• Transport. Data is submitted using Navigator.sendBeacon to Adobe's collection endpoint (currently rum.hlx.live). It is not submitted via tracking pixels.
• Third parties involved in collection. As listed by Adobe, the operators and infrastructure providers involved in handling Operational Telemetry data are Adobe, Fastly, Cloudflare, Coralogix, Google, and Amazon.

The SLICC project uses Operational Telemetry only to diagnose performance and functional issues with the website. We do not use it for advertising, profiling, or any cross-site tracking.

1.3 Hosting

The website is delivered through Adobe Edge Delivery Services (the same platform documented at aem.live). Standard server access logs maintained by the underlying CDN and origin (request URL, timestamp, IP address, response status) may be retained by those providers under their own retention policies for the operational purposes of running a web service. We do not access these logs for marketing, profiling, or analytics purposes.

2. The SLICC Applications

This section covers the SLICC software in all its officially released distribution forms — at the time of writing, the Chrome extension, the Node.js / npx sliccy command-line distribution, the macOS desktop build (an Electron-based application), the iOS build, and any other clients released under the same project. Future distribution forms (for example, a planned cloud variant) will either be covered by this policy or will be accompanied by their own supplementary notice.

2.1 Local-first architecture

SLICC is built around the principle that the user's device is the primary place where their data lives. Specifically:

• Conversations, files, configuration, API keys, and any state SLICC creates while running are stored locally on the user's device, using browser-native storage (IndexedDB, OPFS, and where applicable LightningFS) on web/extension/Electron platforms, and using equivalent on-device storage mechanisms on other platforms.
• The SLICC project does not operate a server that stores or receives user conversations, file contents, or API keys. There is no SLICC-operated user account.
• API keys and provider credentials that the user enters into SLICC remain on the user's device. They are sent only to the provider the user has configured (for example, directly to the Anthropic API, the configured Azure AI Foundry endpoint, AWS Bedrock, Cerebras, or the optional Adobe LLM Proxy described in section 3) for the purpose of authenticating that user's own requests.

2.2 Operational Telemetry inside the applications

The SLICC applications include the same Adobe Experience Manager Operational Telemetry described in section 1.2, applied to the application's own UI. The same characteristics apply: sampled per-page-view, no client-side identifiers, no PII, no IP address persisted, transmitted via Navigator.sendBeacon. No conversation content, file content, prompt text, model output, tool input or output, or credential is ever included in Operational Telemetry payloads.

Operational Telemetry inside the applications is used solely to diagnose performance and compatibility issues with the SLICC client itself. A user who wishes to disable Operational Telemetry can do so by blocking requests to the collection endpoint at the network level; in supported deployments it can also be disabled through the deployment-level settings documented at aem.live.

2.3 Outbound network traffic from the applications

When SLICC is in use, outbound network traffic from the application falls into the following categories:

1. LLM provider traffic. Each request the user makes to a configured language-model provider (chat messages, system prompts, tool definitions, tool inputs, file contents the user attaches, screenshots produced by browser automation, model parameters) is sent directly from the user's device to the endpoint the user has configured. These endpoints are operated by the respective provider (Anthropic, Microsoft / Azure AI Foundry, Amazon Web Services / Bedrock, Cerebras, Adobe via the Adobe LLM Proxy, or any custom OAuth provider the user has added). Each provider is governed by its own privacy policy and terms of service. SLICC does not relay this traffic through a SLICC-operated server.
2. Operational Telemetry. As described above.
3. User-initiated network requests. The SLICC bash shell, browser automation tools, curl, fetch, git, and similar commands make network requests at the explicit direction of the user (or of a model the user is interacting with). These go to whichever destinations the user or model selects. SLICC does not interpose on or log these requests outside the local device.
4. CDP / browser-automation traffic. When SLICC controls a browser via the Chrome DevTools Protocol — using the chrome.debugger extension API in the Chrome extension build, a local WebSocket in the CLI build, or the Electron CDP path in the Electron build — the protocol traffic flows between the SLICC client and the local browser instance on the user's machine. It is not sent to SLICC servers.
5. Skill installation. When the user installs a skill via the upskill command or by importing a .skill archive, requests are made to the source the user names — for example, a GitHub repository, the third-party ClawHub registry (https://clawhub.io), or the Tessl registry (https://tessl.io). These requests are governed by the privacy policies and terms of those services. SLICC does not maintain a server-side record of which skills any user has installed.
6. Provider OAuth flows. When a user authenticates to a provider that uses OAuth (for example, the Adobe IMS provider or a custom corporate SSO provider configured under providers/), the OAuth flow runs between the user's browser and the identity provider, in the standard way. Authentication tokens are stored locally on the user's device and used to authorize subsequent requests to that provider's endpoint.

2.4 Permissions requested by the Chrome extension

The Chrome extension build requires standard Manifest V3 permissions to provide its functionality, including the ability to attach a debugger to tabs the user authorizes (for browser automation), the ability to display a side panel, and the ability to run an offscreen document for the agent runtime. These permissions are used only to provide SLICC's documented features. The extension does not transmit browsing history, page content, cookies, or form data to any SLICC server, because there is no SLICC server. Page content read via browser automation is processed locally and is sent only to the LLM provider the user has configured, and only as part of the user's own active session.

2.5 Voice input

When the user enables voice input, SLICC uses the platform-native speech recognition API — on Chrome and Chromium-based platforms this is the Web Speech API. Audio capture and transcription are performed by the platform; the resulting transcribed text is then handled like any other user input (stored locally, and forwarded to the configured LLM provider when the user submits it). The Web Speech API may transmit audio to the browser vendor's servers for transcription; that processing is governed by the browser vendor's privacy policy.

2.6 Filesystem and screenshots

The SLICC virtual filesystem (/workspace, /scoops/{name}, /shared, and so on) lives entirely within the user's device storage. Screenshots produced by the screenshot and related browser-automation commands are written to the virtual filesystem on the device. They are sent to the configured LLM provider only when the user (or the agent acting on the user's behalf within an active session) attaches them to a request.

2.7 What we do not do

In the SLICC applications, we do not:

• Operate user accounts, sign-up flows, or password storage.
• Maintain a server-side database of user conversations, files, prompts, or model outputs.
• Run advertising, ad-tech, third-party trackers, fingerprinting, or session-replay tooling.
• Combine your data with data from other sources for marketing or profiling.
• Sell personal information.

3. The Optional Adobe LLM Provider

Among the language-model providers a user may configure in SLICC is the Adobe LLM Provider, which authenticates via Adobe Identity Management Services (IMS) and routes requests through the Adobe LLM Proxy operated by Adobe (the adobe-llm-proxy-worker and companion llm-monitoring-worker). This provider is off by default and is only used if a user explicitly selects and signs in to it.

The Adobe LLM Provider is an Adobe-operated service. When a user chooses to use it:

3.1 Adobe Privacy Policy applies

The handling of personal information by Adobe in connection with the Adobe LLM Provider is governed by the Adobe Privacy Policy at https://www.adobe.com/privacy/policy.html and any product-specific notices to which Adobe links from there. Users who have an Adobe ID can manage their account-level privacy preferences through their Adobe account.

3.2 LLM proxy and usage-monitoring data handling

In addition to the general Adobe Privacy Policy, the Adobe LLM Proxy maintains its own internal documentation describing exactly what is recorded for each request. That documentation governs the proxy and is reproduced here in summary form so that SLICC users know what is collected on Adobe's side when they choose to use this provider. Users with questions about, or requests against, this data should contact Adobe at the address given in section 3.5 below.

Access control. Use of the Adobe LLM Provider requires a valid Adobe IMS access token. The token's signature must verify against the Adobe IMS JWKS, and the token must match the configured client. Email addresses on the proxy's blocklist are denied.

Per-request record. Each successful or failed call from SLICC through the Adobe LLM Provider produces exactly one record in the proxy's usage database. The fields recorded are:

• Identity & session: a per-request UUID; the IMS subject (user_id, stored in the clear, not hashed); a SHA-256 hash of the lower-cased email (email_hash); the user's canonical Adobe organization identifier (owner_org); a session identifier provided by the client or derived as SHA-256(userId + first 200 characters of first user message); and a UTC timestamp.
• Request content: the requested model name; the upstream that actually served the request (azure, bedrock, or cerebras); a turn-type flag (user_input or tool_turn); the latest human input extracted from the request body, after secret-redaction and truncation to 100 KB; the message count; a flag indicating whether images were present (the image bytes themselves are stripped before logging and replaced with a [image:<media_type>] placeholder); and a flag indicating whether the secret-redaction regex matched anything in the request or response.
• Response content: the model's text output plus a one-line per-tool-invocation summary, after secret-redaction and truncation to 100 KB; a JSON array of tool calls with sanitized inputs; token counts (input, output, cache read, cache write); the upstream wall-clock duration; a status code; and the upstream HTTP error code on failure.

What the proxy explicitly does not store. The proxy does not store: raw email addresses (only the SHA-256 hash, except in observability logs — see below); image payloads of any kind; bearer tokens, API keys, AWS keys, GitHub PATs, Slack tokens, or password|secret|token|api_key=… values matching its redaction patterns (which are replaced with [REDACTED:<type>] before being queued); cookies, request headers beyond a small documented allowlist (Authorization, x-api-key, x-session-id, Content-Type, anthropic-version); or the full multi-turn conversation history from the request body (only the latest human turn is materialized).

Derived analytics. A separate post-hoc job re-reads already-redacted, already-truncated session text and uses Claude (via Azure AI Foundry) to classify each session, writing the classification into a separate classifications database with fields including outcome, primary_task, engagement_depth, session_feel, detected language, a safety_flags array, a short journey summary, and a free-text rationale. Classifications are versioned by classifier_version so that re-runs do not overwrite earlier results. No raw images and no unredacted secrets are sent to the classifier.

Storage location. The usage records, the classifications, and the ingestion queue are all hosted on Cloudflare in a single Cloudflare account dedicated to this subsystem. Worker logs and traces are stored in the same Cloudflare account's observability backend. No data from this subsystem is shared with third parties beyond the chosen LLM upstream needed to serve the request and the Cloudflare infrastructure on which it runs.

Observability logs. The proxy worker emits structured log lines on each request and completion. These lines are persisted to Cloudflare's observability backend and do contain the raw email and display name of the calling user, alongside the IMS subject, model name, upstream, request ID, and token counts. Cloudflare's default Workers log retention currently applies (approximately seven days). Users with concerns about appearing in these logs should raise them with the operator before sending production traffic; the operator can either drop the email from log lines or shorten the persist window.

Access to the data. Only the proxy writes events to the ingestion queue, and only the monitoring component writes from the queue into the usage database. Reading the data through the admin API requires an Adobe IMS access token whose email appears on a small operator allowlist. Direct database access requires a Cloudflare API token scoped to the production account. There is no public endpoint that exposes raw event content.

Retention. Usage records and session classifications are retained for up to 25 months. Cloudflare observability logs follow Cloudflare's default Workers retention. A user who wishes to have their own records deleted may email catalan@adobe.com with their email_hash (computable as SHA-256(lowercased Adobe email)); deletions are processed manually and propagated to the classification records.

3.3 What SLICC sends

When a user has selected the Adobe LLM Provider, SLICC sends to the Adobe LLM Proxy the same kind of payload it would send to any LLM provider: chat messages, system prompts, tool definitions, tool inputs and outputs, and any attachments (such as screenshots) the user has chosen to include. SLICC does not add hidden telemetry to these requests beyond what is needed for the provider's API to function.

3.4 Choosing a different provider

If a user does not wish to be subject to the Adobe LLM Proxy data handling described above, they can use any other configured provider (for example, direct Anthropic, Azure AI Foundry under their own subscription, AWS Bedrock under their own account, Cerebras, or a custom OAuth provider). In that case the request never traverses the Adobe LLM Proxy and none of the data handling in section 3.2 applies.

3.5 Contact for Adobe-side data

For questions about, or requests against, the data Adobe holds in connection with the Adobe LLM Provider, contact Adobe through the Adobe privacy inquiry form at https://www.adobe.com/go/privacyinquiry. For questions specifically about the proxy data described in section 3.2, contact catalan@adobe.com.

4. Third-Party Language-Model Providers (General)

When a user configures any third-party language-model provider in SLICC — including but not limited to Anthropic, Azure AI Foundry, AWS Bedrock, Cerebras, GitHub-hosted models, or a custom OAuth provider — the user's prompts, attachments, tool inputs and outputs, and model responses are transmitted directly from the user's device to that provider. Each such provider operates under its own terms of service and privacy policy, which the user accepts when they configure that provider in SLICC.

The SLICC project has no visibility into and no control over how a third-party provider stores, retains, trains on, or otherwise processes the data the user sends through SLICC to that provider. Users are encouraged to review each provider's privacy policy before configuring it.

5. Data Retention

Because almost all SLICC data lives on the user's device, retention is effectively under the user's control:

• On-device data (conversations, files in the virtual filesystem, configuration, API keys, installed skills, IndexedDB / OPFS state) is retained until the user deletes it through the SLICC UI, clears their browser storage, uninstalls the application, or otherwise removes it from their device. The SLICC project cannot delete on-device data on a user's behalf because it does not have access to it.
• Operational Telemetry data (website and applications) is retained according to Adobe's documented retention practices for AEM Operational Telemetry. We do not control individual record retention because individual records are not tied to any visitor.
• Adobe LLM Proxy data is retained as described in section 3.2.

6. Your Rights

Where applicable law grants you rights regarding personal information (for example, rights of access, correction, deletion, restriction, objection, or portability under the EU and UK GDPR, or analogous rights under California, Brazil, and other privacy laws), those rights apply to the entity that holds the relevant data:

• For on-device data, the user controls the data directly through the application UI and the operating system's normal storage controls.
• For Adobe Operational Telemetry on the website and inside the applications, the data is by design not tied to a visitor or device, so individual access and deletion requests are generally not technically possible. Adobe's website privacy controls apply where they apply.
• For Adobe LLM Proxy data, exercise rights through Adobe at https://www.adobe.com/go/privacyinquiry or, for proxy-specific deletion, by emailing catalan@adobe.com (see section 3.2).
• For third-party LLM provider data, exercise rights with the provider in question.

If a user believes the SLICC project itself holds personal information about them — which, given the architecture described above, would be unusual — they may contact us at the address in section 9.

7. Children

SLICC is not directed to children. The applications are developer tools intended for technical users. We do not knowingly collect personal information from children. The Adobe LLM Provider additionally enforces an organization-membership requirement that excludes general public use.

8. Changes to This Policy

We may update this Privacy Policy from time to time, for example to reflect new SLICC features, new distribution channels, changes in the providers SLICC supports, or changes in applicable law. The "Last updated" date at the top of this policy will be revised when changes are made, and the previous text will be replaced. For material changes, we will make reasonable efforts to highlight the change in the SLICC applications or on the website.

9. Contact

For questions about this Privacy Policy or about how SLICC handles data:

• General inquiries about the SLICC project: email info@sliccy.com or open an issue at https://github.com/ai-ecoverse/slicc/issues.
• Adobe Privacy Policy and Adobe-held data (including the Adobe LLM Provider): Adobe privacy inquiry form at https://www.adobe.com/go/privacyinquiry; Adobe Ireland Data Protection Officer at DPO@Adobe.com.
• Adobe LLM Proxy data deletion: catalan@adobe.com.