Nillow

Privacy policy

Last updated 27 August 2026.

Who is responsible

Public privacy contact

Nillow is responsible for personal data processed through this website and its services.

Privacy requests can be sent to contact@nillow.ai.

Data we handle

The information needed to provide and protect the service.

Accounts, messages, project requests, payments, and security.

Account identity

Access, not behavioral identity

Email, username, password hash, active sessions, profile fields you choose, and bounded security audit events support account access and protection. If you choose Google or Apple sign-in, Nillow also receives a signed identity proof, the provider's stable account subject, and a verified email claim needed to create or connect the account. Apple may provide a private-relay email address. Nillow never receives your Google or Apple password.

Collaboration projects

Exact members, bounded invitations

A Developer project stores its name, owner, accepted account members, and pending invitations. An invitation email is kept only while the invitation is pending, shown back to the owner in masked form, and scrubbed when it is accepted or expires after 30 days. Project membership does not grant file, repository, deployment, or desktop-runtime access.

Project request

The work you ask us to understand

Your project summary, desired outcome, declared constraints, optional contact fields, permission receipts, and submission state are used to review and respond to the request.

Billing

Only after an explicit checkout

An immutable offer, its acceptance receipt, and bounded Paddle references are processed only when you deliberately start checkout. Paddle—not Nillow—collects payment-card details. A browser redirect never proves settlement and no payment grants enrollment, entitlement, or runtime authority.

Why we use it

Purpose and permission boundaries.

To provide requested services, respond, secure the system, and meet legal duties.

Project intake is recorded for steps taken at your request before a possible contract and for responding to that request.
Contact authorization permits a response about the submitted project. It does not subscribe you to marketing.
Collaboration membership and invitations are processed only to create the project space and admit the exact account or mailbox selected by the project owner.
Optional marketing, if introduced, requires its own unchecked, versioned, withdrawable control.
Security evidence is kept separate from commercial persuasion and does not grant product or runtime authority.
Google or Apple identity proof is requested only when you choose that sign-in method. The provider subject keeps the connection tied to the exact provider account; it is not used for advertising or behavioral profiling.

Cookies and device storage

Essential storage runs requested features; optional analytics starts off.

Optional audience measurement starts disabled. Rejecting it does not block the website, Portal account access, or project requests. The persistent Privacy Controls button reopens the choice and withdrawal removes the optional local identifier.

Essential

Secure sessions and requested actions

n0_session authenticates a Portal session for up to 12 hours, or 30 days only when Remember Me is selected. n0_passkey_pending binds a passkey ceremony for at most three minutes. When public OXA chat is enabled, nillow_public_oxa_v1 holds an opaque, HttpOnly continuity token for 60 minutes; its project-intent state is encrypted server-side and reset when you clear the chat. Expired chat records are removed on access and by scheduled retention even while public chat is disabled. Requested Portal handoffs may use short-lived session storage. A Google or Apple sign-in uses a short-lived, one-use browser binding and server attempt to validate the provider return and prevent replay. These functions are not used for advertising and cannot be disabled while using the related service.

Optional analytics

First-party, bounded, off by default

When allowed, the HttpOnly n0_privacy_choice cookie presents an opaque choice token to the server, while __n0_funnel_sid_v1 groups the sequence of bounded route and interaction events within one tab. Each permitted event also carries the server-side identifier of the active consent receipt, so events made under the same receipt can be associated across tabs and visits for consent enforcement and retention. These fields do not directly name a person or contain visitor-authored project text. Withdrawal revokes the receipt, clears the cookie, and immediately disables and clears the optional tab identifier in every open same-origin tab.

Installed app

Explicit standalone mobile shell

The first-party service worker and nillow-mobile-brand-v2 cache are created only after the site has been installed and launched as a standalone web app. Ordinary browser visits do not register it.

Nillow currently deploys no advertising cookie, third-party analytics SDK, social pixel, or cross-site behavioral tracker.
The versioned consent choice itself is essential storage: it records what you accepted or refused for 180 days so the site can enforce that decision without asking on every page.
Explicit display and motion preferences are stored only after you use the corresponding control and serve that requested preference.

OXA

Project-intent assistance, not personal profiling or automated judgement.

OXA is allowed to map a project. It is not allowed to map a person into a persuasion target.

Nillow accepts account data and bounded project intent. OXA may organize what a project needs, but it does not decide who a person is, whether they are eligible, or what they can be persuaded to buy.

Analysis posture

Project-intent assistance for human review; not personality, vulnerability, or purchasing-authority profiling.

Decision boundary

No solely automated eligibility, pricing, contracting, or similarly significant decision.

Public chat boundary

Enabled with encrypted continuity for 60 minutes.

When you send a chat message, Nillow projects it through a bounded secret and personal-data membrane before sending the necessary public project context to OpenRouter and an eligible model provider. Pattern detection is not a complete data-loss-prevention system, so do not enter passwords, credentials, or unnecessary personal data.
Public OXA uses explicitly free OpenRouter model variants. The selected model provider may retain submitted project text and may use it under that provider's own data policy, so the chat marks this boundary before you send and must not receive secrets, confidential material, or unnecessary personal data. OpenRouter also processes request metadata. OXA chat receives no private Portal record, company-internal repository, or desktop-runtime authority.
The report may organize stated needs, project constraints, possible capabilities, evidence, uncertainty, and open questions.
It must not infer personality, vulnerability, health, wealth, demographics, emotions, or presumed purchasing authority.
The project report remains reviewable and correctable by a person; an operator decides what happens next.

Processors and retention

Providers receive only the data needed for bounded purposes.

Retention review is a deletion decision point, not permission to keep every field indefinitely.

Commercial intake review

Schedule: 180 days
Policy: nillow-commercial-intake-retention.v1

Audience and security schedules

Audience measurement: 90 days
IP and User-Agent evidence: 30 days, then scrubbed
Security audit record: 365 days
Consent proof: Expiry plus 90 days

Bounded recipients

Authorized Nillow operators review submitted project content. Turso can provide database storage, Resend can deliver a bounded operator alert, and Paddle can process billing after explicit checkout, when those services are configured. OpenRouter and the selected model provider process only a visitor-initiated OXA turn when public chat is enabled. Google or Apple processes the authentication request only when you deliberately choose that provider; each provider also applies its own account and security records under its privacy terms.

Expired sessions, abandoned handoffs, notification artifacts, analytics, and closed commercial records require separate, purpose-bounded schedules.
A provider sign-in attempt expires within five minutes. Its sealed browser proof and return path are deleted when the attempt finishes and expired attempts are removed by bounded maintenance.
An active Google or Apple connection keeps the provider identity needed to recognize the same account. For Apple, a sealed revocation token is kept while the connection is active. On disconnection it is moved into a bounded retry job and destroyed after Apple accepts the revocation.
After disconnection, limited security evidence may remain to prevent unauthorized relinking, investigate abuse, or meet a documented legal obligation. It is not used for advertising or behavioral profiling and remains subject to verified access and erasure review.
Limited billing, fraud, security, or claims evidence may need to be retained where a documented legal obligation or legal hold applies.
Commercial handling can create private operator notes, contact and follow-up evidence, internal quote drafts, and bounded processing receipts. These records follow the commercial retention review; won work requires a separate contract and claims review before disposal.
Deletion must cover the primary database, configured processors, and backup expiry—not only the visible account row.

Your rights

Requests require appropriate identity verification.

Access, correct, delete, restrict, object, or request portability.

Access and portability: use the authenticated account export for bounded commercial submissions, self-scoped Developer metadata, and Library entitlement and download metadata. Request a broader verified copy, including review of shared Project content, from the configured privacy contact.
Correction, restriction, objection, and erasure: contact the configured controller. Identity must be verified before private data is disclosed or removed.
Account Security shows connected Google and Apple sign-in methods and lets you disconnect one when another usable sign-in method remains. Disconnecting disables that sign-in method locally first, then submits and, where necessary, retries revocation of the provider token Nillow retains. The local token copy is destroyed after the provider accepts revocation. This does not delete the Google or Apple account itself; limited security evidence may remain as described above.
A processing-restricted commercial submission remains stored but is withheld from notification delivery and commercial operator handling. Restriction is not erasure.
Erasure may produce a disposition explaining which categories were deleted, anonymized, restricted, or retained under an applicable exception.
You may complain to the data-protection authority for your habitual residence, workplace, or the place of an alleged infringement.

Signed-in users can review relevant controls in the Portal.