# Public App Receipt Protocol 1.0

## Purpose

The protocol creates a dated, contestable public record for one exact mobile-app release, one device state, one defined service journey and one choice state. It does not certify an application as “safe”, “private”, “GDPR compliant” or “illegal”.

Its core comparison has three independently sourced tracks:

1. what the institution’s policy says;
2. what the app-store declaration says;
3. what the controlled device can be observed doing.

A fourth track records the practical service outcome: whether a resident could complete the public task after refusing an optional choice or permission.

## Scope unit

Every publishable observation must identify:

- app name and package identifier;
- exact app version and APK hash;
- installation source and acquisition time;
- stock or instrumented device lane;
- device model, OS build, locale and network;
- fresh-install, signed-in, refused, accepted or withdrawn state;
- exact scripted journey;
- test start and end times;
- method version;
- number of repetitions;
- known deviations from the script.

The report is never about “the app” in every possible condition. It is about the recorded release and journeys.

## Audit levels

### R0 — catalogue

Public metadata only. No package preservation or runtime claim.

### R1 — core receipt

Minimum publication package:

- exact release preserved and hashed;
- policy and store label preserved and hashed;
- permissions and manifest inventoried;
- static SDK inventory;
- fresh, refused and accepted journeys;
- stock-device and instrumented-device observation;
- at least two runs for every consequential event;
- endpoint attribution review;
- technical second review;
- right of reply.

### R2 — deep receipt

R1 plus, where safe and relevant:

- authenticated journey;
- payment, upload or location function;
- background and relaunch behaviour;
- consent withdrawal;
- account-deletion route;
- language parity;
- narrowly scoped accessibility checks;
- repeat on a second date or device;
- repair retest.

### CAL — calibration

A synthetic or purpose-built scenario used to test the laboratory and interface. It must never be presented as evidence about a real institution.

## App selection

Publish the selection method before testing. Use a matrix rather than suspicion or prominence alone:

- administrative necessity and availability of alternatives;
- sensitivity of the journey;
- probable reach;
- authority exercised by the institution;
- supplier or platform reuse;
- geographic and language coverage;
- technical and ethical feasibility;
- a deliberate calibration group expected to be comparatively consistent.

The sample should contain good, ambiguous and discrepant results. A laboratory that can only produce accusations is not calibrated.

## Documentary preservation

For every release:

1. save the store page as rendered and as structured metadata where available;
2. save the linked privacy policy and any app-specific notice;
3. record redirect chains, access date, language and document title;
4. calculate SHA-256 hashes;
5. preserve screenshots of the store label and in-app choice screens;
6. record whether the policy is app-specific, service-wide or supplier-wide;
7. retain original Romanian clauses beside any English explanation.

Do not silently replace an unavailable historical policy with the current one.

## Device lanes

### Reality lane

Use a stock, non-rooted device representing an ordinary resident:

- clean research account;
- minimal unrelated applications;
- Romanian locale;
- Romanian physical network where the service is location-sensitive;
- no interception certificate;
- screen and interaction recording;
- external or device-level connection metadata where feasible.

Question answered: **What did an ordinary device appear to contact?**

### Inspection lane

Use a matched research-configured device:

- root or equivalent instrumentation only where authorised and necessary;
- TLS interception where technically and legally appropriate;
- Frida or equivalent only to observe the client, not to attack remote systems;
- package-specific flow attribution;
- payload inspection using synthetic values;
- static package analysis.

Question answered: **Can the laboratory associate request contents with a specific app event?**

A behaviour seen only under instrumentation must be narrowed, repeated and checked for instrumentation effects before publication.

## Synthetic resident kit

Never use unsuspecting residents’ traffic. Maintain dedicated research artefacts:

- unique email aliases per app and journey;
- dedicated research telephone numbers;
- synthetic names and free-text tokens;
- controlled test coordinates;
- low-value dedicated payment instruments where approved;
- institution-provided sandbox identities when available.

A unique token supports stronger wording than a generic field name. It still does not by itself establish legal roles, retention or later use.

## Journey script

Each journey has:

- a public-service goal;
- starting device state;
- precise taps and text entries;
- choice and permission state;
- expected stopping condition;
- forbidden actions;
- event markers;
- service outcome;
- reset procedure.

Minimum state sequence where applicable:

1. fresh installation before any optional choice;
2. choice refused;
3. choice accepted;
4. choice withdrawn and app restarted.

Do not grant every permission automatically. The point is to test the resident’s actual choice architecture.

## Runtime collection

Record at minimum:

- timestamp;
- app and journey marker;
- hostname and resolved IP;
- protocol, port and TLS status;
- certificate subject and issuer where available;
- request method and path only when safe to retain;
- request and response sizes;
- response status;
- redacted readable field names;
- exact synthetic tokens, stored separately from raw credentials;
- capture limitations such as pinning or QUIC.

Raw captures are restricted. Public traces are derived, sanitised and minimised.

## Endpoint attribution

Use a provenance hierarchy:

1. institution or supplier documentation;
2. contract, processor list or privacy policy;
3. service documentation or SDK documentation;
4. certificate, DNS and autonomous-system evidence;
5. reputable domain ownership records;
6. technical inference.

Label every relationship as documented, confirmed, observed, inferred, unresolved or disputed. A CDN, cloud region, IP geolocation or shared hostname does not prove an independent recipient or data-residency conclusion.

## Evidence classes and maximum language

| Evidence | Maximum public wording |
|---|---|
| SDK signature found | The tested package contains SDK X. The test did not establish that all its functions were active. |
| Domain connection observed | The tested release contacted X during this journey. |
| Encrypted destination only | The destination was observed; transmitted fields were not established. |
| Readable field category | A request contained device-model information. |
| Exact synthetic token | The request contained the synthetic email or token used only for this test. |
| No connection observed | This connection was not observed in the tested journeys. |
| Infrastructure association inferred | The destination appears associated with X; its role was not independently confirmed. |
| Institution confirms role | The institution identified X as its contracted processor. |
| Repair passes retest | The original behaviour was not reproduced in the stated retest; this is not a guarantee about all future states. |

Prohibited shortcuts include “spies”, “sells data”, “secretly tracks”, “sends everything”, “GDPR compliant” and “illegal” unless a separate, appropriately sourced investigation establishes the precise proposition.

## Classification

Use one or more claim-level classes:

- declared and observed;
- declared but not observed in tested journeys;
- observed but not clearly described;
- store declaration and policy differ;
- destination identified, transmitted fields not established;
- insufficient evidence;
- repair verified.

“Observed but not clearly described” is not a legal conclusion. “Declared but not observed” is not proof that the declaration is false.

## Reproduction threshold

A consequential runtime claim normally requires:

- exact release preserved;
- at least two successful reproductions;
- package attribution established;
- timing aligned with an event marker;
- instrumentation effect considered;
- endpoint attribution manually reviewed;
- second technical reviewer;
- limitation written before the headline;
- right-of-reply notice sent.

Use three clean runs for a verified repair or a claim whose force depends on repeated non-observation.

## Stop conditions

Narrow or withhold a claim when:

- only an automated classifier produced it;
- the release cannot be established;
- traffic cannot be attributed to the app;
- the behaviour occurs only on the instrumented lane;
- shared infrastructure remains unresolved;
- the event cannot be repeated;
- publication would reveal credentials or an exploitable weakness;
- the test would require false emergency use or interference with operational systems;
- the evidence depends on real citizens’ data.

## Service outcome and choice reality

For every deep receipt, record:

- whether the service could be completed without installation;
- whether a web, telephone or in-person alternative was documented;
- whether refusal blocked the core task;
- whether denying a permission produced a usable alternative;
- whether an account was compulsory;
- whether consent could be withdrawn;
- whether the account could be deleted;
- whether the choice, refusal and deletion routes were accessible;
- whether the routes existed in the language of the service.

Do not collapse these facts into a coercion score.

## Right of reply

Send claim-level notices containing:

- release, date, device and journey;
- observed event;
- evidence class;
- proposed public wording;
- stated limitation;
- exact question;
- smallest apparent repair.

Allow a normal response window of ten working days, with extensions for technically complex or security-sensitive issues. This is an editorial practice, not a claimed statutory deadline.

## Repair lifecycle

Statuses:

`documented → sent for response → acknowledged → repair promised → updated → retest due → verified`

Alternative statuses:

`disputed → unable to reproduce → no response → superseded`

Preserve the original result after repair. Display the verified repair prominently. Reward correction without erasing history.

## Retesting

Retest quarterly and after:

- a major release;
- supplier change;
- revised privacy policy;
- new SDK or service endpoint;
- material institutional response;
- security or consent redesign.

## Security boundary

This is a transparency audit, not a vulnerability scanner. Do not:

- brute-force credentials;
- bypass access controls to reach other users’ data;
- probe remote infrastructure beyond ordinary client actions;
- submit false emergency requests;
- exploit a discovered weakness;
- publish secrets or operational details.

Potential vulnerabilities leave the public receipt workflow and enter responsible disclosure.

## Publication package

A public receipt contains:

- plain-language sentence;
- scope header;
- state comparison;
- three-track replay;
- destination cards;
- claim IDs and evidence strength;
- what could not be established;
- institution and supplier responses;
- smallest repair;
- method version and proof-bundle index;
- machine-readable JSON.

Raw captures, credentials, unredacted payloads and exploitable details remain outside the public package.