TSD — Privacy Policy
Controller: Peter Gimpeliovsky, licensed dealer (עוסק מורשה) no. 347898975, 8 HaGefen St., Kfar Saba, Israel, trading as Kadimasoft ("we", "us", "Provider").
Effective date: 2026-06-27 · Published at https://kadimasoft.com/legal
This Privacy Policy explains how we handle personal data for which we are the
controller when you use the TSD application and the license_server
backend (the "Service"). It is written to meet the Israeli Protection of
Privacy Law, 5741‑1981 (as amended, including Amendment 13, in force 14
August 2025), the Privacy Protection (Data Security) Regulations, 5777‑2017,
and — where it applies — the EU General Data Protection Regulation (GDPR).
Where we process personal data on behalf of a business customer (the data in their ERPNext system — their customers, contacts, orders), that customer is the controller and we are the processor. That processing is governed by our Data Processing Agreement, not by this Policy. This Policy covers the data we decide the purposes and means for ourselves.
1. Scope and roles
The Service is a business tool used by warehouse and sales organisations ("Customers") and their staff ("Operators"). Personal data touched by the Service falls into two buckets:
- Data we control (this Policy): operational telemetry, crash reports, device & security records, authentication metadata, and the contact details of the Customer's administrator/billing contact.
- Data we process for the Customer (the DPA): the Customer's ERPNext business and contact data.
If you are an Operator, please also read the Operator Privacy Notice.
2. What personal data we collect (as controller)
We deliberately minimise what we collect. The App does not collect location data, the device's contact list, photos, or files. Barcode scanning runs entirely on the device (no images leave the device).
2.1 Account & contact data
When a Customer signs up or is onboarded, we hold the business contact details of the administrator/billing contact (name, work email, company, phone if given) and the Customer's company/tenant code.
2.2 Authentication & device records
To run and secure the Service we store:
- a persistent random device identifier (device_id, a UUID generated on the
device) — it does not contain personal information by itself but identifies a
device over time;
- the Operator's ERP username and display name and their assigned roles and
permissions (needed to scope what the App may show);
- authentication tokens — a short-lived access token and a refresh token
stored only as a hash on our server (so it can be revoked); on the device,
credentials and tokens are kept in encrypted storage (AES‑256‑GCM);
- the device's IP address and basic device metadata (device model, OS
version, app version), recorded at activation and used for security and
support;
- a push token (FCM, see §4) so we can prompt the device to sync.
2.3 Daily operational telemetry
Once a day the App uploads an aggregate performance report. It contains: device id, tenant code, the Operator's roles, app version, the reporting time window, and operational metrics — sync latencies and success rates, push messages received, outbox queue depth, barcode-scan-to-acknowledgement latencies, bytes sent/received, number of network calls, and per-background-job success rates. It contains no document content and no customer business data.
2.4 Crash and diagnostic data
If the App crashes, a crash report (stack trace, app/OS version, device model) is sent to our crash-reporting provider (Google Firebase Crashlytics) so we can fix defects. Crash reports can incidentally include technical identifiers; we work to minimise any personal data in them. (If we offer an in-app opt-out for crash reporting, it is in Settings.)
2.5 Security & audit logs
Our backend records audit logs of significant write actions (for example, creating a delivery from an order, or a failed picking operation), including the acting Operator's username, the device, the action, a timestamp, and action-specific metadata such as document identifiers and failure reasons. These support security, troubleshooting, and accountability.
2.6 Support communications
If you contact us, we keep the correspondence and its contents to handle your request.
3. Why we process it, and our legal basis
| Purpose | Data used | Legal basis (GDPR, where applicable) |
|---|---|---|
| Provide and operate the Service (auth, sync, push) | §2.1, §2.2 | Performance of a contract (Art. 6(1)(b)); our legitimate interest in delivering the Service (Art. 6(1)(f)) |
| Secure the Service; prevent abuse; revoke lost devices | §2.2, §2.5 | Legitimate interest in security (Art. 6(1)(f)); legal obligation where applicable (Art. 6(1)(c)) |
| Monitor fleet health and improve performance | §2.3, §2.4 | Legitimate interest in maintaining/improving the Service (Art. 6(1)(f)) |
| Billing and account management | §2.1 | Performance of a contract; legal obligation (tax/accounting) |
| Support | §2.6 | Performance of a contract; legitimate interest |
Under Israeli law, processing rests on the data subject's consent (express or implied through use after notice) and on our legitimate operational needs as described in this Policy. Where we rely on legitimate interest under the GDPR, we have weighed it against your rights; you may object (see §8).
4. Push notifications and crash reporting (Google)
The App uses Google Firebase Cloud Messaging (FCM) to deliver "go and sync" signals and Firebase Crashlytics for crash reports. To do this, a device push token and crash diagnostics are processed by Google, which may process them outside Israel/the EEA (including in the United States). We rely on Google's data-protection terms and appropriate safeguards (see §7). FCM "sync trigger" messages we send do not contain personal or business content.
5. Who we share data with (sub-processors & recipients)
We do not sell personal data. We share it only with service providers that help us run the Service, under contracts that bind them to protect it:
- Hosting / infrastructure — netcup GmbH (Germany (EU)) hosts our backend, the customer-facing hosted ERPNext instances, the databases, and backups. The Customer's commercial data therefore resides in the EU (Germany).
- Google (Firebase) — push delivery (FCM) and crash reporting (Crashlytics).
- Telegram — only if a salesperson chooses to connect the manager-helper bot (their Telegram chat id/username and message content are then processed by Telegram).
- GitHub — distributes the signed app update package (no personal data).
- Professional advisers / authorities — where required by law, legal process, or to establish/defend legal claims.
- Successors — in a merger, acquisition, or asset sale, subject to this Policy.
A current sub-processor list is maintained in our sub-processor register. The Customer's business data held in the Provider-hosted ERPNext instance is processed by us as processor on the Customer's behalf under the DPA, not under this Policy.
6. Data security
We apply technical and organisational measures appropriate to the risk and to the security level required by the Data Security Regulations 2017, including:
- Encryption in transit (HTTPS/TLS) for all App↔server communication;
- Encryption on the device — credentials and tokens in
EncryptedSharedPreferences(AES‑256‑GCM), and the local data mirror with SQLCipher; - Encryption of secrets at rest on the server (ERP credentials, channel tokens) using authenticated (Fernet) encryption;
- Refresh tokens stored only as hashes, with rotation and the ability to revoke a whole device on suspected theft;
- Per-tenant isolation in the database (row-level security) so one Customer's data is not accessible to another;
- Role-based access control enforced at the server boundary;
- access controls, rate limiting, and audit logging.
No system is perfectly secure. We maintain a process to detect, investigate, and respond to security incidents, and we will notify affected parties and the Privacy Protection Authority and/or supervisory authorities where the law requires (including, under the GDPR, within 72 hours where feasible).
7. International transfers
Our primary hosting is in Germany (EU). Some sub-processors (notably Google) may process data outside Israel and the EEA, including in the United States. Where personal data is transferred internationally we rely on lawful transfer mechanisms — for example the EU Standard Contractual Clauses and the recipient's certifications/commitments — and on Israel's status as a country recognised by the EU as providing adequate protection. You may ask us for more detail at kadimaonly@gmail.com.
8. Your rights
Subject to applicable law, you may:
- access the personal data we hold about you and receive a copy;
- request correction of inaccurate data (a right expressly provided under Israeli law);
- request deletion of data we no longer need or that we hold without a lawful basis;
- object to or request restriction of processing based on legitimate interest, and object to direct marketing at any time;
- where the GDPR applies, exercise portability and rights regarding automated decision-making (we do not make decisions producing legal effects about you by automated means);
- withdraw consent where we relied on it, without affecting prior processing.
To exercise a right, contact kadimaonly@gmail.com. We will respond within the period the law requires (under the GDPR, normally within one month). If you are an Operator, some requests may need to go through your employer (the Customer), who is the controller of the business data; we will direct you appropriately. You also have the right to complain to the Israeli Privacy Protection Authority (הרשות להגנת הפרטיות) or, in the EEA, your local supervisory authority.
9. Retention
We keep personal data only as long as needed for the purposes above or as the law requires:
- Account & billing data — for the relationship and then as required by tax and accounting law (in Israel, generally seven (7) years).
- Authentication — access tokens are short-lived; refresh tokens expire after 90 days and are revoked on logout or device wipe.
- Telemetry, device records (incl. IP), and audit logs — for up to 24 months, then deleted or aggregated. (Set and enforce this — see the operational checklist in the README.)
- Crash reports — per our crash provider's retention (typically up to 90 days).
- Support correspondence — for as long as needed to handle and document the request.
When a Customer's account is closed, we delete or return Customer Data per the DPA and delete the controller data above on the schedule stated, except where retention is legally required.
10. Children
The Service is a workplace tool not directed to children and is not intended for anyone under 16. We do not knowingly collect data from children.
11. Changes to this Policy
We may update this Policy. For material changes we will give reasonable notice (in-app, by email, or at https://kadimasoft.com/legal) and update the effective date. Your continued use after the change takes effect constitutes acceptance to the extent permitted by law.
12. Contact and privacy responsibility
For any privacy question or to exercise a right:
- Privacy contact: Peter Gimpeliovsky — kadimaonly@gmail.com
- Provider: Peter Gimpeliovsky, 8 HaGefen St., Kfar Saba, Israel
If, under Amendment 13, we are required to appoint a Data Protection Officer (ממונה על הגנת הפרטיות), that officer's contact details will be published here.
13. Language
This Policy is provided in English and Hebrew. The Hebrew version governs in case of any conflict or discrepancy between the two versions.