Skip to main content

palasgobook.com

Privacy Policy

Kail Privacy Policy

Effective and last updated:

Palas Network (“Palas”, “we”, “us”) operates Kail, a fishing map, forecast, catch-log, trip-recording and community app. This policy explains what Kail processes, why it is processed, who provides supporting services, how long data is kept, and the choices available to you.

Contact: palasnetwork@gmail.com

1. Data Kail processes

Account and identity

If you create an account, Kail processes your Firebase user ID, email address, display name, profile photo and sign-in provider. Authentication may be provided by email/password, Google or Apple. Providers may also process IP address, device/browser information and security events to authenticate you and prevent abuse.

Location

With permission, Kail processes precise device location for the live map, location-specific forecasts, saved fishing locations, navigation, speed and heading, Anchor Watch, and trips that you choose to record. Background location is used only while a trolling or trotline recording that you started needs to continue outside the foreground. Saved locations and recorded tracks can sync to your private account. Kail does not send device GPS or fishing coordinates in ad requests. Google may infer a general location from network information under the advertising choices described below.

For Waktu Solat, Kail rounds latitude and longitude to three decimal places (about 110 metres at the equator) and sends that coordinate cell directly to api.waktusolat.app over HTTPS to resolve the local JAKIM prayer zone. The coordinate is not added to your Kail account or Kail logs. The resolved zone and monthly schedule are cached on your device. The service and network providers can necessarily receive request metadata such as your IP address. Apple classifies latitude/longitude at three decimal places as precise location for App Privacy reporting.

Private fishing data

Kail stores the catches, species, bait, measurements, notes, saved spots, waypoints, tracks, trip details, photos and environmental snapshots you choose to save. These records remain private to your account when sync is enabled. They do not become Community posts unless you deliberately create a separate Community message. GPX, KML and KMZ files you import are processed to create your private waypoints.

Community content and safety data

When you use Community, Kail processes your display name and profile photo; message text; approved photos and voice notes; reply context; timestamps; and the reports, optional report details, appeals and block relationships you create. Other room members can see sent text and moderator-approved media. Blocking is private: Kail does not notify the blocked member.

Text is checked inside Kail’s Cloudflare Worker using local, Unicode-normalised safety rules. Kail does not send message text, display names or report details to a third-party moderation API. New Community photos and voice notes are not automatically scanned. They stay pending and visible only to their author and authorised Kail moderators until a moderator approves them. Moderators may review reported or potentially rule-breaking content, remove it, and process appeals. Community JPEG uploads are byte-validated and stripped of embedded EXIF, XMP, IPTC and comment metadata (including embedded GPS/device metadata) before private Cloudflare R2 storage.

Before Build 49 is admitted, Community media created by the earlier service is made inaccessible while Kail reconciles it. Kail validates each stored file’s actual bytes and exact message ownership; valid JPEGs are rewritten with the same metadata stripping and then remain pending for explicit moderator review. Files that are invalid are removed and their message is tombstoned. A persisted, two-pass bucket inventory also removes objects that have no exact live message or upload-intent owner. Validation-pending bytes are not served to the author, other members or moderators. Aggregate pre-release inspection on 24 August 2026 found nine legacy JPEG objects; all nine passed the hardened byte parser and three required metadata-removing rewrites. This inspection did not publish their keys, account identifiers or contents.

If Kail restricts or suspends a Community account, the active enforcement record can contain the account user ID, status, reason, optional expiry and the moderator user ID. A timed action remains active until its displayed expiry; an action without an expiry remains active until a moderator restores the account or the account is deleted. Moderation action audits can contain the subject and moderator user IDs, action, reason, optional moderator note and optional expiry. Report and appeal free-text details are erased when the case is resolved.

Public Build 49 delivery uses an authenticated, user-scoped Community v2 endpoint that applies current visibility and block rules. Its deployed Worker configuration disables the bare legacy-media route, which returns 404. During an explicitly approved, time-bounded Build 48 rollback, Palas Network may temporarily enable approved legacy-v1 media through an unlisted, hard-to-guess, no-store link. That rollback link is not authenticated and cannot apply a later block relationship; a copy fetched before it is disabled cannot be recalled. Pending or rejected media is never exposed through that route.

Purchases

Apple or Google processes subscription payment information. Kail and RevenueCat receive product, purchase, renewal, expiry and entitlement status so Premium access can be delivered and restored. Kail does not receive or store your full payment-card details.

Ads, consent and tracking choices

Free accounts may be shown ads supplied by Google Mobile Ads. The consent flow and available privacy-options entry point are supplied by Google’s User Messaging Platform. On iOS, Kail requests App Tracking Transparency permission before allowing cross-app tracking. Choosing Ask App Not to Track does not disable Kail. Where consent or permission is absent, Kail requests ads in the most privacy-restricted mode supported by its configuration. Google and its ad partners may process device identifiers, ad interactions, approximate network location and diagnostic data under the choices available to you. Kail does not send fishing coordinates to the ad request.

Kail does not sell personal information for money. Advertising processing that may be treated as “sharing” or cross-context behavioural advertising under some laws is controlled through the in-app advertising privacy choices, the iOS tracking permission, and applicable device/store controls.

Diagnostics, security and notifications

Kail uses Firebase services for authentication, private sync, server functions, push messaging, App Check, Remote Config, crash reports and performance diagnostics. App Check supplies abuse-prevention attestation; Kail does not use it to show a device identity to other users. These services can process user/account identifiers, installation or device identifiers, push tokens, IP address, app interaction, crash and performance information. Diagnostic collection is used to secure, operate and improve Kail, not to publish your fishing content.

2. Why data is processed

Kail processes data to provide features you request; authenticate and secure accounts; sync private content; deliver purchases, maps, forecasts and notifications; operate and moderate Community; prevent fraud, spam and abuse; diagnose reliability problems; comply with law; and honour consent or privacy choices. Depending on the applicable law, these purposes rely on performance of our service contract, consent, legitimate interests in operating a safe and reliable service, or legal obligations.

3. Service providers and disclosures

Kail uses the following categories of providers:

  • Google Firebase/Google Cloud for accounts, private sync, functions, notifications, configuration, security and diagnostics; and Google Mobile Ads/User Messaging Platform for ads and consent.
  • Cloudflare Workers, Durable Objects and R2 for Community transport, moderation state, media storage and authenticated v2 media delivery, plus only an explicitly enabled rollback route under the limitation disclosed above.
  • Mapbox for interactive and static maps. Map requests can disclose the viewed area, IP address and device/app request information to Mapbox.
  • RevenueCat and Apple App Store or Google Play for subscription status, purchase and restoration.
  • Apple and Google when you choose their sign-in services.
  • Waktu Solat for Malaysian prayer-zone and schedule requests.
  • Marine, weather, tide and related data providers contacted by Kail’s secured backend to answer forecast requests.

These providers process data under their own terms and privacy notices and may operate in countries outside Malaysia. We may also disclose information when required by law, to protect users or the service, or as part of a business transaction subject to appropriate safeguards. We do not give private catches, spots, tracks or Community content to data brokers.

Provider information:

4. Retention

Private account records are kept while your account is active or as needed to provide a feature. You can delete individual private records in Kail. Account deletion removes the associated operational account data described below. Security, billing and diagnostic records may remain for the periods required by law, fraud prevention, dispute handling or a provider’s documented schedule. Restricted backups can persist until their normal overwrite cycle.

Community uses these specific limits:

  • Visible Community messages and their media are scheduled for removal after 90 days.
  • Unreviewed pending photos and voice notes are scheduled for removal after 7 days without approval.
  • After a final moderation decision, removed-content evidence is available only to authorised moderators for up to 30 days. The author can submit an eligible appeal during that window but cannot reopen the removed content. Moderator access ends at the expiry even if scheduled physical erasure runs later.
  • De-identified message tombstones and resolved report, appeal and moderation action records are scheduled for removal after 180 days. Report and appeal details are erased on resolution. An action audit can retain the subject and moderator user IDs, action, reason, optional note and optional expiry until that scheduled removal.
  • An active restriction or suspension record is retained until its expiry, manual restoration or account deletion. An action without an expiry remains until manual restoration or account deletion.
  • A block relationship lasts until you unblock the member or either account is deleted.
  • Short-lived abuse-prevention counters stop affecting requests after their expiry and are removed by scheduled maintenance.
  • For Community account deletion, Kail keeps an HMAC-pseudonymised deletion guard derived from the former user ID. It is used only to reject late, replayed or other-device Community operations and make the deletion purge retry-safe. Kail’s Firebase deletion service sends an authenticated server-to-server purge immediately before Firebase Authentication deletion; that purge creates or refreshes the guard for 30 days from the latest trusted purge. Scheduled maintenance then removes an expired guard. The raw user ID is used transiently to address the purge but is not stored in this Community guard.

Firebase account deletion uses a separate server-only job and guard keyed by the raw Firebase user ID. App clients cannot read it. The job stores the finite deletion and recovery state needed to finish safely: step/provider failure codes; a bounded list of linked provider types and domain-separated SHA-256 hashes of each provider type plus provider-account identifier; provider-revocation state; a separate domain-separated SHA-256 proof hash derived from the platform-bound Apple proof type and value (an iOS authorisation code or Android access token); provider-snapshot, preparation-lease, authentication-fence and completion timestamps; and temporary shared-trip cleanup work. A manual-recovery case can additionally add its random case reference, finite proof/revision state, domain-separated hashed operator/request/proof metadata, bounded random attempt IDs, finite rate counters, and lease timestamps. The raw third-party provider identifier, Apple authorisation code, Apple access token and Firebase token are not stored in this ordinary deletion guard. A separate, restricted Apple recovery job can temporarily store encrypted credentials as described below. The guard blocks direct and server-mediated account writes while deletion is pending. It remains enforced for at least 30 days and longer when any deletion step or subsequent provider recheck is incomplete; scheduled maintenance removes it only after the minimum period, successful final provider check and job completion.

Because an older Android Kail package was publicly downloadable and can retain the former Firebase identity in the RevenueCat SDK, Kail keeps a separate server-only RevenueCat deletion-retirement record after the ordinary raw-user-ID guard is ready for removal. Its document identifier is a domain-separated HMAC of the former Firebase user ID. The former user ID itself is encrypted with AES-256-GCM under a separate restricted server key so scheduled maintenance can delete a recreated RevenueCat customer even when no webhook is sent. This ciphertext is reversible by Kail’s restricted server and remains personal data; it is not anonymous or HMAC-only data.

That retirement record contains the HMAC and encryption key versions; encrypted user ID, nonce and authentication tag; a fixed purpose code; creation, update, expiry, next-attempt, match, suppression, provider-erasure and retry-lease timestamps as applicable; bounded attempt/suppression counters; random retry lease identifiers; and finite provider/failure state codes. It contains no Community content, purchase payload, provider response body, Apple proof, deletion receipt, support case or email address. It is used only to erase a RevenueCat customer profile recreated by an unsupported pre-49 client.

The rolling retention period is 1,825 days from the latest raw-guard removal attempt or matching old RevenueCat identity event. A matching event extends but never shortens that period. Kail attempts deletion about every 24 hours and immediately when an authenticated RevenueCat lifecycle/transfer event carries a matching identity. At expiry, Kail first requires RevenueCat to confirm deletion or nonexistence before deleting the HMAC and ciphertext together. A temporary, configuration or provider failure can retain the record past nominal expiry until repair and definitive erasure; malformed server records are retained for restricted operator repair and excluded from the due queue. Scheduled physical deletion is not exact to the minute. The V1 HMAC and encryption keys are kept for the lifetime of all V1 records; any rotation must keep old versions until their records are gone. A dormant unsupported client first used after its last rolling expiry remains a finite residual risk, so Kail also seeks removal of old distribution copies.

Kail also creates a random deletion-recovery receipt on the device. The server stores a domain-separated SHA-256 hash of that bearer receipt, its armed, pending, support_required or confirmed state and timestamps—not the original receipt. While support is required, the receipt record also carries the random non-authorising case reference and a finite recovery-proof state: required, checking, verified, not_required or manual_support. A pending receipt hash has no fixed expiry while deletion remains unresolved. If a linked-provider identity changes after the server has revoked Apple access, Kail keeps authentication and writes fenced, stores an identity-free support_required receipt record with that case/proof state, stops automated deletion and requires an audited support process to finish safely. The raw-UID guard and hashed receipt remain until that process completes; contact palasnetwork@gmail.com. A receipt can be marked confirmed after Firebase Authentication is deleted, but receives no expiry while final cleanup or the completed guard’s provider rechecks remain. After those rechecks succeed and the raw-user-ID guard is ready for removal, the confirmed hash is scheduled for removal after a further 180 days so a device that was offline can still prove that server deletion completed without repeating destructive work.

For a support_required deletion, the holder of the valid private receipt can retrieve a random, non-authorising KDR_… case reference and the finite proof state. On iOS, a required fresh one-time Apple code goes directly from Kail to its App-Check-protected server over TLS. On Android, Kail’s protected server creates one opaque, single-use Apple browser state for 15 minutes; Apple posts the code to Kail’s HTTPS callback, and Kail returns the app to one fixed verified App Link carrying no code, state, receipt, case reference or result. A second Android attempt cannot replace a still-live browser state. Support staff and operators never receive the Apple code or token.

After either recovery flow exchanges the one-time code, a separate server-only job encrypts Apple’s returned refresh token and ID token with AES-256-GCM under a restricted, versioned key that is separate from Kail’s other deletion keys. The job contains the ciphertext, nonce, authentication tag and key version; domain-separated receipt, case, provider-subject and proof-attempt bindings; the iOS proof sentinel or hashed Android web-state binding; finite identity-verification, provider-result and failure states; and creation, update, retry, lease and nominal-expiry timestamps. The job contains no Community content, email address or raw Firebase user ID, and the code and decrypted tokens are never logged. Kail durably verifies the Apple identity before the first revocation request. Only Apple’s definitive HTTP 200 result allows automated proof completion and ciphertext deletion. The nominal retention target is 24 hours, but provider, configuration, integrity or recovery failures retain the encrypted job beyond that target until definitive revocation or restricted, audited repair; it is not deleted by an automatic database time-to-live rule.

One recently authenticated restricted operator may approve a recovery case and a different recently authenticated restricted operator may execute it. Neither operation accepts or returns the deleted account’s user ID, provider ID, private receipt, Apple code or token. If an exact encrypted recovery job is proven irrecoverable after audited key restoration and retry are exhausted, that same two-person process may complete Kail data deletion without claiming that Apple revoked the grant. Kail then keeps a durable manual-revocation flag, shows the user an instruction to stop using Kail in Apple account settings, and retains the raw-user-ID guard beyond its normal minimum until a newer matching signed Apple revocation notification clears the flag.

While an Apple-linked account is active, each production device can also register a random 256-bit lifecycle-recovery bearer. Its server-only registration root is keyed by the Firebase user ID; within that root Kail stores the bearer’s domain-separated hash, a domain-separated Apple subject hash, the fresh Apple-authentication checkpoint, expiry and a bounded registration revision. At most eight can be active for an account. Registration is renewed for 400 days and the app begins renewal 30 days before expiry. An armed receipt does not authorise deletion; it lets that signed-out device reconcile the result of a verified Apple server notification. Active receipts are attached to an Apple-linked deletion before destructive work, mirror support or confirmation, and receive the same further 180-day confirmed-receipt window.

Kail’s Apple server-notification endpoint verifies Apple’s signature, issuer, native-app audience, event type and time. For replay control it stores only domain-separated hashes of the Apple subject, event identifier and payload, plus finite result state and timestamps. Terminal notification records are scheduled for removal after 45 days; unresolved pending or guard-bound records are retained, extended and re-alerted until safely resolved. The raw Apple subject exists only while processing the request and is not stored or logged. A valid consent-revoked or account-deleted event can fence and delete the linked Kail account’s server data even if no lifecycle bearer was registered; a bearer is only for device reconciliation. The app independently checks Apple credential state on supported Apple devices, quarantines access when revocation is indicated, and waits for a confirmed server receipt before erasing local account data.

Kail stores a separate content-free recovery audit containing, as applicable, domain-separated SHA-256 hashes of the case, operator and request identifiers; finite event, result and failure codes; timestamps and expiry; and final deletion milestones. It contains no raw user ID, provider user ID, case reference, private receipt, Apple code, token or Community content. These audit records are scheduled for removal after 365 days; physical removal runs in bounded scheduled maintenance and is not represented as exact to the minute.

Kail’s Cloudflare service does not log user secrets, authentication tokens or Community content.