Account &
workspace privacy.

Google, password and email-link sign-in

You can sign in with Google or an email and password when these methods are enabled. Firebase Authentication, provided by Google, handles the Google sign-in and password creation, verification and reset. Passwords are sent directly from your browser to Firebase, not to our workspace API, and are not stored in our application database. A password account can open a workspace before its email is verified; this does not confirm ownership of that email.

For Firebase sign-ins, Cloudflare D1 stores a workspace member ID and the Firebase project and user identifiers, permitted sign-in method, email address, email-verification status, account-creation or explicit-connection source, notice version and authentication-request time, and creation/update times. Our backend verifies Firebase ID tokens for protected workspace requests. We do not save the raw ID tokens or copy a name, avatar or Google profile into our workspace database. The Firebase SDK and Google may process account and profile information according to their own policies. We do not request access to Gmail, Drive, brokerage accounts or market data.

Existing email-link accounts can use an already issued link or a contextual recovery/connection flow; email-link signup is not shown in the ordinary account form: Resend sends the requested one-time authentication email, and Cloudflare processes it. Open the link in the browser where you requested it and explicitly confirm sign-in. An email-link account is created after verification. Workspaces are not silently joined based on matching email addresses. Connecting a new Google or password sign-in to an existing workspace requires an explicit choice, matching email addresses, and proof of both sign-ins from the last five minutes. When the current and new sign-ins are both Firebase methods, both email addresses must be verified. A recent email-link sign-in can connect a new same-email password sign-in before that password account’s email is verified. If the connection fails, the page attempts to restore the original Firebase sign-in or clear the new sign-in; it reports when the original sign-in must be repeated.

We use these records to authenticate and manage your workspace. The account form shows this notice before authentication. Choosing an account action requests authentication; it is not a claim that you have read or accepted this notice, and it is not marketing consent. Strategy-note storage still requires its separate notice agreement. No payment information is collected by these sign-in methods.

Account entry source labels

When you request an email sign-in link or create a Firebase-linked workspace, we can keep supported source, medium, campaign and content codes and an optional supported ad code. These are browser-supplied URL labels, not verified Meta attribution. Your browser keeps an allowlisted first-entry marker for this tab, including an unknown source marker. That entry marker does not contain an email address, raw URL or click identifier.

Supported labels are recorded only when a new workspace member is created, with the member ID and recording time. For password accounts, this can happen before email verification; an acquisition label does not prove email ownership. Without supported labels, no account acquisition label is recorded. Later sign-ins and explicit connections to an existing workspace do not add or overwrite this record. We do not reconstruct earlier ad visits or combine it with a Meta/Instagram lead record. We use the labels to understand account entry sources; they do not establish unique people, marketing consent or an advertising conversion verified by Meta.

Temporary email-link source records follow the 15-minute verification-ticket lifetime. Expired records are removed during a later sign-in request, not by a guaranteed scheduled deletion. Account acquisition labels have no automatic deletion deadline and are handled with account records under the retention and deletion choices below.

Browser authentication, cookies and sign-in records

Firebase sign-in uses its standard browser-session persistence. The SDK keeps authentication state in browser session storage so it can survive same-tab navigation and reloads; closing the window or tab session clears this state according to browser behavior. We do not put your password in browser storage. This provider-managed authentication state is separate from the allowlisted tab-entry marker and from strategy notes stored in Cloudflare D1. Signing out attempts to clear the Firebase state in this browser and revoke the current workspace session. The page reports when either step cannot be confirmed.

We use secure, HttpOnly workspace cookies. Email-link sessions last up to seven days. A Firebase-linked workspace session lasts at most one hour and is capped by the ID token’s expiry at sign-in. The Firebase SDK can refresh its ID token, but that does not extend this workspace session automatically; after it expires, return to sign-in to establish a new workspace session. For Firebase-linked sessions, the cookie alone does not authorize protected API access: a valid, freshly obtained Firebase ID token is also required. Our application stores hashed session secrets and bounded Firebase session metadata, not raw ID tokens. A short-lived, single-use bootstrap cookie and proof protect Firebase sign-in or explicit connection requests.

The email-link option uses a 15-minute browser-flow cookie. Email links are single-use and expire after 15 minutes. The database stores hashes of email-link tokens, browser-flow values and session secrets rather than their raw values. A demo rule confirmation is bound to your session and expires after 15 minutes. Expired records become unusable and are removed during later sign-in requests rather than at a guaranteed scheduled deletion time.

Your rules and fictional results

The rule text you submit is sent to our server for temporary processing by a bounded English/Korean parser. A server-side deterministic calculator applies the confirmed settings to fixed fictional scenarios. No language model, historical backtest, connected market-data service or brokerage is called.

Rule text and generated results are not saved in our application database. The member page keeps your text, interpretation and up to two results in this tab’s memory. It clears them when you sign out or the account changes. It does not read or attach the earlier anonymous browser example’s saved data to your account. Exporting JSON saves a copy on your device; that file remains under your control.

Do not enter account numbers, credentials, private holdings or other sensitive personal information in the rules. Ordinary hosting providers may separately process request and network metadata to provide and protect the service.

Optional feature interest

If you register interest in a planned feature, we store your member ID, the selected feature, your optional payment-interest choice and creation/update times in Cloudflare D1. There is one record per account and feature; a later selection updates it.

This feedback helps us understand feature demand. A willingness-to-pay selection is nonbinding. It is not a payment, purchase, reservation, subscription or guarantee of availability. Prices are not set, and no payment is taken. Interest registration does not opt you into unrelated marketing.

Providers, operator access and abuse prevention

Our South Korea-based operator may access workspace account and activity records to administer the service and respond to privacy requests. Cloudflare hosts the workspace and its application database, Firebase Authentication handles enabled Google and password sign-ins and password-reset emails, and Resend handles the separate email-link sign-in emails. These providers use distributed infrastructure; processing may occur in multiple countries. We do not promise storage or processing in one country. Firebase and Google processing is also described in Firebase privacy information and Google’s privacy policy.

To limit abuse, we store short-lived counters keyed with daily keyed hashes of network or account rate scopes. Raw IP addresses are not stored in those application counters. Providers may separately keep operational, authentication and delivery metadata, including network information. We do not claim that provider logs or backups contain no personal data.

Retention and your choices

Member accounts, account acquisition labels and feature-interest records have no automatic deletion deadline. We keep records we control while administering your account and feedback, or until you request deletion. To request access, correction or deletion, contact oralab.team@gmail.com and say that your request concerns a workspace member account. We may need to verify control of your workspace account and, where relevant, your email.

Requests are handled manually. For an account-deletion request, we manually remove the associated account acquisition labels, interests, workspace sessions, pending sign-in records, managed identity connections and account record under our control. Strategy records and retained click telemetry are handled through the separate strategy-storage notice and account-deletion procedure. Firebase authentication data must also be handled separately through the provider; deleting a strategy alone does not delete a Firebase account or revoke its credentials. Provider operational or backup retention may differ; we do not promise to delete records outside our control.

Separate from early-access requests

Member records are separate from the website access-request and Meta/Instagram lead forms. Earlier requests do not automatically create a member account, and this account does not enroll you in their marketing consent. Their collection is described in the access-request privacy notice.