Shrimp Farm ← Home

Privacy Policy

Draft — pending legal review before general release. Last updated: 2026-08-13. Applies to the Shrimp Farm Android app, the web app, and this website.

Summary

Shrimp Farm is offline-first. Your farm data — ponds, cycles, water readings, feed, harvests, costs — lives on your device by default and is never sent to us unless you turn on account sync (a separate opt-in feature). If you enable account sync, those records are uploaded to your account so you can use them across devices and, if you choose, share them with an organization you authorize — and that upload includes farm and pond precise locations (GPS coordinates) you enter, select or explicitly capture, unless you turn off sync for a pond location, and farm identifiers you enter. With sync off, no farm records leave the app through sync.

Separately, you can opt in to anonymous, privacy-friendly telemetry to help improve the app. Telemetry carries no directly identifying data and no farm data; you can turn it off at any time, reset its anonymous app-generated id, and delete it.

This website

This website (the public landing at shrimpfarm.app) uses self-hosted, cookieless analytics for page views, referrer, locale, broad browser/screen class and explicitly named key interactions — for example language selection and testing/pilot, web-app or Android-install button choices. We do not send form values, email addresses, account identifiers or farm data to analytics, and we do not use cross-site tracking. IP addresses are used only transiently to generate a daily, non-reversible visitor hash and are not retained. Analytics stores no cookie or tracking identifier on your device; local storage is used only to remember dismissal or opt-out. We run this on the basis of our legitimate interest in understanding and improving the site, and we show an unobtrusive notice about it. You can opt out at any time with one click in that notice; opting out stops further analytics on this browser. This applies to the landing page only — the signed-in web app does not run analytics, and the mobile app's anonymous telemetry stays off unless you turn it on.

Testing and partner-pilot forms

If you submit an email on this site, we store only the normalized email address, the page language, which form it came from, and the submission time. The farmer form is for the smaller closed-testing group. The partner form is for direct human follow-up about the free partner pilot and is kept separate from the farmer tester list. Both use the same minimal first-party endpoint. They collect no farm data or account/device identifier, store no IP address or user-agent, and form values are never sent to site analytics. We keep each lead for up to 180 days, never sell or share it, and you can ask us to delete it at any time at privacy@shrimpfarm.app.

What we collect (only with your opt-in)

Every telemetry item — analytics, crash and feedback — also carries an anonymous install id: an app-generated identifier (a ULID) that encodes only the moment it was created — nothing about your device or who you are — used only as a handle so you can delete your data. You can reset it at any time (which unlinks future data from past data) or delete it.

Analytics events (but not crash reports or feedback) also carry a separate anonymous session id, generated for one app run and not persisted after restart. Neither telemetry identifier is an advertising or hardware device id, and neither is linked to your sign-in account.

Signing in with Google (optional)

You can sign in with a Google account instead of a password. If you do, we store Google's opaque identifier for your account, the address Google reported when you linked it, and when you linked it. From Google's sign-in token we read only that identifier, your email address and whether Google says the address is verified. The token usually also carries your name and profile picture — we do not read or store them, so signing in this way adds nothing to what we know about you beyond an identifier.

We send Google nothing about you. Your phone or browser talks to Google, and our server only downloads Google's public signing keys to check the token is genuine. Google itself will of course see that you signed in to Shrimp Farm, as it does for any site you use it on. If you have a second sign-in factor turned on, it is still required after signing in with Google. You can always sign in with an email address and password instead.

What account sync sends (only if you enable it)

Account sync is off by default and separate from telemetry. When you turn it on, we store the email address used to sign in, a server-generated user id and the display name you enter and can edit to authenticate you, manage the account, associate records with the correct user and let current teammates identify you without using your email as a name. The records you create are uploaded to your account: your farm & production records (ponds, cycles, water — including whether a value was entered manually or explicitly copied from a prior reading and the exact source-reading reference; that water-attempt provenance stays within your account and is not shared with an organization — feed, harvests, costs, samplings, shrimp disease observations/treatment records you enter, including any withdrawal period/source you record, cycle plan/reference points and source labels, raw-parameter logging schedules (including optional recommended farm-local times) and plan assignment/acceptance metadata, the pond's size and depth together with a snapshot of them taken when the pond was stocked, and — only if you turn that feature on — the start and end dates a pond spent in preparation between cycles, and a farm presentation role used to keep pond-first, multi-site and removable demo grouping consistent); farm and pond precise locations (GPS latitude/longitude) when you enter, select or explicitly capture them, except pond locations for which you turn sync off; farm identifiers (a registration/licence id and the farm's timezone); your farm settings (display units, whether money is used, feed-sack weight, the currency the farm works in, the certification-requirements mode, your own wording for the app's dictionaries and the order you keep your lists in); and your notes (the text you save, how it was captured and its timestamps, including text you accepted from an imported conversation archive). This is your data under your account — retained while your account exists, sent over TLS, and made available only to co-workers you invite to the account or to an organization you separately authorize (both are revocable). Notes are an exception even to that: they are never shared with an organization under any sharing grant, and are not included in partner reports. Your farm settings are not shared with an organization either. If — and only if — you turn on the certification-requirements mode, the app additionally records the five kinds of settings edit that change how your data or rights are read (access and grants, feeding program, alert thresholds, the set of required fields, and the mode itself): what changed, its old and new displayed values, which member changed it and when. That record is append-only while the account exists — single entries cannot be edited or removed — and it is deleted with your account. None of it is ever advertising data and none of it is sold.

A cycle plan may contain copied observed reference points, its source-cycle label, logging frequency, optional recommended farm-local times, weekdays/cycle-day limits and the account user who accepted the assignment. These are farm configuration records, not analytics. Accepting a consultant plan does not itself let the consultant or organization read your records; that always requires the separate, revocable sharing consent described below.

An administrator of a linked consultant organization can send an immutable plan offer for one active cycle. We store the organization/program/account/cycle identifiers, consultant-entered plan name or note, typed target and logging schedule, component status, snapshot hash, author and decision user ids, timestamps and expiry. The offer contains plan configuration, not observed farm readings. The owner may accept targets and schedule independently; accepted parts are copied into the farm account and remain there if another pending part is later withdrawn. Sending or accepting an offer does not create a data-sharing grant.

Partner organization registration: if you register a partner organization yourself in the partner portal, we store the organization name and type you enter, a link between that organization and your sign-in identity as its creator, and your organization role. This exists to create your organization workspace, enforce the one-organization-per-creator limit and let our staff suspend an organization for abuse (the suspension reason is kept in an audit log). Erasing your account removes the creator link; the organization itself remains as an institutional record for its other members. Registering an organization gives it no access to any farmer's data — that always requires each farmer's separate, revocable sharing consent.

Farm Team: an account owner may invite a co-worker by email as a manager, worker or viewer. We store the normalized invite email, role, status, seven-day expiry and timestamps, then the accepted member's server-generated user id and role. Membership is account-wide: it covers every current and future farm and pond until the owner removes it. For accepted synced writes, we also store server-owned creator and last-modifier user ids separately from client-entered record fields, so Logbook and exports do not trust a spoofable author value. Current members can see the self-entered display name, role and membership date of current teammates in that same account so a trusted author can be named. Only owners and managers receive teammate email in the directory; worker and viewer responses omit it; a display name is never derived from the hidden email; after removal, historical entries show only “Former member”. A raw invite token is returned only when created or resent; the database stores only its SHA-256 hash. These fields are not anonymous analytics and are removed with account erasure. Older records without trusted authorship are shown as Unknown.

For a farm created from a client's direct or offline authorization, the signed-in farm office also receives the already-stored authorization expiry and retention period with the account list. Current account members can see those dates, including the farmer-owner after handover, so an expiring or expired legal basis is not hidden. This adds no conversation text, farm value or new identifier to the response.

Shrimp disease and treatment entries concern farm animals and farm operations, not your human health. The app does not infer a diagnosis or recommend a product, dose or withdrawal period; account sync stores only what you enter.

Sharing requests and Partner BI consent

Organization membership, a program, invitation, promo or payment does not give an organization access to your records. A linked organization may send a separate, immutable request showing its program, purpose and recipient, farm/pond/cycle scope, supported parameters, requested history, expiry and retention terms. You can allow that requested snapshot, customize individual parameters and history windows, or deny it, and you can later revoke active consent. “Allow all” never means all account data.

A second path applies when an authorized organization administrator creates a managed client farm from records the client supplied directly outside Shrimp Farm. The administrator must explicitly attest that direct authorization and record the current program template, earliest covered history date, access expiry and retention period. We store an immutable synthetic sharing request and a grant labelled offline attestation. This is not presented as the farmer's in-product consent. A managed farm with no recorded basis is not visible to the organization. The partner owner can revoke the basis before handover; after handover, the new farmer owner can revoke it through the same consent control. Revocation closes reads immediately. The farm office continues to show the recorded expiry and retention period to the current account members after handover so the basis does not disappear from view when ownership changes. Handover does not automatically retain the consultant as a farm member or assume the farmer's continued program participation.

We store the request and decision metadata needed to enforce your choice. Every parameter read is checked against one exact active consent; legacy block grants remain separate and are never upgraded automatically. The access audit records actor/organization/program/account and consent ids, parameter codes, result, time and contract versions — not farm values. Account erasure removes these account-scoped requests, decisions, links and audits. Country-specific wording and any future export/report retention remain a legal-review gate before a real-data pilot.

The Partner Portal presents these same authorized records through route-specific, read-only views. Its source manifest contains organization/program identifiers, route/source state and bounded program, participant and case counts. Its Access view may show relationship state, requested and effective data-block counts, request/decision history and the organization's own audited uses described above. User identifiers in that partner-facing history are replaced with program-scoped opaque references. Report and document views refer to the same report jobs, immutable artifacts and short-lived BI snapshots described below; they do not create another copy of measured farm values. Routes whose workflow is not enabled have no records and no write path, so their empty server projection stores no farm payload. These views add no analytics event, device permission or sharing scope by themselves: every farm record still requires the exact active consent above. A separate, explicit PDF email-delivery action is described below.

An authorized Partner Portal reader may save one current cycle comparison question per program. The server stores the order of 2–10 opaque farm/cycle references, metric/formula, period, missing-data and comparability policy versions, and version/idempotency metadata. It does not store measured farm values, calculated ABW/survival/FCR results, farm labels or notes in that saved question. Opening it creates only the same consent-scoped, 15-minute BI input snapshots described below; the browser calculates through the shared deterministic calculation engine. Access loss makes the question unavailable immediately and the next C10 revalidation soft-deletes it. Erasing the reader's account deletes that reader-owned question.

If you allow requested parameters, the program may also propose a collection profile for those exact fields. Sharing consent does not enable it automatically: you separately use it as suggested, customize optional fields and supported frequency, or reject it. We store its scope identifiers, parameter codes, requested/configured frequency, enabled state, version/status, integrity hashes and decision times — not farm measurement values. It cannot let the organization write your records or expand what it may read.

Android keeps only the last server-confirmed effective profile in install-local settings so optional Due Today guidance can work offline. That guidance evaluates existing records and exact sync acknowledgements locally, creates no record and is not telemetry. The profile cache is removed from manual backups. Offline it is only a last-confirmed hint: every organization read still requires live server consent, and the next successful refresh clears a revoked, expired or otherwise ineffective profile.

When an authorized organization member opens Partner BI portfolio or coverage, our server creates a short-lived read snapshot for that member, program and point in time. It can contain opaque farm references, coverage states and reason codes. Only an authorized farm-detail request can add raw canonical input values allowed by that exact active consent and its history/scope. Pending or denied access does not put farm names, other farm metadata or values into the snapshot. The server rechecks live access before every page and invalidates the snapshot if it changed. It does not calculate biological metric values. The snapshot becomes unusable after 15 minutes, is removed by the next daily deletion job (normally within 24 hours), and is removed immediately with account erasure. It is app-functionality farm data, not analytics, crash/feedback data or a manual backup.

An authorized organization member may explicitly generate a bounded, point-in-time coverage report. The first report contains an opaque farm reference, parameter codes, coverage states, reasons, actionable status, unit, timezone and report time. It does not contain the farm name, measured farm values or server-calculated biological metrics. We store the immutable CSV together with its program, filters, exact consent scope, contract versions, access-basis origin for every captured subject and row, size, row count, SHA-256, author, expiry and generate/download audit times. It expires at the earliest of 30 days, the request retention period or consent expiry. Consent and program access are checked again before generation and every download; revoke, expiry or a version change blocks access. Expired report data is removed by the daily deletion job, and the report tree is removed with account erasure. The authorized report list and account-member access history show the same access-basis origin so the two authorization paths are not presented as one; the history adds no farm value. These reports are app-functionality data within either the farmer's optional in-product sharing choice or the direct client authorization explicitly recorded by the current managed-farm owner, not analytics, crash/feedback data or a manual backup.

An authorized organization administrator with the separate Send reports permission may manually enter a recipient email and queue an immutable PDF snapshot of an available report. We recheck organization membership, that permission and every captured consent before creating the delivery and before each send attempt. We store the normalized recipient email, recipient type, sender/program/artifact identifiers, the exact PDF and its checksum/version, a neutral subject/body, and bounded attempt, failure and provider-acceptance metadata. Temporary failures are retried up to three times with the same provider idempotency key. Our transactional email processor, Resend, receives the address, neutral envelope and PDF only to perform this requested delivery. “Sent” means the email service accepted the message; it does not prove delivery or reading. There are no public report links, email read receipts, SMS, messenger messages or webhooks. The server copy is removed with the source report tree or account erasure, but an email/PDF already accepted by the service or recipient cannot be recalled. The partner is responsible for checking the address and the recipient’s authority.

Partner BI may also keep a bounded operational case while current coverage has an actionable gap. One case per program and farm stores an internal account link, opaque farm reference, parameter and reason codes, status, assignment, suppression or due dates, version and transition times. It does not store measured farm values, task titles or notes, diagnoses, treatments or dosage instructions. Follow-up tasks use only a fixed reviewed list. Every read or change rechecks current membership, program and exact active consent. Revocation or expiry immediately hides the case; when the gap disappears, pending tasks are cancelled and the case closes automatically. Resolved or automatically closed cases are deleted after 180 days, and the complete case tree is removed immediately with account erasure. Case metadata is app-functionality data within the farmer's optional sharing choice, not analytics, crash/feedback data or a manual backup.

Partner account security

A network-enabled Partner account can turn on two-step sign-in. It is optional and off unless the Partner enables it; without it, the account is opened by password alone. When it is on, we use multi-factor authentication and revocable security sessions. We store the TOTP authenticator seed encrypted at rest, one-way hashes of single-use recovery codes, and limited session metadata: user and session identifiers, credential version, authentication method and authentication, activity, expiry and revocation times. A PII-minimal security audit records action, result, time and constrained correlation identifiers — not farm values or authenticator secrets, email, IP address, user-agent or device fingerprint. Audit rows cannot be edited; controlled retention and account erasure can delete them. The additional assurance token stays only in browser memory. The server checks role, capability and assurance; report generation/download and access-policy changes require a recent step-up.

The current factor is a TOTP authenticator; phishing-resistant passkeys are a later upgrade. The raw setup seed is shown only during enrollment, raw recovery codes are shown only once, and entered authenticator codes are not stored.

Factor replacement, session revocation or main-account invalidation makes prior assurance unusable. Account erasure removes the MFA credential, recovery codes, sessions and security audit. Expired assurance sessions are deleted by the next daily job, and Partner security audit records are deleted after 180 days. These records are used only for Account management and Security.

If a signed-in owner explicitly creates a demo workspace, we generate a separate synthetic account with sample farms, histories, image-log metadata and fictional team names and roles. It is linked to the signed-in user only so they can open, reset and remove it, and it is not mixed with their real account or used for analytics. A partner can likewise create a four-farmer synthetic cohort for an approved organization; normal grants, projection and access-audit controls still apply. Records or photos a user adds inside a demo follow the normal storage rules and are removed with that demo workspace.

Pond images

On Android, photos added to a pond log are privacy-normalized (including removal of EXIF location metadata) and stored in the app's private storage. The image and thumbnail stay on that device by default. Ordinary account metadata sync does not upload them. If account sync is enabled, only the record metadata — pond, date/time, your comment and a selected historical measurement snapshot — is uploaded as farm data. Another device may therefore show the record with a “file only on the original device” placeholder.

Sync photo files is a separate, versioned choice and is off by default. If you enable it, the privacy-normalized photo and thumbnail are uploaded over TLS to private, access-controlled object storage, with Wi-Fi/Ethernet-only transfers by default. Signed-in devices and the web app use short-lived private links; there are no permanent public photo links or storage credentials in the app. Turning the switch off stops new transfers but keeps existing private copies until you delete/exclude them or erase the account. “Never sync this photo file” cancels transfers and removes that photo's cloud copy while its image-log metadata may still sync.

An organization can preview photos only if you separately grant its approved members the Images data block. Every preview is checked and audited. Organization membership or payment alone never grants photo access.

Camera access and QR scanning

Android declares the optional camera permission. It is used only after you open a camera action: taking a pond/avatar/AI-sampling photo, or scanning an invitation QR code. Photo handling follows the sections in this policy. QR camera frames are analyzed on the device, are not saved or uploaded, and are discarded when you leave the scanner; only the decoded invitation token continues to the invite preview. You can enter an invitation code manually, and the app remains usable on devices without a camera.

Manual backups and Android system backup

When you choose Back up my data, the Android app creates a versioned, unencrypted ZIP containing the farm database and pond-photo originals and thumbnails that are locally available at that time. “Never sync this photo file” controls cloud photo sync and does not exclude a file from a backup you explicitly create. Missing local files remain metadata-only placeholders. Nothing is exported until you choose a destination in Android's document picker; a third-party storage provider you select applies its own terms and privacy policy.

Shrimp Farm disables Android Auto Backup and Android device-to-device transfer for its private database and files. The supported local-only phone migration path is the explicit ZIP backup and restore flow.

In the signed-in owner web app, Text, XLSX and PDF exports are generated locally in the current browser tab after you choose the exact cycles or farm-local date range and information sections. A download does not pass through a Shrimp Farm export server. “Generate & share” opens the browser or operating system share chooser; Shrimp Farm does not embed or select WhatsApp, LINE, Zalo, Telegram or another recipient. The app you choose receives the file under its own terms and privacy policy. Sensitive health, financial, precise-location, image-metadata, authorship and free-text sections are marked before generation; image metadata never includes the photo bytes. PDF charts are built locally from the selected records and use fonts bundled with the app; no font or report is uploaded. If Hindi or Devanagari text cannot be shaped safely, PDF generation stops and asks you to choose Text or XLSX instead of producing distorted text.

AI sampling photos and optional model download

On supported Android devices, the optional AI sampling flow creates a privacy-normalized temporary copy of the photo and analyzes it on that device. The photo, masks and unconfirmed result are not uploaded, synced, sent to telemetry or retained when you leave the flow. Only count and total sample weight that you review and save become an ordinary farm sampling record.

If you explicitly download the optional ONNX model, the app fetches only that model package over HTTPS, verifies its app-pinned size and SHA-256 hash, and stores it privately. The request contains no photo, farm identifier or sampling result. The production model host may receive ordinary connection data such as IP address and request time; its provider and retention terms will be confirmed before release.

Notes photo OCR and optional OCR models

On supported Android devices, a photo you take or choose for a Note is decoded and analyzed on that device. The source photo is not uploaded, added to sync, telemetry, crash reports or feedback, and its temporary app copy is deleted after the OCR flow. No source-photo path or source-photo bytes are stored in the Note or manual backup. Only text that you review and explicitly save follows the Notes rules below.

The optional PP-OCRv6 Small unified detector/recognizer, specialized PP-OCRv5 Thai/Devanagari models, their dictionaries and the shared text-line orientation classifier are fetched from our first-party HTTPS model channel. Only files needed for the selected language and model are downloaded. Every file is verified by app-pinned size and SHA-256 and stored privately. A model request contains no photo, recognized text, farm identifier or logged value. Ordinary hosting connection data such as IP address and request time may still be processed by the hosting provider.

A development/staging build may let testers keep both verified OCR model families and choose Automatic, PP-OCRv6 Small or PP-OCRv5 specialized for the next photo. That choice is only an app-private local runtime identifier, is not included in telemetry, sync or manual backup, and is ignored outside the staging model channel. If a selected model cannot recognize the current writing system, the app keeps the compatible specialized model instead.

Notes dictation and microphone access

On Android, you can tap the optional microphone control inside Notes to dictate free text on supported devices. The flow explains its microphone use before requesting Android permission. The microphone is read only while the app is in the foreground and the Notes control visibly says Listening; Stop, Cancel, app backgrounding or the 60-second limit closes capture. The app does not expose direct voice commands, KWS/Field Mode or a wake-word control.

Microphone audio is processed on the device and is not saved, uploaded, synchronized, sent to telemetry or written to diagnostic logs.

Notes dictation has a separate, versioned disclosure. Recognized text is placed into an editable field and is stored only after you tap Save. Once saved, that text and its capture provenance are stored in the app-private local database and, if you have enabled account sync, are uploaded to your account so your notes are available on your other signed-in devices. Microphone audio and any source photo are not uploaded — only the text you saved and its provenance. Notes remain excluded from photo-file sync, telemetry, crash reports and feedback. They are included in the unencrypted manual ZIP backup only when you explicitly create one; that backup contains no microphone audio or hidden source-photo path. Deleting a Note clears its raw text and local-media reference and propagates the deletion to your other signed-in devices, leaving only a content-free deletion tombstone.

Retaining note text or audio for model training remains a separate, off-by-default choice and is not enabled by account sync.

Optional voice models are downloaded only when you choose them, from our first-party HTTPS model channel. Compatible model files are verified by pinned size and SHA-256 and stored privately. A development/staging build may let testers keep multiple verified voice-model packs, including a multilingual comparison pack, and select one for the next Notes dictation. That selection is an app-private local runtime identifier, is not included in telemetry, sync or manual backup, and is ignored outside the staging model channel. Model requests contain no audio, transcript, farm identifier or logged value. Standard hosting connection data such as IP address and request time may still be processed by the hosting provider. There is no wake-word, continuous/background microphone or microphone foreground service.

Records and notes imported from a conversation

In the signed-in web app, the account owner can explicitly choose one farm, a WhatsApp text or ZIP export and how ambiguous dates should be read. An owner-web demo can instead prefill a clearly marked synthetic example; it follows the same processing path. Before upload, the app names the active provider, exact model, workspace region, inference scope, sent data classes, product retention, training fact and this Privacy Policy. One unchecked confirmation accepts that processing and confirms the right to provide the conversation. The backend rejects a missing or stale disclosure version and stores the accepted version, timestamp and disclosed facts with the temporary job. This minimal snapshot contains no conversation text or client IP. Only then is the archive uploaded over the authenticated connection. Raw archive bytes are parsed in request memory and are not stored; the filename is not retained. After fail-closed parsing, only normalized message text, participant labels, local timestamps and stable source references are stored temporarily, encrypted with a dedicated key, so the leased extraction worker can recover after a restart. This payload expires after 24 hours and is normally deleted earlier when extraction succeeds, fails or is cancelled. The continuously running worker removes expired payloads, with the daily retention job as fallback. We separately keep a temporary parser summary, typed proposals, stable source references and short evidence excerpts so the owner can review, correct and select them. A proposal needing attention must be corrected and confirmed, and a separate final confirmation is required before selected proposals become farm records. Duplicate matching does not overwrite an existing record automatically. An applied farm record keeps its stable source reference for provenance, but not the review's evidence excerpt.

Cancelling deletes the proposals immediately; the content-free disclosure snapshot remains only with the cancelled job until its seven-day expiry. Otherwise the temporary review expires after seven days and is deleted by the daily deletion job, normally within 24 hours after expiry. Applied records follow normal account retention; the pre-change journal remains only for the limited whole-import undo window. The production-safe default is disabled. When an operator explicitly enables the reviewed qwen configuration, our backend sends bounded extraction windows — message text, participant labels, local message timestamps, and pond names or aliases — to Alibaba Cloud Model Studio (Qwen), exact model qwen3.5-flash-2026-02-23, through its workspace-specific Germany (Frankfurt) endpoint with the disclosed EU inference scope. Media, account/user IDs, farm-record IDs, archive bytes, authentication tokens and telemetry identifiers are not sent to the model. The development fixture remains local to our backend.

Alibaba Cloud's published terms describe Model Studio as processing input on the customer's behalf and say Member Content is not used to develop or improve models without separate consent; its privacy notice likewise says transmitted data is not used for model training. Frankfurt is the selected workspace/API endpoint, but the Product Terms allow processing or cross-border transfer where Alibaba, affiliates or subcontractors maintain Model Studio facilities. The public API documentation does not promise a separate short deletion interval for each input. Provider handling therefore follows the Model Studio privacy notice, Product Terms and applicable Data Processing Addendum, rather than Shrimp Farm's seven-day review TTL. The versioned opt-in is the product gate for a limited pilot in ID/IN/VN/TH/EC/PH; vendor/DPA and country operator tasks remain an internal checklist before production GA and scaling. The adapter is disabled by default.

Separately, if a consultant proposes an import into your farm, the proposal identifies who sent it, its source, record count and what will be skipped. The messages themselves are a separate part of the proposal that you can decline while still accepting the records, and that part is off by default. Any import can be undone as a whole for a limited period after it is applied.

Content you or a consultant supplies is your own material: whoever supplies an archive is responsible for having the right to supply it, and whoever accepts one is responsible for what they bring into their farm. We do not inspect where an archive came from.

Pond location and device permission

On Android, Use current location can request foreground (“while in use”) location access and obtain one device position for a pond. The app asks only after you tap that action. It does not monitor location in the background, keep a location stream, or request background location permission. You can instead choose a point in the optional embedded Google map or enter coordinates manually. Reverse-geocoded addresses are approximate labels.

The embedded picker uses the Google Maps SDK for Android only if the release is configured with a Maps key and you choose to open it. It connects to Google to load tiles and provide the map. According to Google's SDK disclosure, it automatically processes request/device/SDK metadata, crash metrics, IP address and a Maps-specific pseudonymous identifier, and may process map interactions such as panning and zooming. The viewport and point you choose are used to provide that interaction. Google's Privacy Policy and Maps/Earth Additional Terms apply.

After a device fix or map selection, the app may ask Android's platform geocoding service for an approximate address. That service may send the coordinate to the device platform's geocoding provider. You can use manual coordinates without opening the embedded map; a missing address never prevents saving the coordinate.

With account sync off, the pond point stays on your device. With account sync on, a new pond location is included by default; you can turn off Sync this pond location before saving or later. That pond's location then stays local while its other records continue to sync. Location is never included in anonymous telemetry.

In the signed-in web app, saved pond coordinates are shown as text. If you explicitly click Open in Maps, the web app opens a Google Maps search URL containing those coordinates in a new browser tab. Google then receives the coordinates and ordinary web-request information (such as your IP address) under Google's own terms and privacy policy. Shrimp Farm sends nothing to Google before that click, does not embed a Google Maps SDK, and does not reverse-geocode the point in this flow. You can copy the coordinates instead without opening Google Maps.

What we do NOT collect

Legal basis and consent

Analytics and crash reporting are off by default. In the app, a single optional choice at first run — unticked by default — turns them on together; afterwards you can turn each of them on or off independently at any time in Settings → Privacy & data. We always ask before mobile-app telemetry is sent; withdrawal stops new data and discards anything still queued on the device.

The public landing site is different: the limited cookieless analytics described above runs by default on the basis of legitimate interest, with an in-page notice and a one-click opt-out. Dismissing the notice does not opt out. The signed-in web app runs no analytics.

Photo-file sync has its own disclosure and switch, off by default. Withdrawing it stops and cancels new transfers. Individual “Never sync” controls remove selected cloud copies.

How long we keep it (retention)

Data is deleted automatically after these windows.

Your rights and controls

In Settings → Privacy & data you can:

Data transfer and security

All telemetry is sent over TLS to our own infrastructure. Anonymous endpoints are rate-limited and protected by a non-user application key (anti-abuse only, not an identifier). Access to the internal analytics database is read-only and restricted to our operators.

Account sync is also sent over TLS to our infrastructure. When you use the optional embedded map or Android address lookup, the service data described above is processed by Google or the device's platform geocoding provider under that provider's terms and privacy policy.

Children

The app is not directed to children and we do not knowingly collect data from children.

Changes

We may update this policy; material changes will be reflected here with a new date and, where appropriate, surfaced in the app.

Who we are & contact

Shrimp Farm is built independently by Zykov Dmitrii. It is not owned by any feed company, lender or marketplace. Questions or data requests: privacy@shrimpfarm.app.