Privacy Policy

alink gives you a contact point you control. Visitors use your al.ink link to explain who they are and why they are reaching out. Rules and AI triage then route the request to your inbox.

Our revenue comes from subscriptions. We do not sell personal data, run ads, or use third-party cross-site tracking.

This policy explains what data we collect, why, how it is stored and protected, how long it is retained, and the rights you have. It covers three groups of people:

1. Data we collect

We follow data minimization: we only collect what is necessary to provide the service, and sensitive content is always stored encrypted.

1.1 Account and identity data (users)

• Login email: used for magic-link sign-in, account recovery and service notices.
• Passkey credentials: we store only the public key and credential metadata. Your biometrics (fingerprint, face) never leave your device and we cannot access them.
• Recovery code: we store only an irreversible hash; the plaintext is shown to you exactly once when generated.
• xid and handle: the xid is your system-generated permanent identifier; a custom handle is a display alias you choose to bind.
• Display name, avatar and other public profile fields: filled in by you.

alink has no passwords, so we store none.

1.2 Card page and Contact Contract (users)

• Public card fields: you decide what to publish, with four visibility levels (public / link_only / network / private). Before publishing you can preview as an external visitor — the preview matches exactly what outsiders see.
• Intents: the "what I am looking for" statements you choose to publish, shown according to the visibility you select — link_only / public intents appear on your card page and in your principal document (the public API response) as information you have deliberately made public. Intents expire and are taken down automatically; you can pause, complete or delete them at any time. Public intents are displayed — and will be searchable in a future directory — ordered by time and relevance, never by payment.
• Contact Contract: your declared allowed/blocked request types, topics, required context fields, auto-reply tone, response-time commitments and similar settings. Contracts are versioned for audit traceability.

1.3 Request data submitted by requesters

When a requester submits through a card page form, we collect:

• Self-declared name, organization, role, and a verifiable link (LinkedIn / GitHub / homepage);
• A reply email (its ownership is confirmed when you first enter the in-site conversation — the entry link is only ever sent to this address);
• Your interface language at submission (used to localize the notices we send you, and as the default language when your account is opened automatically — see Section 7.1);
• Subject, body, and the context fields the receiver's Contact Contract requires (for example deck link, stage and traction for a pitch);
• A self-declared referrer (recorded only, not verified);
• Consent state at submission: AI-processing acknowledgment and data-retention acknowledgment (both required);
• Once your request is accepted, the messages you exchange with the receiver in the in-site conversation (stored encrypted, visible only to the two of you);
• Anti-abuse metadata: IP reputation, submission frequency, honeypot signals. Used solely for abuse prevention and never shown to any user.

1.4 Relationship and contact records (users, encrypted)

When a request is approved, the system drafts a relationship record (source, topic, outcome); you can also record contact details and interaction notes yourself. This data:

• is your private notebook, encrypted per user (see Section 4) and visible only to you;
• is never searchable by others, never used for cross-user inference, and never forms any global social graph;
• is redacted of sensitive fields before any semantic search index is generated;
• can be deleted item by item at any time — deletion also purges the corresponding search index and ciphertext.

1.5 Audit events

Every gateway decision, approval, consent change, subscription change and administrative action on your account is written to an audit log chained by hashes, so the log cannot be silently tampered with. Administrators' own actions are separately audited.

1.6 Billing data

• Payments are handled on Stripe-hosted checkout pages — we never touch or store your card number (PCI SAQ-A boundary).
• We keep a projection of subscription state (tier, period, status) and billing event receipts for entitlement computation and reconciliation.

1.7 Referral attribution data

Your card page and identity link double as your referral link. When a visitor clicks through to signup, we record the source xid via an attribution cookie valid for 30 days. Rules:

• Referrers never see who signed up through them — only aggregate statistics and achievement counts; statistics that map to a referee's action dates are disclosed only up to the previous calendar week, preventing time-correlation inference;
• Referees can see in settings that they signed up via a referral link, with this explanation;
• When a referee deletes their account, the attribution record is immediately anonymized with an irreversible hash;
• Referral conversion counts never enter gateway decisions — nobody's request is filtered differently because of who referred them.

1.8 Usage and operational data

• Metering such as AI triage counts and quota usage (visible to you in settings);
• Email deliverability data: unsubscribe records and a local suppression mirror of hard bounces and complaints (30-day lifetime);
• Technical logs necessary to operate the service.

1.9 Visitor conversation data (card page AI assistant)

Visitors can converse asynchronously with the owner's AI assistant on a card page; the conversation entrance carries an explicit acknowledgment of AI processing and data retention, and the conversation only starts after it is confirmed. Rules for this data:

• Conversation transcripts are stored encrypted and short-term — hard-deleted within 30 days (scheduled sweep);
• The owner cannot see the conversation transcript — the transcript serves the anti-abuse audit process only (for example, sampled review for assistant-overreach detection). An assistant that speaks for you must not double as a wiretap on your visitors;
• In the conversation the assistant uses only what the card page has already made public (the public profile — including any public Q&A (FAQ) the owner wrote for the assistant — public intents, the behavioral boundary declared by the Contact Contract) — there is no code path by which private data can enter the conversation;
• Every assistant reply carries a fixed AI identity label and a "this is not a commitment by the person" footer, which cannot be turned off;
• If the visitor confirms submitting a structured request in the conversation, that request is handled under Section 1.3 "Request data submitted by requesters" — the transcript does not travel with the request into the receiver's Inbox; only the structured content the visitor confirmed does.

1.10 Encounter signals

We count "encounter" signals on card pages: visits, intent views, conversations started, submissions, and conversations started but abandoned without submitting. What is counted, and how deeply, is identical for every visitor and independent of the owner's paid tier — payment only affects how much detail the owner gets to see. Rules:

• Anonymous visitors are counted, never identified: aggregate counts contain only a referral-channel category (direct / QR / social / search etc.), the UTC hour bucket, and the request category (the structured request's type enum), plus the assistant conversation's question category (a fixed enum — pricing / availability / background / media / scheduling / collaboration / other — with an answered/unanswered flag; the fixed enum guarantees never request bodies or conversation content, and it is never linked to a visitor identity);
• When a signed-in alink user visits someone else's card page, their identity (display name and handle) is visible to the owner by default — this default is disclosed here, in this policy and in the Terms of Service; the "stealth visit" switch lives in Console → Account & security → "Incognito browsing", can be changed at any time, and is an account-level preference: set it once and it applies to every card page you visit afterwards, reversible at any time (see Section 6);
• In stealth mode only the anonymous aggregate counts are incremented; no identity is recorded;
• We never do reverse-IP lookups, browser fingerprinting, or company/organization identification, and never sell or provide visitor-identity inference to owners (IP hashes serve only the existing anti-abuse rate limiting and never enter signals);
• Signals are visible only to the owner of that card page;
• Retention is a rolling window (see Section 5): anonymous aggregate counts 366 days, identity events of signed-in non-stealth visitors 90 days, cleaned up automatically on expiry;
• Deletion: when an owner deletes their account, all their signal data is deleted with it; when a visitor deletes their account, their identity events are deleted immediately from all owners' dashboards (anonymous aggregates never contained their identity, so nothing remains to handle).

1.11 File locker data

• Files: stored privately and available only through short-lived signed links. They are not shown on public pages or made available to AI models;
• Delivery records: recipient source, download count, and expiry. We do not record reading time, opening location, or forwarding behavior;
• Recipient declarations: fields such as name, organization, email, and purpose are encrypted in the file owner's account and follow the same retention period as request data;
• Withdrawal: the owner may withdraw a link at any time. A short-lived URL already issued may take a few minutes to expire.

1.12 Organization and collaboration data

Users may create organizations, invite members, and join collaborations as themselves or as an organization. Organizations process member data; alink hosts that data.

• Organization profile: name, purpose, public visibility, and published intents;
• Member roster: account identifier, membership status, role, and permissions. The roster is visible only to members. Publishing a member's name requires separate approval from the organization and that member;
• Organization audit records: who acted, on whose behalf, whether AI was involved, and the relevant authorization;
• Collaboration records: decisions, commitments, deliveries, and outcomes shared by the parties;
• Shared context: information one party gives to named readers. It is encrypted and future access ends when it is withdrawn.

Responsibility: for rosters, organization audit records, and collaboration records, the organization and its controllers decide the purpose of processing; alink hosts the data under their instructions. By creating an organization, you confirm that you may process invitees' data and will meet applicable notice and rights-request duties.

Members may leave, export their own records, inspect their permissions, and refuse public attribution. An organization cannot remove these rights.

Organizations cannot access a member's private account data. An organization agent can use only the organization's public profile and authorized seat data. A member's relationship records, inbox, and private files are not added to the organization context.

2. Purposes and legal bases

We will not use your data for: sale or rental to any third party, advertising, cross-site tracking profiles, training general-purpose AI models, or any form of "social credit scoring".

3. AI processing disclosure

AI is how alink works, and we do not water down our disclosure duties:

1. Disclosed before submission: requesters see a non-skippable AI disclosure ("your request will first be processed by an AI assistant") and must acknowledge it before submitting.
2. AI never impersonates a human: any reply generated and sent automatically by AI carries a clear AI identity label.
3. Explainable decisions: every AI triage outcome (approve / decline / needs more context / needs human review) comes with a human-readable reason stating which Contact Contract rule it matched or missed. No black-box verdicts.
4. Humans make the final call: high-stakes actions such as approving a request or granting agent authority always require human confirmation; AI cannot substitute.
5. Misfire protection: AI can be wrong. A built-in guardrail suspends auto-decline for an account whose false-rejection rate exceeds the threshold, downgrading to "archive + visible in the daily digest"; declined requests can be overturned.
6. Where processing happens: triage inference runs on our infrastructure provider (Cloudflare Workers AI); request content is treated as untrusted data and isolated from system instructions to resist injection attacks.
7. No training: we do not use user or requester content to train AI models.
8. Card page conversations are equally transparent: the conversation entrance carries a non-skippable acknowledgment of AI processing and data retention; every assistant reply carries an AI identity label and a "this is not a commitment by the person" footer that cannot be turned off; the assistant uses only what the card page has made public, and the owner cannot see the transcript (Section 1.9).

4. Data security

• Per-user envelope encryption: each user has an individual data-encryption key (DEK); sensitive data (contacts, relationship memory, raw logs, export bundles) is stored encrypted under it. DEKs are themselves encrypted under a master key and support rotation.
• Minimal plaintext residency: decryption happens only transiently at runtime after the policy engine allows it, and plaintext never lands in logs. Administrators and internal tools cannot view your sensitive plaintext.
• Cryptographic erasure: deleting your account destroys your DEK, rendering ciphertext in backups and historical snapshots permanently unreadable (see Section 6).
• Passwordless authentication: passkey-first with email magic links as fallback, eliminating credential stuffing and weak passwords; high-stakes operations (handle rebinding, account deletion, materially loosening a contract, granting a delegate seat, full export) require step-up re-verification; login-email changes take effect after a 7-day delay with notices to both old and new addresses.
• Verifiable audit: hash-chained audit log plus separately audited administrative actions (Section 1.5).
• Infrastructure: the service runs on Cloudflare's global edge network (Workers, Durable Objects, D1, KV, R2); daily encrypted snapshots are additionally stored with an independent object-storage provider as cold backup.
• Email content minimization: notification emails contain summaries and a login link only — never request bodies or sensitive fields — so a compromised mailbox does not leak your Inbox contents.

5. Data retention

Data past its retention period enters the deletion queue and is cleaned up automatically.

6. Your rights (users)

• Access and rectification: view and edit your profile, contracts and relationship records in-product at any time.
• Export: start a full export from the "Data & Revocation" page. The bundle contains contracts, relationships, requests, and the audit chain with its verification proof; export is not tiered — it always contains all data within retention.
• Deletion: start account deletion from the "Data & Revocation" page. The process:
  1. a 7-day cooling-off period, cancelable at any time;
  2. then cryptographic erasure — your data-encryption key is destroyed and entity data plus vector indexes are deleted across stores; ciphertext in historical backups becomes permanently unreadable once the key is gone;
  3. exceptions: billing data is retained as required by law (Section 5); audit-chain events are kept per the compliance floor; your custom handle enters a 90-day cooldown rather than being released immediately (so "delete to free the name" cannot be abused by squatters);
  4. your xid is never recycled, but it points to no data after deletion.
• Consent withdrawal: agent authority (ConsentGrant) can be revoked instantly; any single relationship record can be deleted.
• Stealth visits: when you visit someone else's card page while signed in, your identity (display name and handle) is visible to the owner by default — that default is disclosed here. The switch is in Console → Account & security → Incognito browsing, changeable at any time; it is a persistent account-level preference — set it once and it applies to every card page you visit from then on, and you can switch back anytime. In stealth mode you are counted only in anonymous aggregates and no identity is recorded (Section 1.10).
• Unsubscribe: all notification emails carry RFC 8058 one-click unsubscribe; transactional security emails (such as account-recovery confirmations) are exempt.
• Complaints: contact us anytime via Section 11. You may also complain to the Hong Kong Privacy Commissioner for Personal Data (PCPD); EU/UK users may complain to their local data protection authority.

7. Rights of non-users

7.1 Requesters

Conversing with the owner's AI assistant (before submitting)

• The card page conversation entrance first asks you to acknowledge the AI-processing and data-retention policy; the conversation starts only after you confirm.
• Conversation transcripts are stored encrypted for no more than 30 days (Section 1.9), and the owner cannot see the transcript; only a structured request you explicitly confirm in the conversation reaches the owner's Inbox.
• You may at any time ask us, via the channels in Section 11, to delete personal information you provided in a conversation.

Submitting and tracking

• After submitting you receive an unguessable, read-only status link showing only coarse-grained progress — it never echoes what you submitted, and it expires with the request's retention period. Keep it safe: when a request is declined, the graceful reply is shown on this status page too (we send no decline emails).
• The receipt states the retention period and the deletion-request channel; you may ask us to delete the personal information you submitted at any time.
• Your request data is visible only to the target receiver; we never use it for any purpose of other users.

After acceptance: the in-site conversation and your automatic account

• When your request is accepted we send the only email of the request's lifecycle to your reply address: the release notice with the conversation entry link. The entry link is your personal credential; if lost, request a re-send from your status page (rate-limited) — it only ever goes to the reply address you submitted, and the previous link stops working.
• Entering the conversation for the first time automatically opens your alink account, created from the name, reply email and interface language you submitted, and signs you in on that device. The release email discloses this in advance; entering the conversation proves your ownership of the reply mailbox with the same strength as a magic-link signup.
• An automatically opened account has exactly the same rights as a self-registered one: use it to manage conversations and publish your own card page, or delete it anytime on the Data & Revocation page (with cryptographic erasure, see Section 6).
• If your reply email already has an alink account, we only link the conversation to it — holding the entry link never signs anyone into that account; signing in always requires the real login ceremony.
• Conversation messages are stored encrypted and visible only to the two participants.

7.2 Contacts recorded by users

Users' relationship records are private notes: encrypted by default, never externally searchable, never used for cross-user inference. If you believe an alink user's records contain your personal information and you want it deleted, contact us via Section 11 — we provide a response process.

7.3 Event guests (organizer-created cards)

• Before being claimed, a card defaults to link-only visibility with a noindex tag (never in search engines or any public directory) and is clearly labeled "created by the organizer, awaiting claim by the person";
• Claiming is entirely voluntary; cards unclaimed 60 days after the event are automatically taken offline and their data deleted.

8. Cookies

alink uses functional cookies only — no third-party tracking, advertising or cross-site analytics cookies:

9. Processors and international transfers

We use only the following third parties to process your data, each under data-processing terms:

The operating entity is in Hong Kong, with the Hong Kong Personal Data (Privacy) Ordinance (PDPO) as our compliance baseline. The service runs on Cloudflare's global edge network, so your data may be processed outside your jurisdiction. For EU/UK users we honor the GDPR's extraterritorial provisions (Art. 3(2)), using Standard Contractual Clauses (SCCs) or equivalent safeguards for cross-border transfers.

10. Minors

alink is built for working professionals and is not directed at children under 16. Registration requires being at least 18 (see the Terms of Service). If we learn we have collected a minor's personal data, we will delete it promptly.

11. Contact us

• Email: [email protected] (for privacy and data requests — export, deletion, non-user deletion requests — put "Privacy" in the subject; for security reports put "Security")
• Operating entity: Yiwen AI Limited (億文智能有限公司), a private company limited by shares incorporated in Hong Kong; the registered address is available on request and via the Hong Kong Companies Registry.

12. Changes to this policy

This policy may evolve with the product. Material changes (new data categories, changed purposes or processors) will be announced at least 14 days in advance by email or in-product notice; other revisions update this page with a new effective date. Continued use of the service constitutes acceptance.

Language versions: this policy is authored in Chinese; this English text is a convenience translation. Unless stated otherwise, the Chinese version prevails.