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.

Strategy notes, drafts and approved versions

When you add a strategy note, we save your original text, note ID and creation time with your member-owned strategy in Cloudflare D1. Your English or Korean text is not interpreted by a language model. A note does not silently change the structured strategy fields.

We also save the eight manually edited strategy fields, draft revisions, and the approved version snapshots and note references you explicitly confirm. The fields describe your goal, universe, horizon, entries, exits, risk limits, evidence sources and unresolved assumptions. Saving a draft does not change an approved version. The current workspace provides one strategy per member.

This stored strategy content is separate from the temporary six-pattern rule parser and fictional run results described below. The full descriptive strategy is not automatically executable, and no verified mapping to the six demo rules is provided. GPT, current market data, historical event analysis and historical backtesting are not connected. No payment is taken.

Do not put account numbers, secrets, sensitive holdings or personal information in notes or strategy fields. Strategy records have no automatic deletion deadline. You can delete your saved strategy through the confirmed Delete my strategy action in the workspace. Access and correction requests, and account deletion, are handled manually for records under our control.

Strategy mutations keep request UUIDs, strategy IDs, operation types, content hashes, claim/status information and times to prevent duplicate saves. These records do not duplicate your original note text. Separate strategy-save counters are linked to your member ID. Buckets older than about two hours are removed during a later strategy write, not at an exact deletion deadline. This differs from the daily keyed authentication counters described below.

Deleting a strategy removes its original notes, draft fields, approved versions and prior content-hash request records. Minimal deletion identifiers and status/time metadata, including a hash of the deletion request rather than your note or field content, remain until account deletion to prevent delayed requests from recreating the deleted strategy. Deleting your strategy does not delete your member account, independent demo results or feature-interest records.

Separate demo 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 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 account deletion, we remove the member’s strategy notes, drafts, versions, strategy request/deletion metadata and save counters, then account acquisition labels, pending source labels, feature-interest and feature-action records, sessions, pending login tickets and the account record under our control. 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.

Contextual feature clicks and analysis setup actions

When you open a contextual workflow action, we record the click with your member account to help prioritize features. The event row contains your account identifier, random event identifier, feature identifier, workflow surface and timestamp. Cleanup eligibility is calculated from the timestamp and the 30-day retention rule; no separate expiry field is stored. It contains no note text, email address, raw URL or raw IP address. These clicks are distinct from previous optional feature-interest or payment-preference records; a click is not a willingness-to-pay response, marketing consent, a purchase or execution request.

Feature click rows become eligible for cleanup after 30 days. Cleanup occurs on later writes, rather than at a guaranteed scheduled deletion time; a row can remain until a later cleanup opportunity. Deleting a strategy does not delete these separate account-linked click records. An account deletion request includes removal of its feature click records. The interface confirms a record only after a successful server response. We do not infer impressions or conversion rates from these clicks.

Analysis setup forms keep company names, dates, questions and cost assumptions in the current browser tab. These values are not included in action measurement requests. When you attempt to run an analysis, we separately record a run-attempt event; if you then press the payment button, we record a payment-button event. Each row contains the account identifier, feature, stage, workflow surface, random event and attempt identifiers, and server timestamp. The same attempt identifier links its two stages. A repeated network retry uses the same event identifier rather than creating another click. These records are separate from earlier feature clicks and optional payment-preference surveys. They have the same 30-day cleanup eligibility and later-write cleanup timing described above, and are included in account deletion. They do not represent executed analysis, a payment or a reservation. No impression denominator is collected, so the events do not establish a visitor conversion rate.

Sentence-based draft previews arrange exact source quotations in your browser. Applying a preview changes your unsaved draft only. Saving the original note, saving fields and approving a version remain separate actions governed by the strategy storage notice above.