1. Responsibility and scope
Bud Apps is an independently operated project based in Norway. The actual responsible controller, publishable operator identification and a working private privacy contact remain to be confirmed. This draft does not invent a registered company, address or representative. These details are required before publication as an effective policy.
This notice distinguishes visitors to the public website, account holders using the online Web Portal and users of LiftBud Android. Android and the Web Portal remain review software. Practices vary by installed app version, enabled feature and provider test-account eligibility.
The statements below describe inspected implementations and known limitations. Bud Core supplies the shared account and training records for Android and the website. The browser uses protected cookies for its own session; signing in on the website does not create a separate website copy of an existing LiftBud account. Provider account conflicts require explicit linking after authentication.
2. Visiting the public website
Public information and legal pages can be read without an account or a working Bud Core connection. The site uses locally served assets, system fonts and a locally hosted Google button font. This candidate adds no advertising, behavioral analytics, tracking pixels, session replay, external font requests, embedded video or service worker.
A web server necessarily receives technical request information such as an IP address, requested URL and browser information to deliver pages. Infrastructure may produce access or error logs. The operator must confirm actual logging configuration, recipients and retention; no anonymous-only logging claim is made.
Simply reading the public information and legal pages does not activate provider sign-in SDKs. Browser storage and provider requests associated with opening an authentication or account-connection page, or selecting a provider, are described separately below. No cosmetic cookie-consent banner is used as a substitute for controlling optional technology.
3. Account, profile and training data
Depending on the features you use, the service processes:
- Account email, password hash for password accounts, creation/update timestamps, session state and configured Google or Facebook identity identifiers. Provider sign-in can supply verified identity information such as name and email.
- Profile information such as display name, username, discoverability, profile image, preferred units, training goal, experience, rest preference, training days and session duration. The profile model also supports optional date of birth, height and body weight where supplied by a supported client.
- Programs, Routines, selected Exercises, set and rep targets, planning notes, active/favorite status, visibility and source attribution for copied Programs.
- Workout sessions, exercise order, recorded sets, repetitions, weight, set type, RPE/RIR where supplied, notes, completion times and feeling ratings. Progress and personal records are derived from completed training.
- Bud relationships/requests, profile and Social search, posts, comments, likes, attached workout references and uploaded Social images. Direct-message records include participants, message text, sender and sent/read timestamps; notifications include the recipient, actor, related content and read state.
- AI program questionnaire answers, including goal, experience, days, duration, equipment and optional focus/exclusion text; generation proposals; and accepted Programs.
- Technical error and diagnostic information produced by current app and infrastructure features, potentially including request timing, device model, Android/app version and service status. Diagnostics are not a promise that no identifying information can ever appear in a log.
4. Sources and purposes
Most information comes from you when you register, set preferences, log training, upload content, send messages or request generation. Providers supply sign-in identity data. Other users supply messages, Bud requests and interactions involving your account. The service derives progress summaries and records from completed sets.
Account information enables authentication and account access. Profile and training records let you plan, log, retrieve and review your own activity. Social information lets the service find discoverable people, deliver supported posts and messages to their permitted audiences, manage relationships and show notifications. Public Program information enables discovery and independent copying.
Optional generation processes the questionnaire you submit to propose a Program, saved after you accept it. Technical information supports delivery, security, diagnosing failures and maintaining the service. Any additional purpose requires its own assessment and disclosure; the content-operation license is not permission for unrelated advertising or AI training.
5. Legal bases and sensitive information
The following mapping is proposed for legal review, not a claim that all processing has an approved basis. Necessary account administration, requested training functions, communications and generation may rely on performance of the requested service under GDPR Article 6(1)(b). Each purpose must be limited to what is actually necessary.
Proportionate security and abuse prevention may rely on Article 6(1)(f) only after an appropriate legitimate-interest assessment. A specific legal preservation requirement may rely on Article 6(1)(c). Optional storage or processing that requires consent must have a valid choice and an effective withdrawal mechanism before activation. Clicking an upload or provider button does not supply blanket GDPR consent.
Training, body metrics, feelings and free-text entries may reveal health information in context. The operator needs qualified assessment of whether particular uses require an Article 9 condition in addition to an Article 6 basis, extra safeguards or a data-protection impact assessment. No implemented explicit health-data consent flow is claimed here. A fitness disclaimer does not settle that question.
7. Infrastructure, providers and optional AI
Bud Core stores canonical account, training and Social records in PostgreSQL-compatible infrastructure. Profile and Social image uploads use server-managed filesystem storage with database references. Public API traffic uses an HTTPS reverse proxy. The actual hosting entities, processor roles and agreements need confirmation before publication.
Configured Google and Facebook sign-in connect to those providers. Google website sign-in sends a short-lived authorization code to Bud Core, which exchanges it directly with Google and verifies the returned identity token using the existing account rules. The resulting Google access and refresh tokens are not retained or used to access other Google services. Google account linking still uses the existing identity-token flow, and Facebook uses its existing access-token verification. Provider services and policies apply to their processing. The website does not intentionally persist provider codes or tokens. The resulting Bud session has its own lifetime and revocation rules, separate from provider credentials.
The inspected AI arrangement sends the bounded questionnaire and curated exercise list from Bud Core to a loopback-only model service on the server host. This implemented configuration does not send this generation data to OpenAI or another hosted AI service. The coding assistant used during software development is separate; this policy does not infer a product provider from it.
Bud Core validates proposals before an accepted Program is saved. A fake provider is restricted to tests; separately, normal generation can use a deterministic fallback after invalid model proposals. An unavailable local service can return an error. The model does not write directly to the database. A provider or hosting change needs a fresh disclosure and legal assessment.
8. Browser storage and sign-in choices
The Web Portal removes legacy Bud credentials from sessionStorage and localStorage. Bud Core sets an encrypted session cookie and a separate short-lived sign-in challenge cookie on api.getbudapps.com. Both are Secure, HttpOnly, SameSite=Lax and restricted to that host. Website JavaScript receives a CSRF proof and safe account information, not Bud access tokens, refresh tokens or session identifiers. Those credentials are not stored in browser Web Storage. Earlier website versions used a different session design.
The sign-in challenge expires on the server after 20 minutes. Browser sessions follow the existing Core 30-day foreground-inactivity window and 15-minute access lifetime; renewal alone does not count as foreground activity. Remember me requests a persistent cookie bounded by the server's inactivity expiry; otherwise a browser-session cookie is used. Browser restore settings can affect local cookie retention, while server expiry and revocation remain authoritative. Origin and CSRF checks protect account requests, and logout revokes the website session and expires its cookies. Logging out does not delete account or training records. The website has no offline edit queue or shared cache of private API responses; account and private-media requests use no-store handling. Previously retained copies and provider-managed storage have separate lifecycles.
When a page displays an available Google sign-in or account-connection control, Google's SDK loads as that page opens, before you select the button. Sign-in and registration use a locally rendered generic button; account linking retains Google's rendered button. Loading can contact Google but does not itself open an account chooser, select an account or sign you in. Selecting the sign-in button starts Google's supported account-selection popup and code exchange described above. Facebook's SDK loads when its sign-in action is selected and is initialized without its optional cookie feature. Provider codes and credentials pass transiently through the applicable verification flow without being saved in website storage. Provider-controlled storage and processing still require their own assessment.
There are no active provider controls when their public configuration is absent. Required account storage and the requested Remember me choice need individual assessment under Norwegian rules on storing or accessing terminal information. Any optional provider technology outside the narrow necessary-service exemption must have appropriate prior consent and a comparably easy refusal/withdrawal path before publication; this draft does not certify that assessment.
9. Android, server and offline storage
Server records and uploaded images are separate from the Android working copy. Supported Android candidate builds keep account-scoped cached profile, Program, Routine, History and workout-draft data, Social pages, Buds, comments, recent messages and notifications. A local outbox holds supported pending operations with timestamps, retry/conflict state and payloads.
Structured offline payloads use Android Keystore-backed encryption, and session/account selection uses protected local storage. This is not a claim that every database metadata field or image file is encrypted. App-private cached profile and Social media files are not separately file-encrypted by the inspected cache implementation.
Supported pending edits may synchronize during foreground use, after reconnecting or through scheduled background work. A local edit awaiting synchronization has not yet been acknowledged by Bud Core. Synchronization is still being stabilized; not every feature works offline and automatic successful replay or conflict resolution is not guaranteed.
Remote deletion and visibility changes cannot be detected instantly while disconnected. Signing out locks account access and cancels that account's synchronization, but retained caches and pending work are not securely erased merely by logout. Reauthentication and supported account access are distinct from deletion.
The Android 0.12.2 recovery candidate excludes app preferences and its device-key-encrypted offline database from Android cloud backup and device transfer. Older builds permitted these copies; other app files and existing backups have separate lifecycles. If session or account preferences cannot be authenticated with their encryption key, the candidate retains the unreadable encrypted files on the device and creates fresh encrypted storage. Signing in again may be required. This does not recover data whose original key is unavailable, erase old copies or guarantee transfer of unsynchronized work. Recovery-selection metadata stays in Android's no-backup storage; retained unreadable preferences have no automatic expiry. Actual platform behavior and backup erasure still need review.
10. Retention, deletion and export
The operator has not yet implemented or documented a complete retention schedule. The criteria below describe relevant record lifecycles and unresolved decisions; they are not invented time limits.
Account and training records support the user's ongoing service history. Owner actions can remove particular Programs, Routines, images and Social content. Completed workout history can remain when its original planning structure is removed. Whole-account deletion and export are not currently self-service features; a private request process and enforceable retention criteria must be supplied.
Copied Programs belong to the recipient and can retain narrow source attribution. Direct messages, notifications and related metadata require separate retention/deletion decisions. Removing a Bud relationship or provider identity is not whole-account erasure.
Android caches and pending/conflicted edits can remain after logout. Their removal must account for unsynchronized work and disconnected devices. Legacy browser credentials can remain in an older client's Web Storage until removed. The current web client clears its legacy keys and clears its in-memory account view after logout or account changes. Its cookies are subject to server-enforced expiry and revocation as described above. Clearing browser storage does not remove Bud Core records.
AI questionnaire answers and proposals have no dedicated database table in the inspected design. Accepted Programs are ordinary account data. Temporary memory, client caches and operational logs are separate; the absence of a table is not a claim that no temporary copy exists. Raw questionnaire prompts are not intentionally logged by the inspected generation flow.
Operational logs, uploads, server backups and device backups require documented access, rotation, deletion and restoration policies. No enforced deadline is claimed until the operator confirms and implements it. Uninstalling the app does not delete server data or necessarily erase every backup. Independent copies and legal preservation obligations can require a separate assessment.
11. International transfers
The location and legal role of every hosting, authentication and backup provider must be documented. Google, Facebook or other infrastructure arrangements may involve processing outside Norway or the EEA. The server-local AI design alone does not establish that the entire service stays in one country.
Where GDPR Chapter V applies, the operator must identify the actual transfer route, safeguards and any supplementary measures. This draft does not claim a particular hosting region, adequacy decision, standard contractual clauses or other safeguard that has not been verified. These remain publication requirements.
12. Security and diagnostics
Implemented safeguards include password hashing, authenticated owner-scoped routes, validation, HTTPS for the public API and efforts to sanitize diagnostics. Some Android structured offline data is encrypted as described above. Uploaded media and other storage have different controls.
No system is perfectly secure. This draft claims no certification, end-to-end message encryption, blanket encryption at rest or guaranteed erasure. Private information should not be placed in public support threads. Operational access, incidents, backup security and retention require an accountable operator process.
13. Choices, rights and complaints
Depending on applicable law and the processing basis, you may have rights of access, correction, erasure, restriction, objection and data portability, and a right to withdraw consent for processing that relies on it. Withdrawal does not make earlier lawful processing unlawful. These rights exist even when an app button is missing.
Profile and certain content can be edited or removed through existing owner controls. Disconnecting sign-in, logging out or uninstalling does not erase the Bud account. A real private contact and process for other rights requests, proportionate identity verification and timely responses remain required before publication.
If you already have a verified private contact for the project, use that channel. Do not submit passwords, account details, private training/health data or privacy requests to public issue threads. The missing dedicated public privacy channel is an unresolved gap, not a restriction on your rights.
You may complain to Datatilsynet in Norway or another competent data-protection authority. The authority's channel is separate from Bud's own contact.
14. Children and eligibility
LiftBud is not currently designed or intentionally offered as a children's service. A minimum product age, guardian requirements and any age-assurance process have not been approved. No age-verification or parental-consent tooling is claimed.
The operator must assess the relevant Norwegian/EEA rules for the actual training and Social uses before broader availability. A statutory consent age is not automatically the product's minimum age. Do not supply a child's personal data without confirming that the intended use is lawful and appropriate.
15. Changes, contact and review status
Material changes to features, purposes, audiences, providers, storage or retention require updated information and an appropriate way to bring the changes to users' attention. That notification process and any new effective date must be approved; a date change alone is not sufficient.
This review draft was substantively revised on 22 September 2026 (revision 3), based on the published baseline of 18 August 2026 and the earlier September drafts. Complete operator/private-contact information and professional legal review remain outstanding. The substantive edits are proposals for review, not a claim of legal approval or a new effective policy.