Security & Privacy
A technical overview of how B.Legal protects client data, isolates firm information, and ensures the integrity of your records.
App Sandbox
What it is
The macOS native app runs inside Apple's App Sandbox, a security mechanism that restricts the application to a declared set of system resources. The sandbox prevents B.Legal from accessing files or system features beyond what it explicitly declares and what you explicitly grant.
How it protects you
- File system isolation. B.Legal can only read and write files within its own sandbox container and files you explicitly grant access to via Open/Save panels (e.g., when uploading documents or choosing a backup folder). It cannot roam your disk.
- Outbound-only network. The app declares the outbound network-client entitlement for its cloud services and integrations (Firestore, Google APIs, Zoom, Sentry, Anthropic, local Ollama). It does not act as a network server.
- Permission-gated capabilities. Features that need deeper access ask for it when you enable them: Full Disk Access for iMessage scanning, Screen Recording for screen capture, Contacts for matching message senders, and the camera for document scanning. Each is a macOS-level permission you can revoke at any time in System Settings.
- Inter-process isolation. The sandbox prevents B.Legal from interacting with other running applications, injecting code, or reading memory from other processes.
What this means in practice
Even if a vulnerability were discovered in B.Legal, the sandbox limits the potential damage. An attacker could not use a B.Legal exploit to access your other files, applications, or accounts. The sandbox is enforced by macOS at the kernel level and cannot be bypassed by the application itself.
Firestore Security Rules
What they are
B.Legal uses Google Cloud Firestore as its primary database. Firestore Security Rules enforce access control at the database level, ensuring that every read and write operation is authorized. These rules run on Google's servers, not on your device, so they cannot be bypassed by a compromised client.
How they protect you
- Multi-tenant isolation. Every document in Firestore belongs to a specific firm (identified by a firm ID). Security rules ensure that users can only read and write documents belonging to their own firm. There is no way for a user at Firm A to access data belonging to Firm B, even if they know the document ID.
- Role-based access. Within a firm, security rules enforce role-based permissions, so what a user can write is checked on the server -- not just hidden in the interface.
- Append-only compliance records. The rules treat compliance-sensitive collections accordingly -- for example, conflict-check and reconciliation records are append-only: they can be created but not rewritten.
Key point
Security rules are the last line of defense. Even if all client-side code were compromised, the Firestore rules would still prevent unauthorized access to another firm's data.
API Hardening
What it is
B.Legal's web API endpoints (used for the AI assistant and server-side operations) are hardened against common attack vectors, with multiple layers ensuring that only legitimate requests are processed.
Protection layers
- Origin validation. API endpoints verify the origin of every request. Requests from unauthorized domains are rejected.
- Rate limiting. Requests are rate-limited per IP address, throttling brute-force and abuse patterns while staying generous for normal use.
- Authentication. Authenticated endpoints require a valid Firebase authentication token. Expired or invalid tokens are rejected.
- PII-sanitized logging. Server logs are scrubbed of personally identifiable information, so request logs do not leak client data.
- Encryption in transit. All API communication is encrypted with TLS.
Sentry Error Monitoring
What it is
B.Legal reports application errors to Sentry so the engineering team can identify and fix issues -- sync failures, authentication errors, backup failures, and the like. The reporting is deliberately narrow: it describes what went wrong in the code, never the content of your practice.
What IS captured
- Error type and stack trace: The technical description of what went wrong and where in the code it occurred.
- Technical context tags: Which operation failed (e.g., which sync collection), without record contents.
- App version and platform: Which version of B.Legal you are running and on which platform (macOS, iOS, web).
What is NOT captured
- Client names, matter names, or case details
- Billing narratives or time entry descriptions
- Trust account balances or transaction details
- Document contents
- Email content, message content, or communication details
- Your name, email, or user identifiers
- AI-generated content or prompts
- Screen capture data
Key point
Sentry error reports contain no client-identifiable information and no privileged content. The reports are purely technical diagnostic data.
Encrypted Backups
What it is
On macOS, B.Legal automatically backs up the local database after changes, using the SQLite Online Backup API for transaction-consistent snapshots. Each backup is AES-encrypted with a key held in your Mac's Keychain -- not by B.Legal -- and older automatic backups are pruned so the set stays bounded.
How it works
- Automatic local backups. The Mac app takes consistent, encrypted snapshots of the local database automatically as you work.
- Device-held encryption key. The backup encryption key lives in your Mac's Keychain. Backups are deliberately non-portable to other machines -- a copied backup file is useless without your Keychain.
- Manual backup to any folder. Create a backup to a location you choose (e.g., an external drive) from the app on macOS.
- Safe restore. Restoring from a backup first snapshots the live database to a safety copy, so a restore can itself be undone.
- Cloud sync as the off-machine copy. Your synced data lives in Firestore, so a lost or stolen laptop does not mean lost records -- sign in on another device and your synced data is there.
Tips
- For a portable, human-readable copy of your data, use the export tools (CSV/JSON, and PDF for trust records) -- exports are independent of the encrypted backup system.
- Keep FileVault enabled on your Mac for full-disk protection underneath the app-level encryption.
Update Signing (EdDSA)
What it is
Every macOS app update is cryptographically signed using EdDSA (Edwards-curve Digital Signature Algorithm). The Sparkle update framework verifies this signature before applying any update, ensuring that the update was published by B.Legal and has not been tampered with in transit.
How it protects you
- Authenticity. The EdDSA public key is embedded in the app at build time. Every update package includes a corresponding signature. If the signature does not match, the update is rejected and not installed.
- Integrity. The signature covers the entire update payload. Any modification to the update file (even a single byte) invalidates the signature and prevents installation.
- Notarized releases. Releases are notarized DMGs, so macOS Gatekeeper independently verifies them as well.
Key point
EdDSA (Ed25519) is the same signature algorithm used by Signal, SSH, and other security-critical applications. It provides strong authentication without the overhead and complexity of traditional certificate chains.
Data Isolation Between Firms
What it is
B.Legal is a multi-tenant system where each firm's data is logically isolated from every other firm's data. This isolation is enforced at the database level through Firestore Security Rules and at the application level through firm-scoped queries.
How isolation works
- Firm ID scoping. Every document in the database includes a firm ID field. All queries are automatically scoped to the authenticated user's firm ID. There is no global query that returns data across firms.
- Security rule enforcement. Firestore Security Rules verify the firm ID on every read and write operation. A user authenticated for Firm A is blocked from reading or writing any document belonging to Firm B, regardless of the query or document path.
- No cross-firm data sharing. There is no feature in B.Legal that shares data between firms. Each firm is a completely independent tenant.
- User-to-firm binding. Each user account is bound to a single firm, preventing accidental cross-firm data access.
Authentication & Access
What it covers
B.Legal uses Firebase Authentication for user identity. Accounts sign in with email and password, with secure password reset by email, and the native apps offer biometric unlock so your session is protected without storing your password.
Security features
- Biometric unlock. On macOS (Touch ID) and iOS (Face ID), biometric authentication gates your saved session. Your password is never stored on the device.
- Fail-closed deactivation. Deactivated accounts are rejected at sign-in -- a removed team member loses access immediately.
- Role-based permissions. Users carry roles within their firm, and Firestore rules enforce what each role can write on the server side.
- Secure credential storage. API keys and tokens on the native apps are stored in the system Keychain, not in plain files.
Tips
- Use a long, unique password managed by a password manager -- it remains the root of your account's security.
- Enable biometric unlock on the native apps; it protects the saved session and lets you open your local data quickly.
- If a device is lost, change your password promptly and contact support to review the account.
Security questions or concerns?
For security inquiries, vendor questionnaires, or to report a vulnerability, contact our security team.