Last updated: 23 June 2026
Scara is operated by:
Lukasz Tkacz, trading as Scara NIE: Z4291451R Address: Cortijo el Rincón, 1, 29314, Huertas del Río, Archidona, Málaga, Andalucía, España Contact: [email protected]
I operate Scara as an individual (autónomo), not through a registered company. For the purposes of EU/Spanish data protection law (GDPR and LOPDGDD), I am the data controller — the person responsible for deciding how and why your data is processed, and the person you can contact directly with any question or request about it.
Scara is an AI-assisted self-reflection tool. You write; Scara responds with questions, not answers, summaries, or advice. The aim is to help you think more clearly using your own words — not to interpret you, diagnose you, or tell you what to do.
Scara is not therapy, counselling, or a medical service, and is not a substitute for professional mental health support. See Section 12 below.
Scara is currently in early, invite-only beta, accessed via individual access codes.
When you activate an access code, the following is stored in Cloudflare KV (our server-side storage):
This is the minimum needed to authenticate you, record the consents you gave at sign-up, and keep the beta access system working.
This is the part that matters most, so it's worth being precise.
The content of your conversations with Scara is encrypted on your own device before it is ever stored, using AES-GCM encryption. The encryption key is derived from your password and access code using PBKDF2, and that key never leaves your browser — it is held only in temporary session storage and is gone the moment you close the tab.
In practice, this means:
The one moment your conversation content does leave your device is when you send a message: the text of your current message, plus your last 5 conversation turns for context (a "turn" being one message from you and one reply from Scara), is sent to Anthropic so that Scara can generate a response. This includes any information you choose to write about other people — partners, family members, colleagues, or anyone else you mention. Scara is a private tool and doesn't share your content, but be aware that anything you write and send will transit to Anthropic as described below. This is covered in Section 5.
Separately from your journal content, Scara keeps a small amount of operational data, none of which contains what you actually wrote:
If you sign up for the waitlist on the Scara landing page, your email address is collected and stored by Loops.so, our email service provider, under a double opt-in process. This is entirely separate from the access-code/beta system — there is no technical link between a waitlist signup and any beta account.
Some people may choose to share content that touches on sensitive topics — matters relating to mental health, emotional state, or other areas that fall under Article 9 GDPR's "special categories" of personal data. Scara doesn't ask for this, and nothing in the product requires it. But if you do, that content will be transmitted to Anthropic as part of generating a response (see Section 5). Because this is special-category data under Article 9, processing it requires explicit consent beyond your general agreement to use the service. At account creation, you are asked to give this consent via a dedicated checkbox — separate from the general terms, because Scara is fully usable without ever sharing special-category content. This consent is voluntary, scoped to this specific processing, and withdrawable at any time by ceasing to share such content or by deleting your account.
I do not use your data for advertising, profiling, or any purpose beyond running the service.
Scara uses a small number of service providers (data processors) to function:
I do not sell data, share it for advertising, or use any analytics or tracking tools — Scara runs with no analytics platform, no tracking pixels, and no third-party scripts beyond what's listed above.
Anthropic and Cloudflare both operate infrastructure outside the European Economic Area, including in the United States. Where this involves a transfer of your data outside the EEA, the following safeguards apply:
| Data | Retention |
|---|---|
| Access code records | Until 180 days after expiry |
| Behavioral/event logs | 30 days |
| Safety-lock records | 180 days |
| Safety counters | 24 hours |
| Rate-limiting data | 60 seconds to 24 hours |
| Waitlist email | Until you unsubscribe, or the waitlist period ends |
| Journal/conversation content | Entirely under your control — stored on your device until you delete it or delete your account; never held by me at all |
Scara's own application code sets no cookies. The only cookies present are set by Cloudflare Access, which gates access to the app:
| Cookie | Purpose | Type |
|---|---|---|
CF_AppSession |
Identifies your authenticated session | Strictly necessary |
CF_Authorization |
Authentication token for access control | Strictly necessary |
Both are required for the app to function and fall under the "strictly necessary" exemption — no cookie consent banner is used because no optional or tracking cookies exist. Scara uses no analytics cookies, no advertising cookies, and no third-party tracking of any kind.
Your journal content is protected by client-side AES-GCM encryption with a key derived from your password and access code via PBKDF2 — a key that never leaves your device. Account passwords are stored only as one-way hashes. All API access is authenticated and rate-limited to prevent abuse.
This protection isn't just architectural — it's contractually backed. Cloudflare, which hosts Scara's infrastructure, commits in its Data Processing Addendum that it has never turned over encryption or authentication keys (its own or its customers') to any third party, never installed law enforcement software or equipment on its network, never provided any law enforcement organization a feed of customer content, and never weakened or compromised its encryption at anyone's request.
No system is perfectly secure, but Scara is built so that even in the event of a server-side data breach, journal content would remain encrypted and unreadable without your password — which I do not have, and cannot recover. In the event of a breach affecting personal data, I will notify the AEPD within 72 hours as required by Article 33 GDPR, and will communicate directly with affected users where the breach is likely to result in high risk to their rights and freedoms.
Under GDPR and LOPDGDD, you have the right to:
You can exercise most of these directly inside the app: Settings lets you view a summary of the data held about your account, download all your conversations (as plain-text files), and delete your account entirely. Account deletion removes your access code record and all associated event logs from Cloudflare KV; this happens on the server first, then locally, so you never end up in a state where local data is gone but the account technically still exists.
You're not required to export your data before deleting your account — but since deletion is immediate and irreversible, I'd recommend downloading anything you want to keep first.
Wherever possible, use the in-app Settings panel directly — account data access, export, and account deletion are all handled there, verified automatically by your password, with no email exchange needed.
For anything not available as a self-service option, email [email protected] and I'll handle it directly, normally within a few days and always within the one-month period required by law. The proof I'll ask for depends on what's being requested. For deletion — which only removes data and discloses nothing to the requester — your access code is sufficient. For any request that would disclose information about your account, I'll ask you to use the in-app Settings panel, which verifies you via your password. If you cannot access the app, I cannot safely verify your identity for disclosure purposes and will be unable to fulfil that specific request — this is a security-driven limitation flowing from the architecture, not a gap in your rights.
One known limitation: safety-lock and safety-counter records (Section 3.3) are stored against a conversation ID rather than your access code, and there is no stored mapping between the two — so I cannot look up and individually delete these specific records on request. They expire automatically via the retention periods in Section 7.
You also have the right to lodge a complaint with the Spanish data protection authority, the Agencia Española de Protección de Datos (AEPD), at www.aepd.es, if you believe your data has been mishandled.
Scara is intended for use by adults aged 18 and over. I do not knowingly collect data from anyone under 18. If you believe a minor has used Scara and provided personal data, please contact [email protected] and I will delete the relevant account.
Scara is a self-reflection tool, not a medical device, therapy service, or crisis service. It does not diagnose, treat, or provide professional advice of any kind. If you are in crisis or need immediate support, please contact local emergency services or a crisis helpline rather than relying on Scara. (Full terms on this are set out in the Terms of Service.)
Scara is currently in early beta. Access codes are time-limited. When access expires, your account moves to a read-only state — you can still view, export, and delete your data, but cannot send new messages, until/unless beta access is renewed.
If this policy changes in a material way, I'll update the date at the top and notify active users directly, with at least 30 days' notice before the change takes effect. If you do not agree with the updates, you can export your data and delete your account via the Settings menu at any time before the new policy takes effect. For minor, non-material corrections (such as fixing a typo or clarifying existing wording without changing meaning), the date will be updated and no separate notification will be sent.
Questions, requests, or concerns about your data: [email protected]
This policy is written in plain language wherever possible. If anything is unclear, please ask — that's a sign the policy needs to be clearer, not a sign you've misunderstood it.