Security

01Encryption in transit

All traffic between your browser or device and TailJournal is encrypted using TLS 1.2 or higher, with TLS 1.3 negotiated wherever the client supports it. We do not accept unencrypted HTTP connections: requests to the plain-HTTP endpoint are redirected to HTTPS, and the application is served with HTTP Strict Transport Security (HSTS) so that compliant browsers refuse to connect over an unencrypted channel after their first visit.

Connections terminate at managed load balancers and edge nodes that maintain modern cipher suites and forward secrecy. Internal service-to-service traffic within our infrastructure — for example, between the application layer and the database, cache, and background workers — travels over private networking and, where it crosses a trust boundary, is itself encrypted in transit. Outbound calls to broker and market-data APIs are likewise made over TLS, and certificates are validated on every connection.

02Encryption at rest

Data stored by TailJournal is encrypted at rest. Our primary databases, object storage, backups, and log stores reside on managed infrastructure where volume-level encryption is applied using AES-256 or an equivalent industry-standard cipher, with encryption keys managed by the underlying cloud provider’s key-management service.

At-rest encryption protects against a specific class of risk — the theft or improper disposal of physical media and the exposure of raw storage volumes. It is a baseline, not a complete defense, which is why we layer additional application-level encryption over the most sensitive fields (described in the next section) and enforce strict access controls over the systems that can read decrypted data.

03Application-layer encryption of broker tokens

Broker access tokens, OAuth refresh tokens, and scoped API keys are the most sensitive secrets we hold, because they are the keys that let our background jobs read your account activity. These are not protected by disk encryption alone. Before such a credential is written to the database it is encrypted a second time at the application layer using authenticated symmetric encryption (AES-256-GCM), under a key that is held in a dedicated secrets manager and is never stored alongside the data it protects.

In practice this means a database backup or a leaked storage volume does not, on its own, yield usable broker credentials: the ciphertext is meaningless without the separately held encryption key. Decryption happens only inside the running application, only for the specific job that needs to call a broker on your behalf, and the plaintext token exists only transiently in memory for the duration of that call. Encryption keys are rotated on a defined schedule, and the scheme supports re-encrypting stored credentials under a new key without exposing plaintext.

04Passwords and credential hygiene

We never store account passwords in plaintext, and we cannot recover or display your password to you or to ourselves. When you set or change a password it is hashed using bcrypt with a per-password salt and a deliberately high work factor, and only the resulting hash is persisted. Verifying a login compares hashes; the original password is never reconstructed.

Bcrypt is intentionally slow, which makes large-scale offline guessing expensive for an attacker who somehow obtained the hash store. We enforce minimum password-strength requirements at sign-up and on reset, screen against well-known compromised passwords, and rate-limit authentication attempts to blunt credential-stuffing and brute-force attacks. We encourage every user to choose a unique password not reused on any other site, or to sign in with Google so that no password is held by us at all.

05Authentication

You can authenticate to TailJournal either with an email address and password or through Google OAuth. With email sign-up we require email verification before an account is fully active, which confirms control of the address and reduces fraudulent and mistyped registrations. With Google we receive a verified identity assertion and a minimal profile scope; we never receive or store your Google password.

Password resets are handled through single-use, time-limited tokens delivered to your verified email address. A reset link expires after a short window and is invalidated once used, and initiating a reset does not, by itself, lock you out of an active session unless you complete it. Wherever a security-relevant change occurs — a password change, a new sign-in method, or an email change — we notify the account owner.

Sessions are represented by signed, tamper-evident tokens with bounded lifetimes. Session cookies are issued with Secure, HttpOnly, and SameSite attributes so that they are sent only over HTTPS, are not readable by client-side scripts, and are resistant to cross-site request forgery. Sessions can be revoked — by you, by signing out, or by us in response to a credential change or suspected compromise — and revocation takes effect server-side rather than relying on the client to discard the token.

06Authorization and data isolation

Every record in TailJournal — every trade, account connection, note, and report — is owned by a single user account, and every request that reads or writes data is authorized against the identity of the authenticated session. Authorization is enforced on the server for each operation; the client interface never decides what you are allowed to see. A request for a resource you do not own is rejected, and our data-access layer scopes queries to the requesting user by default so that omitting a check fails closed rather than leaking data.

This per-user isolation is the core boundary of the product. It means one customer cannot enumerate, read, or modify another customer’s journal, and it is exercised continuously by automated tests that assert cross-account requests are denied. Where TailJournal offers shared or team features, access is granted explicitly through membership and roles, and the same server-side checks apply to every shared object.

07Internal access, least privilege, and audit logging

Access to production systems and customer data by TailJournal personnel is restricted to the small number of staff who require it to operate and support the service, and is granted on a least-privilege basis. Administrative access requires strong, individually attributed authentication with multi-factor authentication, and standing access to production datastores is minimized in favor of scoped, time-bounded, and reviewed access.

Privileged actions — administrative logins, access to customer records in support tooling, configuration changes, and data exports — are recorded in audit logs that capture who did what and when. These logs are retained, protected from casual modification, and reviewed as part of our monitoring. We do not read the contents of your journal except where strictly necessary to provide support you have requested, to maintain the integrity and security of the service, or to comply with a legal obligation.

08Infrastructure and availability

TailJournal runs on established, managed cloud infrastructure operated by providers that maintain recognized third-party attestations such as SOC 2 and ISO 27001 for the physical and environmental security of their data centers. We do not operate our own physical hardware; we build on top of these providers and inherit their controls for facility access, hardware lifecycle, and environmental safeguards, while remaining responsible for the security of everything we configure and run on top.

Environments are isolated: development, staging, and production are separated, and production data is not copied into lower environments for routine development. Backups of production databases are taken on a regular schedule, encrypted, and retained for a defined window to support recovery from corruption or accidental loss, and restoration is periodically exercised so that backups are known to be usable rather than merely present.

09Broker credential handling

TailJournal connects to your brokerage to import trade activity, and it does so with the least access necessary. Wherever a broker supports it, we connect through OAuth or through scoped, read-only API keys that permit us to read account and trade data but not to place, modify, or cancel orders and not to move funds. We ask only for the scopes the journal needs.

We never ask for, never want, and never store your broker login password. When a broker’s integration is OAuth-based, authentication happens on the broker’s own site and we receive only a delegated token; when it is key-based, you generate a scoped key in your broker’s portal and provide it to us. In both cases the resulting secret is protected by the application-layer encryption described above. You can revoke a broker connection from TailJournal at any time, and revoking it from the broker’s side immediately stops our access as well.

10Monitoring and incident response

We operate logging, metrics, and alerting across the application and infrastructure to detect errors, abnormal traffic, and indicators of abuse or compromise. Authentication anomalies, rate-limit breaches, and unexpected access patterns generate alerts that route to on-call staff, and security-relevant events are retained for investigation.

We maintain an incident-response process that defines how suspected incidents are triaged, contained, investigated, and remediated, with defined roles and escalation paths. In the event of a confirmed security incident affecting customer data, we will investigate promptly, take steps to contain and remediate it, and notify affected users and any applicable authorities in accordance with our legal and contractual obligations and within the timeframes those obligations require. Post-incident, we conduct reviews to address root causes and reduce the likelihood of recurrence.

11Secure development lifecycle

Security is built into how we ship software rather than bolted on afterward. Changes go through version control and peer code review before reaching production, automated tests run on every change, and secrets are kept out of source code and injected at runtime from a managed secrets store. We keep dependencies current and monitor them for known vulnerabilities through automated scanning, prioritizing and patching issues according to severity.

We follow established practices to defend against common web-application risks — parameterized queries and an ORM to prevent injection, output encoding and content-security controls to mitigate cross-site scripting, anti-CSRF protections on state-changing requests, and consistent server-side authorization on every endpoint. Production deployments are automated and repeatable, which reduces configuration drift and makes it straightforward to roll a fix forward quickly.

12Responsible disclosure

We welcome reports from security researchers and customers who discover potential vulnerabilities in TailJournal. If you believe you have found a security issue, please email security@tradrtrades.com with enough detail to reproduce it — affected URLs or endpoints, a description of the issue, and any proof-of-concept steps. We aim to acknowledge reports within approximately two business days and will work with you on validation and remediation, keeping you informed of progress.

We ask that you act in good faith: investigate only against your own account, avoid accessing or modifying other users’ data, avoid degrading the service for others, and give us a reasonable opportunity to remediate before any public disclosure. Researchers who follow these guidelines will not face legal action from us for their good-faith research, and we are happy to credit those who responsibly disclose valid issues.

13Your data: ownership, export, and deletion

Your trading data is yours. We process it to provide the journal and analytics you have asked for; we do not sell it. You can export your journal data in a portable format at any time, so that you are never locked into the platform and always hold your own copy of your records.

You can delete individual records or close your account entirely. When you delete your account we remove or irreversibly anonymize your personal data and revoke any associated broker connections, subject to limited, defined retention where we are legally required to keep certain records or need to retain minimal information to resolve disputes, prevent abuse, or maintain financial and security logs. Encrypted backups age out on the retention schedule described above and are then purged, after which recovery is no longer possible. If you have a specific question about what we hold or a request relating to your data, contact us and we will respond in line with our Privacy Policy and applicable law.