Security Policy

1Security approach

Ohlim designs authentication, authorization, data operations and administrative access around server-side controls. Safeguards are reviewed as the service changes, but this Policy is not a certification, warranty or guarantee against every incident.

2Data in transit

Production application traffic is served over HTTPS behind the configured reverse proxy. Service credentials belong in restricted server configuration and are not intentionally exposed in client code or user-facing errors. Ohlim does not claim that all stored data is end-to-end encrypted or encrypted at rest to a particular certified standard.

3Authentication

Ohlim uses configured OAuth providers and does not maintain a separate user-password database. Google is supported when configured; Apple is available only where credentials are configured and the option is displayed. Production sessions use protected cookies, and mobile sign-in uses short-lived, one-time server-managed handoffs.

A package ID, User-Agent, custom header or device claim alone is not treated as proof of an official app. Signing out of Ohlim does not end the underlying Google or Apple account session.

4Sessions and revocation

Protected requests require a current server-recognized session identifier and account session generation. A user can end the current session, a selected session, or all Ohlim web and mobile sessions; revoked sessions are rejected server-side. Legacy tokens without the required claims are not accepted.

5Authorization and isolation

Server-side authentication, ownership and role checks scope account, diary, nutrition, file and health operations to the authenticated user. Administrative functions use separate role checks, and authorized personnel may access only information needed to operate, secure, support or moderate the service. Inputs and uploaded files are bounded and validated where handled.

6Health Connect controls

On Android, Ohlim requests only the Health Connect read permissions required for steps, weight, active calories and sleep. Users can stop synchronization, manage Android permissions and separately delete imported server data. Server deletion is not the same as revoking an OS permission on an offline or unavailable device, so the application reports the two results separately.

7Deletion and export controls

Authenticated export creates a bounded ZIP through a temporary server file, excludes credentials and internal anti-abuse secrets, and cleans up the temporary archive after streaming. Account deletion uses an explicit confirmation, locks account mutations, revokes sessions, removes private database records and known owned files through restricted storage roots, and supports retry after partial filesystem failure. Approved shared catalogue content may remain only without account attribution.

8Operational controls

Relevant authentication, administrative, moderation, deletion and security actions create audit or security events. Selected endpoints use rate limits, and deployment checks include automated tests and dependency/build validation. Infrastructure access and network exposure are intended to be restricted to operational need. Operational backups may support recovery, but recovery from every event without loss or delay is not guaranteed.

9What users can do

Protect the Google or Apple account used for sign-in, keep the device and operating system current, use a screen lock, review Ohlim sessions, and sign out after using a shared device. Treat exported ZIP files and screenshots carefully because they may contain sensitive nutrition or health information. If compromise is suspected, secure the OAuth account, end Ohlim sessions where possible and contact support.

10Vulnerability reporting and limitations

Use the public security contact form to describe the affected feature, reproducible steps and likely impact. Attachments are not accepted. Include only the minimum evidence; never send passwords, tokens, another person's records or unnecessary personal data. Act in good faith, avoid privacy violations, service disruption, destructive testing and premature disclosure. Ohlim does not currently promise a bug bounty or response SLA.

Third-party providers, operating systems and devices have their own controls and limitations. Ohlim may take protective action during an investigation, but absolute security cannot be guaranteed. Version 1.6 is effective 2026-09-06. Ohlim is operated under the Ohlim name. Legal, privacy and security inquiries may be submitted through the public Ohlim contact form.