BloomScroll legal

Privacy Policy

This policy explains what happens to your data in the BloomScroll website, Android app, local demo, and authenticated cloud account.

Effective date: October 7, 2026

The short version: the browser demo stays local. Before Android sign-in, the share target keeps only a canonical public URL on that installation; it discards the shared caption and title and does not upload the capture. Authenticated capture and sync use BloomScroll's Cloudflare services. AI extraction and optional learning transforms send relevant source text and platform context to Gemini models through standard Google Cloud Vertex AI. YouTube processing uses public captions or transcript-panel text; without usable transcript text it stops before calling Vertex AI. For an eligible Reddit video, the backend temporarily fetches the exact public Reddit-hosted video and optional audio MP4 under strict limits and sends them inline in one Vertex request per processing attempt. For an eligible direct Facebook Reel, it temporarily fetches only the strictly identity-bound public SD MP4 under strict limits and sends that video inline in one Vertex request. In both media paths, the model analyzes speech, on-screen text, and visible action; Facebook descriptions, titles, comments, surrounding feed text, and engagement metadata are not provider input or evidence.

1. Who is responsible

BloomScroll is operated by Tom Cool. For privacy questions or rights requests, email tom@cool.dev.

2. Local demo mode

The local demo does not create a cloud account. Demo items, preferences, and learning progress are stored in this browser only and are not synchronized to BloomScroll's database. They remain on this device until you clear them in the app or remove this site's browser data.

The local demo is separate from authenticated capture. If you choose to sign in and submit a real link for extraction, the cloud processing described below applies.

3. Android sharing before sign-in

When you send text to BloomScroll from the Android share sheet while signed out, the app looks locally for a valid public HTTPS link and stores only its canonical URL. It does not retain the surrounding caption, prose, or shared title. Duplicate URLs collapse, and this ownerless pending queue is bounded to 20 captures.

In the secure v4 Android app, pending captures are kept in private noBackupFilesDir storage on that installation. They are not uploaded before sign-in. Import requires an explicit approval for the current pending entries. The first authenticated account that claims that approved import becomes its only permitted owner; a different account cannot resume it, and captures added after approval are not silently included.

These signed-out captures are not linked to a BloomScroll account, so deleting an account does not delete them. A pending URL leaves this storage when the app removes it after import or rejection, when Android app data is cleared, or when BloomScroll is uninstalled.

4. Ownerless data from an older Android version

If an installation is upgraded from the ownerless v1 prototype, BloomScroll moves the old local identifier, URL, title, and original date into a device-only Room table named legacy_unverified and records when the migration occurred. It discards the old generated-looking output. This quarantine is not trusted knowledge, is not uploaded, and is not assigned to the next or any other account that signs in.

The quarantine survives sign-out and app upgrades. It remains until an Android account-deletion flow on that installation runs its local-cleanup step, Android app data is cleared, or BloomScroll is uninstalled. Because no account ownership can be proven, that local cleanup is device-wide: deleting any account through the Android app clears the entire legacy_unverified quarantine on that installation, including entries that were not created by the deleted account. This wipe does not establish that the deleted account owned those entries. A web account deletion cannot reach this device-only table.

5. Information used for an authenticated account

6. Android storage and background sync

After sign-in, the secure v4 Android app keeps an owner-scoped Room database so capture survives restarts and weak connectivity. It can contain saved knowledge and its canonical URL, title, folder, tags, status, source text, provenance, generated knowledge and variants, plus a synchronization outbox with URLs, optional titles or source text, server identifiers, error state, attempt counters, and timestamps.

The secure v4 app stores the native session token together with its owner and expiry as one encrypted record protected with the Android Keystore. Its session file is excluded from Android backup. Owner-scoped background sync is scheduled only when Android reports a network connection; it sends queued capture or source data to the BloomScroll API and may continue after you leave the app.

Backup behavior differs by Android version. The distributed BloomScroll 1.0.1 release (version code 2) was compiled with allowBackup=true. Its backup_rules included every database and shared-preference domain. Its data_extraction_rules did the same for cloud backup and omitted a device-transfer section, which left device-to-device transfer fully enabled. Data that 1.0.1 stored in those areas could therefore be copied by Android into the user's personal Google Account backup and transferred to another device. The BloomScroll developer cannot access that personal cloud copy.

The secure v4 candidate sets allowBackup=false and contains all-domain exclusions for both cloud backup and device-to-device transfer. Those controls prevent v4 app data from entering those Android backup paths, but v4 cannot retroactively inspect or delete a historical Android- or Google-managed backup created by 1.0.1. The user controls that personal backup through Android and Google Account settings and can contact BloomScroll support for help understanding the distinction.

A completed sign-out in secure v4 removes the local encrypted session, requests revocation of the server session, asks Android's Google credential provider to clear its sign-in state, and requests cancellation of that owner's scheduled sync. It does not erase that owner's local Room knowledge cache or unsynchronized outbox; those remain owner-scoped on the device so the same account can resume later.

7. How the service uses data

BloomScroll uses account data to authenticate you, synchronize your library, generate structured learning material, enforce fair-use limits, support data-access requests and deletion, prevent abuse, moderate reported generated results, and maintain the service. An authorized moderator may inspect the linked private item only as needed to understand a report; submitting a report does not publish the item. The closed beta has no advertising or analytics SDK and contains no ads. BloomScroll does not sell or rent personal data and does not use it for targeted advertising.

8. Cloudflare, Google Cloud Vertex AI, and Google authentication

These providers may process data outside your country. Their contractual safeguards and privacy terms govern their processing. BloomScroll does not claim that provider logs or backups disappear instantly when an app record is deleted.

For an eligible public Instagram Reel or TikTok video, the backend also verifies the exact page and clip identity and temporarily fetches only its public MP4 from the validated platform CDN. These clips are limited to 8 MiB and 120 seconds, require a verified MP4 duration, and are sent inline to the same standard EU Vertex AI provider in one request per processing attempt. Descriptions, captions surrounding the post, comments, feed text, and engagement metadata are not provider input or evidence for these video paths. The model analyzes the actual speech, on-screen text, and visible actions. Only explicitly labelled AI-derived observations and provenance are saved, never raw media or signed media URLs. No platform login cookies are sent by the backend. If public acquisition is blocked or validation fails, processing stops before calling Vertex; BloomScroll does not substitute the description for the video.

9. Legal grounds

Where the General Data Protection Regulation applies, BloomScroll processes data to provide the service you request, for legitimate interests such as security and reliability, to comply with legal obligations, and with consent where consent is required.

10. Retention

Local demo data remains in your browser until you clear it. Signed-out secure-v4 Android captures follow the device-only lifecycle in section 3. The ownerless v1 quarantine follows the separate, device-wide lifecycle in section 4. The secure-v4 Android Room cache and outbox remain on that installation after logout until the same owner successfully completes the in-app deletion and local-cleanup flow, Android app data is cleared, or BloomScroll is uninstalled. A personal Android/Google backup previously created from distributed version 1.0.1 follows the user's Google Account and Android backup settings; BloomScroll cannot access it or promise that account deletion will remove it. Synchronized account data is kept while your account is active and until it is deleted or no longer needed for the purposes above. A generated-result report is deleted with its linked item and when its account is deleted.

Reddit, Facebook, Instagram and TikTok media bytes are request-transient: BloomScroll does not intentionally write the raw MP4, audio/video bytes, their base64 representation, or temporary signed media URLs to D1, browser storage, Android storage, application logs, or BloomScroll backups. Google and Cloudflare may still process request and network data under their own terms. Operational logs, abuse-prevention records, and provider backups may remain for limited periods under Cloudflare's and Google's retention schedules or where law requires retention. BloomScroll does not promise a fixed deletion time for independent provider logs or backups.

11. Export, correction, and deletion

The closed beta does not yet include a self-service export button. You can request access to, correction of, or an exportable portable copy of your account data by emailing tom@cool.dev from your account address.

To permanently delete an authenticated account and its associated BloomScroll cloud records, use Delete account inside the signed-in Android app or the account deletion page while signed in on the web. After the Android app sends a deletion request, it removes that owner's local Room knowledge and outbox when the server confirms deletion. If the network outcome becomes unknowable after dispatch, it also removes the local owner data rather than reopening a possibly deleted account, but reports the cloud deletion as unconfirmed. If the app cannot prove local cleanup, it reports a failure instead of claiming that cleanup succeeded.

A web deletion cannot directly erase storage on another Android installation. Neither web deletion nor secure-v4 local cleanup can retroactively erase a personal Android/Google backup created by distributed version 1.0.1; the user must manage that historical copy through Android or Google Account backup controls. If you delete on the web and cannot reopen the Android deletion flow, clear BloomScroll's Android app data or uninstall it to remove the remaining local cache and ownerless v1 quarantine. Local demo data and the ownerless pending captures described in section 3 must also be cleared separately because they are not associated with the deleted account. By contrast, when any account deletion inside the Android app reaches local cleanup, it clears the installation-wide legacy_unverified quarantine described in section 4 as well as the deleted owner's Room data. You may also object to or restrict certain processing and lodge a complaint with your local data-protection authority.

12. Security

BloomScroll uses HTTPS, restricted server-side credentials, access controls, and release checks intended to protect data. No online service can guarantee absolute security. Please report a suspected security issue to tom@cool.dev.

13. Age requirement and policy changes

BloomScroll is currently intended only for people aged 18 or older as a closed-beta product and safety restriction. We may update this policy when the service or its providers change. The effective date at the top will show the latest published version.