| Document version | 1.0 |
| Date | 24 February 2026 |
| Data Controller | Slawomir Szostak (individual developer) |
| Contact | contact@wildstash.app |
| Applicable law | GDPR (EU) 2016/679; Polish Act on Protection of Personal Data (Ustawa o ochronie danych osobowych) |
| Supervisory authority | UODO (Urzad Ochrony Danych Osobowych), ul. Stawki 2, 00-193 Warszawa, Poland |
| Review schedule | Annually, or upon significant change to processing activities |
Table of Contents
1. Introduction and Scope
1.1 Purpose of This Assessment
This Data Protection Impact Assessment (DPIA) is conducted in accordance with Article 35 of the GDPR to systematically evaluate the risks to the rights and freedoms of natural persons arising from the processing of personal data within the WildStash application.
The assessment is undertaken proactively, prior to public launch, because the application processes location data — a category of data that, when combined with user identity, can reveal behavioural patterns and physical whereabouts of individuals.
1.2 Why a DPIA Is Necessary
A DPIA is required under Article 35(1) GDPR when processing is “likely to result in a high risk to the rights and freedoms of natural persons.” The following criteria from the Article 29 Working Party guidelines (WP248 rev.01) are met:
- Processing of location data — GPS coordinates submitted by users when creating spots could, in aggregate, reveal movement patterns or habitual locations.
- Systematic monitoring of publicly accessible areas — spots are mapped in public locations, and the aggregated dataset could potentially be used to monitor activity in those areas.
- Innovative use of technology — the three-level visibility model (public/group/private) introduces a non-standard access control mechanism that must be rigorously assessed.
1.3 Scope
This DPIA covers all personal data processing performed by the WildStash mobile application and its backend infrastructure, specifically:
- User account creation and authentication
- Spot creation (GPS coordinates, descriptions, species data, photos)
- Three-level visibility system (public, group, private)
- Group creation, membership, and spot sharing
- Photo upload, storage, and serving
- Species data enrichment from external APIs
Processing by third-party sub-processors (Cloudflare) is assessed to the extent that personal data is transferred to or processed by them.
2. Description of Processing
2.1 Nature of the Processing
WildStash is a mobile application for community-driven mapping of wild plants (fruits, herbs, bushes, fruit trees, mushrooms) in publicly accessible locations. Users create geo-located “spots” on an interactive map, annotating them with species information, descriptions, and photographs.
2.2 Categories of Data Subjects
| Category | Description |
|---|---|
| Registered users | Individuals who create an account to add spots, join groups, and interact with the community |
| Anonymous guests | Individuals who browse the public map without an account (no personal data collected beyond standard HTTP headers) |
2.3 Categories of Personal Data
| Data Category | Specific Data Elements | Sensitivity |
|---|---|---|
| Account data | Email address, nickname, password hash (PBKDF2-SHA-512) | Standard personal data |
| Location data | GPS coordinates (latitude, longitude) of spots created by the user; geohash index | Personal data with behavioural significance |
| Photos | Plant/location photographs uploaded by users (EXIF stripped client-side) | Standard personal data (may incidentally contain identifiable features) |
| Group membership | Group names, membership lists, invite codes | Standard personal data |
| Usage metadata | Spot creation timestamps, spot confirmations | Standard personal data |
| Technical data | IP address, device type (via HTTP headers) | Standard personal data (not linked to user profile) |
2.4 Processing Operations
| Operation | Description | Legal Basis |
|---|---|---|
| Account registration | Collecting email, nickname, and password to create a user account | Art. 6(1)(b) — performance of a contract |
| Spot creation | Storing GPS coordinates, species, description, and visibility level for a spot | Art. 6(1)(b) — performance of a contract |
| Location processing | Using device GPS to assist spot placement (only on explicit user action) | Art. 6(1)(a) — consent |
| Photo upload and storage | Receiving, storing, and serving user-uploaded photographs | Art. 6(1)(b) — performance of a contract |
| Group functionality | Managing group creation, membership, and spot sharing | Art. 6(1)(b) — performance of a contract |
| Visibility enforcement | Applying access control rules to ensure private/group spots are not exposed to unauthorized users | Art. 6(1)(b) — performance of a contract; Art. 6(1)(f) — legitimate interest (security) |
| Security monitoring | Rate limiting, abuse prevention via IP analysis | Art. 6(1)(f) — legitimate interest |
| Species data enrichment | Querying Wikipedia, Wikidata, GBIF, Perenual for species information | No personal data involved |
2.5 Data Flows
graph TD
A["📱 User Device\n(Android)"] --> B["🔒 Local Processing"]
B --> B1["EXIF Metadata Stripping\n(before upload)"]
B --> B2["EncryptedSharedPreferences\n(JWT tokens, AES-256)"]
B --> C["🔐 HTTPS / TLS 1.3"]
C --> D["⚡ Cloudflare Workers\n(API layer, edge processing)"]
D --> E["🗄️ Cloudflare D1\n(SQLite, EU jurisdiction)"]
D --> F["📦 Cloudflare R2\n(object storage, EU jurisdiction)"]
D --> G["⚡ Cloudflare KV\n(cache, EU jurisdiction)"]
E --- E1["Users, spots, groups,\nspecies, translations"]
F --- F1["Spot photos, avatars,\nspecies reference images"]
G --- G1["Species data cache,\ni18n strings"]
style A fill:#2D6A4F,color:#fff,stroke:#1B4332
style C fill:#E09F3E,color:#2B2D2E,stroke:#C88A2E
style D fill:#3A8B5C,color:#fff,stroke:#2D6A4F
style E fill:#E8F0E4,color:#2B2D2E,stroke:#2D6A4F
style F fill:#E8F0E4,color:#2B2D2E,stroke:#2D6A4F
style G fill:#E8F0E4,color:#2B2D2E,stroke:#2D6A4F
style B fill:#F0F5ED,color:#2B2D2E,stroke:#D4DDD0
style B1 fill:#FAFAF5,color:#5F6368,stroke:#D4DDD0
style B2 fill:#FAFAF5,color:#5F6368,stroke:#D4DDD0
style E1 fill:#FAFAF5,color:#5F6368,stroke:#D4DDD0
style F1 fill:#FAFAF5,color:#5F6368,stroke:#D4DDD0
style G1 fill:#FAFAF5,color:#5F6368,stroke:#D4DDD0
2.6 Data Processor
Cloudflare, Inc. acts as the sole data processor. The Cloudflare Data Processing Addendum (DPA) has been accepted, which incorporates EU Standard Contractual Clauses. All data storage (D1, R2, KV) is restricted to EU jurisdiction. Cloudflare is a certified participant in the EU-US Data Privacy Framework.
2.7 Data Retention
| Data | Retention Period |
|---|---|
| Account data (email, nickname, password hash) | Until account deletion by user |
| Spots and photos | Until deletion by user or account deletion |
| Server logs (IP address, device info) | 30 days (Cloudflare standard retention) |
| Refresh tokens | 30 days (automatic expiry) |
3. Necessity and Proportionality Assessment
3.1 Necessity
Each category of personal data processed is strictly necessary for the application's core functionality:
- Email address — required for authentication and account recovery. No alternative identifier is collected.
- Password hash — required for credential-based authentication. Only the hash is stored; the plaintext is never persisted.
- GPS coordinates — the fundamental purpose of the application is geographic mapping of plant spots. Without location data, the service cannot function.
- Photos — optional, user-initiated. Photos enhance spot information and community verification. Users choose whether to upload.
- Group data — necessary to implement the group visibility tier, a core feature of the application.
- Nickname — minimal identifier for community interaction. Users choose their own display name.
3.2 Proportionality
The following measures ensure processing is proportionate to the purpose:
- Data minimisation — only essential data is collected. No analytics, advertising identifiers, device fingerprints, or continuous location tracking.
- Purpose limitation — data is used exclusively for the WildStash service. No secondary uses, no data sales, no profiling.
- User control — users control the visibility of every spot they create. Private spots are visible only to the author. Group spots are visible only to selected group members.
- EXIF stripping — photo metadata (including embedded GPS coordinates) is removed on the device before upload, preventing accidental disclosure of precise location data.
- No continuous tracking — the application accesses device GPS only when the user explicitly requests it (to centre the map or set a spot location). No background location tracking occurs.
3.3 Data Subject Rights
The following GDPR rights are fully supported:
| Right | Implementation |
|---|---|
| Access (Art. 15) | GET /users/me/data-export — JSON export of all personal data |
| Rectification (Art. 16) | Profile editing in app (nickname, email, password) |
| Erasure (Art. 17) | DELETE /users/me/account — permanent deletion of account, all spots, and all photos |
| Data portability (Art. 20) | GET /users/me/data-export — machine-readable JSON format |
| Restriction (Art. 18) | Manual request via contact@wildstash.app |
| Objection (Art. 21) | Manual request via contact@wildstash.app |
| Withdraw consent (Art. 7(3)) | User can stop submitting location data at any time; account deletion removes all data |
4. Risk Assessment
4.1 Methodology
Each risk is evaluated on two dimensions:
- Likelihood: Very Low / Low / Medium / High / Very High
- Severity: Negligible / Low / Medium / High / Critical
The resulting Risk Level is determined by combining likelihood and severity:
| Likelihood / Severity | Negligible | Low | Medium | High | Critical |
|---|---|---|---|---|---|
| Very Low | Acceptable | Acceptable | Low | Medium | Medium |
| Low | Acceptable | Low | Low | Medium | High |
| Medium | Low | Low | Medium | High | High |
| High | Low | Medium | High | High | Very High |
| Very High | Medium | Medium | High | Very High | Very High |
4.2 Risk Register
Risk 1: Private Location Disclosure Medium
| Attribute | Assessment |
|---|---|
| Description | User's private or group spot locations could be exposed to unauthorized parties through an API vulnerability, SQL injection, or access control bypass |
| Affected data | GPS coordinates, spot details |
| Impact on data subjects | Disclosure of secret foraging locations; potential for harassment or exploitation of disclosed locations |
| Likelihood | Low — all SQL queries use parameterized statements; visibility is enforced at the query level with EXISTS subqueries; dedicated getSpotWithAccessCheck() helper function centralises access control |
| Severity | High — reveals user's private locations, which they explicitly chose to keep hidden |
| Risk level | Medium |
Existing mitigations:
- Three-level visibility enforced at SQL query level with EXISTS subqueries
- Centralised
getSpotWithAccessCheck()helper ensures consistent access control - All SQL queries are parameterized (no string concatenation)
- Private/group spot coordinates never appear in public API responses
- Rate limiting: 100 req/min anonymous, 300 req/min authenticated
- Private photos served through Workers with token validation, never via direct R2 URL
Residual risk after mitigations: Low
Risk 2: Foraging Pattern Profiling Low
| Attribute | Assessment |
|---|---|
| Description | An attacker or the controller could analyse spot creation timestamps and locations to reconstruct user movement patterns, habitual foraging routes, or home/work locations |
| Affected data | Spot GPS coordinates, creation timestamps, user identity |
| Impact on data subjects | Surveillance, behavioural profiling, potential physical safety risk |
| Likelihood | Low — no analytics pipeline exists; no aggregation or pattern analysis is performed; spots are discrete, user-initiated events; no continuous tracking |
| Severity | Medium — while concerning, the data represents only discrete voluntary submissions, not continuous tracking |
| Risk level | Low |
Existing mitigations:
- No continuous location tracking — GPS accessed only on explicit user action
- No analytics or tracking infrastructure
- No data aggregation or pattern analysis
- Spot creation is a deliberate, manual action (not automatic)
- Users control visibility of all their spots
- Account deletion removes all spot data
Residual risk after mitigations: Acceptable
Risk 3: Photo Metadata Leakage Medium
| Attribute | Assessment |
|---|---|
| Description | GPS coordinates or other identifying metadata embedded in EXIF data of uploaded photos could expose precise location information, even for spots marked as private |
| Affected data | Photo EXIF metadata (GPS coordinates, device information, timestamps) |
| Impact on data subjects | Disclosure of precise location where photo was taken, potentially revealing private spot locations or user's physical position |
| Likelihood | Very Low — EXIF metadata is stripped on the Android device before upload; the server never receives original EXIF data |
| Severity | High — could reveal exact location, bypassing the visibility system |
| Risk level | Medium |
Existing mitigations:
- EXIF stripping performed client-side on Android before upload (including GPS, device info, timestamps)
- Photos served through Cloudflare Workers with access validation — never via direct R2 URL
- Private spot photos require authentication and ownership/group membership verification
- No raw photo access endpoint exists
Residual risk after mitigations: Low
Risk 4: Species Data Accuracy — Health and Safety High
| Attribute | Assessment |
|---|---|
| Description | Incorrect or misleading information about plant edibility, toxicity, or identification could lead users to consume harmful or poisonous plants or mushrooms |
| Affected data | Species descriptions, edibility information, common names |
| Impact on data subjects | Physical harm, poisoning, potentially life-threatening consequences |
| Likelihood | Medium — species data is sourced from authoritative databases (Wikipedia, Wikidata, GBIF), but community-contributed spots may contain misidentifications; no expert review process exists in MVP |
| Severity | Critical — incorrect edibility information could result in serious illness or death |
| Risk level | High |
Existing mitigations:
- Species data sourced from authoritative scientific databases (Wikipedia, Wikidata, GBIF, Perenual)
- Edibility disclaimer prominently displayed in Terms of Service
- Onboarding acknowledgment: users must accept a disclaimer that WildStash does not guarantee the accuracy of species identification or edibility information
- Foraging safety rules screen shown during initial onboarding
- Species entries include warnings field for known risks
Additional measures recommended:
- Display a visible warning banner on species pages that contain edibility information
- Encourage users to cross-reference identifications with field guides and expert sources
- Consider adding a community reporting mechanism for misidentified species
Residual risk after mitigations: Medium (inherent to any plant identification platform; cannot be fully eliminated)
Risk 5: Unauthorized Access to Accounts Medium
| Attribute | Assessment |
|---|---|
| Description | Attackers could gain access to user accounts through credential stuffing (reused passwords from other breaches), brute-force attacks, or session hijacking |
| Affected data | Account data, all spots and photos owned by the compromised account |
| Impact on data subjects | Exposure of private spots, modification or deletion of user data, impersonation |
| Likelihood | Medium — credential stuffing is prevalent; users commonly reuse passwords across services |
| Severity | Medium — exposure of private spots and personal data; no financial data at risk |
| Risk level | Medium |
Existing mitigations:
- Password hashing: PBKDF2-SHA-512 with 100,000 iterations and 16-byte random salt
- JWT access tokens with 15-minute TTL (limits session hijacking window)
- Refresh tokens with 30-day TTL stored in Android EncryptedSharedPreferences (AES-256)
- Rate limiting: 100 req/min anonymous, 300 req/min authenticated (limits brute-force attacks)
- HTTPS/TLS 1.3 enforced by Cloudflare (prevents man-in-the-middle attacks)
Residual risk after mitigations: Low
Risk 6: Data Breach — Unauthorized Access to Infrastructure Medium
| Attribute | Assessment |
|---|---|
| Description | Unauthorized access to the Cloudflare D1 database or R2 storage could expose all user data, including account information, spot locations, and photos |
| Affected data | All personal data stored in the system |
| Impact on data subjects | Mass exposure of account data, private spot locations, photos, and group memberships |
| Likelihood | Very Low — all infrastructure is managed by Cloudflare; no direct database access is possible; Workers API is the only access path; Cloudflare maintains SOC 2 Type II, ISO 27001, and other security certifications |
| Severity | High — would affect all users and all data categories |
| Risk level | Medium |
Existing mitigations:
- All data storage restricted to EU jurisdiction (Cloudflare D1 + R2)
- Cloudflare Data Processing Addendum (DPA) accepted
- Encryption at rest provided by Cloudflare
- No direct access to D1 database or R2 storage — all access through Workers API layer
- Cloudflare infrastructure security certifications (SOC 2 Type II, ISO 27001, PCI DSS)
- Wrangler CLI access secured by Cloudflare account credentials
- No database credentials exposed in application code (D1 binding is environment-level)
Residual risk after mitigations: Low
4.3 Risk Summary
| # | Risk | Likelihood | Severity | Initial Risk | Residual Risk |
|---|---|---|---|---|---|
| 1 | Private location disclosure | Low | High | Medium | Low |
| 2 | Foraging pattern profiling | Low | Medium | Low | Acceptable |
| 3 | Photo metadata leakage | Very Low | High | Medium | Low |
| 4 | Species data accuracy | Medium | Critical | High | Medium |
| 5 | Unauthorized access to accounts | Medium | Medium | Medium | Low |
| 6 | Data breach (infrastructure) | Very Low | High | Medium | Low |
5. Technical and Organisational Measures
5.1 Technical Measures
| Measure | Description |
|---|---|
| Encryption in transit | HTTPS with TLS 1.3 enforced by Cloudflare on all API endpoints |
| Password hashing | PBKDF2-SHA-512, 100,000 iterations, 16-byte random salt |
| Token security | JWT access tokens with 15-minute TTL; refresh tokens with 30-day TTL |
| Client-side token storage | Android EncryptedSharedPreferences (AES-256) |
| EXIF stripping | All photo metadata (including GPS) removed on device before upload |
| Visibility enforcement | SQL-level access control with EXISTS subqueries; centralised getSpotWithAccessCheck() |
| Private photo serving | Photos served through Workers with authentication and authorisation checks; no direct R2 URLs |
| Rate limiting | 100 req/min anonymous, 300 req/min authenticated |
| Parameterized queries | All D1 SQL queries use parameterized statements to prevent injection |
| EU data residency | D1 and R2 configured with EU jurisdiction restriction |
| Encryption at rest | Provided by Cloudflare infrastructure |
| No direct database access | D1 accessible only through Workers bindings; no external connection strings |
5.2 Organisational Measures
| Measure | Description |
|---|---|
| Data Processing Addendum | Cloudflare DPA accepted (includes EU Standard Contractual Clauses) |
| Data minimisation policy | Only essential data collected; no analytics, advertising, or tracking |
| Privacy Policy | Published in English (and Polish), accessible in-app and on website |
| Terms of Service | Includes edibility disclaimer and foraging safety acknowledgment |
| Consent flow | Registration requires explicit, unchecked checkboxes for data processing consent |
| Account deletion | Self-service via DELETE /users/me/account; permanently removes all user data, spots, and photos |
| Data export | Self-service via GET /users/me/data-export; JSON format |
| Onboarding safety screen | Foraging rules and disclaimer shown during initial setup |
| DPIA review | This assessment reviewed annually or upon significant changes to processing |
6. Consultation
6.1 Data Subjects
The application provides clear and accessible information to data subjects through:
- A comprehensive Privacy Policy (available in English and Polish)
- A consent flow with unchecked checkboxes during registration
- A foraging safety and disclaimer screen during onboarding
- In-app access to privacy settings, data export, and account deletion
6.2 Data Protection Officer
As an individual developer processing data that does not require a DPO under Article 37 GDPR (no large-scale systematic monitoring; no special category data), no DPO has been appointed. The Data Controller (Slawomir Szostak) is directly responsible for data protection compliance and is reachable at contact@wildstash.app.
7. Conclusion and Decision
7.1 Overall Assessment
This DPIA has identified six risks to the rights and freedoms of data subjects. After applying the technical and organisational mitigations described in this document:
- Five out of six risks have a residual risk level of Low or Acceptable.
- One risk (species data accuracy) retains a residual risk level of Medium. This risk is inherent to any community-driven plant identification platform and is mitigated through disclaimers, authoritative data sources, and user acknowledgment. It is a safety risk rather than a data protection risk per se, but is included in this assessment due to its severity.
7.2 Decision
Processing can proceed with the existing mitigations in place. The residual risks are acceptable and proportionate to the purposes of the processing.
7.3 Prior Consultation with Supervisory Authority
Under Article 36 GDPR, prior consultation with the supervisory authority (UODO) is required only when the controller cannot sufficiently mitigate high risks. As all identified risks have been reduced to acceptable or low levels through the measures described above, prior consultation with UODO is not required.
7.4 Ongoing Obligations
The Data Controller commits to:
- Reviewing this DPIA at least annually, or whenever there is a significant change to processing activities.
- Monitoring the effectiveness of mitigations on an ongoing basis.
- Updating this assessment if new risks are identified or existing risks change in likelihood or severity.
- Reporting any personal data breach to UODO within 72 hours and to affected data subjects without undue delay, in accordance with Articles 33 and 34 GDPR.
8. Approval
| Role | Name | Date | Signature |
|---|---|---|---|
| Data Controller | Slawomir Szostak | 24 February 2026 | _________________ |
Revision History
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | 24 February 2026 | Slawomir Szostak | Initial DPIA — pre-launch assessment |