iDaka Privacy Policy

• Version: 1.0
• Effective date: 2026-09-01
• Last updated: 2026-08-05
• Applies to: the iDaka management console at web.i-daka.com and the iDaka mobile apps for iOS and Android
• Governing law: the Personal Data Protection Act of the Republic of China (Taiwan) (個人資料保護法, "PDPA") and its Enforcement Rules

1. Introduction

1.1 Plain English, not legalese

We have tried to write this policy so that a person can actually read it. Where we have to use a legal term, we explain it. Where the PDPA requires specific wording, we say so and give the plain meaning next to it.

1.2 Who we are

璽樂科技股份有限公司 (Xile Technology), unified business number 82878484, trading as iDaka, with its registered office at Rm. 5, 7th Fl., No. 46, Minxiang 3rd St., Hualien City, Hualien County 970007, Taiwan.

Where the English and Chinese names differ, the Chinese company name is the legally operative one.

In this document, "iDaka", "we", "us" and "our" mean that company. "the Service" means:

• the iDaka management console at web.i-daka.com;
• the iDaka mobile app for iOS and Android; and
• the iDaka messaging app together with the self-hosted communications server behind it at agent.i-daka.com.

1.3 Scope of this document

This policy covers the Service as defined above, and nothing else. Specifically:

In scope

• Your iDaka account and how you sign in to the console and the apps.
• What the console and the apps record while you use them (logs, device information, diagnostics).
• Messages, media and push notifications handled by the messaging features.

Out of scope

• On-site devices deployed at a Customer's premises — facial recognition access terminals, AIBOX video analytics units, IoT sensors, in-vehicle cameras and similar equipment. Personal data captured by that equipment is collected under the Customer's own privacy notice and our data processing agreement with that Customer, not under this policy.
• Third-party platforms you separately choose to use — for example LINE, the Apple App Store, or Google Play. Their own privacy policies apply to what they do with your data.

1.4 The Customer and the User — and why our role changes between them

The PDPA distinguishes between the party that decides why personal data is collected (the collector, 蒐集者) and a party that only handles data on someone else's instructions (an entrusted party, 受託處理者, under PDPA Article 4 and Enforcement Rule Article 8). Our role depends on whose data it is:

A single person can be both: an administrator at a Customer is also a User with their own account.

Where we act as an entrusted party, the Customer remains subject to PDPA Article 8 notice obligations towards its own staff. We supply a template notice on request, but issuing it is the Customer's responsibility, not ours.

1.5 Changes to this document

If we make a material change, we will give Customers reasonable notice before it takes effect, by a notice in the console and in the apps, and by notifying the Customer's administrative contact through the channel set out in our contract with them. Continuing to use the Service after the effective date means the new version applies. Every version is listed in §13.

2. PDPA Article 8 notice

PDPA Article 8 requires us to tell you six specific things before we collect your personal data. This section is that notice in the statutory order. The rest of the document explains each item in more detail.

3. What we collect, and why

We collect the minimum needed to run the Service. We do not build advertising profiles, and we do not sell personal data to anyone.

3.1 Information you or your organisation provide

We do not collect an email address for your account. Your account identity is your mobile number, and we do not send you account or system email or SMS.

3.2 Information collected automatically

The mobile apps do not use third-party advertising or analytics SDKs, and we do not profile you for advertising.

Location. We do not collect your location. The console and the mobile apps do not record where you are, and we do not track your movements.

3.3 Messaging in the mobile app

The messaging features run on our own self-hosted communications server at agent.i-daka.com. We operate it. It is not a public service, and it is not federated with any outside server — your messages are not exchanged with other organisations' communications servers, and no outside server holds a copy of them.

• Account: a messaging account is created for you in the form @u<mobile number>:agent.i-daka.com, separate from your console account but provisioned from it.
• Message content: conversations are end-to-end encrypted by default. For an encrypted conversation, the server stores only ciphertext. Nobody at iDaka can read it — not our engineers, not our infrastructure provider, and not anyone who compels us to hand over the data. We can only produce what we hold, which is ciphertext.
• Unencrypted conversations: if encryption is turned off for a particular room, the content is technically readable on the server. We access it only in the circumstances in §7.3.
• Metadata: even for encrypted conversations, the server necessarily holds who is in which conversation, when messages were sent, and message sizes. Encryption protects content, not the fact that a conversation happened.
• Media: files and images you send are stored in our media store in the AWS Asia Pacific (Tokyo) region, encrypted for encrypted rooms.
• Encryption keys: device keys and cross-signing material are held on your devices. If you lose every device and have no key backup, encrypted history is unrecoverable — by design, and we cannot restore it for you.

3.4 Push notifications

To notify you when an app is in the background, we run our own push gateway and forward a minimal payload from it to Apple Push Notification service (iOS) or Firebase Cloud Messaging (Android). We do not use anyone else's push gateway.

• We store the push token your device's operating system issues, linked to that app installation.
• For messaging notifications, the payload we send to Apple or Google contains only an event identifier and a conversation identifier — no sender name, no message text. Your device fetches and decrypts the message locally before it is displayed.
• Operational alerts sent by the platform itself — a safety alarm, for example — are different: they carry a readable title and body, which is the point of them. Where a Customer has enabled an alert, it may be delivered to every member of the relevant project.
• Push tokens are deleted when you sign out or uninstall, and are rotated by the operating system.

3.5 Cookies and local storage

The console uses cookies and browser local storage that are strictly necessary for the Service: keeping you signed in, holding your session token, and remembering interface preferences such as language. We do not use advertising cookies, third-party tracking cookies, or web analytics.

You can clear these through your browser, but you will be signed out and some preferences will reset.

3.6 Site-entry applications and identity confirmation

Where a Customer uses the site-entry workflow, you may be asked through the console or an app to submit an entry application containing your photograph and any certificates the Customer requires. To confirm that the applicant is the account holder, we compare the photograph you submit against the photograph already held on your record, using an automated facial comparison service operated by our cloud provider in the AWS Asia Pacific (Tokyo) region.

• The comparison produces a similarity score. It is used only to accept or flag the application; the Customer makes the final decision, and no consequence follows from the score alone.
• We do not use these photographs to identify you anywhere else, and we do not share them with anyone other than the Customer and the provider performing the comparison.
• The access control terminals installed at a Customer's site are out of scope of this policy (§1.3) and are governed by the Customer's own notice.

4. Our legal basis under the PDPA

As a non-government agency we may collect and process personal data only on one of the grounds in PDPA Article 19, and may use it only within the scope of the specific purpose (Article 20). We rely on:

• Article 19(1)(2) — a contractual or quasi-contractual relationship: the main basis. Your organisation has a contract with us, and running your account is how we perform it. We maintain the security measures that this ground requires (§7).
• Article 19(1)(5) — your consent: where a feature is genuinely optional, such as push notifications. Consent can be withdrawn at any time; see §8.
• Article 19(1)(1) — express provision of law: where a statute or a competent authority requires us to keep or produce records.
• Article 19(1)(7) — a legitimate business interest in keeping the Service secure and abuse-free, balanced against your interests, for security logging.

Special-category data. PDPA Article 6 restricts data on medical records, healthcare, genetics, sex life, physical examinations and criminal records. We do not collect any of these through the console or the mobile apps.

5. How long we keep data

Our standard retention period is two years. Unless a longer period is required by law, we delete personal data two years after we no longer need it for the purpose it was collected for.

When a retention period ends we delete the data or irreversibly anonymise it. Backups are rotated on their own cycle, so a deleted item may persist in encrypted backups for up to 30 days after it is deleted from the live system.

6. Who else touches your data

We share personal data only as described here. We do not sell personal data, and we do not disclose it for anyone else's marketing.

6.1 Service providers

Each is bound by contract to process data only on our instructions and to maintain appropriate security. We supervise them as PDPA Enforcement Rule Article 8 requires of an entrusted party.

6.2 Your organisation

If your account was created by a Customer, that Customer's administrators can see your account details, your role and permissions, your activity within their workspace, and any content you post in unencrypted areas of their workspace. Your organisation's own policies govern what they do with that.

6.3 Cross-border transfer

Our infrastructure is in the AWS Asia Pacific (Tokyo) region in Japan. Storing Taiwanese personal data there is a cross-border transfer under PDPA Article 21. We rely on the fact that the competent authority has not restricted transfers of this kind for our industry, and we impose contractual security obligations on the provider. If a competent authority restricts such transfers in future, we will relocate the affected data or obtain the necessary approval before continuing.

Push notification delivery involves a transfer of the minimal payload in §3.4 to Apple and Google infrastructure outside Taiwan.

6.4 Legal and safety disclosures

We disclose personal data to authorities or third parties only when we reasonably believe it is necessary to comply with a law, court order or lawful request from a competent authority; to enforce our agreements; to protect the security and integrity of the Service; or to prevent imminent serious harm to a person. We disclose only what we can technically access — which for end-to-end encrypted content is ciphertext only, as explained in §3.3. Where we are legally permitted to do so, we notify the affected Customer before disclosing.

6.5 Business transfers

If iDaka is involved in a merger, acquisition or sale of assets, personal data may be transferred as part of the transaction. We will notify affected Customers before their data becomes subject to a different privacy policy.

7. Security

7.1 Technical measures

• All traffic between your browser or app and our systems is encrypted with TLS.
• Passwords are stored as salted one-way hashes, never in readable form. We use bcrypt with a cost factor of 12 and a unique per-password salt, for both console and messaging accounts. Even we cannot read your password; if you forget it, we reset it rather than tell you what it was.
• Selected sensitive fields are encrypted at rest with AES-256 in addition to storage-level encryption.
• Messaging content is end-to-end encrypted by default (§3.3).
• Databases sit in private subnets and are not reachable from the public internet; administrative access requires an authenticated tunnel.

7.2 Organisational measures

• Access to production personal data is limited to personnel whose role requires it, and is reviewed periodically.
• Engineers investigating a fault use read-only credentials by default; write access to production data requires a specific reason.
• Administrative actions in the console are recorded in an audit log.

7.3 When our staff can see your data

Our engineers may access unencrypted data only to operate, secure or repair the Service, to investigate a fault the Customer has reported, or where the law requires it. They cannot decrypt end-to-end encrypted content, and we do not attempt to.

7.4 Your part

Keep your password to yourself, use a distinct one, and enable any additional protection the Service offers. Tell us immediately, using the contact details in §11, if you believe your account has been compromised.

7.5 Data breach notification

If personal data is stolen, leaked, altered or otherwise infringed, PDPA Article 12 requires us to notify the affected individuals after investigating. We will notify affected Customers and, where we are the collector, affected individuals, without undue delay once we have established what happened, and we will report to the competent authority where required.

7.6 Reporting a vulnerability

Report security vulnerabilities using the contact details in §11. We welcome good-faith research and will not pursue researchers who report responsibly and do not access or destroy other people's data.

7.7 The honest limit

No system is perfectly secure. We take the measures above seriously, but we cannot guarantee that a sufficiently determined and well-resourced attacker will never succeed. End-to-end encryption is what limits the damage if they do.

8. Your rights

Under PDPA Article 3 you have five rights over your personal data, and you cannot waive them and we cannot contract out of them:

1. Inquire about or review your personal data.
2. Obtain a copy of it.
3. Request supplementation or correction of it.
4. Request that we stop collecting, processing or using it.
5. Request deletion of it.

How to exercise them

Contact us using the details in §11, with enough information for us to find your record and confirm your identity. Many things — your profile, your notification settings, your messages — you can change or delete yourself in the console or the app, which is faster.

If your account was created by a corporate Customer, we act as an entrusted party for most of that data (§1.4). Please contact your organisation first; if you contact us, we will pass the request to them and support them in answering it.

How long we take

PDPA Article 13 sets the deadlines and we follow them:

• Inquiry, review, or a copy: within 15 days, extendable once by up to 15 days if necessary, with reasons given.
• Supplementation, correction, discontinuation or deletion: within 30 days, extendable once by up to 30 days, with reasons given.

We may charge the necessary cost of producing a copy, as PDPA Article 14 permits. We may refuse a request only on the grounds the PDPA allows, and if we do we will tell you why.

Limits

Some data we must keep even after a deletion request — for example accounting records required by law, or records we need to establish or defend a legal claim. Where that applies we restrict the data to that purpose rather than continuing to use it normally.

9. Children

The Service is a workplace tool sold to organisations and is not directed at children. We do not knowingly collect personal data from anyone under 18. If you believe a child has provided us with personal data, contact us using the details in §11 and we will delete it.

10. Complaints

If you think we have handled your personal data unfairly or misleadingly, tell us first using the details in §11 — we would rather fix it than argue about it.

If you are not satisfied with our answer, you may complain to the competent authority — the Personal Data Protection Commission, or the regulator with competence over our industry — and you may also raise the matter with the local government of the city or county where we are registered.

You also retain your right to bring a civil claim under PDPA Chapter 4.

11. Contact

12. Definitions

13. Document history