Privacy

Caution

Yang Chun Comment is designed with privacy as a priority.

There is no guarantee that the system design complies with any data and privacy regulations, including but not limited to GDPR (General Data Protection Regulation). This document is intended only to technically explain the design and operation of the system.

🚧 Work in progress 🚧

Commenter Anonymity and Pseudonyms

Commenters can freely choose whether to enter a nickname when commenting. If left blank, the comment remains Anonymous. If any nickname is entered, it undergoes SHA-256 hashing on the frontend. Based on the hash value, a set of adjective and noun is selected from a fixed word bank and combined to form a Pseudonym. Only this pseudonym is transmitted to the backend server and stored in the database.

The word bank used for pseudonyms is small (139 adjectives and 549 nouns, total phrase space is 139 * 549 = 76,311). It is intentionally designed to be collision-prone, making it very difficult to reverse-engineer the user’s original nickname due to the high number of possibilities.

Data Collection

The data transmitted from the frontend webpage to the backend server only includes:

• Optional pseudonym
• Comment content
• Replying comment ID (if any)
• Email

The Email field is used as a Honeypot. Normal human users cannot fill in this value, and the backend server does not store any form of this value.

The data actually stored by the backend server includes:

• id: Comment ID, generated by the backend server.
• pseudonym: Optional pseudonym, from the frontend.
• msg: Comment content, from the frontend.
• pubDate: Timestamp of comment publication, generated by the backend.
• modDate: Timestamp of comment editing or deletion, generated by the backend.
• replyTo: Replying comment ID, from the frontend.
• isAdmin: Whether it is an administrator’s comment, determined by the backend via the administrator’s HttpOnly Cookie.

Browser Fingerprinting

For commenters, rate limiting uses a Proof-of-Work mechanism, without using any identification methods containing user personal information (such as IP address, User-Agent, or Cookie).

However, for the administrator login process, the system temporarily caches the IP address hash processed via HMAC-SHA256 (with server-side secret) as the basis for identification in rate limiting and brute force protection mechanisms.

This method has limited identification capability but is not equivalent to complete browser fingerprinting because:

1. Multiple users may share the same IP address in public or corporate network environments.
2. A single user may use different IP addresses at different times due to ISP dynamic address allocation.
3. The IP address processed by HMAC-SHA256 is an irreversible hash, and the original IP cannot be restored from the hash value.

Therefore, identification based solely on IP address (even if hashed) cannot effectively or reliably uniquely identify a user, which is significantly different from real browser fingerprinting solutions (such as FingerprintJS).

Cookie

For commenters, no cookies are used.

For administrators, login credentials use HttpOnly cookies.

Comment Editing Credentials

For commenters, after publishing a comment, the backend server returns a Token containing a keyed HMAC-SHA256. This Token is not stored in LocalStorage or SessionStorage, but exists in JavaScript variables.