Law Enforcement Guidelines

Last Updated: May 20, 2026

Effective Date: May 30, 2026

Foreword

These Law Enforcement Guidelines (hereinafter referred to as “this Guide”) apply to law enforcement agencies, judicial authorities, prosecutorial authorities, and other statutory competent bodies (hereinafter collectively referred to as the “Requesting Party”) that lawfully possess jurisdiction over criminal investigations, national security reviews, evidence collection, or trials.

The software operator of Easchi (hereinafter referred to as the “Operator” or “the Platform”) is committed to striking a balance between protecting users’ lawful rights and interests, safeguarding data security, and fulfilling its statutory obligations. This Guide is intended to illustrate the Operator’s general principles for handling data requests, the boundaries of its technical capabilities across different software versions, and specific protocols for judicial assistance. It does not constitute legal advice, a commitment to cooperate, or a guarantee of the outcome in any specific case.

Special Disclaimer: To the maximum extent permitted by applicable law, the Operator shall assume no legal liability for any direct or indirect losses (including but not limited to user privacy lawsuits or claims) arising from the Operator’s good-faith cooperation with a Requesting Party’s data request. In the event of any conflict between this Guide and mandatory laws applicable to the Operator, the Operator will process the relevant request in accordance with the applicable law.

1 Core Principles

1.1 Principle of Legality

The Operator processes data requests solely on the basis of legally binding judicial instruments, statutory procedures, or other mechanisms recognized by applicable law. Requests not made through lawful procedures fall, in principle, outside the scope of processing by the Platform.

1.2 Principle of Governing Law

The Operator will assess each data request on a case-by-case basis within the framework of applicable law. Such applicable law may include, but is not limited to:

• The law of the jurisdiction where the Operator is located;
• The law of the jurisdiction where the data is physically stored;
• Data protection and privacy laws;
• Cybersecurity and data security laws;
• International treaties and other applicable mutual legal assistance mechanisms.

1.3 Principle of Proportionality

The Operator will, as required by law, conduct the necessary review of the scope, time period, and relevance of a data request. For requests that are manifestly excessive, lack specificity, or bear no reasonable connection to the case at hand, the Operator reserves the right to request supplementary explanations or to decline processing to the extent permitted by law.

2 Requests and Review

2.1 Requesting Entities

The Operator only processes data requests submitted by official authorities with statutory jurisdiction over criminal investigations, national security reviews, or court proceedings.

2.2 Documentary Requirements

A data request must contain information sufficient to identify the case, the scope of the request, the relevant time period, and the issuing authority, and must be accompanied by a legally binding judicial instrument or other document recognized by applicable law. The Operator reserves the right to request supplementary materials as necessary on a case-by-case basis to complete the requisite review.

2.3 Verification of Document Authenticity

The Operator reserves the right to take reasonable measures to verify the identity of the requesting entity and the authenticity and integrity of the documents. The Operator may decline to process a request or require supplementary materials if the source cannot be confirmed, there is a risk of forgery, the content is manifestly abnormal, or reasonable verification cannot be completed.

3 Internal Processing

3.1 Necessary Review

Upon receipt of the relevant request, the Operator will conduct a necessary review to the extent permitted by law. Once the review is passed, the Operator will process the relevant request within the bounds of applicable law and its technical capabilities.

3.2 Scope of Data

The Operator will only produce data that it actually possesses, is able to access, and is legally permitted to provide. Data that may be provided includes account metadata (e.g., registration time, order status) and encrypted copies of data stored on the servers.

The Operator cannot access or decrypt plaintext content data across all versions. Specific technical limitations vary by software version (see Section 4 for details). The Operator is not responsible for reverse engineering, deciphering, or any assistance beyond what is expressly set forth in this Guide with respect to any disclosed ciphertext data on behalf of the Requesting Party.

3.3 User Notification

Unless expressly prohibited by applicable law, a court has issued a confidentiality order (such as a Gag Order), or notification may pose an imminent threat to life or safety, the Operator generally reserves the right to notify the affected user within a reasonable period after the assistance has been completed (and provided it is permitted by applicable law and any confidentiality order).

3.4 Data Retention

The Operator manages data retention periods in accordance with its Privacy Policy. The Operator makes no guarantee that it will be able to continue to access, recover, or produce data that has been deleted, has expired, or is no longer under the Operator’s control.

4 Technical Capabilities and Version Differences

Due to differences in laws and regulations across countries and jurisdictions, this software offers different feature versions based on compliance requirements. The Requesting Party must first ascertain the software version used by the target account in order to determine the technical assistance the Operator is capable of providing.

4.1 Standard Edition

Under this version, the Platform employs an end-to-end encryption (E2EE) architecture. User content data is stored on the servers in encrypted form after synchronization. The Operator does not hold users’ decryption keys and therefore cannot access, recover, or provide the plaintext form of user content. The Operator can only provide a copy of the encrypted data stored on its servers, which is unreadable without the user’s keys.

4.2 Solo Edition with Third-Party Storage

In this mode, based on compliance requirements in specific jurisdictions or the user’s privacy choices, the software does not activate, nor does it offer, any form of official cloud synchronization infrastructure.

Data storage and multi-device synchronization rely entirely on third-party network storage protocols (such as WebDAV or S3-compatible object storage) configured by the users themselves. The Operator’s servers do not touch, host, or process any user content files or synchronization data.

The Operator technically possesses absolutely no capability to collect or decrypt any content data. The Requesting Party should directly obtain evidence in accordance with law from the user’s terminal device or from the integrated third-party storage service provider (e.g., the relevant cloud storage service provider).

4.3 Solo Edition with KN Sync

KN Sync utilizes a key negotiation mechanism. The Operator holds a regionally isolated master private key, which may only be used to assist in decrypting specific data in the context of judicial assistance. The master private key is subject to strict offline physical isolation. The Operator cannot proactively review any user data and may only initiate a case-specific judicial assistance procedure upon receipt of a final court order from a court with absolute territorial jurisdiction.

In order to prevent data leakage, protect the privacy of non-target users, and ensure the rigor of law enforcement procedures, the Operator adheres to the following protocols for decryption assistance involving KN Sync:

4.3.1 Necessary Identity Anchoring Information

Since the software’s registration process follows the principle of “no directly identifiable personal information” (e.g., no collection of mobile phone numbers, email addresses), the Requesting Party must provide accurate account identification information to pinpoint the target:

• Accurate Username: The automatically generated unique username.
• Payment Credential Information: Historical order numbers, payment transaction IDs, or payment platform transaction screenshots for the target account.

4.3.2 Form of Judicial Instrument and Verification of Cross-Border Electronic Requests

Given the risks of phishing, fraudulent data requests, and electronic forgery, the Operator implements prudent verification mechanisms for cross-border and electronic documents to ensure data security.

4.3.2.1 Priority Principle

The Operator prioritizes requests delivered through international mutual legal assistance treaties (MLATs), through diplomatic channels, or through physical delivery of original paper documents by judicial officers of the jurisdiction where the Operator is located. Paper documents should be sent to the Operator’s registered address or the legal service address published in its Privacy Policy.

4.3.2.2 Prudent Verification Mechanism for Cross-Border Electronic Requests

For jurisdictions outside the location of the Operator, where a Requesting Party transmits a decryption request by electronic means such as email, the Operator reserves the right to initiate a security verification process prior to execution:

• Email Service Provider Protocol Interception: The Platform’s external communication mailboxes rely entirely on mainstream commercial email service providers, with security filtering mechanisms enabled (including but not limited to SPF, DKIM, and DMARC protocol verification). Any request emails that are automatically intercepted, rejected, or bounced by the email service provider due to sender identity forgery, domain spoofing, or failure to pass the email service provider’s cryptographic identity verification shall be deemed undelivered to the Operator’s inbox. The Operator assumes no legal obligation to have knowledge of, communicate about, or respond to such requests that have failed to meet basic technical compliance standards.
• Official Trusted Channel Verification: Electronic requests should, in principle, be sent from an email address using the official domain of the law enforcement authority (e.g., .gov.uk, .gov.au). The Operator reserves the right to decline to process informal requests sent from non-official domains or public email services (such as Gmail, Outlook, etc.).
• Formal Judicial Instrument and Case Number Verification: The electronic request email must have attached a formal, signed judicial instrument in PDF format. The instrument must clearly contain a legal case reference number / case ID, the issuing authority, and the name of the responsible officer. Any request conveyed merely as a plain-text email, without a formal legal instrument attached, or lacking a valid case number, will be treated by the Operator as an individual ultra vires act or a warrantless request and will not be processed.
• Trusted Digital Signature or Note Verbale: The Operator recommends that electronic instruments carry a verifiable official digital signature (e.g., a PGP signature) or that identity be confirmed via a note verbale from the requesting country’s embassy or consulate in the jurisdiction where the Operator is located.
• Urgent Exemption Circumstances: For urgent cases involving an ongoing threat to life or safety, terrorist attacks, or similar emergencies, the Operator may, upon receipt of preliminary proof and an internal assessment, optimize or waive part of the electronic verification process and provide expedited assistance to the extent technically feasible.

4.3.3 Decryption Execution Process and Chain of Evidence Preservation

Upon satisfaction of the above identity anchoring and document verification requirements, the Operator will perform the following steps:

1. Dual-Match Identity Anchoring: The administrative backend will conduct a strong consistency check against the “account identification information” provided by the Requesting Party. The “username” and the “historical payment credential information (such as order number or transaction ID)” supplied by the law enforcement party must exactly match the records in the system backend. In the event of inconsistent information, data conflict, or a scenario where the payment credential belongs to an innocent third-party victim, the decryption process will be automatically terminated to protect the privacy of non-target users, and the Operator will require the Requesting Party to provide further clarification and supplementary materials.
2. Offline Environment Operation: Decryption operations will be performed on physically isolated, offline devices. The master private key will only be imported for decryption within the offline environment to ensure that system security is not compromised.
3. Specific Data Decryption: The Operator will decrypt only the specific encrypted data files explicitly designated by the Requesting Party and covered by the legal instrument.
4. Evidentiary Validity Disclaimer: The Operator performs extraction and disclosure solely in accordance with the current state of technology and the data in its original form. The Operator makes no express or implied warranty as to the admissibility, legality, or evidentiary weight of the data provided to the Requesting Party in any particular judicial proceeding. The Operator shall not be liable for any data not being admitted in litigation due to defects in the form of evidence, cross-border transfer procedures, or similar issues.

5 Supplemental Notes

• This Guide is solely for the purpose of illustrating the Operator’s general principles and the boundaries of its technical capabilities in handling data requests, and does not constitute legal advice or a commitment to cooperate;
• The Requesting Party shall independently ensure that the relevant request complies with the requirements of its own jurisdiction, the jurisdiction where the Operator is located, and other applicable laws;
• The Operator reserves the right to amend this Guide in response to changes in law, regulatory requirements, or platform policies;
• The amended version shall become effective as of the date of publication and shall apply to data requests received thereafter.