TR WheelChair Terms of Service

Version: v0.0.4 (Closed Beta) | Effective/Publication Date of these Terms: 8 September 2026

Language priority note: This English version is a translation. Pursuant to §11.3, the Traditional Chinese version is the original and governs in the event of any discrepancy.

Closed Beta notice: The Program is currently in a Closed Beta phase. The related special provisions are consolidated in §B Closed Beta Special Provisions below, which prevails during the Closed Beta period. Please read it in full.

Summary of revisions in v0.0.4: This version carries forward the functional-fact alignment of v0.0.3 (write functions, Policy Centre, business gateway domains) and revises the trusted-device rolling window to match the live implementation: the Glossary entry "Trusted Device" and §5.8(b) are tightened from 30 days to 14 days, consistent with client grant, Web Portal grant, and the trilingual UI copy. Matters unchanged in this version: The development entity and allocation of responsibility, the scope of personal data collection (Article 5, other than §5.8(b) and the Glossary entry "Trusted Device"), the geolocation mechanisms (Article 6), and the remaining account and device security mechanisms (§4.5, §5.7, §5.8(a)(c)(d), §5.9, §10.5–10.6) remain as in v0.0.3. The write-function fact alignment introduced in v0.0.3 is retained in full.

---

§B Closed Beta Special Provisions

This section sets out the special provisions applicable to the Closed Beta phase of the Program. During the Closed Beta period, in the event of any inconsistency between this section and the other articles of these Terms, this section prevails; matters not addressed in this section are governed by the other articles of these Terms. Upon conclusion of the Closed Beta phase, this section automatically ceases to have effect, while the other articles remain in force.

B.1 Characterisation and Purpose of the Closed Beta Phase

• (a) Phase Characterisation: The Program is currently in a Closed Beta phase, and version v0.0.4 of these Terms is the version applicable to that phase.
• (b) Primary Purpose: The primary purpose of this phase is to collect operational issues of the client under real-world usage conditions (including but not limited to functional defects, interface anomalies, performance bottlenecks, compatibility issues and process design deficiencies) in order to improve the Program. It is not aimed at providing a stable, production-grade service.
• (c) Role of the User: Users participating in the Closed Beta acknowledge and agree that their role combines both "user" and "issue reporter" attributes. Reporting is not a mandatory obligation of the User; however, the Administrator encourages Users to proactively report issues encountered via the channels listed in §B.4.
• (d) Scope of Participation: The Closed Beta phase is open only to specific Users individually invited by the Administrator (User eligibility must still satisfy all requirements of §2.3 in full). Persons not invited may not participate, and Users may not transfer their Closed Beta eligibility to any other person (see §2.4 and §4.1).

B.2 Approval of the Business Website Operator and the Basis for Use in the Production Environment

• (a) Approval of the Business Website Operator Obtained: The Administrator has reported the development of the Program, its data processing mechanisms and the conduct of this Closed Beta to the institution to which the target website belongs (the "Target Institution" as referred to in §3.2(d)) and has obtained its approval. On the basis of such approval, Closed Beta Users may use this beta version in the production environment to process real business data, without needing to obtain separate individual authorisation.
• (b) Scope and Limits of the Approval: The effect of the foregoing approval is strictly limited to the Target Institution's awareness of the Program and its consent at the data security level. The User acknowledges and agrees that such approval:
  • (i) does not alter the non-official product nature stipulated in §3.1 and §3.2(d)(i) — the Program remains a project developed and operated personally by the Administrator and is not a system component officially released, maintained or formally authorised by the Target Institution;
  • (ii) does not constitute any warranty or endorsement by the Target Institution as to the functionality, stability, security or business suitability of the Program (consistent with §3.2(d)(ii));
  • (iii) does not create, extend or modify the User's access rights to the target website — the User's access rights continue to derive entirely from their own employment relationship or business authorisation (consistent with §3.2(c)).
• (c) User Responsibility for Use in the Production Environment: When using this beta version in the production environment to process real business data, the User must discharge their professional duties with the same standard of care as when using a formal release, including but not limited to: completing a full manual review before use of any business document generated with the assistance of the Program (see §3.4); verifying any data submitted to the target website through the Program before submission and re-verifying the outcome on the official web front end of the target website after submission (see §3.6 and §B.3(g)); handling locally exported files in compliance with applicable requirements (see Article 7); and complying with the terms of service of the target website (see §4.3). Closed Beta status does not mitigate or exempt the User from any responsibility owed under these Terms or under their professional standards.

B.3 Service Level of the Closed Beta Phase and Risk Disclosure

The User acknowledges and expressly accepts that the beta version differs materially from a formal release in the following respects:

• (a) No Availability Undertaking: The Administrator gives no undertaking as to the availability, continuity or response speed of the Program. During the Closed Beta period, planned or unplanned service interruptions, feature suspensions, mandatory version updates or server-side restarts may occur, and the Administrator may implement them without prior notice.
• (b) Risk of Known Defects: The beta version may contain defects not yet discovered or not yet fixed, which may result in functional anomalies, incorrect data display, operation failures or program crashes.
• (c) Risk of Local Data Loss: The User acknowledges that program anomalies, version updates or local cache rebuilds may cause cached data, downloaded attachments, one-click form-filling template configurations and local preference settings stored on the User's local device to be lost or require reconfiguration. The User should separately back up any local files they consider important; the Administrator bears no liability for local data loss arising from the foregoing circumstances.
• (d) Feature Changes and Withdrawal: The Administrator may add, modify, suspend or withdraw any function of the Program during the Closed Beta period without prior notice, and this does not constitute a breach towards the User.
• (e) Phased Narrowing of Department Entry Points: During the Closed Beta period, the main interface of the Program opens the entry points of only some business departments — the BI department entry point is currently open and the WS department entry point is not displayed for the time being (for the target websites of both departments, see §2.2). This is a phased product arrangement (the relevant functional code has not been removed); the Administrator will progressively open them in accordance with tiered per-user access rights after the formal data integration is completed. The User may not assert any right on the ground that an entry point has not been opened.
• (f) Continuity of Disclaimers: The disclaimers set out in Article 9 (disclaimer for third-party conduct, disclaimer for User operations, and the "as is" no-warranty statement) apply equally and in full during the Closed Beta phase; the provisions of this §B.3 particularise Article 9 in the Closed Beta context and do not narrow it.
• (g) Closed Beta Risks Specific to Write Functions (new in this version): The write functions of the Program (see §2.5(b)) act directly upon real business records on the target website. The User acknowledges and expressly accepts that:
  • (i) the write path in a beta version may, owing to defects, give rise to failed submissions, duplicate submissions, missing or misaligned fields, or anomalous status transitions;
  • (ii) certain statuses are irreversible once written (see §3.6(d)), of which "signed" in particular calls for careful confirmation before submission;
  • (iii) after each write operation, the User must verify the outcome on the official web front end of the target website, and may not rely on the success message shown in the Program's interface as the sole evidence that the operation has taken effect in the business system (see §3.6(e)); and
  • (iv) the business consequences arising from the foregoing circumstances are borne by the User in accordance with the allocation of responsibility under §9.2 and §3.6. Users encountering write anomalies are encouraged to report them via the channels in §B.4 so as to assist with remediation.

B.4 Issue Reporting and Submission of Diagnostic Information

• (a) Reporting Channel: The User may submit issue reports to the Administrator via the contact methods listed in Article 12 (email).
• (b) Submission of Diagnostic Information Is Initiated by the User: The client contains a "Diagnostic Log" window (which may be opened via the "Manage One-Click Form Filling" menu on the main interface or the Ctrl+J shortcut), used to record locally the execution of operations such as one-click form filling. The User acknowledges and agrees that:
  • (i) this log is generated and retained solely on the User's local client, and the Program does not automatically upload it to the Administrator's backend server or to any third party;
  • (ii) if the User proactively copies the log content and sends it to the Administrator by email in order to assist in diagnosing an issue, this constitutes the User's own voluntary disclosure.
• (c) De-identification Obligation Prior to Submission: Before submitting any log, screenshot or other diagnostic material, the User should review it and remove any customer identity information, policy details, transaction records or other business-sensitive data contained therein. The Administrator requires only information needed to diagnose technical issues and neither requires nor encourages the User to submit any customer business data. Consequences arising from submission without de-identification are borne by the User, in accordance with the attribution-of-liability principles in §5.6(c) and §7.2.
• (d) Use of Reported Content: The Administrator may use issue reports submitted by the User for defect fixing and functional improvement of the Program. The User agrees that no consideration is payable by the Administrator for such use; the Administrator owes a duty of confidentiality in respect of materials submitted by the User and will not disclose them to third parties except as required by law.

B.5 Data Processing During the Closed Beta Phase

• (a) No Expansion of Collection Scope by Reason of the Closed Beta: The scope, purposes, retention periods and third-party service disclosures for personal data collection during the Closed Beta phase are identical to those set out in Articles 5 and 6, and are not expanded in any way by reason of Closed Beta status.
• (b) Continuity of the "Never Collected" Safeguards: The core "never collected" safeguards listed in §5.3 (customer business data, browsing history, keyboard input, local files, plaintext passwords and PINs, etc.) apply equally and without any diminution during the Closed Beta phase.
• (c) Locality of Business Data Unchanged: The principle stipulated in §5.6 that "target website data is retained solely on the User's local client and is not uploaded to the Administrator's backend server" is fully maintained during the Closed Beta phase. The same applies to data submitted by the User to the target website through the write functions — the recipient is the target website, and such data is not relayed through the Administrator's backend server, nor is any copy retained on any facility of the Administrator (see §5.6(e)). The Administrator will not collect the User's business data for Closed Beta purposes.

B.6 Conclusion of the Closed Beta Phase and Version Transition

• (a) Conclusion of the Phase: The Administrator may declare the Closed Beta phase concluded at any time and publish a formal version of the Terms.
• (b) Acceptance of the Formal Version: After the formal version of the Terms is published, the User must re-read and accept the new version in accordance with the mechanisms of §1.3 ("Subsequent Confirmation (upon updates to the Terms)") and §10.2 ("Immediate Effect of a New Version") in order to continue using the Program.
• (c) Termination of Closed Beta Eligibility: The Administrator may terminate a particular User's Closed Beta participation eligibility pursuant to the powers of disposal listed in §4.4, or for operational reasons such as the conclusion of the Closed Beta phase or adjustment of Closed Beta quotas. Where eligibility is terminated due to the conclusion of the Closed Beta phase or quota adjustment, the Administrator will notify the User by email in advance.
• (d) Continuity of Data: User accounts, records of acceptance of the Terms and audit logs established during the Closed Beta phase continue to be retained in accordance with the retention periods stipulated in §5.5 after the transition to the formal version, and the User need not re-register.

---

§0 Glossary

To help users without a technical background accurately understand the technical terms used in these Terms, this Glossary is provided. The definitions set out here carry the same legal force as the main body of these Terms; where such terms first appear in the main body, they are generally cross-referenced with "(see §0 Glossary)".

Term	Definition
PIN	A four-digit numeric security passcode set by the user within the Program, serving as an independent second authentication factor in addition to the login password. See §2.4, §5.2, §5.3.
One-Time Confirmation Link (commonly known in the industry as a magic-link)	A one-time URL link delivered by the system to the user's registered email upon the user's request; clicking the link is deemed completion of the corresponding confirmation action (such as email verification, password reset, email change confirmation, etc.). Each link may be used only once and has a defined validity period (see the next item).
Validity Period (commonly known in the industry as TTL · Time To Live)	The permitted period of validity of a link, verification code, or session, counted from the moment the system issues it. Upon expiry it automatically becomes invalid and must be re-requested by the user.
Frozen Status	A suspension status imposed by the system or the administrator on a user account. An account in Frozen Status may not log in and may not initiate any operation; it may only be unfrozen by the administrator pursuant to the procedures set out in these Terms, and the user cannot self-unfreeze.
Forced Password Reset	An intermediate-stage measure imposed by the administrator on an account pursuant to §4.4: the system immediately revokes all active sessions of that account and requires the user to first reset the login password via the standard "Forgot Password" procedure before the next login in order to continue use.
Trusted Device	A device for which the user has actively selected "Trust This Device" at login. The system grants it a 14-day rolling trust window counted from the last successful login, during which certain secondary security checks may be waived. See §5.8.
Device Fingerprint	An irreversible identification string derived from a combination of static characteristics of the device's hardware, operating system, browser, etc.; used to identify the device rather than the user's natural identity, and from which no original device information can be reconstructed.
Rolling Validity Period	A mechanism for extending the validity of a session or trust window: within the existing validity period, each valid operation by the user automatically extends the validity to "the original length again counted from the moment of that operation"; if no operation occurs before expiry, the session or trust status automatically becomes invalid.
OTP (One-Time Password)	The abbreviation of One-Time Password; a numeric or alphanumeric combination generated by the system upon the user's request, usable only once and with a short validity period, commonly used for email or mobile verification.
Argon2id	A one-way password hashing algorithm that won the 2015 Password Hashing Competition (PHC), widely recognized in the industry for its strong resistance to hardware-accelerated attacks. The Program uses this algorithm for the server-side storage of both login passwords and PINs; hash values processed by this algorithm cannot be reversed back to the original password.
AES-256-GCM	A widely adopted symmetric authenticated encryption algorithm (Advanced Encryption Standard · 256-bit · Galois/Counter Mode); it generates an authentication tag at the time of encryption, enabling detection of whether the ciphertext has been tampered with upon decryption. The Program uses this algorithm to encrypt sensitive credentials (session tokens, business account passwords) stored on the User's local device when writing them to disk (see §5.9). Unlike the one-way hashing of Argon2id, AES-256-GCM is reversible encryption — only the holder of the correct key can decrypt and recover it.
OS Credential Vault (commonly known in the industry as OS Keyring / Credential Vault)	A secure credential storage facility natively provided by the operating system (Windows Credential Manager / macOS Keychain / Linux Secret Service); it protects the stored key with the operating system account permission as its boundary, safeguarded by the operating system's underlying encryption mechanism (such as Windows DPAPI). The Program entrusts the master key required for the aforementioned AES-256-GCM encryption to this facility and does not write the master key in plaintext to any file (see §5.9).
HTTPS	HyperText Transfer Protocol Secure, the industry-standard encrypted network communication protocol; all data transmission between the user and the target website is encrypted by this protocol.
Business gateway (commonly API Gateway)	The server-side endpoint at which the target website receives programmatic data requests. It has a different address from the front-end site that users visit with a browser, but belongs to the same business system and shares the same account and permission framework. All business data requests of the Program (whether read or write) are sent to the business gateway. See §2.2.
Reservation record (target website field name reservePolicy)	The record in the target website's business system documenting a single insurance reservation. It is the sole object of the Program's write functions (see §2.5(b)).
Reservation status and approval routing	The stage of a reservation record within the target website's business workflow, which may be: to be completed; first review passed / rejected; secondary review passed / rejected; reservation confirmed (i.e. final review passed) / final review rejected; signed; cancelled; or expired. Of these, expired, final review rejected, cancelled and signed are terminal states — once a record enters a terminal state, its status can no longer be changed. See §3.6(d).
Policy (target website field name policy)	The record in the target website's business system documenting a policy already in force. It is a different object from a reservation record, and the two do not share a common status-code scheme. The Program's "Policy Centre" page is for viewing policies only and provides no write function whatsoever. See §2.5(a).
Geolocation API	The location-service application programming interface provided by the operating system or browser; the Program obtains the device's geographic location information through this interface.
User-Agent	The software type and version identifier self-reported by the browser or client when initiating a network request (not containing user identity information); the Program records this string as part of its login compliance trail.
Resend	The cloud email delivery service provided by Resend (Resend · Email API for developers); the delivery of all system emails of the Program (verification codes, security alerts, account notifications, etc.) is entrusted to this service.
Tencent Location Service	The cloud-based geographic location service provided by Tencent; the Program uses this as its primary geographic service provider, for reverse-geocoding device latitude/longitude into administrative-division-level text, and for estimating location from the client IP address (IP-based location) when the device fails to report valid coordinates.
MaxMind GeoLite2 / DB-IP Lite City	The GeoLite2 offline IP geolocation database published by MaxMind and the DB-IP Lite City database published by DB-IP; the Program uses these solely on the backend server as an offline fallback when Tencent Location Service is unavailable for city-level IP reverse-lookup, and never transmits any user data upstream to such database providers.

---

Article 1 Status of the Agreement and Method of Acceptance

1.1 Legal Contract: These Terms of Service (the "Terms") are a legally binding contract between you (the "User") and the TR WheelChair Administrator (J) (the "Administrator") regarding the TR WheelChair desktop tool and its accompanying web portal (home.tr-whc.com, the "Web Portal") (collectively, the "Program") and related services.

1.2 Effect of Electronic Confirmation: Pursuant to Section 17 of the Electronic Transactions Ordinance (Cap. 553 of the Laws of Hong Kong), when the User selects "I have read and agree to the above Terms of Service" or a similar confirmation mark on the login interface, the User is deemed to have read, understood, and agreed to be bound by all provisions of these Terms. Such electronic confirmation has the same legal effect as a handwritten signature.

1.3 Timing of Display and Acceptance Mechanism:

• Initial Consent (at registration): Before beginning the registration process, the User must read the full text of these Terms in their entirety and complete a dual check — "I agree to all provisions of these Terms" and "I agree that the Program may obtain this device's location information during use" — before entering the registration form. Upon successful registration, this consent record has continuing legal effect.

• Subsequent Confirmation (upon update of the Terms): After the Administrator releases a new version of the Terms, existing Users must, at their next login, re-read the full text of the new version during the login process and complete the aforementioned dual check before continuing to use the Program (no grace period; see §10.2).

• Acceptance: Completing the dual check and clicking the "Accept" button is deemed the User's clear and legally effective consent, allowing continuation of the registration or login operation.

• Refusal: If the User selects "Refuse", the current operation terminates immediately. Refusal at the registration stage creates no user account and collects or retains no registration data; an existing User who refuses the new version upon an update of the Terms is deemed to have actively terminated this service relationship.

• No Intermediate State: These Terms provide no "Decide Later" option; the User must make a clear choice.

• Post-registration Email Verification Obligation (dual-validity mechanism): After the User submits the registration, the system will immediately send a One-Time Confirmation Link (see §0 Glossary) to the email address registered by the User. To balance link security with user convenience, this mechanism adopts a "short-lived link + long-lived window" dual-validity design:

  • (i) The verification link has a validity period of 1 hour from the moment of issuance — beyond this period the link is deemed invalid by the system and clicking will be rejected. Setting the validity period to 1 hour is intended to minimize the link's exposure window within the User's mailbox and reduce the risk of misappropriation due to mailbox compromise or man-in-the-middle interception.
  • (ii) The 24 hours after registration constitute the email verification grace period — within this 24-hour window the User must successfully complete at least one valid click of a verification link. If the verification link received by the User has expired because the 1-hour validity period has elapsed, the User may at any time select "Resend Verification Email" on the login interface or email prompt page to obtain a new link (each new link likewise being valid for 1 hour from its respective moment of issuance).
  • (iii) Automatic handling upon failure to verify within the 24-hour grace period: If the User has still not completed verification via any valid link click 24 hours after registration submission, the system will automatically place the account into Frozen Status (see §0 Glossary) and simultaneously revoke all active sessions established by the account; such automatically frozen accounts cannot be self-unfrozen by the User — even if the User subsequently completes a verification link click, login capability will not be automatically restored, and the User must contact the Administrator via the contact methods listed in Article 12, with the Administrator deciding whether to unfreeze after manual verification.
  • (iv) Resend Frequency Limit: The User may select "Resend Verification Email" at any time within the 24-hour grace period, but for abuse protection and out of respect for the User's mailbox, the resend frequency is subject to system limits (typically a 60-second short hard interval + a cumulative cap on the number of times within 24 hours).

• The above three-layer mechanism of "short-lived link + long-lived window + freezing upon expiry" is a core safeguard component of Article 5 "Account and Device Security" of these Terms, intended to prevent registration with invalid mailboxes, guard against abuse of anonymous accounts, reduce the risk of verification links being hijacked within the User's mailbox, and ensure the deliverability of subsequent security alert emails.

1.4 Amendment of the Terms: The Administrator has the right to amend these Terms according to operational needs or laws and regulations. A new version carries no grace period — once it takes effect, existing Users must re-read and accept it at their next login before continuing to use the Program. So that the User is able to complete such acceptance, the User may still log in to the Program normally before accepting the new version; however, until acceptance is completed, the User may not perform any operation other than reading and accepting the new version. Refusal to accept the new version is deemed the User's choice to terminate this service relationship, with the same effect as the "Refusal" scenario in §1.3.

1.5 Phase Nature of This Version: Version v0.0.4 of these Terms is the version applicable to the Closed Beta phase. The consent given by the User under this Article extends to these Terms in their entirety (including §B Closed Beta Special Provisions). When the Administrator publishes a formal version of the Terms after the Closed Beta phase concludes, the User must accept it anew in accordance with the "Subsequent Confirmation" mechanism in §1.3 and the immediate-effect mechanism in §10.2 (see §B.6).

---

Article 2 Definition of Service and User Eligibility

2.1 Nature of the Program: The Program is a non-profit personal productivity tool developed to improve work efficiency. Its core function is to establish, on behalf of the User, an HTTPS (see §0 Glossary) session with the target website using standard browser request characteristics, and to convey information to which the User already has lawful access rights in both directions between the User and the target website:

• Read direction: fetching the target website's information to the User's local client, assisting the User in viewing and processing it efficiently (the "read functions"); and
• Write direction: submitting to the target website the content entered, edited, selected, or selected for upload by the User on the local client (the "write functions").

The Program does not bypass any security mechanism of the target website, does not modify the target website's page content or interface logic, and does not create any business operation that does not already exist on the target website — every operation the Program is capable of performing (whether read or write) is an operation the User could equally perform with their own account on the official web front end of the target website. The itemised inventory of both categories is set out in §2.5; the source of authority for, and business consequences of, the write functions are set out in §3.6.

2.2 Scope of Target Websites: The Program currently supports assisting access to only the target websites listed below. Each target website comprises a front-end site and a business gateway (see §0 Glossary) — what the User sees in a browser is the front-end site, whereas the Program's data requests are in fact sent to the business gateway; both belong to the same business system:

Business department	Front-end site	Business gateway	Current entry point in the Program
BI department	https://bank.lmwfortune.com	https://gateway-bank.luckyins.com	Open
WS department	https://mate.hk-ws.com	https://gateway-ws-gx.luckyins.com	Not open for the time being (see §B.3(e))

2.3 User Eligibility Requirements:

• The User must be an individual aged 18 or above who has the legal capacity to enter into a legally binding contract. Persons under 18 may not use the Program.
• The User must be a specific lawful user verified by the Administrator who holds a valid invitation code or authorized account.
• The User must be an internal employee of a licensed insurance company or a licensed insurance intermediary, and their use of the Program must be a lawful business activity within the scope of their job authorization.

2.4 Prohibition of Account Lending: The Program adopts a "one person, one account" mechanism. Any User is strictly prohibited under any circumstances from lending, leasing, or transferring their authorized account, password, or device access rights to any third party for use.

In addition to the login password, the Program sets up a four-digit numeric PIN security passcode (the "PIN") as an independent second authentication factor, used for on-the-spot re-verification of certain highly sensitive operations (e.g., unlocking the client lock screen, client high-sensitivity function thresholds, etc.). The PIN has the same non-lendability as the login password; any User is strictly prohibited from disclosing their PIN to any third party in any form (including but not limited to oral notification, delivery of written records, screenshot transmission). The specific storage and processing mechanism of the PIN is detailed in §5.2 and §5.3.

2.5 Scope of Functions and Inventory of Write Operations: So that the User is clearly informed of the boundaries of the Program's capabilities, the Program's current functions are set out below according to the two data directions defined in §2.1. This inventory will change as the Program evolves, and the Administrator will update it when the Terms are revised; operations not listed are not provided by the Program.

(a) Read functions (obtaining data from the target website to the User's local client):

Function	Description
Reservation management list	Obtains the list of reservation records within the User's authority, with filtering, sorting and pagination performed locally
Reservation record details	Views the complete fields of a single reservation record
Policy Centre (new in this version)	Obtains and views the policy list and policy details. This page provides no write function whatsoever
Attachment download	Downloads files attached to reservation records / policies to the local customer attachment directory (batch download supported)
Reservation form export	Requests the target website to generate the reservation form file for a record and downloads it locally
Proposal enquiry	Enquires the product proposal information corresponding to a reservation record
Dictionary and personnel option enquiry	Obtains option data such as nationalities, insurance companies, products and on-duty / signing / co-operating personnel, solely for interface drop-down selection and not persisted to disk
One-click form filling	Populates a local PDF template with the information visible to the User locally and saves a copy (see §3.4)
Local data export	Exports the list records visible locally to an Excel file (see Article 7)

(b) Write functions (submitting data from the User's local client to the target website):

Function	Description
Create reservation	Enters policyholder, insured and beneficiary particulars and product information locally and submits them to create a new reservation record
Edit reservation record	Modifies the fields of an existing reservation record and writes them back either as "save draft" or as "submit"
Cancel reservation	Sets the reservation record to "cancelled" (a terminal state)
Approval routing	Marks first review passed / secondary review passed / final review passed, or the corresponding rejection, within the scope of the authority attaching to the User's official duties
Service allocation	Assigns the signing person, KYC personnel, co-operating personnel and channel after final review has been passed
Signed	Enters the policy number, policy type and (for prepayment records) the prepayment term, and sets the reservation record to "signed" (a terminal state)
Regenerate proposal	Requests the target website to regenerate the proposal for the reservation record
Import reservation form	Uploads a reservation form file completed by the User locally, which the target website's server parses in order to generate reservation records (see §7.4)

The source of authority for, manner of taking effect of, irreversible statuses arising from, and the User's verification obligations in respect of the foregoing write functions are all set out in §3.6; the corresponding Closed Beta risk disclosures are set out in §B.3(g).

---

Article 3 Special Declaration on Insurance Regulatory Compliance

3.1 Administrator's Identity and Affiliation Statement: The User acknowledges that the Administrator, in their capacity as a natural person, holds an insurance intermediary license issued by the Insurance Authority of Hong Kong, and, in their licensed business activities, holds lawful login authorization to the target websites (see §2.2). The Program is developed and operated by the Administrator in the capacity of an individual technical developer, as a non-profit personal productivity project, and is not an official product, official client, or business subsystem of any licensed institution or of the institution to which the target websites belong, nor has it been officially authorized or endorsed by any institution.

3.2 Statement of Tool Independence: Although the Administrator personally holds lawful login authorization to the target websites, the Program:

• (a) does not act in any form on behalf of the Administrator's licensed institution or the institution to which the target websites belong;
• (b) does not provide any insurance advice or business service to the User in the Administrator's capacity as a licensed insurance intermediary;
• (c) does not create, extend, or modify any User's access rights to the target websites — the User's access rights derive entirely from their own employment relationship or business authorization and exist independently of the Program;
• (d) Data Security Compliance and Official Relationship Statement: The Administrator has reported the development and data processing mechanisms of the Program to the institution to which the target websites belong (the "Target Institution"), and undertakes to comply with the data-security-related agreements signed with the Target Institution. The User acknowledges and agrees:
  • (i) Non-official Product Statement: although the Program has obtained the Target Institution's knowledge and data-security-level consent, the Program remains a project developed and operated by the Administrator personally, and is not a system component officially released, maintained, or formally authorized by the Target Institution;
  • (ii) Boundaries of Liability: the Target Institution's knowledge of the Program does not constitute its guarantee of the Program's functionality, security, or business suitability, and the risks of use and business results of the Program remain entirely at the User's own risk;
  • (iii) Compatibility Risk Borne by User: the Target Institution reserves the right to update its website systems at any time, and if a system update renders the Program inoperative, this is not deemed a breach by the Administrator, who will use best efforts to maintain it under the agreement framework with the Target Institution but does not guarantee continued effectiveness.

3.3 Statement of Non-Regulated Activity: The service of the Program itself does not constitute any "regulated activity" under the Insurance Ordinance (Cap. 41 of the Laws of Hong Kong). The Program does not provide the following services:

• (a) soliciting, recommending, or inducing the purchase of any insurance product;
• (b) providing professional advice on specific insurance products;
• (c) entering into, arranging, or negotiating insurance contracts on behalf of any party;
• (d) collecting or processing premiums or any insurance-related payments.
• (e) The write functions do not alter the foregoing characterisation: what the Program's write functions (see §2.5(b)) perform are record-level workflow operations carried out by the User in their official capacity within the Target Institution's internal business system (such as entering reservation records, marking outcomes in an approval workflow, and recording signing particulars). Those operations act upon the Target Institution's internal business records, are not directed at any insurance consumer, and involve none of the conduct listed in paragraphs (a) to (d) of this Article. Any insurance business activity engaged in by the User outside the Program is characterised, and liability allocated, in accordance with §3.5.

3.4 Nature as an Auxiliary Function: The product-information retrieval and "comparison tag" functions provided by the Program have content sourced from the User's own entries or publicly available internet information; the tags are used only for quick location and reuse, and contain no system-generated evaluation of product merits or purchase recommendations. Any business document auxiliarily generated by the Program (such as a PDF produced by one-click form filling) is a layout tool based on the User's local input information, and the User must conduct comprehensive manual checking and professional review before use. All content submitted through the Program's write functions likewise originates entirely from the User's entries, selections, or the file the User has selected for upload — the Program does not generate, recommend, auto-complete, or modify any business content; field validation and record creation are performed exclusively by the target website's server (see §3.6(b)).

3.5 Reservation of Professional Judgment: As a licensed practitioner, the User shall independently exercise their professional judgment. The legal liability for any insurance business activity engaged in by the User during use of the Program (including but not limited to offline meetings, product explanations, signing guidance, etc.) is borne entirely by the User and their licensed institution, and is unrelated to the Program or the Administrator's capacity as a technical developer.

3.6 Source of Authority for, and Business Consequences of, the Write Functions: The Program's write functions (see §2.5(b)) act directly upon real business records on the target website. The User acknowledges and agrees that:

• (a) The source of authority is unchanged: the scope of the write operations the User can perform through the Program is exactly the same as the scope that User could perform with their own account on the official web front end of the target website. The Program does not create, extend or modify any business authority of the User (consistent with §3.2(c)); the User must not use the Program to perform any operation outside the scope of the authority attaching to their official duties.
• (b) Authority and business validation are performed exclusively by the target website: the determination of authority, field validation, assessment of workflow legitimacy, and ultimate business effect of every write request are decided entirely by the target website's server. An operation refused by the target website cannot be made effective by the Program; and the business effect of an operation accepted by the target website is neither increased nor diminished by the Program's involvement.
• (c) Immediate effect; no local rollback: once accepted by the target website, a write operation takes effect immediately upon real business data. The Program provides no undo, rollback, or local staging isolation mechanism — "save draft" is a record status of the target website's own business system (such a draft has in fact been written to the target website) and is not a local hold within the Program.
• (d) Certain statuses are irreversible: once a reservation record enters any of the four terminal states — expired, final review rejected, cancelled, signed (see §0 Glossary) — its status can no longer be changed. Of these, "signed" is subject to an express warning in the Program's interface before submission. The User must complete their own confirmation before submitting; the business consequences of a record entering a terminal state through mis-operation are borne by the User pursuant to §9.2.
• (e) Obligation to verify outcomes: after each write operation, the User must verify the outcome on the official web front end of the target website, and may not rely on the success message shown in the Program's interface as the sole evidence that the operation has taken effect in the business system.
• (f) Limits of business effect: any status marking within the Program (including "signed") is merely a workflow status within the target website's business process; it does not constitute the formation, variation, or termination of any insurance contract, nor does it substitute for underwriting, premium payment, execution, or any other statutory or internal institutional procedure (consistent with §3.3).

---

Article 4 User Conduct Standards and Prohibition of Program Distribution

4.1 Strict Prohibition of Unauthorized Distribution: The copyright and distribution rights of the Program belong to the Administrator. Any User, individual, or company is strictly prohibited from distributing, reposting, or disseminating the Program (or any of its components) to third parties not verified and approved by the Administrator, without the Administrator's express written consent. This prohibition applies equally regardless of whether it is for profit.

Official Distribution Channel: The installation package of the Program is distributed solely through the official channel designated by the Administrator — the User must sign in to the Web Portal with their own account and obtain it from the download page. The User must not forward the installation package or its download address to any third party; the Administrator accepts no responsibility for the integrity, security or functional performance of an installation package obtained from any other source. The download page also publishes the official checksum (SHA256) of the installation package, against which the User may verify the integrity of the downloaded file.

4.2 Prohibition of Reverse Engineering: The User may not reverse engineer, decompile, or disassemble the Program, or otherwise attempt to extract the Program's source code.

4.3 Commitment to Compliant Use: The User undertakes, when using the Program to log in to the target websites, to conscientiously comply with the target websites' terms of service, user agreements, and privacy policies. The User bears full legal liability for all their operational conduct, data-fetching conduct, and the consequences arising therefrom on the target websites.

4.4 Administrator's Disposal Authority (the three states of "Suspension / Forced Password Reset / Permanent Revocation"):

• First State · Suspicion Stage (Suspension): If the Administrator has reasonable grounds to suspect that the User does not comply with any provision of these Terms, the Administrator has the right to immediately suspend the relevant User's or device's right to use the Program, without explanation. Suspension is a temporary measure that may subsequently be escalated to the second or third state based on the results of fact-checking, or may be lifted after suspicion is cleared.
• Second State · Intermediate Stage (Forced Password Reset): If the Administrator confirms that an account's authentication security has been or may be threatened (e.g., a remote login alert is triggered, a password is suspected of leakage, suspicious multi-account activity on the same device, etc.), but has not yet reached the level of permanent revocation, the Administrator has the right to immediately initiate a Forced Password Reset (see §0 Glossary) on the relevant account:
  • (i) the system immediately sets the "Forced Password Reset" flag on the user account and immediately revokes all active sessions of that account;
  • (ii) at the next login the User will be compelled to complete a password reset via the "Forgot Password" standard path listed in §4.5(d) before continuing use (the specific mechanism is detailed in that clause);
  • (iii) the Administrator will simultaneously deliver the reason for the measure to the User by email (if the Administrator chooses to fill it in). A Forced Password Reset measure is not deemed a termination of the User's service relationship and is intended to restore the account's security status at minimum cost.
• Third State · Verification Stage (Permanent Revocation): If investigation confirms that the User has indeed violated the provisions of these Terms, the Administrator has the right to permanently revoke the relevant User's or device's right to use, and reserves the right, at its discretion, to bring legal proceedings and claim damages for the relevant violations.

4.5 Account Protection Mechanisms: To prevent brute-force cracking, credential-stuffing attacks, and account theft, the Program implements the following automated protection mechanisms in the authentication process; the User acknowledges and agrees:

• (a) Login Password Failure Lockout: When consecutive login password verification failures reach a cumulative 5 times (any successful login resets the failure count to zero, with no rolling time-window statistics), the system will automatically lock the account for 30 minutes, during which any login attempt will be rejected; after the 30-minute lockout expires, the account will automatically unlock without Administrator intervention. During the lockout, the User may at any time complete a password reset via the "Forgot Password" path listed in (d), and a successful reset simultaneously lifts the login lockout status.
• (b) PIN Failure Lockout: When consecutive PIN verification failures reach a cumulative 5 times (any successful PIN verification resets the failure count to zero, with no rolling time-window statistics), the system will automatically lock the account's PIN factor and send a PIN lockout alert to the User's registered email. PIN lockout does not lift automatically; the User must lift it via any of the following paths:
  • (i) complete the full login process with the login password (i.e., the non-"Trusted Device" single-step login path);
  • (ii) complete a password reset via the "Forgot Password" path listed in (d);
  • (iii) be handled by the Administrator via the "reset PIN to empty state" path listed in §4.5(e) (the User re-sets the PIN after the next login). PIN lockout affects only operations requiring PIN re-verification (such as lock-screen unlocking, PIN security passcode change), and does not affect the password login path or general functions after login.
• (c) Security Implications of the Unlocking Mechanism: The 30-minute login lockout set in (a) is an automatic-unlock mechanism intended to block automated credential-stuffing attacks within a controllable time window and avoid excessively long service interruptions due to input errors; the PIN lockout set in (b) does not use automatic unlocking and must be lifted by the User with a higher level of proof (password login or password reset), corresponding to the high-sensitivity positioning of the PIN factor in these Terms. Neither unlocking mechanism constitutes a denial of attack suspicion — beyond unlocking, the Administrator may independently assess and execute "Suspension", "Forced Password Reset", or "Permanent Revocation" measures pursuant to §4.4.
• (d) Escape Hatch (Forgot Password): If the User forgets the login password, they may at any time select "Forgot Password" on the login interface, and the system will send a one-time 6-digit numeric password-reset verification code to the User's registered email (OTP · see §0 Glossary · valid for 10 minutes from the moment of issuance, allowing at most 5 erroneous entries, after which it is voided and must be re-requested). The User completes the password reset by entering this code and the new password on the login interface of the client or the Web Portal. After completing the password reset, the account's login failure lockout and PIN failure lockout statuses are simultaneously cleared, the "Forced Password Reset" flag is also cleared, and all other active sessions are revoked to ensure the exclusivity of the new password.
• (e) The PIN's Escape Hatch: The PIN has no self-service "Forgot PIN" recovery path (see §5.3(f)). If the User loses the PIN, the only disposal method is for the Administrator to reset the PIN factor to an empty state in the backend (the User re-sets the PIN after the next login); this operation is written to the audit log and the User is simultaneously notified by email.
• (f) Registration Rate Limit: To guard against automated bulk registration and abuse of server computing resources, the registration endpoint of the Web Portal imposes a rate limit based on the network address from which the registration request originates: a single network address may submit at most 10 registration requests within 10 minutes (counted whether successful or not); upon reaching the limit, further registration requests from that network address are temporarily refused for 30 minutes, after which the limit is lifted automatically without Administrator intervention. This limit applies only to the registration endpoint and does not affect login or any functionality of existing accounts; multiple Users behind the same network address (e.g. a shared office network) share the above quota.

---

Article 5 Principles of Personal Data Collection and Processing (PDPO)

5.1 Lawful Purpose of Collection: Pursuant to the Personal Data (Privacy) Ordinance (Cap. 486 of the Laws of Hong Kong), the sole purpose for which the Administrator collects User personal data is to: (a) verify the User's identity; (b) safeguard account and device security; (c) provide necessary technical support; and (d) fulfill legal compliance audit obligations.

5.2 Scope of Data Collected: The Program collects only the minimum data necessary to achieve the above purposes, specifically including:

• User Profile: registered email, username/English name, encrypted identity authentication credentials (including the Argon2id (see §0 Glossary) hash of the login password and the Argon2id hash of the PIN security passcode), invitation code.
• Device and System Information: irreversible device fingerprint (see §0 Glossary), client version number.
• Interface Preferences: the interface display language selected by the User and the colour theme of the Web Portal (dark / light / follow time of day). Such preferences are used solely to render the interface according to the User's habits and do not participate in any identity recognition or security determination.
• Compliance Trail: agreement acceptance status and time, login/logout times, client IP address, browser User-Agent (see §0 Glossary).
• Geographic Location Information: see the dedicated provisions in Article 6.

5.3 "Never Collect" Core Safeguard: The terms "collect", "store", and "transmit" used in this Article specifically refer to upstream transmission and retention by the Program client to the backend server operated by the Administrator or to any third-party service, and do not include the fetching and submission of data that the Program performs locally between the local client and the target website to achieve its core function (see §5.6). For the avoidance of doubt: data submitted by the User to the target website through the write functions (see §2.5(b)) is received by the target website, and not by the Administrator's backend server or any third-party service, and therefore falls outside the "collection" referred to in this Article (for the flow of, and responsibility for, such data, see §5.6(e)). Under this definition, the Administrator undertakes that the Program will never collect, store, or transmit upstream to the backend server or any third party the following sensitive data:

• (a) any customer identity, policy details, transaction records, or business data obtained or processed by the User on the target websites through the Program — such data is retained entirely on the User's local client and disposed of at the User's discretion;
• (b) the User's browser history, cookies (except for the target website login state), or form autofill content;
• (c) the User's keyboard input records, screenshots, or clipboard content;
• (d) any file list or content of the User's local file system — save for the single file the User actively selects and uploads pursuant to §7.4, which is likewise received by the target website, with the Administrator's backend server at no point coming into contact with its content;
• (e) the microphone, camera, contacts, SMS, or call records of the User's device.
• (f) the plaintext of the User's login password and the plaintext of the PIN security passcode — such plaintext is held only temporarily on the User's local client on an as-needed basis for instant verification or setting, and is immediately cleared from memory after verification; the credentials transmitted upstream to the backend server are only one-way hash values processed by the Argon2id algorithm, from which the Administrator cannot reconstruct the original password or PIN, and no form of PIN recovery mechanism is provided (if the User loses the PIN, the only disposal method is for the Administrator to reset it to an empty state pursuant to §4.5(e)).

5.4 Third-Party Service Disclosure: To achieve specific functions, the Program needs to invoke the following third-party services to process specific data:

• Tencent Location Service: reverse-geocodes latitude/longitude data into administrative-division-level text; and, when the device fails to report valid coordinates, provides a service to estimate location from the client IP address (country/province/city level) as the primary fallback location source for remote-login alerts (see §6.6-1).
• Resend (see §0 Glossary): used to deliver verification codes, alert notifications, and agreement update emails.
• MaxMind GeoLite2 / DB-IP Lite City (see §0 Glossary): used for offline city-level IP location locally on the backend server (involving no outbound data transmission); provides a further offline fallback when the IP estimation of the above Tencent Location Service fails (see §6.6-1).

5.5 Data Retention Periods:

• User Master Profile: retained during the account's validity period; retained for 90 days after account deregistration for security traceability.
• Session Raw Coordinates (latitude/longitude, positioning accuracy): retained for 30 days after login, after which the system automatically nullifies the relevant fields, retaining only the reverse-geocoded text location down to street level.
• Session Reverse-Geocoded Location and Metadata (country/province/city/district/street, IP, login time, client version, etc.): retained for at least 1 year as a baseline for remote-login alerts and a basis for internal security audit; archived or physically deleted together with the audit event logs upon expiry.
• Agreement Acceptance Records: retained permanently as legal evidence.
• Audit Event Logs (Auth Events): retained for at least 1 year.

The above retention periods strictly correspond to the purpose of "account security protection and remote-login alert" set out in §6.1.

5.6 Nature of Local Fetching and Submission of Target Website Data: The User acknowledges and agrees:

• (a) Technical Principle: The Program establishes, on behalf of the User, an HTTPS encrypted session with the target website using standard browser request characteristics, fetches the data returned by the target website to the User's local client for the User to view and process, and submits to the target website the content entered or selected by the User on the local client. Its technical essence is entirely equivalent to the User manually visiting the target website using a general-purpose browser (such as Chrome or Edge) and viewing, filling in and submitting on its pages — the scope of data fetching and submission, storage location, and attribution of compliance liability do not change due to the use of the Program.
• (b) Locality: The customer data returned by the target website is retained entirely on the User's local client (including memory, page cache, and attachments and exported files downloaded locally), is neither transmitted upstream to the Administrator's backend server nor forwarded to any third-party service.
• (c) Attribution of Liability: The User's viewing, copying, processing, saving, and compliant disposal of such customer data locally is entirely equivalent to the User's operations using a general-purpose browser, and the relevant legal liability is borne entirely by the User and is unrelated to the Program's backend data processing mechanism (see §4.3).
• (d) Precondition: The sole precondition for the Program to perform the above local fetching and submission is that the User already holds lawful login authorization to the target website; the Program does not create, extend, or modify the User's access rights (see §3.2(c)).
• (e) Direction of Submission (new in this version): All data submitted by the User through the write functions — including but not limited to all fields of a reservation record (the identity, contact, address, occupational and financial particulars of the policyholder / insured / beneficiary, together with any identity-document images attached), the outcomes marked in approval routing, signing particulars, and any file uploaded pursuant to §7.4 — is transmitted directly upstream from the User's local client to the target website, is not relayed through the Administrator's backend server, and no copy is retained on any facility of the Administrator. The Administrator has no means of knowing the content of any business data submitted by any User. The User bears full responsibility for the truthfulness, completeness and compliance of the content they submit, and for its falling within the authority attaching to their official duties (see §3.6 and §4.3).

5.7 Changes to Account Information: Changes to the User's core account information (including email address, username, and PIN security passcode) are subject to the following mechanisms:

• (a) Email Address Change (User Self-Service): The User may initiate an email address change request in the client or the Web Portal. To ensure that both the old and new addresses are held by the same natural person, the system adopts two-way verification:
  • (i) the system sends a one-time verification code to the old email address (OTP, see §0 Glossary · valid for 10 minutes from the moment of issuance, allowing at most 5 erroneous entries, after which it is voided and the change request must be re-initiated), and the User must enter the correct OTP to prove control of the old mailbox;
  • (ii) the system sends a One-Time Confirmation Link to the new email address (see §0 Glossary · valid for 1 hour from the moment of issuance), and the User must click the link to prove control of the new mailbox. Only when both verifications succeed does the system complete the email address switch.
• (b) Forced Session Reset After Email Change: After a successful email address change, the system will immediately revoke all active sessions of the account (including the current session in which the change request was initiated), and the User must log in again with the new email address and the original password to ensure the new mailbox owner's exclusive control of the account.
• (c) Username Change (Executed by Administrator): Username changes are not open to a User self-service channel and may only be executed by the Administrator after the User's written request and verification. After the Administrator executes a username change, the system will automatically send an informational notice to the User's registered email (including the before-and-after values) and write to the username change history log for subsequent traceability; this change does not affect the User's active sessions, password, PIN, or other account attributes.
• (d) PIN Security Passcode Change (User Self-Service): The User may at any time initiate a PIN change request in the client "Account Security" interface, or on the account page of the Web Portal, after login. To ensure that the initiator is indeed the account holder, the system adopts two-factor verification:
  • (i) the User must enter the correct old PIN to prove current possession of the account;
  • (ii) the system will send a one-time verification code to the User's registered email address (OTP · see §0 Glossary · valid for 10 minutes from the moment of issuance, allowing at most 5 erroneous entries, after which it is voided and the change request must be re-initiated), and the User must submit this OTP together with the new PIN. Only when both verifications succeed and the new PIN differs from the old PIN does the system complete the PIN update.
• (e) Session Handling After PIN Change: Unlike an email address change, a PIN change does not trigger a forced reset of the current active session — based on the determination that "the User has proved substantive possession of the account via the dual factors of the old PIN + email OTP", a forced logout would excessively harm the user experience without corresponding security benefit. The synchronized effect is: the system will clear the account's PIN failure count and lockout status under §4.5(b) (a PIN change is deemed a security-status reset of the PIN factor).
• (f) Change Restriction Under PIN Lockout Status: If the account's PIN factor is currently in lockout status (see §4.5(b)), the system will refuse to accept any PIN change request, and the User must first lift the PIN lockout via any of the paths listed in §4.5(b) (password login / forgot password / Administrator resets PIN to empty state) before initiating a change. This restriction is intended to prevent an attacker from bypassing the lockout mechanism via the change path during PIN trial-and-error.
• (g) Distinction from "Forgot PIN": Items (d), (e), and (f) of this clause apply only to active-change scenarios where the User knows the old PIN; if the User loses the PIN (does not know the old PIN), they must follow the "Administrator resets PIN to empty state" path listed in §4.5(e) (the User re-sets the PIN after the next login), and the two may not be conflated.
• (h) Handling of Change Failure: If any verification step above (OTP verification, old PIN verification, new mailbox link click, etc.) fails or times out, the original email / username / PIN remains unchanged, and the original session is unaffected; the User may re-initiate the change request at any time.

5.8 Memory and Revocation of Trusted Devices: To balance security with convenience of use, the Program provides a "trusted device memory" mechanism for devices that have passed full identity verification:

• (a) Scope of Memory: Only the irreversible device fingerprint (see §5.2) and the User's most recent login time on that device are remembered; no other identifiable information on the device is collected.
• (b) Trust Window: For a device for which the User has actively selected "Trust This Device" at login, the system will grant it a 14-day rolling trust window counted from the last successful login — within the window, the device may be exempted from certain secondary security check steps (the specific steps being determined by the system based on real-time risk assessment); each successful login within the window automatically renews it, and if there is no login for more than 14 days, the trust status automatically becomes invalid.
• (c) Triggers for Forced Distrust: In the following circumstances, the system will forcibly cancel the device's trust status regardless of whether the window has expired:
  • (i) the User performs a password reset or is subjected to a Forced Password Reset by the Administrator (see §4.4 Second State);
  • (ii) the User performs an email address change (see §5.7(b));
  • (iii) the system detects a substantive change in the device's fingerprint;
  • (iv) the Administrator handles the account under the First or Third State of §4.4.
• (d) Revocation Channels: The User may actively revoke remembered trusted devices at any time via the following channels:
  • (i) view and revoke item-by-item in the client "Account & Devices → Trusted Devices" interface or on the account page of the Web Portal (revoking "this device" will simultaneously terminate the current login session on this device);
  • (ii) request assistance with revocation in the Administrator backend;
  • (iii) initiate a revocation request via the contact methods listed in Article 12.

5.9 Encrypted Storage of Local Sensitive Assets: To protect sensitive credentials stored on the User's local device against theft by other processes or malicious programs on the same device, the Program applies an AES-256-GCM (see §0 Glossary) encryption-at-rest mechanism to such local sensitive assets. The User acknowledges and agrees:

• (a) Scope of Encryption: The local sensitive assets encrypted by this mechanism are limited to
  • (i) the Program's login session token (the credential used to maintain login status and avoid frequent password re-entry) and its session state such as validity period; and
  • (ii) the business account password (i.e., the password the User uses to log in to the target websites listed in §2.2) retained locally after the User selects "Remember Password" in the client. The former is stored in whole-file encrypted form, the latter in individual-field encrypted form.
• (b) Custody of the Master Key: The master key (256-bit) required for the above encryption is generated by the Program and then entrusted to the OS Credential Vault (see §0 Glossary), protected by the operating system account permission and its underlying encryption mechanism (such as Windows DPAPI), and is not written in plaintext to any file. Any third-party process unable to obtain operating system account authorization cannot obtain the master key and therefore cannot decrypt the aforementioned local sensitive assets.
• (c) Tamper-Resistance of the Encryption: AES-256-GCM generates an authentication tag at the time of encryption, which the Program verifies upon each read; if the ciphertext has been tampered with or the master key does not match, the Program will refuse to load such assets and treat them as corrupted (rebuilding an empty state), so as to prevent tampered credentials from being misused.
• (d) Degradation Handling When No Memory Capability Is Available: If the OS Credential Vault on the User's device is unavailable (e.g., the operating system environment lacks the corresponding component), the Program will not persistently store the aforementioned sensitive credentials locally — the session token and business account password will be valid only temporarily in the memory of the current run, lost upon program closure, and the User must log in again or re-enter the business account password at the next startup. In this circumstance, the Program will never write such sensitive credentials to a local file in plaintext or weakly encrypted form as a fallback.
• (e) Transparent Upgrade of Existing Data: For such credentials already stored locally in unencrypted form before this encryption mechanism took effect, the Program will automatically upgrade them to encrypted storage upon first read, with no manual action required by the User.
• (f) Distinction from Locally Fetched Data and Exported Files: The encryption described in this clause acts only on the aforementioned login session token and business account password of the Program itself, and does not include the customer business data fetched by the User from the target websites through the Program (the local disposal of which is detailed in §5.6), nor the local files actively exported by the User (the format of and encryption responsibility for which are detailed in Article 7). The encryption in this clause is the Program's security hardening of the credentials it itself manages, and does not change, aggravate, or mitigate the attribution of User liability set out in §5.6 and Article 7.

---

Article 6 Special Provisions on Geographic Location Information (GPS)

6.1 Necessity of the Collection Purpose: The sole purpose for which the Program collects geographic location information is to implement "account security protection and remote-login alert". By establishing a security baseline of "user-device-usual location", when an account exhibits an abnormal geographic shift, the system can promptly identify a potential account-theft risk and alert the Administrator and the User.

6.2 Timing of Legal Authorization:

• Application-Layer Legal Authorization: The User's specific legal authorization for location information collection has been completed via the dual check at registration (see §1.3), constitutes continuing consent, remains effective during the period in which the agreement version is not upgraded, and need not be re-given at each startup.
• System-Layer Permission: The location information collected by the Program is obtained through the Geolocation API (see §0 Glossary) provided by the operating system; therefore, in addition to the legal authorization at registration, the operating system level must also grant the Program location permission before actual collection can occur.

6.3 Legal Nature of the Startup Location Confirmation Dialog: To improve the user experience and avoid the operating system's location authorization pop-up causing unexpected disruption to the User, the Program displays a "Location Authorization Explanation Dialog" to the User after each successful identity verification and before invoking the operating system location permission. This dialog:

• (a) is product experience design, serving only for prompting and confirmation, and does not constitute a new legal authorization request;
• (b) the location authorization consent given by the User at registration (see §1.3) is a continuing authorization and does not re-occur due to the display of this dialog;
• (c) if the User selects "Cancel" in this dialog, it is deemed only a waiver of this startup's use and does not constitute a withdrawal of the location authorization consent given at registration;
• (d) the User may still re-choose whether to continue using the Program at the next startup, without needing to complete the registration-stage dual check again.

6.4 Specific Fields Collected: The Program collects latitude/longitude (Lat/Lng), positioning accuracy (Accuracy · i.e., the radius error value of the positioning result, in meters), source hint (Source Hint · e.g., positioning source types such as GPS, Wi-Fi, IP estimation), and collection status (Status · e.g., success, timeout, denied). The above data is converted into textual descriptions at the country, province, city, district, and street levels for security audit.

6.5 Legal Consequences of Refusing Authorization: Geographic location security verification is part of the Program's core security model. If the User refuses to grant or turns off the Program's location service permission in the operating system settings, the Program will be unable to start or unable to enter the main interface to use its functions.

6.6 Exceptional Circumstances (Soft Degradation): The Program's location authorization gate opens soft degradation only for the single scenario of "the operating system does not support the location service component on which the Program depends" — specifically, the runtime environment lacks the location service component required by the Program's underlying layer (typically seen in very old versions or customized slimmed-down operating systems), where the User fundamentally cannot grant location permission at the operating system level, so the Program chooses to allow it to continue running without location data, with no business function restriction; in this scenario, all security alert baselines that depend on location data will be supported instead by the server-side IP-estimated location listed in §6.6-1. Apart from the above single scenario, any other form of location collection failure (including but not limited to the User refusing authorization, the operating system location service being turned off, missing positioning hardware, positioning signal too weak, positioning collection timeout, and positioning accuracy too low) does not trigger soft degradation — among them, the scenarios of refusing authorization and the service being turned off are handled with a hard lock pursuant to §6.5 (the User may apply for an Administrator exemption pursuant to §6.7), while in the scenarios of missing hardware/weak signal/timeout/low accuracy the Program runs as usual but this positioning data will be empty, to be supplemented by the server pursuant to §6.6-1.

6.6-1 Server-Side Location Fallback Chain (IP Estimation): When the client fails for any reason to report valid latitude/longitude (including but not limited to the soft-degradation scenarios listed in §6.6, missing hardware, collection timeout, and positioning accuracy below the acceptable threshold), the server will automatically estimate location data from the client IP address via the following chain to complete security determinations such as remote-login alerts:

• (i) the IP location interface of Tencent Location Service (country/province/city level);
• (ii) the MaxMind GeoLite2 / DB-IP Lite City offline databases (local resolution · no outbound data transmission);
• (iii) recorded as "location unknown" if all the above fail. The User acknowledges and agrees: (a) the location accuracy derived from such IP estimation is far lower than device GPS collection, and is used only for coarse-grained security determination of remote-login alerts and not for any business function; (b) IP estimation is triggered only when the client coordinates are missing, and will not be used together with or override the client coordinates; (c) the retention period and processing rules for IP-estimated data are consistent with the location data listed in §5.5.

6.7 Administrator Location Exemption Mechanism (Fallback for Users in Restricted Environments): To address Users' reasonable restricted usage environments (such as traveling to areas without GPS signal coverage, temporary failure of positioning hardware, enterprise IT policies restricting location permission, etc.), the Program sets up the following two types of location hard-lock exemption issuance authority for the Administrator. The User may submit an application via the contact methods listed in Article 12, with the Administrator deciding whether to issue after case-by-case review:

• (a) One-Time Pass: At the User's application, the Administrator may issue a one-time location hard-lock exemption to a specific device, allowing that device to bypass the location authorization gate once and enter the main program within the validity period specified by the Administrator. This exemption is consumed upon first successful use (i.e., "use once and burn"); subsequent encounters with the location hard lock require a new application.
• (b) Permanent Exemption: For Users in long-term restricted environments who genuinely cannot obtain location authorization within a foreseeable period, the Administrator may issue a permanent exemption (the specific reason must be filled in upon issuance and confirmed twice), allowing that device to continuously bypass the location authorization gate until the Administrator actively revokes it. The issuance of a permanent exemption will be strictly reviewed and approved only where the User genuinely has a long-term restricted environment and other mitigation measures are infeasible.
• (c) Notification and User Revocation Right: The system will actively notify the User by email of status changes such as the issuance, consumption (first use of a one-time pass), and revocation of an exemption. The User may at any time request the Administrator, via the contact methods listed in Article 12, to revoke an exemption already granted to their device; for an exemption grant that the User does not approve of (e.g., the Administrator misjudged the scenario), the User has the right to refuse acceptance and demand immediate revocation.
• (d) Administrator Alert Mechanism: When a User device encounters the location hard lock and does not hit an existing exemption, the system will automatically send an alert notification to the Administrator so that the Administrator may promptly intervene and assess whether to issue an exemption. This alert contains only device-level identification and failure-reason information (such as a device fingerprint short code, failure type code, client clock skew, etc.), and does not contain any business data input or processed by the User within the Program.
• (e) Audit Trail of Exemptions: All issuance, consumption, and revocation of exemptions are written to the account's security audit log (retention period same as §5.5), and the User may retrieve the exemption history under their account via the data rights request path listed in Article 12.
• (f) Relationship of Exemptions to Other Provisions of These Terms: A location exemption acts only on the location authorization gate defined in §6.5 and does not affect any other account protection mechanism under these Terms (including but not limited to the login failure lockout and PIN lockout of §4.5, the session validity period and lock screen of §10.5, and the Administrator's disposal authority of §4.4); after an exempted device enters the main program, it must still comply with all other provisions of these Terms.

---

Article 7 Local Data Export and File Import

7.1 Nature of Local Data Export: The Program currently provides a "local data export" function on both the "Reservation Management" and "Policy Centre" pages, allowing the User to export records viewed and filtered on the local client into a local file (such as an Excel spreadsheet) saved to a local directory of the User's choice. Attachments, reservation forms and proposal files downloaded locally from the target website by the Program are of the same nature, and responsibility for them is allocated in the same way, as provided in this Article. The User acknowledges and agrees:

• (a) Local Autonomous Conduct: The export operation is completed entirely on the User's local device, the exported file is written only to the local path specified by the User, is not transmitted upstream to the Administrator's backend server, nor forwarded to any third-party service. Its nature is entirely equivalent to the User exporting local data using general-purpose software (such as browser "Save As", Excel "Save As"), and is the User's local autonomous disposal conduct.
• (b) Liability Borne by User: The content of the exported file may contain customer business data obtained by the User on the target website. The User bears full legal liability for the saving, encryption, transfer, sharing, and compliant disposal of the exported file; any resulting data leakage, non-compliant processing of customer information, etc., is entirely at the User's own risk and unrelated to the Program or the Administrator (consistent with the liability attribution principles of §4.3 and §5.6).
• (c) Current Format of Exported Files: The User acknowledges that the files currently exported by the Program are in unencrypted plaintext format. The AES-256-GCM local encryption that the Program applies to the credentials it itself manages (login session token, business account password) (see §5.9) does not extend to data files actively exported by the User — the two differ in nature: the former is the Program's security hardening of the credentials required for its own operation, while the latter is business data autonomously exported by the User. If the User needs to apply encryption protection to exported files, the User must handle it using encryption methods they trust. The Administrator may add encryption capability to the export function in a subsequent version, but such an addition is merely a security convenience additionally provided for the User's local autonomous conduct and does not change, aggravate, or mitigate the User liability attribution set out in (b).

7.2 Sharing and Recipient Obligations:

• Sharing Liability Borne by User: The User's act of sharing an exported file with any third party (regardless of whether the recipient is a lawful user) is the User's personal act. Any resulting data leakage, non-compliant processing of customer information, etc., is entirely at the User's own risk.
• Recipient Obligations: A User who imports or receives a file shared by another must self-confirm that they have lawful authority to use the relevant data.

7.3 Definition of Nature: The data files exported by the Program contain only business information viewed locally by the User or textual material entered by the User, and do not contain the Program's executable code. Sharing such data files does not constitute distribution of the Program (distinguished from "Program distribution" prohibited in §4.1).

7.4 Import of Local Files (Upload to the Target Website): The Program's "import reservation form" function allows the User to upload a reservation form file they have completed locally to the target website, which the target website's server parses in order to generate reservation records. The User acknowledges and agrees:

• (a) The upload is strictly limited to the single file selected by the User: the Program reads and uploads only that one file which the User actively designates through the file selection dialog, and does not scan, index, or upload any other file or any file listing of the User's local file system (consistent with §5.3(d)).
• (b) The recipient is the target website: the file is transmitted directly upstream from the User's local client to the target website, not through the Administrator's backend server, and is not forwarded to any third-party service (consistent with §5.6(e)). The Administrator has no means of obtaining the content of that file.
• (c) Format and size limits: the current version accepts the .xlsx, .xls and .csv formats, and a single file must not exceed 10 MB; a file exceeding that limit is rejected locally by the Program and no upload is initiated.
• (d) Parsing and validation are performed by the target website: the parsing of the file's content, field validation, and the reservation records generated therefrom are carried out entirely by the target website's server. The Program does not parse, modify, or auto-complete the file's content (consistent with §3.6(b)).
• (e) The User's verification obligation: the User must satisfy themselves that the content of the uploaded file is true and complete and that the upload falls within the authority attaching to their official duties (see §3.6(a)); once the import is complete, the User must verify the reservation records generated on the official web front end of the target website in accordance with §3.6(e).
• (f) Template download: the Program provides a convenience entry point for downloading a blank reservation form template from the target website; the downloaded template file is saved to the "Downloads" directory of the User's operating system. That download constitutes local fetching as provided in §5.6, and responsibility for it is allocated in accordance with §5.6(c).

---

Article 8 Intellectual Property and Administrator Rights

8.1 Ownership of Rights: All intellectual property rights in the Program (including but not limited to code, interface design, icons, documents, etc.) belong personally to the Administrator (J) and are protected by Hong Kong and international copyright law.

8.2 Final Right of Interpretation: To the maximum extent permitted by law, the Administrator holds the final right of interpretation over all matters relating to the Program (including these Terms, descriptions of program functions, activity rules, etc.).

---

Article 9 Limitation of Liability and Disclaimer

9.1 Disclaimer for Third-Party Conduct: The Program is not liable for impaired functionality caused by target website failures, system maintenance, technical changes, or the interruption of any third-party service (such as Tencent Location Service, Resend).

9.2 Disclaimer for User Operations: The Administrator is not responsible for any loss (including but not limited to account bans, customer complaints, legal prosecution, etc.) caused by the User's personal negligence, misoperation (including but not limited to submitting erroneous or incomplete content to the target website through the write functions, or causing a record to enter one of the irreversible terminal states provided in §3.6(d)), or violation of the target website's agreement during use of the Program.

9.3 No Warranty Statement: To the maximum extent permitted by applicable law, the Program is provided "as is", without any express or implied warranty of any kind, including but not limited to fitness for a particular purpose or non-infringement.

---

Article 10 Agreement Mechanism and Changes

10.1 Binary Choice Mechanism: The User is bound by the latest version of the agreement in effect at the time of each login to the Program. The User must clearly select "Accept" to continue use; selecting "Refuse" will immediately terminate the current login session.

10.2 Immediate Effect of a New Version (No Grace Period): Updates to these Terms carry no grace period. Once a new version takes effect, the User must re-read and accept it at their next login before continuing to use the Program; prior to acceptance the User may still log in to the Program in order to complete such acceptance, but may not perform any operation other than reading and accepting the new version. Sessions already logged in will not be forcibly signed out upon publication of a new version, but acceptance under this Article is still required once that session ends (or at the Program's next startup).

• Distinction from client version updates: Grace periods apply only to client program version updates (where the Administrator may allow a transition period during which an older version remains usable) and not to updates of these Terms. The reason for the distinction is that these Terms are a precondition for using the Program: allowing a User to remain on an older version of the Terms while running an updated client would create a mismatch between the User's rights and obligations and their actual use.

10.3 Dual-Check Confirmation: When accepting the agreement, the User must simultaneously check approval of the "full text of the agreement" and the special consent to "obtaining location information".

10.4 Access to Prior Versions of the Agreement: The Administrator will provide a channel to access historical versions of these Terms. The User may view the full text of any previously effective historical version within the Program or by contacting the Administrator. The display of historical versions is for reference only; the User's rights and obligations are governed by the version applicable at the time of their acceptance.

10.5 Session Validity Period and Lock Screen: To balance security with convenience of use, the Program implements the following validity and idle control mechanisms for authenticated sessions:

• (a) Session Rolling Validity Period: After each successful login, the system grants the session a 1-hour rolling validity period counted from the last valid operation — each valid operation by the User within the validity period (such as page switching, data query, business action, etc.) automatically extends the validity to "1 more hour counted from the moment of that operation"; a session with no valid operation for more than 1 hour automatically becomes invalid, and the User must log in again.
• (b) Circumstances Triggering the Lock Screen: The Program's lock screen is triggered in the following three circumstances, all of which are unlocked in exactly the same manner:
  • (i) Automatic idle lock (5 minutes without operation): within the session's 1-hour rolling validity period, if the User performs no mouse, keyboard, or touch operation within the Program for 5 consecutive minutes, the Program will automatically lock the screen;
  • (ii) User-initiated lock: the User may lock the screen immediately at any time by clicking the lock button at the top right of the client's main interface, without waiting for the idle timeout;
  • (iii) Upon restoring the main window from the taskbar: where the User has minimised the main window to the taskbar pursuant to §10.6, the Program will automatically lock the screen when the main window is next restored (see §10.6(c)).
• (c) Manifestation and Unlocking: The lock screen appears in the client as the program interface being covered by a full-screen overlay, and in the Web Portal as a redirect to a dedicated lock screen page; in both cases the User must re-enter the PIN security passcode to continue operation. In the client, in order to prevent business information from remaining exposed on screen during the lock:
  • (i) The overlay covers all windows of the Program: while locked, windows of the Program other than the overlay itself (such as the customer detail window and the settings window) will be temporarily withdrawn from view, and restored exactly as they were upon unlocking;
  • (ii) Withdrawal is not closure: the aforesaid withdrawal merely renders the windows temporarily invisible; it does not close them and does not interrupt any entry or editing the User has in progress, and the User may resume from where they left off upon unlocking;
  • (iii) while locked, the Program accepts no mouse or keyboard input other than the unlocking operation.
• (d) Session Status During the Lock Screen: While locked (irrespective of the triggering circumstance), the session itself remains valid, and the session's rolling validity period is not renewed by the lock screen but also does not become invalid due to the lock screen itself; however, if the cumulative idle duration during the lock screen exceeds the session's 1-hour rolling validity period, the session will simultaneously become invalid pursuant to (a), and the User must complete a full login again. If the User's consecutive PIN verification failures reach the cap set in §4.5(b) (5 times) while locked, the system will forcibly invalidate the session and require the User to complete the full login process with the login password before continuing use.
• (e) Triggers for Forced Logout: In the following circumstances, the system will forcibly invalidate the session regardless of whether the session validity period has expired:
  • (i) the User actively logs out within the Program;
  • (ii) the User completes a password reset on another device or session;
  • (iii) the User completes an email address change (see §5.7(b));
  • (iv) the Administrator imposes any measure on the account pursuant to §4.4;
  • (v) the User's consecutive PIN verification failures reach the cap set in §4.5(b) upon unlocking the lock screen (see (d)).
• (f) Notification and Transparency: The User may view the current session and historical login records of the current account in the client "Account & Devices → Login History" interface or on the account page of the Web Portal (up to 50 entries within the past 90 days are currently displayed); the User may also at any time request the Administrator, via the contact methods listed in Article 12, to view or revoke a specified session on their behalf.

10.6 Background Residency and Automatic Start-up of the Client: So that the User need not repeat the full start-up sequence (including location authorisation, device authorisation handshake, and version check) after a brief absence, the Program's client provides two mechanisms: "minimise to taskbar" and "start automatically on boot". The User acknowledges and agrees:

• (a) The behaviour on closing the main window is selected by the User: When the User clicks the close button of the main window, the Program offers three dispositions — ask every time (default), exit the Program directly, and minimise to the taskbar. On the first click of the close button, the Program will present a dialog inviting the User to choose then and there; the User may tick "do not ask again" to fix that choice, and may change it at any time under the client's "Settings → General → When closing the main window". The Program will not default the closing behaviour to background residency without the User's selection.
• (b) Nature of Background Residency: After the User selects "minimise to taskbar", the main window is hidden while the Program's process continues to run, and an icon is displayed in the taskbar notification area. The User may restore the main window at any time via that icon, or select "Exit" to terminate the Program entirely. The User acknowledges that, in this state, the Program continues to hold the User's login session, and the session's validity period and invalidation mechanisms remain exactly as set out in §10.5, unchanged by the minimisation.
• (c) Minimising Constitutes Locking: Once the main window is minimised to the taskbar, the Program enters the lock-screen state set out in §10.5; when the User next restores the main window, the User must re-enter the PIN security passcode before continuing operation. This design takes account of the possibility that the User has left their seat after minimising the main window, and thereby prevents others from restoring the window and viewing business information in the User's absence.
• (d) Where No Taskbar Notification Area Is Available: If the User's operating system environment does not provide a taskbar notification area, the Program will not offer the "minimise to taskbar" option, and the close button will always exit the Program directly — so that the User cannot be left unable to restore the Program after minimising it.
• (e) Residency After Logout: After the User actively logs out within the Program, the main window closes while the process remains resident in the taskbar, and the Program reverts to a logged-out state. The User may log in again via the taskbar icon, or select "Exit" to terminate the Program. The User acknowledges that, while logged out, the Program holds no login session whatsoever and performs no acquisition or transmission of business data.
• (f) Nature and Scope of Automatic Start-up: The Program offers a "start automatically on boot" option, implemented by writing an entry pointing to the Program's executable into the operating system start-up items of the User's own account (the Run key under HKEY_CURRENT_USER in the Windows registry). The User acknowledges and agrees:
  • (i) Disabled by default: this option is unticked by default at installation and takes effect only upon the User's affirmative selection;
  • (ii) Toggleable at three entry points: the User may enable or disable it at any time on the "Select Additional Tasks" page of the installer, under the client's "Settings → General → Start-up", or from the right-click menu of the taskbar icon; all three refer to the same single setting;
  • (iii) Removed on uninstallation: when the User uninstalls the Program, the aforesaid start-up entry is automatically removed together with it, leaving no residue;
  • (iv) Effective for the current user only: the entry is written to HKEY_CURRENT_USER and affects only the current operating-system user account; it does not touch other user accounts on the device and requires no administrator privileges.
• (g) Locality of the Preferences Under This Article: The closing-behaviour preference and the automatic start-up setting described in this Article are stored solely on the User's local device (in the Program's local configuration file and the aforesaid operating-system start-up item respectively), and are not transmitted to the Administrator's backend servers nor forwarded to any third party; they therefore fall outside the scope of collection defined in §5.2. The Administrator has no means of knowing any User's aforesaid settings.
• (h) Relationship with Data Collection: The background residency described in this Article does not expand the scope of data collection defined in §5.2, nor does it derogate from the "never collected" core safeguards set out in §5.3. While resident in the background, the Program performs no acquisition, transmission, or background harvesting of business data whatsoever, save for the heartbeat communications required to maintain the login session.

---

Article 11 Miscellaneous Provisions

11.1 Severability: If any provision of these Terms is, for any reason, held to be invalid or unenforceable, such provision shall be deemed severed from these Terms and shall not affect the legality and validity of the remaining provisions.

11.2 Entire Agreement: These Terms constitute the entire agreement reached between the User and the Administrator regarding use of the Program, superseding all prior oral or written representations, undertakings, or agreements between the parties.

11.3 Language Priority: The Traditional Chinese version is the original version of these Terms. In the event of any ambiguity between the Traditional Chinese version and any other language version (such as the English version), the Traditional Chinese version shall prevail.

---

Article 12 Governing Law, Jurisdiction, and Contact Methods

12.1 Governing Law: The conclusion, validity, interpretation, performance, and dispute resolution of these Terms are governed by the laws of the Hong Kong Special Administrative Region of the People's Republic of China.

12.2 Court of Jurisdiction: For any dispute arising from or in connection with these Terms, the parties shall first seek amicable settlement through negotiation; failing settlement, it shall be submitted to the exclusive jurisdiction of the courts of the Hong Kong Special Administrative Region.

12.3 Contact Paths:

• Administrator (J): admin@tr-whc.com
• Technical Support Team: support@tr-whc.com
• Data Rights Requests (PDPO): For requests regarding data access or correction, please email admin@tr-whc.com noting "Data Rights Request".