Data Minimization in Flowo Under PIPEDA and GDPR

What the two laws ask for

PIPEDA and the GDPR both limit collection to what a stated purpose needs. PIPEDA's fair information principles include Limiting Collection, principle 4.4 in Schedule 1 of the Act, which restricts collection to what is necessary for the purposes the organization has identified. Article 5(1)(c) of the GDPR requires personal data to be adequate, relevant and limited to what is necessary, and Article 25 asks for data protection by design and by default.

Neither text names a field or a table. An engineering team has to turn the principle into a list: which values exist, where each one lives, and which purpose needs it. The rest of this article is that list for Flowo.

A registry of every local store

Flowo keeps an inventory of its on-device storage in one class, ProtectedDataRegistry. It lists 24 Hive stores, from tasks and the timeline to the consent ledger and the audit log.

Each entry declares seven things: a classification, whether encryption is required, a retention policy, whether the store is eligible for export, what erasure does to it, a backup policy and an owning module. All 24 entries require encryption, and all 24 prohibit backup.

Export and erasure read this list directly. The export covers the 21 stores marked eligible. The three it leaves out are internal app metadata, the audit log and the compliance metadata. A test asserts that the set of boxes the erase flow deletes equals the registry's erasable stores.

We keep a single list because a second one drifted. A comment in the compliance configuration records that an older hardcoded list fell out of step with the boxes the app opened, and it warns against bringing that list back.

What the backend knows about an install

Flowo has no account, so the backend's knowledge of a person is one device record. The record holds a random UUID, the platform, the plan, the times the install was first and last seen, a revoked flag, the attestation key and its counter, and the expiry and last event of a paid plan.

It holds no name, email address or phone number, because the app never asks for one. The partition key in the table is a SHA-256 digest of the identifier.

Usage is metered with one counter per install, per request family and per UTC day. Each counter carries an expiry timestamp set two days after its reset. The backend has no table for tasks, notes or schedules, a point our article on local-first storage covers in more detail.

What each cloud request carries

A cloud AI request in Flowo carries the item it is about and the settings needed to answer in the right language. The request models on the server show the fields.

• Estimate a task: the title and optional notes.
• Break a task down: the title, the estimate in milliseconds, optional notes, the number of subtasks wanted and the interface language.
• Draft the first plan: a description of the week limited to 4,000 characters, the locale and the time zone. A correction to a draft is limited to 1,000 characters.
• Word the reminders: for each upcoming slot, the task identifier, title and start time, plus the time zone name and the language.
• Tidy the braindump: the current groups, the ungrouped items and the language.

The reminder request is the only one in this list that the person does not start by hand, so it has a remote switch and an optional time horizon. A slot that is skipped uses fallback wording that is already on the phone.

The server logs sizes where it logs anything about content. The onboarding route logs the length of the description in characters, and the braindump route logs how many items and groups arrived. The line written for every request holds a request id, the method, the path, the status and the duration.

Purposes and the basis recorded for each

Every use of data in Flowo is attached to a named purpose, and the consent ledger stores the lawful basis next to each decision. The current purposes are essential storage, analytics, session replay, voice upload and cloud AI.

Three of them can be withdrawn at runtime: analytics, session replay and voice upload. Essential storage and cloud AI are shown as explanations, since neither rests on consent. Voice upload is the one AI purpose that stays a consent, because a recording carries whatever the person happened to say.

The age rule shows the same thinking. The terms require a person to be 16 or older. The app records a confirmation as its own ledger entry with the basis eligibility_confirmation, and it collects no date of birth. A birth date would answer the question and then remain in storage with no further use.

Two purposes retired in consent version 2, crash reports and personalization, are still defined as identifiers. Ledger entries written by older builds therefore still resolve to a known purpose.

Data the platform offers that we decline

Both mobile platforms make far more data available than a planner needs, so part of minimization is leaving permissions out of the manifest. On iOS, Flowo declares four usage descriptions: camera, microphone, photo library read and photo library add. The Android manifest requests the camera and the microphone for the same features. Neither build requests location or contacts.

The photo library description states that selected media is stored locally inside Flowo. Captured media lives in a folder in the app's own documents directory.

Android's backup system is switched off in two places. The application sets allowBackup to false, and the data extraction rules exclude the whole app directory from both cloud backup and device-to-device transfer.

The analytics SDK is configured the same way. IP address, carrier, device model and advertising identifier collection are off, and the device check behind our test filter reduces the hardware information to one boolean.

What minimization costs us

Collecting less has costs, and we carry them knowingly. With no account there is nothing to restore a plan from, and nothing to sign in to on a second phone.

Support is harder too. Our data rights page says that BBMM Technologies may be unable to match an app installation after its local identity has been erased. A request about records we do hold goes by email to the Privacy Officer, and the page asks people to leave task text and identity documents out of that email.

We also know less about where the app is used. With IP collection off, the country shown in our analytics comes from the store storefront or the device region.