One page for data handling and product security.

What Focuslock keeps on device

• Session labels entered by the user.
• Session duration, interruption count, score, completion timestamp, and completion status.
• Streak information, including current streak count and last qualifying session date.
• Saved duration presets created or reordered by the user.

Core product functionality only

This information is used to run the timer, calculate session results, display history, maintain streaks, and remember preferred preset durations. In the current codebase, these features work without requiring an account.

Local-first implementation

The analyzed release uses on-device app storage to save sessions, streak state, and presets. The app does not currently implement remote user databases or cloud synchronization for this information.

No account profile required

Based on the current implementation, Focuslock does not ask for a name, email address, phone number, mailing address, payment information, contact list, or precise location to provide its core timer and history features.

Small attack surface by design

Because the current version does not rely on a multi-user backend, a cloud session database, or account credentials, it avoids many common internet-facing risks associated with account takeover, API abuse, and remote exfiltration of session records.

How the live session behaves

During a running session, the app keeps the screen awake and tracks app state changes so it can count interruptions when the app is backgrounded or becomes inactive. This behavior supports the core product function and is not a remote monitoring system.

No routine third-party sharing in this release

The current implementation does not include a feature that routinely sends stored session history, streak data, or preset durations to third parties. Data remains on the device until removed by the app or deleted when the app is uninstalled.

Device-level access still matters

Local storage is not the same as zero risk. If a device is compromised, lost while unlocked, or accessed by someone with sufficient privileges, locally stored data may still be exposed. Security outcomes therefore depend in part on the phone’s own operating system protections and access controls.