Privacy Policy

Eigenigma Blog (“Eigenigma Blog,” the “Site,” “we,” “us,” or “our”) is a personal-publishing website operated by an individual based in the United States, publicly identified as “WindFade.”

This Privacy Policy explains how we handle personal data when you visit the Site, use optional AI chat or AI search features, choose browser-based preferences, or contact us by email.

To the extent applicable, this Privacy Policy is intended to provide notice under the EU General Data Protection Regulation (“GDPR”), the UK GDPR, the Swiss Federal Act on Data Protection (“FADP”), and similar data-protection rules. Nothing in this Privacy Policy should be read as an admission that any particular law applies to every processing activity described here. In particular, the Site is not directed to persons in the EEA, the United Kingdom, or Switzerland; it is a personal blog made available on the open web, not a commercial service targeted to those markets.

The Site does not require user accounts, does not take payments, does not sell products or services to visitors, does not run advertising, and does not sell or share personal data for behavioural advertising or cross-context advertising purposes.

For a short summary, read Section 1: At a glance. For browser-level privacy controls, use the Privacy preferences section at the bottom of this page.

2. Controller and contact details

You may use the email address above for any privacy question, data-protection correspondence, or rights request. If you need to send a request by post, email us first and we will provide a postal address for that purpose.

3. Regulatory status and territorial scope

This section explains our position on several threshold legal questions. These positions do not reduce the transparency commitments made elsewhere in this Privacy Policy. They explain why we have not appointed certain representatives or officers, and why we do not consider certain privacy statutes to apply to the operation of this Site.

3.1 GDPR and UK GDPR territorial-scope position

We do not consider Article 3(2) GDPR or the equivalent UK GDPR territorial-scope provision to apply to this Site.

The Site is operated from the United States by an individual. We are not established in the EEA or the United Kingdom. The Site is a personal blog and is not marketed as a product or service to persons in the EEA or the United Kingdom. It does not display prices in local currencies, offer paid goods or services, maintain user accounts, provide localised commercial offerings, run region-specific campaigns, or otherwise target those markets.

We also do not consider the analytics described in this Privacy Policy to constitute monitoring of persons in the EEA or the United Kingdom for Article 3(2) purposes. The analytics is first-party, self-hosted, aggregate site measurement. It does not involve cross-site tracking, cross-day profiling, behavioural advertising, ad targeting, prediction of individual behaviour, or evaluation of individual users. The analytics design is described in more detail in Section 4, Section 7, and Section 9. This position is consistent with Recital 24 GDPR and the EDPB Guidelines 3/2018 on the territorial scope of the GDPR.

The Site remains technically accessible from the open web. That accessibility should not be read as targeting the EEA, the United Kingdom, or Switzerland, or as an offer of goods or services to persons in those jurisdictions.

If a competent supervisory authority determines that Article 3(2) GDPR or the corresponding UK GDPR provision applies to any of our processing activities, we will reassess the affected processing activities and the related compliance obligations.

3.2 No EU or UK representative

We have not appointed an EU or UK representative.

Our position is that Article 27 GDPR and the corresponding UK GDPR representative obligation do not apply because, for the reasons stated in Section 3.1, we do not consider Article 3(2) GDPR or UK GDPR to apply to the Site.

If a competent supervisory authority determines that Article 3(2) applies to any of our processing activities, we will reassess whether a representative is required for those activities and will appoint one where required.

3.3 No Data Protection Officer

We have not appointed a Data Protection Officer.

Article 37 GDPR requires a Data Protection Officer only in specified cases, including where the controller is a public authority, where the controller’s core activities require regular and systematic monitoring of data subjects on a large scale, or where the controller’s core activities consist of large-scale processing of special-category data or criminal-conviction and offence data. The reading of those cumulative conditions in the Article 29 Working Party Guidelines on Data Protection Officers (WP243 rev.01), endorsed by the EDPB, is the position we follow.

Those conditions are not met here.

First, the Site is not operated by a public authority or public body.

Second, the Site’s core activity is personal publishing: making written content available to readers. The analytics described in this Privacy Policy is ancillary to that activity. It is used for aggregate site measurement, capacity awareness, and content review. It is not the activity for which the Site exists.

Third, the analytics is not large-scale monitoring. The Site has no user accounts, no registration flow, no persistent sessions, no behavioural advertising, no cross-site tracking, and no advertising profile system. Analytics events are stored only for the retention period stated in Section 9, and the IP-derived analytics identifier is created using a salted hash with daily salt rotation so that cross-day linkability is broken by design.

Fourth, the Site is not designed to collect or process special-category data under Article 9 GDPR, criminal-conviction or offence data under Article 10 GDPR, or equivalent sensitive categories under other regimes. The AI features and email channel are not intended to receive that information, as described in Section 4, Section 7, and Section 11.

Without accepting that the Site’s analytics amounts to “monitoring” in the Article 37 sense, the cumulative requirements for a mandatory Data Protection Officer are not met. If a competent supervisory authority determines that a Data Protection Officer is required for our specific activities, we will appoint one.

3.4 Swiss FADP status and no Swiss representative

The Swiss FADP is a separate legal regime. We have not appointed a representative in Switzerland under Article 14 FADP.

Article 14 FADP requires a foreign controller to designate a representative in Switzerland only where the relevant conditions are met, including processing connected with offering goods or services to persons in Switzerland or monitoring their behaviour, processing on a large scale, regular processing, and processing that presents a high risk to the personality of the data subjects.

We do not offer goods or services to persons in Switzerland. The Site has no Swiss-localised marketing, pricing, product offering, paid service, account system, or commercial visitor relationship.

Our position does not depend on denying that analytics could ever fall within a behaviour-monitoring concept. Even if a Swiss regulator treated the aggregate analytics described in this Privacy Policy as behaviour monitoring, the representative obligation would still not attach on the facts of this Site because the processing is not large-scale and is not high-risk.

The processing is not large-scale. The Site is a personal blog with no user accounts, no persistent sessions, no behavioural advertising, no cross-site profile system, and modest traffic. Analytics retention is limited, and analytics identifiers are designed to prevent cross-day linkability.

The processing is not high-risk. Assessed by its intrinsic nature and purposes, before considering risk-reduction safeguards, the Site’s processing does not intentionally collect sensitive personal data, does not carry out legal or similarly significant automated decisions, does not score individuals, does not run behavioural advertising, does not conduct cross-site profiling, and does not maintain a large-scale account or profile system. Pseudonymisation, short retention, log minimisation, and self-hosting are additional safeguards; they are not the sole basis for the high-risk conclusion.

We do not separately rely on an argument that the processing is not regular. The Site is available continuously and does not geo-block Swiss visitors, so a regulator could read the regularity condition against us. Our position does not depend on that condition.

If the FDPIC or another competent authority determines that a Swiss representative is required for our specific activities, we will appoint one.

3.5 CCPA / CPRA non-applicability

We do not consider the California Consumer Privacy Act, as amended by the California Privacy Rights Act (“CCPA / CPRA”), to apply to our operation of the Site.

The CCPA / CPRA applies to an entity only if it qualifies as a “business” under Cal. Civ. Code § 1798.140. That definition requires, among other elements, a for-profit entity that does business in California, collects consumers’ personal information, determines the purposes and means of processing that information, and meets at least one of the applicable quantitative thresholds.

This Site fails the threshold “business” analysis at the outset. It is not operated for profit and has no advertising, paid product, paid service, sponsorship, affiliate revenue, subscription revenue, or other visitor-related revenue stream.

In any event, the quantitative thresholds are not met. The Site does not have annual gross revenues exceeding the adjusted statutory revenue threshold, currently USD 26,625,000 per the CPPA’s Updated Monetary Thresholds (CPI-adjusted for the 2025–2026 cycle). It does not buy, sell, or share the personal information of 100,000 or more California consumers or households. It does not derive 50% or more of annual revenues from selling or sharing California consumers’ personal information.

We do not sell personal information, share personal information for cross-context behavioural advertising, or run advertising at all. Accordingly, we are not a “business” within the meaning of the CCPA / CPRA, and the CCPA / CPRA does not apply to our operation of the Site.

This position does not rely on a standalone personal-or-household-activity exemption. It rests on the statutory “business” definition and the applicable thresholds.

4. Personal data we collect

We collect or process the categories of personal data described below. Some data is provided directly by you, some is generated automatically when your browser connects to the Site, and some is stored only in your own browser.

4.1 Technical and security data

The Site runs through Cloudflare Workers and related Cloudflare services. When your browser requests the Site, Cloudflare necessarily processes technical request data required to route traffic, terminate TLS, apply security checks, and serve the requested page.

We do not keep a general access log of our own.

We have configured Cloudflare Workers Logs with a 1% head sampling rate. Cloudflare’s platform default is 100%, but this Site is configured to capture only 1% of Worker invocations. The sampled request metadata is enriched by Cloudflare and retained for the retention period associated with our Cloudflare Workers plan. At the time of this policy, we use the Workers Free plan, for which the applicable Workers Logs retention window is 3 days. If we upgrade to a plan with a different retention window, we will update the retention details in Section 9.

We have disabled the automatic invocation log that would otherwise record the request method and URL.

Our own application-level logs are limited to failure diagnostics. On failure, they record only an opaque request identifier and an error type. They do not record your IP address, User-Agent, Referer, request payload, AI prompt, AI response, email content, or other request contents.

4.2 Browser preference data

The Site’s default theme setting is auto, which follows your system colour-scheme preference. On first visits, and on visits where you leave the theme at the default setting, the Site writes no theme preference to localStorage.

If you actively switch the theme away from the default, the Site stores the selected value in your browser’s localStorage so that the Site can remember that choice in the same browser.

The theme preference is stored only in your browser. It is not transmitted to our server, is not used for analytics, and is not used for tracking, profiling, advertising, or identification.

The exact storage keys and retention rules are described in Section 13.

4.3 Analytics data

We use a self-hosted, cookie-free Umami analytics deployment to understand aggregate use of the Site.

The analytics data may include:

• the page viewed;
• the referring website or referrer value;
• approximate location at country level;
• broad device type;
• browser type;
• operating system category;
• time spent on the page or visit-duration signals; and
• event / session information required by Umami to produce aggregate site statistics.

The analytics deployment is first-party and self-hosted by us, as described in Section 7. Analytics data is not sent to Umami Software or to any third-party analytics vendor.

Before analytics data is stored, the visitor IP address is hashed with a daily-rotated salt. We do not write the raw IP address to disk in the analytics database. Because the salt rotates daily, the resulting IP-derived value is not designed to link visits across days.

We treat this analytics data as pseudonymous personal data within the meaning of Article 4(5) GDPR, not as anonymous data, in line with CJEU case law on identifiability (Breyer, C-582/14). That treatment is deliberately conservative: although the stored analytics record is not designed to identify a visitor, we do not assert that it is impossible in every circumstance for an IP-derived or device-derived signal to relate to an identifiable person.

4.4 AI interaction data

The Site provides optional AI chat and AI search features. These features are general-purpose text fields.

They are not designed to request, elicit, identify, classify, infer, or extract:

• special-category data under Article 9 GDPR;
• criminal-conviction or offence data under Article 10 GDPR;
• personal data about third parties that you do not have a lawful basis to share with us;
• confidential information;
• personal data about children; or
• personal data submitted on behalf of a child.

You should not submit that information through the AI chat, AI search, or any related AI input field.

We do not run sensitive-category detection on AI prompts. We do not retain AI prompts, conversation context, or model responses on our side after the response stream ends. We do not use prompt content for analytics, profiling, advertising, training, model improvement, user classification, or any independent purpose.

When you submit an AI request, the prompt and the immediately relevant conversation context are transmitted in real time to the model provider used for that request, solely to generate the response you requested. The relevant provider-side processing, retention, and no-training configuration are described in Section 7 and Section 9.

The only request-tied state we keep for AI features is the short-lived rate-limit counter described in Section 4.5. That counter is not associable with the contents of any prompt or response.

We do not treat clicking “Send” or submitting an AI query as explicit consent under Article 9(2)(a) GDPR. We do not rely on Article 9(2)(a) as a legal basis for AI-feature processing.

4.5 AI rate-limit data

To protect the AI chat and AI search endpoints from abuse and runaway cost, each Cloudflare Workers isolate that serves /api/chat or /api/search maintains a short-lived in-memory token-bucket counter.

The counter is keyed by an unsalted SHA-256 hash of the cf-connecting-ip header, which is the client IP address set at the Cloudflare edge for the request. The raw IP address itself is not written to disk or to any persistent store by this rate-limit mechanism.

For each key, the Worker isolate stores only:

• the number of remaining tokens; and
• the millisecond timestamp of the last refill.

No request-body identifier, prompt content, response content, request identifier, User-Agent, Referer, analytics identifier, or email data is included in or derived for this key or value. The counter cannot be joined back to the contents of any AI prompt or response.

The counter exists only in the process memory of the Worker isolate. It is not written to Cloudflare KV, Durable Objects, R2, D1, Workers Analytics, the self-hosted Umami PostgreSQL database, or any other persistent store.

Entries are evicted automatically once they are older than twice the configured rate-limit window. The current configured window is 60 seconds, so eviction occurs within roughly two minutes. The entire in-memory counter is also discarded when the Worker isolate is recycled.

We treat the SHA-256-of-IP key as pseudonymous personal data rather than anonymous data, in line with CJEU case law on identifiability (Breyer, C-582/14), even though the short-lived, in-memory-only design makes practical re-identification by us highly unlikely.

4.6 Communication data

If you contact us by email, we process the personal data contained in that message.

That may include:

• your email address;
• your name or display name, if included;
• message headers;
• subject line;
• message body;
• attachments; and
• any other information you choose to include.

The published email address is a Firefox Relay alias that forwards to a consumer Gmail account. Mozilla Firefox Relay and Google Gmail handle that email path as independent controllers, not as our processors. The email path is described in more detail in Section 7.

The email channel is not designed or intended to receive special-category data, criminal-conviction or offence data, confidential information, personal data about children, or personal data about third parties that you do not have a lawful basis to share with us.

If such information nonetheless reaches us by email, we will limit our processing to handling your request, will not use it for analytics, profiling, advertising, training, or any independent purpose, and will delete the message and any local copy of it when the matter is closed, subject to the retention rules in Section 9 and any applicable legal-hold obligation. We cannot control what Mozilla or Google retains on their own infrastructure after the message has passed through their services.

4.7 Data we do not intentionally collect

We do not intentionally collect special-category data under Article 9 GDPR, criminal-conviction or offence data under Article 10 GDPR, children’s personal data, or equivalent sensitive categories under other data-protection regimes.

The Site has no user accounts, no registration form, no payment system, no advertising identifier system, no behavioural-advertising profile, and no feature designed to collect identity documents, financial account data, health information, biometric identifiers, precise location data, or other high-risk personal data.

For children’s data, see Section 11.

5. Purposes and legal bases

This section explains why we process each category of personal data and, where GDPR or UK GDPR applies, the legal basis we rely on.

Some activities also involve storing information in, or reading information from, a visitor’s terminal equipment, such as browser localStorage. That storage-access question is addressed separately under ePrivacy rules where relevant. The ePrivacy analysis is separate from the GDPR lawful basis for subsequent processing of any personal data.

We do not currently rely on GDPR consent under Article 6(1)(a) or explicit consent under Article 9(2)(a) for any processing described in this policy.

5.1 Website operation and security

We process technical and security data to serve the Site, route traffic, maintain availability, detect failures, and protect the Site from abuse.

This processing is necessary for the Site to function. The legitimate interest is limited to basic operation and security. We minimise our own logs and rely on Cloudflare’s short platform retention for sampled Workers Logs, as described in Section 4 and Section 9.

5.2 Theme preference

If you actively switch the theme away from the default auto setting, the Site writes a localStorage entry in your browser so that the selected theme can be applied on later page views in the same browser.

The storage is triggered by your own action and is used only to remember the interface preference you selected. It is not used for analytics, identification, advertising, profiling, or server-side tracking.

We acknowledge that the “strictly necessary” exemption under ePrivacy Article 5(3) is narrow, especially for UI-customisation storage. We have therefore limited the theme preference to an absolute, non-sliding 90-day time-to-live. The value is not refreshed on read. When the value expires, it is removed on the next page load and the Site falls back to the system-default behaviour. You can also clear it at any time using the privacy controls at the bottom of this page .

We do not rely on consent for this storage or for the related processing. If a competent supervisory authority concludes that the current implementation does not fall within the relevant ePrivacy exemption, we would further tighten the implementation, for example by shortening the storage period or using session-scoped storage. We would not retroactively reclassify your theme selection as GDPR consent.

5.3 Analytics

We use self-hosted Umami analytics for limited first-party audience measurement.

The analytics is used to understand aggregate page views, referrers, broad device and browser categories, approximate country-level location, and site-performance signals. It is not used for advertising, behavioural profiling, cross-site tracking, cross-context advertising, user scoring, or prediction of individual behaviour.

Our Umami deployment does not set or read first-party or third-party cookies. It does not write to localStorage except where you use the optional umami.disabled opt-out control, which is described in Section 13.

To the extent a regulator treats the server-side combination of a salted IP-derived value, User-Agent-derived information, and same-day session-identification signals as storage access or access to information from terminal equipment under ePrivacy Article 5(3), we rely, where available, on the narrow audience-measurement exemption recognised by certain national supervisory authorities for limited, first-party analytics. We do not rely on GDPR consent for this processing.

If a competent supervisory authority concludes that the audience-measurement exemption does not cover our Umami configuration and that prior opt-in is required for the storage-access step, we will stop the analytics or change its implementation rather than introduce a consent mechanism for this Site.

For the GDPR lawful basis for subsequent processing, where applicable, we rely on Article 6(1)(f): legitimate interest in understanding aggregate use of the Site and improving performance and content. That interest is balanced by the following safeguards:

• no advertising;
• no advertising profiles;
• no cross-site tracking;
• no third-party analytics vendor;
• self-hosted storage;
• no raw IP written to the analytics database;
• daily salt rotation for the IP-derived analytics value;
• limited retention; and
• an opt-out control at the bottom of this page .

5.4 AI chat and AI search

The AI chat and AI search features are optional. They process the text you submit only to generate the response you requested.

We rely on Article 6(1)(f) GDPR, where applicable, because the processing is initiated by the user, limited to the immediate request, and directly supports the feature the user chose to use.

We do not retain prompts, conversation context, or responses on our side after the response stream ends. We do not use prompt content for analytics, advertising, profiling, model training, model improvement, or any independent purpose.

The AI input fields are not intended to receive special-category data under Article 9 GDPR or criminal-conviction and offence data under Article 10 GDPR. We do not treat submission of an AI query as explicit consent under Article 9(2)(a), and we do not rely on Article 9(2)(a) as a legal basis.

Provider-side handling is described in Section 7 and Section 9.

5.5 AI rate limiting

We use a short-lived in-memory rate-limit counter to reduce abuse, automated scraping of AI endpoints, and runaway cost.

The counter is limited to the data described in Section 4.5. It contains no prompt content, no response content, no request payload, and no durable identifier. It is not written to persistent storage and is evicted within roughly two minutes under the current configuration.

We rely on Article 6(1)(f) GDPR, where applicable, based on the legitimate interest in keeping the AI features available and technically sustainable.

5.6 Email correspondence

If you email us, we process the message so that we can read it, respond to it, and maintain a proportionate correspondence record.

We rely on Article 6(1)(f) GDPR, where applicable. The legitimate interest is responding to the person who chose to contact us. The data-subject expectation follows from the act of sending the email.

The inbound email path involves Firefox Relay and consumer Gmail as independent controllers, as described in Section 7.

5.7 No advertising, profiling, or significant automated decisions

We do not use personal data for personalised advertising, behavioural advertising, ad targeting, ad auctions, cross-context behavioural advertising, or advertising profiles.

We do not carry out profiling that produces legal or similarly significant effects.

We do not carry out automated decision-making within the meaning of Article 22 GDPR.

6. Are you required to provide personal data?

No statute or contract requires you to provide personal data to visit this Site. Providing personal data is not a requirement necessary to enter into a contract with us. We do not offer visitor contracts, paid accounts, paid services, or purchases through the Site.

Different data categories have different practical consequences:

The privacy controls at the bottom of this page affect only the current browser. They are not synced to our server and do not apply across other browsers or devices.

7. Recipients and processing roles

This section describes the third parties that may receive or process personal data in connection with the Site, and the role in which they do so.

The same provider may act in different roles for different layers of data. For example, a provider may act as our processor for customer content that we send to it to provide a feature, while also acting as an independent controller for account, billing, authentication, security, abuse-prevention, usage-metering, or diagnostic data that the provider processes for its own service operations.

7.1 Overview of recipient categories

We use the following categories of recipients:

• Infrastructure and security provider. Cloudflare processes traffic, routing, TLS termination, security, hosting, CDN, DNS, image delivery, Workers, KV, and Tunnel-related data.
• AI model providers. OpenAI processes AI chat inputs and outputs. Google processes AI search inputs and outputs through the paid tier of the Gemini API.
• Self-hosted analytics infrastructure. Umami is self-hosted by us and is not a separate analytics vendor. Cloudflare still processes analytics requests in transit because analytics traffic reaches the self-hosted backend through a Cloudflare Tunnel.
• Email forwarding and mailbox providers. Mozilla Firefox Relay and consumer Gmail handle the inbound email path as independent controllers, not as our processors.

We do not use advertising networks, ad exchanges, third-party analytics vendors, data brokers, affiliate-tracking networks, or cross-context behavioural advertising services.

We do not share personal data with third parties beyond the recipients described in this section, except where required by law, court order, valid legal process, or a comparable binding obligation.

7.2 Cloudflare

Cloudflare provides hosting, routing, security, and edge infrastructure for the Site.

The Cloudflare services used in connection with the Site include Cloudflare Workers, KV, CDN, DNS, Images, TLS termination, security checks, and the Cloudflare Tunnel that exposes the self-hosted analytics backend.

For visitor traffic that Cloudflare routes, secures, terminates TLS for, or serves on our behalf, Cloudflare acts as a processor under the Cloudflare Customer DPA, to the extent applicable data-protection law treats the traffic as personal data processed on our behalf.

Cloudflare also processes a separate layer of data for its own service operations. That layer may include account information, authentication information, billing or plan information, security telemetry, abuse-prevention logs, usage metering, diagnostic data, and network-level operational metadata. For that layer, Cloudflare acts as an independent controller or equivalent service-side actor under its privacy policy and terms, not as our processor under our instructions.

The Site does not use Cloudflare Web Analytics or a Cloudflare RUM beacon. The disabled Cloudflare features and logging controls are described in Section 10.

7.3 OpenAI

OpenAI receives the prompts and immediately relevant conversation context that you submit through AI chat, in real time during the request, to generate the streaming response you requested.

For that customer-content layer, OpenAI acts as a processor under the OpenAI API Data Processing Addendum, to the extent applicable data-protection law applies and the relevant content is personal data.

Our current OpenAI configuration is limited as follows:

• We use the OpenAI Responses API for streaming AI chat response generation.
• We use the OpenAI Moderations API for pre-flight content checks on the user’s message.
• We pass store: false on every Responses API call.
• We have not opted in to OpenAI voluntary data-sharing programmes for training-data sharing, evals, fine-tuning data sharing, Playground feedback, or similar optional sharing.
• We do not use Chat Completions, Assistants, Threads, Conversations, Vector Stores, the Files API, Fine-tuning, Evals, Batches, the Realtime API, image endpoints, audio endpoints, or video endpoints for the Site’s AI chat feature.
• We do not build any feature on top of OpenAI stored responses, stored conversations, vector stores, uploaded files, or server-side conversation state.

Under the OpenAI API data-controls documentation, API data is not used to train or improve OpenAI models by default unless the customer explicitly opts in. Our configuration does not opt in.

The store: false parameter affects the Responses API Application State layer. It means that our Responses API outputs are not intentionally stored by us through OpenAI’s stored-response feature and are not retrieved by us later through stored-response endpoints. That parameter does not disable OpenAI’s separate abuse-monitoring retention.

By default, OpenAI may retain API abuse-monitoring logs for up to 30 days. Those logs may include customer content, such as prompts and responses, and metadata derived from that content, such as classifier outputs. Longer retention may apply where required by law or where reasonably necessary to protect OpenAI’s services or third parties from harm.

For the Moderations API, OpenAI’s published endpoint table records no abuse-monitoring retention and no Application State retention.

We do not have Zero Data Retention or Modified Abuse Monitoring for this Site. Those controls require OpenAI approval and additional requirements; they are not automatically granted by the standard DPA. OpenAI also reserves the right to make certain current or future models ineligible for those controls for specific customers where necessary to investigate severe-risk activity, as described in OpenAI’s published data-controls documentation.

We have not requested non-US data residency for this Site. OpenAI data-residency controls are a separate project-level configuration and require eligibility and, for non-US regions, additional approval conditions. The Site therefore uses OpenAI’s default API processing arrangement rather than a non-US regional-residency configuration.

OpenAI also processes a separate operational layer for its own service operations. That may include account data, billing and usage metering, authentication data, safety and abuse telemetry generated by OpenAI, moderation classifier outputs, policy-violation signals, crash and diagnostic reports, and connection metadata such as the IP address of the API caller. For that operational layer, OpenAI acts under its privacy policy, business terms, and service-side legal basis rather than as our processor for your AI prompt content.

7.4 Google Gemini API

Google receives the prompts and immediately relevant conversation context that you submit through AI search, in real time during the request, to generate the streaming response you requested through the paid tier of the Gemini API.

For that customer-content layer, including prompts, responses, and request metadata needed to deliver the service, Google acts as a processor under the Data Processing Addendum for Products Where Google is a Data Processor, as scoped by the Gemini API Additional Terms applicable to paid services.

Our current Gemini configuration is limited as follows:

• All Gemini API calls are made through a Google Cloud project with active billing.
• We do not use unpaid Gemini API quota and have no fallback path to unpaid quota.
• The AI search feature uses the Gemini API paid services tier.
• The Gemini SDK surface used for AI search is chats.create with sendMessageStream, routed to the generateContent family of endpoints.
• We do not use the Interactions API.
• We do not use background execution.
• We do not use server-side conversation state through previous_interaction_id.
• We do not use Grounding with Google Search.
• We do not use Grounding with Google Maps.
• We do not use the File API.
• We do not use explicit context caching.
• We do not use the Live API.
• We do not use the Batch API.
• We do not use image, audio, or video generation endpoints.
• We do not use Deep Research or Antigravity agents.
• Each request carries only the conversation context required to generate the immediate response.

Under the Gemini API Additional Terms, prompts and responses submitted through paid services are not used by Google to improve Google products. Our use of the Gemini API is configured to remain within the paid-services treatment by using an active-billing Google Cloud project and by not falling back to unpaid quota.

The paid-services no-product-improvement rule is separate from Google’s abuse-monitoring retention. Under Google’s published Gemini API abuse-monitoring documentation, Google retains prompts, contextual information provided with prompts, and model outputs for 55 days for the purpose of detecting and preventing Prohibited Use Policy violations, maintaining the safety and security of the services, and making required legal or regulatory disclosures.

If prompts or model outputs are flagged by safety filters or abuse-detection systems, authorized Google personnel may review the flagged content through Google’s internal governance and review platform. Logged content used for abuse monitoring is not used to train or fine-tune Google’s general-purpose generative AI or machine-learning models, but may be used for Google models used specifically for policy enforcement.

Certain Gemini features may carry separate feature-specific storage or retention rules. We do not currently use the features listed above. If we begin using additional Gemini features that materially change the data flow or retention position, we will update this Privacy Policy.

Google also processes a separate operational layer for its own service operations and Google Cloud project management. That may include account information, project information, billing history, usage metering, token counts, authentication details, safety-filter triggers, software errors, crash reports, quality and performance metrics, security and abuse telemetry, and connection metadata such as IP addresses. For that layer, Google acts under its controller-to-controller terms, the Google Privacy Policy, the Google Cloud terms, or other applicable Google terms, rather than as our processor for your prompt and response content.

7.5 Self-hosted Umami analytics

Umami is not a separate analytics vendor for this Site.

Our Umami analytics deployment is operated by the same individual controller who operates the Site. The analytics script is loaded from analytics-tunnel.eigenigma.io, which is proxied through a Cloudflare Tunnel to a Umami instance running in a Kubernetes cluster on bare-metal hardware that the controller owns and operates directly.

Events are stored in a self-managed PostgreSQL database on that same hardware. We do not send analytics events to Umami Software, a managed Umami cloud service, a third-party analytics vendor, a data broker, or an advertising network.

Cloudflare still processes analytics requests in transit because the analytics endpoint is exposed through a Cloudflare Tunnel. That is not a separate analytics recipient; it is the same Cloudflare processor relationship described in Section 7.2.

Analytics data is used only for aggregate site measurement. It is not used for advertising, behavioural profiling, cross-site tracking, cross-context advertising, sale, sharing, or user scoring.

7.6 Email path: Firefox Relay and Gmail

If you contact us at the email address published in this Privacy Policy, your message does not go directly to an inbox operated by us.

The published address is a Firefox Relay alias:

1vua5eer1@mozmail.com

Email sent to that alias is forwarded by Mozilla Firefox Relay to a backing consumer Gmail mailbox that we use for correspondence.

For our purposes, Mozilla Firefox Relay and Google consumer Gmail act as independent controllers for the email path, not as our processors. We do not have a data-processing agreement with Mozilla or Google for the consumer email forwarding and mailbox path, and we do not direct their independent filtering, abuse-prevention, security, retention, or mailbox-processing activities.

Mozilla Firefox Relay receives mail sent to the alias and forwards it to the backing mailbox. The Firefox Relay privacy notice states that Relay email masks forward messages to the user’s true inbox. Mozilla also states that Relay does not filter spam itself; its email partner Amazon SES blocks spam and malware on that path. If the Relay service is temporarily down, Mozilla states that it may temporarily store emails until they can be sent, but not for longer than three days. Mozilla’s broader privacy practices are governed by the Mozilla Privacy Policy.

The forwarded message then reaches a consumer Gmail account. Consumer Gmail is provided by Google under consumer terms, not under a Google Workspace DPA for us. Per the Google Privacy Policy, Google’s automated systems analyse the content of messages delivered to the inbox to detect abuse such as spam, malware, and illegal content, and to provide and improve spam, phishing, malware, and abuse-protection filtering. That processing is governed by the Google Privacy Policy and the Google Terms of Service, not by our instructions.

The sender address, recipient address, headers, subject line, message body, attachments, and related transmission metadata may therefore pass through Mozilla, Amazon SES, and Google infrastructure. We retain our own copy only as described in Section 9.

If you do not want your message to traverse Firefox Relay, Amazon SES, and consumer Gmail, do not use email to contact us. We will add an alternative contact channel when a suitable privacy-preserving channel is available.

7.7 Sensitive information in emails

The email channel is not designed or intended to receive:

• special-category data under Article 9 GDPR;
• criminal-conviction or offence data under Article 10 GDPR;
• confidential information;
• personal data about children;
• personal data submitted on behalf of a child; or
• personal data about third parties that you do not have a lawful basis to share with us.

If such information nonetheless reaches us by email, we will limit our own processing to handling the request, will not use it for analytics, profiling, advertising, training, model improvement, user classification, or any independent purpose, and will delete our local copy when the matter is closed, subject to Section 9 and any applicable legal-hold obligation.

We cannot control what Mozilla, Amazon SES, or Google retain on their own infrastructure after the message has passed through their services.

8. International transfers

This section describes international-transfer safeguards to the extent GDPR, UK GDPR, Swiss FADP, or comparable transfer rules apply.

The Site is operated from the United States. Some recipients described in Section 7 are located in, or may process data from, the United States or other countries outside the EEA, the United Kingdom, and Switzerland.

We distinguish between:

• processor transfers that occur under our service-provider arrangements; and
• independent-controller processing on the inbound email path or in provider operational layers.

8.1 Processor transfers

For processor relationships described in Section 7, our baseline transfer safeguards are as follows, where applicable.

For EEA-origin personal data subject to GDPR Chapter V, the baseline safeguard is the European Commission’s Standard Contractual Clauses under Article 46(2)(c) GDPR, as incorporated into or referenced by the relevant provider’s data-processing terms.

For UK-origin personal data subject to the UK GDPR, the baseline safeguard is either the UK International Data Transfer Addendum to the EU SCCs or the UK International Data Transfer Agreement, depending on the provider’s transfer documentation.

For Swiss-origin personal data subject to the Swiss FADP, the baseline safeguard is the EU SCCs as recognised for Swiss purposes by the FDPIC, with the adaptations required for use under Swiss data-protection law.

These instruments apply only where there is a restricted transfer within the meaning of the relevant law and where the provider’s applicable data-processing terms incorporate or support the relevant transfer mechanism.

8.2 Data Privacy Framework

The EU-U.S. Data Privacy Framework, the UK Extension to the EU-U.S. Data Privacy Framework, and the Swiss-U.S. Data Privacy Framework may provide an adequacy-style route for transfers to US recipients that are actually self-certified on the Data Privacy Framework List for the relevant framework component and the relevant data type.

We do not make a blanket assertion that every recipient or every transfer described in this Privacy Policy is covered by the Data Privacy Framework.

Where a recipient is currently certified for the relevant framework component and data type, that certification may serve as an alternative or additional transfer route. Where a recipient is not certified, or where the certification does not cover the relevant transfer, the applicable contractual transfer instruments described in Section 8.1 remain the relevant safeguard for processor transfers.

Certification status can change. The operative check is the recipient’s current status on the public Data Privacy Framework List at the time of the relevant transfer assessment.

8.3 Cloudflare transit and hosting layer

Cloudflare may process data in multiple locations as part of its global network, security, routing, and hosting services.

For traffic and service data processed by Cloudflare on our behalf, we rely on Cloudflare’s data-processing terms and transfer safeguards, including the relevant SCC, UK, and Swiss mechanisms where applicable.

This applies both to ordinary Site traffic and to analytics traffic that reaches our self-hosted Umami backend through a Cloudflare Tunnel.

8.4 OpenAI and Google AI provider transfers

AI chat data sent to OpenAI and AI search data sent to Google may be processed outside the EEA, the United Kingdom, or Switzerland.

For the customer-content layer that the AI providers process on our behalf, we rely on the relevant provider data-processing terms and transfer safeguards, including the applicable SCC, UK, and Swiss mechanisms where applicable.

We have not configured a non-US OpenAI data-residency project for this Site. Google Gemini API calls are made through a Google Cloud project with active billing, but we do not make a separate regional-residency commitment for Gemini processing in this Privacy Policy.

Provider operational data, such as account, billing, metering, safety, diagnostic, abuse, and authentication data, may be processed by the providers for their own service operations under their own terms and privacy notices. That operational layer is not controlled by our instructions in the same way as customer-content processing.

8.5 Email path transfers

Email sent to the address in this Privacy Policy is routed through Mozilla Firefox Relay and then to a consumer Gmail account.

Mozilla and Google act as independent controllers for that email path. We do not have a Chapter V GDPR, UK GDPR, or Swiss FADP transfer instrument with Mozilla or Google for that consumer email path because they are not acting as our processors for that forwarding and mailbox processing.

If you are in the EEA, the United Kingdom, or Switzerland and choose to email us, your message may be transferred to and processed in the United States or other countries by Mozilla, Amazon SES, and Google under their own privacy notices, terms, transfer mechanisms, and legal responsibilities.

We disclose this path so that you can decide whether to use email. We can control only our own handling of the correspondence after it reaches us. We cannot impose SCCs, a UK IDTA, a UK Addendum, Swiss-Finish clauses, or equivalent safeguards on independent-controller processing that we do not direct.

8.6 Self-hosted analytics storage layer

The Umami analytics backend itself runs on bare-metal hardware that the controller owns and operates directly. Analytics events stored in the self-managed PostgreSQL database are not disclosed to a separate managed analytics provider, cloud-hosted analytics vendor, or managed-Kubernetes provider at the storage layer.

That does not mean there is no international-transfer consideration for analytics traffic. Analytics requests reach the self-hosted backend through a Cloudflare Tunnel. Cloudflare therefore processes analytics requests in transit as described in Section 7.2 and Section 8.3.

As an additional safeguard, the raw IP address is not written to the analytics database. The IP-derived analytics value is created using a daily-rotated salt before storage.

8.7 Copies of transfer safeguards

Where Article 13(1)(f), Article 46 GDPR, UK GDPR, Swiss FADP, or a comparable rule requires information about transfer safeguards, you may contact us at 1vua5eer1@mozmail.com.

Where the relevant instrument is a public standard form, such as the EU SCCs, the UK IDTA, or the UK Addendum, we may provide the authoritative public source and identify the mechanism we rely on. Where the relevant safeguard is incorporated into a provider’s public data-processing terms, we may point you to the provider’s applicable DPA and transfer terms.

Commercially sensitive, security-sensitive, or third-party confidential information may be redacted where legally permitted.

9. Retention

We retain personal data only for the period reasonably necessary for the purpose for which it is processed, unless a longer period is required for legal obligations, security investigations, dispute resolution, or the establishment, exercise, or defence of legal claims.

Retention differs by data category and by whether the data is held by us, stored only in your browser, or retained by a third-party provider under its own terms.

9.1 Cloudflare Workers Logs

Cloudflare Workers Logs are retained for the plan-dependent Cloudflare retention window.

At the time of this Privacy Policy, we use the Cloudflare Workers Free plan, for which the Workers Logs retention window is 3 days.

If we upgrade to a plan with a different Workers Logs retention window, we will update this Privacy Policy.

Deletion occurs through Cloudflare’s automatic retention process.

9.2 Application-level error logs

Our own application-level failure logs record only an opaque request identifier and an error type.

They do not record IP addresses, User-Agent values, Referer values, request payloads, AI prompts, AI responses, or email contents.

These logs are retained only as long as needed for failure diagnostics and routine operational review, unless needed longer for security investigation or legal claims.

9.3 Umami analytics events

Umami analytics events are retained for 13 months.

A scheduled purge process deletes sessions and associated events older than 13 months from the self-hosted PostgreSQL database.

The raw IP address is not written to the analytics database. The stored analytics identifier is based on a daily-salted IP hash, so it is not designed to link visits across days.

9.4 Theme preference in localStorage

The theme key is stored only in your browser if you actively switch the theme away from the default auto setting.

It has an absolute, non-sliding 90-day time-to-live from the moment the preference is written.

The time-to-live is not refreshed on read. On the first page load after expiry, the entry is treated as expired, removed from localStorage, and the Site falls back to the system-default theme behaviour.

You can also clear this key at any time using the privacy controls at the bottom of this page or through your browser settings.

9.5 Theme tooltip flag in localStorage

The theme.tipShown key is stored only in your browser after the one-time theme tooltip has been shown.

It has the same absolute, non-sliding 90-day time-to-live as the theme key. It is not refreshed on read.

The privacy controls at the bottom of this page clear this key together with the theme key.

9.6 Umami opt-out flag in localStorage

The umami.disabled key is stored only in your browser if you use the Umami opt-out control at the bottom of this page .

When set, the value is the literal string 1.

We do not set a time-based expiry for this key because it records a persistent privacy preference in the current browser. It remains until you remove it by using the same control again or by clearing it through your browser settings.

This key is not transmitted to our server and is not synced across browsers or devices.

9.7 AI interaction data on our side

We do not retain AI prompts, conversation context, or model responses on our side after the response stream ends.

The prompt and immediately relevant context are forwarded in real time to the relevant AI provider to generate the response you requested. Once the response stream ends, we do not store the prompt, context, or response in our own database, logs, analytics system, object storage, KV store, Durable Object, R2 bucket, D1 database, or other persistent store.

9.8 AI rate-limit counter on our side

The AI rate-limit counter is held only in the process memory of the relevant Cloudflare Workers isolate.

For each key, the counter stores only a token count and a last-refill timestamp.

Entries are evicted once they are older than twice the configured rate-limit window. The current configured window is 60 seconds, so entries are evicted within roughly two minutes. The whole counter is also discarded when the Worker isolate is recycled.

No manual deletion path is required because the counter is not written to persistent storage.

9.9 AI interaction data retained by OpenAI

For OpenAI API processing, OpenAI’s published data-controls documentation states that data sent to the OpenAI API is not used to train or improve OpenAI models by default unless the customer explicitly opts in. We have not opted in.

For the Responses API, OpenAI’s endpoint table records no Application State retention where no application-state exception applies, and our configuration passes store: false on every Responses API call. The store: false setting concerns Application State; it does not eliminate OpenAI’s separate abuse-monitoring retention.

By default, OpenAI may retain abuse-monitoring logs for up to 30 days. Those logs may include prompts, responses, and metadata derived from customer content, such as classifier outputs. Longer retention may apply where required by law or where reasonably necessary to protect OpenAI’s services or third parties from harm.

For the Moderations API, OpenAI’s published endpoint table records no abuse-monitoring retention and no Application State retention.

We do not have Zero Data Retention or Modified Abuse Monitoring for this Site.

Deletion of OpenAI provider-side abuse-monitoring logs is governed by OpenAI’s retention process and applicable DPA terms. Outside approved Zero Data Retention or Modified Abuse Monitoring arrangements, individual per-message deletion of past abuse-monitoring copies may not be available through us as a practical provider-side mechanism.

9.10 AI interaction data retained by Google Gemini

For Gemini API processing through paid services, the Gemini API Additional Terms state that Google does not use prompts or responses to improve Google products and processes prompts and responses under the applicable Google data-processing terms.

Separately, Google’s Gemini API abuse-monitoring documentation states that Google retains prompts, contextual information provided with prompts, and outputs for 55 days to detect and prevent Prohibited Use Policy violations, maintain the safety and security of the services, and make required legal or regulatory disclosures.

Flagged content may be reviewed by authorized Google personnel through an internal governance and review platform. Logged content used for abuse monitoring is not used to train or fine-tune Google’s general-purpose generative AI or machine-learning models, but may be used for models Google uses specifically for policy enforcement.

Deletion of Google provider-side abuse-monitoring logs is governed by Google’s retention process and applicable terms.

If we later adopt Gemini features with different feature-specific retention, such as file handling, explicit context caching, background execution, server-side interaction state, grounding integrations, Live API, Batch API, or agent features, we will update this Privacy Policy before or at the time of that material change.

9.11 Emails retained by us

Emails that reach us may be retained for up to 3 years after the last correspondence.

This retention period allows us to respond, maintain a proportionate record of the correspondence, understand prior context if the same person follows up, and defend against potential claims.

We may delete correspondence earlier when it is no longer needed.

If an email contains special-category data, criminal-conviction or offence data, children’s data, confidential information, or third-party personal data that the email channel was not intended to receive, we will delete our local copy when the matter is closed, subject to legal-hold obligations and any need to preserve a record for legal claims.

9.12 Emails retained by Mozilla Firefox Relay and Google Gmail

Copies or transient copies of email may exist on Mozilla Firefox Relay, Amazon SES, and Google Gmail infrastructure.

Mozilla, Amazon SES, and Google set their own retention, logging, security, filtering, abuse-prevention, backup, and legal-compliance rules. We do not control those provider-side retention periods.

Mozilla states that Firefox Relay may temporarily store emails if the service is down until it can send them, and that it will not store those emails for longer than three days in that circumstance.

Google’s retention and processing of messages in consumer Gmail is governed by the Google Privacy Policy, the Google Terms of Service, and Gmail-related product settings that apply to the relevant account.

9.13 Legal holds and claims

We may retain data longer than the periods stated above where necessary to comply with a legal obligation, respond to lawful process, investigate abuse or security incidents, resolve disputes, or establish, exercise, or defend legal claims.

Where a legal hold applies, deletion may be suspended for the affected data until the hold is lifted.

9.14 Requests to access or delete data

To request access to, deletion of, or other action on personal data we hold, contact us at 1vua5eer1@mozmail.com.

The practical ability to act on a request depends on the data category.

For example, we generally cannot identify analytics records that correspond to a particular visitor because analytics identifiers are daily salted and the raw IP address is not stored. We also cannot retrieve AI prompts or responses from our own systems after the response stream ends because we do not retain them on our side. Provider-side AI logs and independent-controller email copies are addressed in Section 12.

10. Security

We implement technical and organisational measures appropriate to the nature, scope, context, and purposes of the processing described in this Privacy Policy, and to the risks that the processing may present, in line with Article 32 GDPR.

Those measures include the controls described below.

10.1 Encryption in transit

The Site is served over HTTPS.

At the Cloudflare edge, “Always Use HTTPS” and “Automatic HTTPS Rewrites” are enforced. The Site publishes an HSTS policy with a 6-month max-age. The HSTS policy does not currently include includeSubDomains and is not submitted for preload.

The minimum negotiated TLS version at the Cloudflare edge is TLS 1.2. TLS 1.3 and Encrypted Client Hello (ECH) are enabled. TLS 1.0, TLS 1.1, opportunistic 0-RTT, and legacy cipher suites are disabled.

Origin connections use Cloudflare Full SSL mode, so edge-to-origin traffic is also TLS-encrypted. The Cloudflare Tunnel that exposes the self-hosted analytics backend is encrypted between the Cloudflare edge and the origin.

10.2 Encryption at rest

Analytics events are stored in a PostgreSQL database on encrypted volumes.

Backups are encrypted.

Provider-side encryption for Cloudflare, OpenAI, Google, Mozilla, and Gmail is governed by the applicable provider’s own security documentation, service terms, and data-processing terms, as relevant.

10.3 Source-side pseudonymisation

For analytics, visitor IP addresses are pseudonymised before storage.

The IP address is hashed with a daily-rotated salt before any analytics record is written to the self-hosted PostgreSQL database. The raw IP address is not written to that database.

Because the salt rotates daily, the IP-derived analytics value is not designed to link visits across days.

We treat the resulting analytics data as pseudonymous personal data, not anonymous data.

10.4 Log minimisation

We minimise logs under our control.

Cloudflare’s automatic Worker invocation log is disabled. Cloudflare Workers Logs are sampled at 1% of invocations and retained for the plan-dependent period described in Section 4 and Section 9.

Our own application-level logs record only an opaque request identifier and an error type on failure. They do not record IP addresses, User-Agent values, Referer values, request payloads, AI prompts, AI responses, or email content.

We do not export Workers Logs through Logpush to R2, S3, a third-party SIEM, or any comparable external logging sink.

10.5 AI data minimisation

AI prompts, immediately relevant conversation context, and model responses are forwarded in real time to the relevant AI provider only to generate the response requested by the user.

We do not persist AI prompts, conversation context, or model responses on our side after the response stream ends.

The only request-tied state we keep for AI features is the rate-limit counter described in Section 4 and Section 9. That counter is held only in Worker isolate memory, is keyed by a SHA-256 hash of the client IP, contains no prompt-derived or response-derived data, and is evicted within roughly two minutes under the current configuration.

10.6 Cloudflare features configured off

To reduce edge-side observability of visitors and to keep the Site free of edge-injected scripts, the following Cloudflare zone-level, Worker-level, or related features are configured off for eigenigma.io:

• Cloudflare Web Analytics / RUM beacon (no static.cloudflareinsights.com script is injected into our pages);
• Workers Traces;
• Workers Logpush jobs (no export of Workers Logs to any external sink such as R2, S3, or a third-party SIEM);
• the *.workers.dev preview subdomain for the Worker (workers_dev = false, preview_urls = false);
• Cloudflare Zaraz;
• Argo Smart Routing;
• Cache Reserve;
• Page Rules;
• Email Address Obfuscation (no edge rewriting of mailto: links);
• Rocket Loader (no edge rewriting of <script> tags);
• Auto-Minify for HTML, CSS, and JavaScript;
• Mirage;
• Polish;
• Always Online;
• Hotlink Protection;
• Mobile Redirect;
• IP-Geolocation header injection (Cloudflare does not add a CF-IPCountry header to requests delivered to our Worker); and
• TLS 0-RTT.

Workers Logs are configured to sample 1% of invocations and to suppress the automatic “<METHOD> <URL>” invocation log, as described in Section 4 and Section 9.

This list describes our current configuration. If Cloudflare changes or adds relevant features, or if we materially change the Site’s configuration, we will update this section where the change is material to the privacy or security posture described here.

10.7 Access control

Administrative access to Cloudflare and to the self-hosted infrastructure is restricted to the individual controller.

Administrative accounts are protected by strong unique passwords and hardware-backed multi-factor authentication.

Secrets are stored in a dedicated secrets manager and are not committed to source control.

10.8 Infrastructure control

The self-hosted analytics backend runs on bare-metal hardware owned and operated directly by the controller.

The Kubernetes cluster and PostgreSQL database used for analytics are not operated by a managed-Kubernetes provider, managed database provider, or third-party analytics vendor.

Cloudflare still processes analytics traffic in transit through the Cloudflare Tunnel, as described in Section 7 and Section 8.

10.9 Supply-chain controls

Software dependencies are pinned through a lockfile.

Dependencies are monitored for known vulnerabilities.

The Site is rebuilt and redeployed from source on changes through a reproducible CI pipeline.

10.10 Breach response

If we become aware of a personal-data breach affecting data under our control, we will assess the nature of the breach, the categories of data affected, the likely consequences, and the risk to affected individuals.

Where GDPR, UK GDPR, Swiss FADP, or comparable breach-notification rules apply, we will notify the competent supervisory authority where required.

Where GDPR or UK GDPR applies, and where a personal-data breach is likely to result in a risk to the rights and freedoms of natural persons, we will notify the competent supervisory authority without undue delay and, where feasible, within 72 hours after becoming aware of the breach, unless the breach is unlikely to result in such a risk.

Where the breach is likely to result in a high risk to the rights and freedoms of natural persons, we will also notify affected individuals where required.

11. Children’s privacy

The Site is intended for a general adult audience and is not directed to children.

The Site has no user accounts, no registration flow, no payment system, no age-gated services, no behavioural advertising, no child-directed content strategy, and no feature designed to build behavioural audiences of children.

We do not knowingly collect personal data from children under 16 years of age. Article 8 GDPR uses 16 as the default age threshold for consent in relation to the offer of information society services directly to a child, while allowing EU Member States to set a lower age, provided it is not below 13. Where a lower national threshold applies, that threshold applies for the relevant jurisdiction.

This statement does not mean that we rely on consent as the legal basis for the processing described in this Privacy Policy. As stated in Section 5, we do not currently rely on GDPR consent for any processing described here.

11.1 AI features and age-related restrictions

The AI chat and AI search features are not intended for children.

Some model-provider terms impose age-related restrictions that go beyond our own privacy-law analysis. The Gemini API terms applicable to AI search impose an 18+ condition, so persons under 18 should not use AI search. OpenAI terms applicable to AI chat require parental or guardian permission for minors.

We do not design, direct, or market the Site or its AI features to children. We do not knowingly collect children’s personal data through those features.

If we learn that a child has submitted personal data through AI chat, AI search, or email, we will delete data under our control without undue delay, subject to any legal-hold obligation. Where feasible and relevant, we will also request deletion from the applicable processor.

11.2 Parent or guardian contact

If you are a parent or guardian and believe that a child has provided personal data to us, contact us at 1vua5eer1@mozmail.com.

Provide enough information for us to locate the relevant correspondence or request, if any. We will not ask for additional identifying information unless it is necessary to verify or act on the request.

12. Your privacy rights

Where GDPR, UK GDPR, Swiss FADP, or comparable data-protection rules apply, you may have rights in relation to personal data that we process about you.

The practical scope of each right depends on the data category, the legal basis for processing, the applicable law, and whether the data is in a form that allows us to identify you or the relevant record.

12.1 Right of access

You may request confirmation of whether we process personal data about you.

Where we do, you may request access to that data and the information required by applicable law, such as the purposes of processing, categories of personal data, recipients, retention periods, rights available to you, and available source information.

12.2 Right to rectification

You may request correction of inaccurate personal data.

You may also request completion of incomplete personal data, taking into account the purposes of processing.

This right is most likely to be relevant to email correspondence, because most other data categories described in this Privacy Policy are either not retained by us, not directly identifying, or stored only in your browser.

12.3 Right to erasure

You may request deletion of personal data where a legal ground for erasure applies.

Examples may include cases where the data is no longer necessary for the purpose for which it was processed, where you successfully object to processing and there is no overriding legitimate ground, or where deletion is required by applicable law.

This right is subject to legal exceptions, including where retention is necessary for legal obligations, security investigations, dispute resolution, or the establishment, exercise, or defence of legal claims.

12.4 Right to restriction of processing

You may request restriction of processing where the applicable legal conditions are met.

This may apply, for example, while the accuracy of data is being verified, while an objection is being assessed, or where you need data preserved for legal claims but no longer wish it to be otherwise processed.

12.5 Right to object

Where we rely on legitimate interests under Article 6(1)(f) GDPR, you may object to processing on grounds relating to your particular situation.

If you object, we will stop the relevant processing unless we demonstrate compelling legitimate grounds that override your interests, rights, and freedoms, or unless the processing is necessary for the establishment, exercise, or defence of legal claims.

Because analytics records are not stored in a form that generally lets us identify a particular visitor, the practical effect of an objection to analytics may be limited by the identifiability issues described in Section 12.9. You can use the Umami opt-out control at the bottom of this page to prevent future analytics reporting from the current browser.

12.6 Right to data portability

The GDPR right to data portability applies only to personal data that you provided to us, where the processing is carried out by automated means and is based on consent or contract.

The processing described in Section 5 is not based on GDPR consent or contract. It is based on legitimate interests, where GDPR applies.

For that reason, the GDPR data-portability right generally does not apply to the processing described in this Privacy Policy.

12.7 Right to withdraw consent

We do not currently rely on GDPR consent under Article 6(1)(a), or explicit consent under Article 9(2)(a), for any processing described in this Privacy Policy.

There is therefore no GDPR consent to withdraw for the current processing.

If we later introduce a feature that relies on consent under GDPR, UK GDPR, ePrivacy rules, or another applicable framework, we will identify that consent basis in this Privacy Policy and provide a withdrawal mechanism.

12.8 Right not to be subject to certain automated decisions

We do not carry out automated decision-making that produces legal effects or similarly significant effects concerning you.

The AI chat and AI search features generate responses to prompts submitted by users. They do not decide access to rights, eligibility, employment, credit, housing, education, healthcare, insurance, public benefits, legal status, or any comparable matter.

12.9 Identifiability limits

Some data described in this Privacy Policy is not stored in a form that allows us to identify a particular visitor or retrieve records corresponding to that visitor.

For analytics, the raw IP address is not written to the analytics database. The IP-derived analytics value is hashed with a daily-rotated salt, and the stored analytics data is not designed to link visits across days. As a result, when you contact us to exercise rights, we generally have no reliable way to identify which analytics records correspond to your visits.

Where Article 11 GDPR or an equivalent rule applies, we will not collect additional identifying information from you solely to identify analytics records that we are not otherwise able to associate with you.

For browser preference data, the relevant values are stored only in your own browser. We do not receive them on our server. You can clear them using the privacy controls at the bottom of this page or through your browser settings.

12.10 AI interactions

AI interactions involve two distinct layers.

First, there is the customer-content layer: the prompt, immediately relevant conversation context, model response, and any provider-side abuse-monitoring copy of that content. For this layer, OpenAI and Google act as processors under their respective data-processing terms, as described in Section 7.

We do not retain AI prompts or responses on our side after the response stream ends. If you contact us about a past AI request, we generally cannot retrieve it from our own systems because there is no retained copy on our side.

For provider-side customer-content copies, you may contact us and we will route the request through the relevant provider channel as far as available under the applicable DPA or support process. Provider-side abuse-monitoring retention is governed by the provider’s own retention process. Outside approved Zero Data Retention or comparable arrangements, per-message deletion of individual past requests may not be practically available through us.

Second, there is the provider operational layer. This may include provider account data, project data, billing and usage metering, authentication records, security and abuse telemetry generated by the provider, moderation classifier outputs, diagnostic logs, crash reports, and connection metadata.

For that operational layer, the provider acts as an independent controller or service-side controller-equivalent under its own privacy notice and terms. We cannot exercise your rights against that provider-controlled layer on your behalf. To exercise rights in relation to that layer, contact OpenAI or Google directly through the contact channels in their privacy notices.

12.11 Email data

For emails you send us, we can act on rights requests for the copy under our control, subject to applicable limits and legal exceptions.

Copies or transient copies handled by Mozilla Firefox Relay, Amazon SES, and Google consumer Gmail are controlled by those providers under their own privacy notices, terms, and retention rules. Rights requests relating to those provider-side copies should be addressed to Mozilla or Google directly.

If your request concerns an email you sent to us, include enough information for us to identify the correspondence, such as the sending address, approximate date, and subject line. Do not include sensitive information unless necessary.

12.12 How to exercise rights

To exercise a privacy right, contact us at 1vua5eer1@mozmail.com.

Your request should identify the right you wish to exercise and provide enough information for us to locate the relevant data, if any.

We may ask for additional information where necessary to verify the request, prevent unauthorized disclosure, or locate the relevant data. We will not ask for additional identifying information solely to match analytics records that we cannot otherwise identify.

12.13 Response timeline

Where GDPR or UK GDPR applies, we will respond to rights requests without undue delay and in any event within one month of receiving the request.

Where the request is complex or where we receive a high number of requests, we may extend that period by up to two additional months. If we use an extension, we will inform you within the original one-month period and explain the reason for the extension.

12.14 Complaints to supervisory authorities

Where applicable, you may lodge a complaint with a supervisory authority.

For EEA visitors, this may be the supervisory authority for your habitual residence, place of work, or the place of the alleged infringement.

For UK visitors, this is the Information Commissioner’s Office.

For Swiss visitors, this is the Federal Data Protection and Information Commissioner.

Contact details are provided in Section 19.

13. Cookies, localStorage, and similar technologies

We do not set first-party cookies of our own.

The Site uses limited first-party browser storage through localStorage. Each localStorage key described below is written only after an action taken in the current browser. The values are not transmitted to our server, are not synced across devices, and are not used for advertising, profiling, cross-site tracking, cross-context behavioural advertising, or user identification.

You can clear these values through the privacy controls at the bottom of this page or through your browser settings.

13.1 theme

The theme key stores the optional theme preference described in Section 4, Section 5, and Section 9.

The Site writes this key only if you actively switch the theme away from the default auto setting. The default auto setting follows your system colour-scheme preference and writes nothing to localStorage.

The stored value is a small JSON object containing:

• the selected theme value, either light or dark; and
• the Unix-millisecond timestamp at which the value was written.

The key contains no identifier and is not transmitted to our server.

The theme key has an absolute, non-sliding 90-day time-to-live. The time-to-live is measured from the timestamp at which the preference was written. It is not refreshed when the Site reads the value. On the first page load after expiry, the key is removed and the Site returns to the default auto behaviour.

13.2 theme.tipShown

The theme.tipShown key is a one-time tooltip suppression flag.

It is written only after the theme tooltip has been shown. The key records that the explanatory tooltip associated with the theme preference has already appeared in this browser.

The stored value is a small JSON object containing:

• the value 1; and
• the Unix-millisecond timestamp at which the flag was written.

The key contains no identifier and is not transmitted to our server.

The theme.tipShown key has the same absolute, non-sliding 90-day time-to-live as the theme key. It is not refreshed on read. This ensures that a tooltip-suppression flag cannot outlive the preference it documents.

The privacy controls at the bottom of this page clear theme.tipShown together with theme.

13.3 umami.disabled

The umami.disabled key is the Umami analytics opt-out flag for the current browser.

When you use the Umami opt-out control at the bottom of this page , the Site writes the literal value 1 to umami.disabled in localStorage. The Umami analytics script checks this local browser flag before sending analytics events. When the flag is present, analytics reporting from this browser is suppressed.

The key contains no identifier. It is not transmitted to our server and is not synced across browsers or devices.

We do not set a time-based expiry for umami.disabled because it records a persistent privacy preference in the current browser. It remains until you remove it by using the same control again or by clearing it through your browser settings.

13.4 Cloudflare challenge cookies

Cloudflare may set strictly necessary cookies in the rare event that it issues a security challenge to your connection.

For example, Cloudflare may set a cf_clearance cookie to record that a visitor has passed a challenge, so that Cloudflare does not need to issue the same challenge again on subsequent requests within the applicable clearance period.

These cookies are set by Cloudflare for security and traffic-protection purposes. They are not set by us for analytics, advertising, profiling, or behavioural tracking.

13.5 Clearing browser storage

The privacy controls at the bottom of this page can:

• opt out of Umami analytics in the current browser;
• re-enable Umami analytics in the current browser by removing the opt-out flag;
• clear the stored theme preference in the current browser; and
• clear the theme tooltip flag in the current browser.

These controls affect only the current browser and current site origin. They do not affect other browsers, devices, or provider-side records.

You may also clear localStorage and cookies through your browser settings. For general guidance, see allaboutcookies.org.

14. Do Not Track and Global Privacy Control

14.1 Do Not Track

The DNT request header, commonly known as “Do Not Track,” was an early browser-level privacy signal intended to express a user’s preference not to be tracked, defined by the W3C Tracking Preference Expression specification.

That specification was discontinued without becoming a W3C Recommendation, the W3C Tracking Protection Working Group was closed, and MDN now lists the DNT header as discontinued and non-standard. A user-facing toggle is still present in some browsers (for example, Chrome still documents how to turn the “Send a Do Not Track request” preference on or off), while others — notably Safari — have removed or never implemented one; the signal therefore continues to exist on the wire even though the underlying standard is no longer maintained.

We do not treat the DNT header as a legally operative opt-out signal for this Site.

We do not change the Site’s processing depending on whether your browser sends DNT: 1, DNT: 0, or no DNT header.

This does not reduce the privacy posture described elsewhere in this Privacy Policy. The Site does not run advertising, does not sell or share personal data, does not conduct cross-site tracking, and does not use personal data for cross-context behavioural advertising, regardless of any DNT signal.

14.2 Global Privacy Control

The Sec-GPC request header, commonly associated with Global Privacy Control, is a browser-level signal designed to express a privacy preference, particularly an opt-out from sale or sharing of personal information and from cross-context behavioural advertising where applicable law gives that signal legal effect.

We treat Sec-GPC: 1 as a legitimate machine-readable expression of that preference.

The practical effect on this Site is limited because there is no sale, sharing, cross-context behavioural advertising, or third-party advertising layer for the signal to disable.

Specifically:

• we do not sell personal data;
• we do not share personal data for cross-context behavioural advertising;
• we do not run advertising;
• we do not run an ad exchange or ad auction;
• we do not embed third-party advertising SDKs, pixels, or tags;
• we do not transfer personal data to any third party for advertising, behavioural profiling, or targeting;
• our self-hosted analytics does not build cross-site or cross-context profiles;
• our AI features process submissions only to generate the requested response; and
• the optional theme preference is a first-party interface setting, not a tracking or advertising mechanism.

For those reasons, sending Sec-GPC: 1 does not change the Site’s behaviour. The no-sale, no-share, no-cross-context-behavioural-advertising baseline already applies to every visitor.

If we ever introduce processing that Global Privacy Control is designed to opt out of, such as sale, sharing, cross-context behavioural advertising, or third-party advertising or profiling systems, we will update this Privacy Policy and implement Sec-GPC: 1 as an effective opt-out for that processing where required.

15. Marketing

We do not operate email newsletters.

We do not send marketing emails.

We do not run third-party advertising campaigns.

We do not use visitor data for advertising audiences, lookalike audiences, retargeting, lead generation, affiliate marketing, sponsorship attribution, or promotional profiling.

If we later introduce a marketing feature that requires consent under applicable law, we will identify that processing in this Privacy Policy and request consent before using personal data for that purpose.

16. External websites and third-party content

The Site may link to external websites, repositories, papers, documentation, social profiles, or other third-party content. Examples may include GitHub, academic publishers, standards bodies, documentation sites, blogs, or reference materials.

This Privacy Policy applies only to Eigenigma Blog and to processing described in this Privacy Policy.

External websites and third-party services are operated by their own controllers or service providers. Their privacy practices, security practices, content, and terms are not controlled by us.

Clicking an external link may cause your browser to disclose technical data to the destination website, including the fact that your browser requested that external resource. You should review the privacy notice of the destination service if you want to understand how that service handles data.

17. Changes to this Privacy Policy

We review this Privacy Policy from time to time and may update it to reflect changes in the Site, infrastructure, AI-provider configuration, analytics implementation, legal requirements, or privacy controls.

Material changes will be posted on this page or highlighted within the Site.

The “Last updated” date at the top of this Privacy Policy identifies the date of the current version.

If a change materially affects how we process personal data, we will update the relevant sections before or at the time the change takes effect.

18. How to contact us

For privacy questions, data-protection correspondence, or rights requests, contact:

Email: 1vua5eer1@mozmail.com

This address is a Firefox Relay alias and forwards to a consumer Gmail mailbox, as described in Section 7.

If you prefer to send privacy or data-protection correspondence by post, email us first and request a postal address. We will provide a postal address for that purpose, including for data-subject rights requests that you prefer to send in writing.

When making a rights request, provide enough information for us to understand the request and locate any relevant data that we can identify. Do not include special-category data, children’s data, confidential information, or third-party personal data unless it is necessary for the request.

19. Supervisory authorities

Where applicable, you may lodge a complaint with a data-protection supervisory authority.

19.1 EEA

If you are in the EEA, you may contact the supervisory authority for your habitual residence, place of work, or the place of the alleged infringement.

The European Data Protection Board publishes a directory of EU and EEA data-protection authorities through its members page.

19.2 United Kingdom

UK visitors may contact the Information Commissioner’s Office.

19.3 Switzerland

Swiss visitors may contact the Federal Data Protection and Information Commissioner.