Play declares in-app search history as shared but not collected

[simonoppowa]

What the public record shows

Read from play.google.com/store/apps/datasafety?id=com.opennutritracker.ont.opennutritracker on 2026-09-05:

Shared	In-app search history — App functionality
Collected	Approximate location; Crash logs; Diagnostics — no search history

Google's two definitions are not independent:

"Collect" means transmitting data from your app off a user's device.

"Sharing" refers to transferring user data collected from your app to a third party.

Sharing is defined over collected data. So "shared but not collected" is not a state the framework has a name for, and the search term is unambiguously transmitted — to Open Food Facts (a third party) and to the Supabase backend.

Two readings, and the public page cannot tell them apart

A — the collection answer is wrong. Collected was answered No for a type the app transmits. That is an under-declaration, and Play's own guidance makes it the expensive kind of mistake.

B — it is marked ephemeral, and the page is behaving correctly. Google:

Processing data "ephemerally" means accessing and using it while the data is only stored in memory and retained for no longer than necessary to service the specific request in real-time.

Ephemeral data must be declared in the form but is not displayed in the public section. So collected = Yes + ephemeral = Yes renders exactly as observed, while sharing still shows.

Only the Console distinguishes them, which is why this is filed as a question rather than as a defect. If it is B, the record is already correct as entered and this closes with the reasoning written down.

Why B is worth a second look rather than a shrug

The ephemeral claim is easy to justify for the Supabase leg. #882 made backend access RPC-only precisely so the term travels in a POST body and stays out of the gateway log, which holds only the caller's IP for 24 hours. Nothing retains the search term.

It is much harder to justify for the Open Food Facts leg, and that is the leg the sharing entry is about. Ephemeral is a claim about what the recipient does with the data, and Open Food Facts is a third party whose retention this project cannot warrant. docs/ai-legal-constraints.md already reaches that conclusion for the AI providers, in terms that apply here unchanged:

Do not rely on this. You cannot warrant the retention behaviour of an endpoint the user chose.

The AI providers at least publish retention policies. This is the same argument with less to go on.

What to do

1. Open the Data safety form and read what In-app search history actually says for Collected and Processed ephemerally. That settles A versus B in one look.
2. If A, set Collected = Yes, purpose App functionality, and decide optional — a search is core functionality and cannot be turned off, so Required is the likely answer.
3. If B, decide whether the ephemeral marking is defensible for the Open Food Facts leg specifically. If it is not, unmark it and let the type appear publicly.
4. Either way, record the reasoning here. The next person reading the public page will see the same apparent contradiction and re-derive this from scratch otherwise.

Scope

Deliberately not part of #1050, which is the AI feature's two new types and is ready to enter as it stands. This is an older declaration about a different code path, found while verifying that one. Fixing it silently inside #1050 would have buried a decision that deserves its own record.

Acceptance criteria

• The form's actual answers for In-app search history are read and recorded here
• Collected and Processed ephemerally are correct for both the Open Food Facts and the Supabase legs, judged separately
• The reasoning is written down, so the public page's shape stops looking like an error to the next reader

Blocked by

None. Independent of #1050 and of any release.