Privacy Policy Version History

This page contains an archive of all versions of the Kalum Privacy Policy. We maintain complete version history for transparency. The current version is always available at the main privacy policy page.

All Versions

Version 2026-10-06

Current Version

Effective Date: October 6, 2026

Status: Active

Summary: §2.9 now says that if your phone is set to a country where we cannot open accounts yet, the app counts that once, as a total for that country with no identifier. It tells us where people want Kalum next. No other privacy practices changed.

Key Points:
  • §2.9: a phone set to a country where accounts cannot be opened yet is counted once per device, by that country's calling code only
  • Like every setup count, it carries no identifier, no timestamp and no per-event record
  • No change to sub-processors, retention or your rights
View Current Version

Version 2026-10-03

Archived

Effective Date: October 3, 2026

Status: Superseded by 2026-10-06

Summary: On iOS, each purchase now carries an account token, a code derived from your account identifier that Apple cannot turn back into it, so a purchase is credited only to the Kalum account that made it even when another account signs in on the same device first. §2.2 and the Apple row in §4.1 describe it. §2.9 now says that a first purchase and a first call are counted once for an account created on a device, rather than once per device. §2.3 lists the last number called, which the app keeps briefly for the after-call rating and removes at sign-out. No other privacy practices changed.

Key Points:
  • §2.2 and §4.1: an account token on each iOS purchase; Apple still receives no phone number or account identifier
  • §2.9: first purchase and first call counted once per new account on a device, never for an existing account signing in there
  • §2.3: the last number called is kept on the device only, and removed at sign-out
  • No change to sub-processors, retention or your rights
View Archived Copy

Version 2026-09-29

Archived

Effective Date: September 29, 2026

Status: Superseded by 2026-10-03

Summary: Two cross-references to the new §4.3 “Caller ID” of the Terms of Use, and no change of substance. §2.1 now says that your phone number is not shown to the people you call, because calls are placed from a shared outbound number we control. The Twilio row in §9 now says that your phone number is not passed to Twilio as the caller ID. What is collected, shared and kept is unchanged.

Key Points:
  • §2.1: your phone number is not the caller ID the person you call sees
  • §9 Twilio row: your phone number is not passed to Twilio as the caller ID
  • Both cross-reference §4.3 of the Terms of Use
  • No change to what is collected, to sub-processors, to retention or to your rights
View Archived Copy

Version 2026-09-26

Archived

Effective Date: September 26, 2026

Status: Superseded by 2026-09-29

Summary: Adds §2.11 “Family Wallet”, which lets up to five users call on one owner's balance without moving money between accounts. It states what is kept (membership and dates, monthly limits, single-use invite codes, and how much of each member call the family wallet paid), what each side sees (the owner: members' last four digits and monthly spend; a member: the owner's last four digits and what is left), and that no one sees anyone else's destinations. §2.2 adds the credit reserved during a call and which balance paid for it. §3, §9 and §14 gain matching rows. No other privacy practices changed.

Key Points:
  • New §2.11: family wallet membership, limits, invite codes and per-member spend
  • The owner sees last four digits and spend only — never the numbers or countries a member called
  • §2.2: per call, the credit reserved and charged and which balance paid
  • Family records are deleted with your account
  • No change to sub-processors or your rights
View Archived Copy

Version 2026-09-23

Archived

Effective Date: September 23, 2026

Status: Superseded by 2026-09-26

Summary: Names NeuEra Apps LLC as the operator of Kalum and as the data controller. Earlier versions named the operator as “NeuEra Apps” and listed an individual by name in the contact section. This version names the legal entity, NeuEra Apps LLC, instead. §1 “Who We Are” and §13 “Contact” are updated to match. No privacy practices changed.

Key Points:
  • Data controller in §1, including for users in the EEA, UK and Switzerland, is NeuEra Apps LLC
  • Service operator in §13 is NeuEra Apps LLC
  • No individual is named as operator
  • No change to what is collected, sub-processors, retention or your rights
View Archived Copy

Version 2026-09-20

Archived

Effective Date: September 20, 2026

Status: Superseded by 2026-09-23

Summary: Discloses two aggregate measurements that were already running and had no section. New §2.9 “Aggregate Setup Measurement” covers the counts kept as someone sets the app up for the first time — the step reached, the destination’s country calling code where there is one, the platform and the app version — and states that two versions of the first-run experience are tried, with the choice made by a coin flip on the device and recorded only as a single letter. New §2.10 “Aggregate Refused-Call Measurement” covers the counts kept when a call to a destination we do not connect is refused: the country calling code and the reason, never the number dialled. Both carry no identifier, no timestamp on any count and no per-event record, and both add matching rows to §3 and §14. No new data is collected by this version; it describes collection that was already in place.

Key Points:
  • New §2.9: setup steps are counted per step, destination code, platform and app version — totals only
  • Which of two first-run experiences a device sees is decided on the device; only the letter is counted, and no server learns which device drew what
  • Counts that mean something only once — first open, first purchase, first call — are sent at most once per device, so a total is devices and not taps
  • New §2.10: refused calls are counted per destination code and reason; the number dialled is not recorded and a refused call is not charged
  • Nothing to retrieve or delete per person in either, because neither identifies anyone
  • No change to call metadata, transactions, sub-processors, retention or rights
View Archived Copy

Version 2026-09-11

Archived

Effective Date: September 11, 2026

Status: Superseded by 2026-09-20

Summary: Adds §2.8 “Campaign Landing Pages”. Links to Kalum from video descriptions, creator pages or printed QR codes may open a short landing page before the app store; opening it and tapping a store button each add one to a daily count for that campaign. The section states the whole record — campaign name, day, total — and that no visit is recorded on its own and no identifier, IP address, browser detail or referring page is kept. It also states that app-store install figures per campaign reach us only in aggregate under the stores’ own terms. §14 gains the matching summary row. No other privacy practices changed.

Key Points:
  • New §2.8: campaign landing page views and button taps are daily totals per campaign
  • No per-visit record, no identifier, no IP address, no browser or referrer detail
  • Store install counts per campaign arrive in aggregate from Apple and Google, never who installed
  • Nothing to retrieve or delete per person, because the data identifies no one
  • No change to call metadata, transactions, sub-processors, retention or rights
View This Version

Version 2026-09-10

Archived

Effective Date: September 10, 2026

Status: Superseded by 2026-09-11

Summary: Documents the optional after-call rating added in 2026-09. §2.2 names the one-tap rating and issue tag as call metadata you may choose to give. New §2.7 “Aggregate Call-Quality Measurement” records that answers are counted per destination country code, platform, answer and issue — no identifier, no timestamp on any count, no per-answer row and no free-text field — and states the purpose: turning a pattern of dropped or one-way calls to one destination into a routing decision. §4.1 discloses that an answered rating is also attached to that call’s record at Twilio so it can be compared against Twilio’s network measurements, and §9 records that Twilio holds it for 30 days. §3 and §14 updated to match. No other privacy practices changed.

Key Points:
  • Optional one-tap rating after some calls; skipping is always available and records only that it was skipped
  • New §2.7: answers are counted, not recorded — no identifier, no timestamp, no per-answer row, no free text
  • Asked more often after calls that appear to have gone wrong; never a question about the app and never a route into an app-store review
  • Answered ratings are additionally attached to the call record at Twilio for comparison with its jitter, packet-loss and delay measurements; kept there 30 days
  • New purpose row in §3 (legitimate interest), new retention row in §9, new summary row in §14
  • No new identifier, no change to sub-processors, and no change to your rights
View Archived Copy

Version 2026-08-17

Archived

Effective Date: August 17, 2026

Status: Superseded by 2026-09-10

Summary: Corrects and narrows §2.6. The separate website counter described in 2026-08-16 was retired, so the paragraph describing it is removed — no destination lookups are counted on kalum.app at all. §2.6 now also names the three non-identifying dimensions each count carries besides the destination (whether the request came from a verified copy of the app, whether a sign-in token was attached, and whether the device was iOS or Android), states that a small total may reflect a single lookup rather than many contributors, and discloses that one date is kept for the measurement as a whole — when the current counting period began — while no count carries a timestamp. No other privacy practices changed, and nothing new is collected.

Key Points:
  • Website destination counting withdrawn entirely; the paragraph describing it is removed
  • §2.6 now names every dimension a count carries, not only the destination
  • "No timestamp" scoped precisely: no count carries one; one counting-period start date is kept for the measurement as a whole
  • Wording corrected so it remains true of a destination looked up only once
  • No new collection, no new sharing, no change to retention, sub-processors or rights
View Archived Copy

Version 2026-08-16

Archived

Effective Date: August 16, 2026

Status: Superseded by 2026-08-17

Summary: Documents the aggregate demand measurement added in 2026-08. New §2.6 records that a destination rate lookup increments a per-destination counter holding the country calling code and at most three national digits, with no identifier, no timestamp and no per-event row — and states plainly that because it identifies no one, there is nothing within it to retrieve or delete on request. Also discloses the separate, country-level-only counter for lookups made on kalum.app. Links the NeuEra Apps Data Practices Charter as the governing standard. No other privacy practices changed.

Key Points:
  • New §2.6 "Aggregate Demand Measurement" — what is counted, and what is deliberately not
  • Country calling code plus at most 3 national digits; none at all where the calling code is 4+ digits
  • No identifier, no timestamp, no per-event row — the counts cannot be separated back out
  • States that an access or erasure request has nothing to act on, because the data identifies no one
  • Purpose stated: negotiating better rates on the routes people actually price, including abandoned lookups
  • Website lookups counted separately, at country level only, never combined with the app's counts
  • Links to the NeuEra Apps Data Practices Charter (Tier A) as the governing standard
  • No change to call metadata, transaction data, sub-processors, retention or rights
View Archived Copy

Version 2026-05-24

Archived

Effective Date: May 24, 2026

Status: Superseded by 2026-08-16

Summary: Updated to reflect the rollout of Apple in-app purchases on iOS and additional opt-in flows. Added Apple Inc. as a sub-processor for App Store payment processing, restructured the iOS/Android permissions section to list optional permissions invoked by the Stripe SDK (camera, photo library, biometrics, approximate location) and the new opt-in contact-import flow (iOS Contacts / Android READ_CONTACTS), removed absolute "does not collect" claims that no longer fit the optional flows, and noted that account deletion is now available in-app at Settings → Delete Account.

Key Points:
  • Apple Inc. added as a sub-processor for iOS in-app purchase processing (StoreKit)
  • Stripe role clarified: Android and web only (cards, Google Pay)
  • New §2.5 documents opt-in permission flows (contacts, camera, photo library, biometrics, location)
  • Android READ_CONTACTS added for opt-in "Import from contacts"
  • iOS permission section expanded to list all Info.plist declarations
  • Apple privacy policy added to third-party notices
  • Account deletion now available in-app (Settings → Delete Account)
  • Receipt-validation idempotency added to security controls
View Archived Copy

Version 2026-05-04

Archived

Effective Date: May 4, 2026

Status: Superseded by 2026-05-24

Summary: Aligned the Privacy Policy with the current product. Disclosed Firebase App Check and Firebase Crashlytics, clarified that contacts are manually added in-app (no device address-book import), added GDPR/UK lawful bases and EEA/UK rights, expanded data-retention disclosure for financial records, and enumerated the iOS/Android permissions actually requested by the app (no AD_ID, no location).

Key Points:
  • Sub-processors expanded: Firebase Auth, Firebase App Check, Firebase Crashlytics, Twilio, Stripe, Fly.io
  • Apple Pay and Google Pay disclosed as Stripe-routed payment methods
  • "Manually added" contacts only — no OS address-book import
  • GDPR / UK GDPR rights and lawful bases added
  • iOS and Android permissions explicitly listed; AD_ID confirmed removed
  • Financial-records retention up to 7 years for tax and anti-fraud
  • Standard Contractual Clauses for international transfers
  • No analytics, telemetry, or advertising SDKs
View Archived Copy

Version 2026-02-07

Archived

Effective Date: February 7, 2026

Status: Superseded by 2026-05-04

Summary: Initial privacy policy for Kalum prepaid VoIP calling service.

Key Points:
  • Phone number verification via Firebase Authentication
  • Call metadata collected for billing (destination, duration, timestamps)
  • Payment processing via Stripe (we never see card details)
  • Voice call audio handled by Twilio (we never access call content)
  • No advertising or third-party marketing
  • CCPA compliance for California residents
  • 18+ age requirement
  • Data security with encryption in transit and at rest
View Archived Copy

About Our Version History

We believe in transparency. Every time we update our privacy policy, we:

  • Create a permanent archived copy of the previous version
  • Update the effective date on the new version
  • List all versions on this page for your reference
  • Maintain this archive indefinitely

Our core commitment remains unchanged: we collect only the minimum data necessary to provide our calling service, and we never sell your personal information.