Every public Naver review comes with three things attached to the person who wrote it: a nickname, a stable account id, and a link to their entire public review history. This Actor returns none of them, and the reason the decision holds is that a test fails the build if it is ever violated.
What Naver publishes with a review
All three, to any visitor. That is not a leak on Naver's part — a review is more credible when it belongs to a visible account, and the history link is how a reader judges whether a reviewer is a real person.
What is reasonable to display on a page is a different thing from what is reasonable to hold in a database of 3,295 businesses, which is the whole argument here.
The account id is the real problem
The nickname is weak identification. The history link is a URL. The stable account id is what changes the character of the dataset: because it is stable, it joins one person's reviews across every business they have ever reviewed.
Collect reviews for 3,000 restaurants with the account id attached and you have not built a review dataset. You have built a movement and preference profile for tens of thousands of Koreans, keyed and queryable — which nobody asked for and which is far more sensitive than anything the reviews say about the restaurants.
The decision, and why it is not a toggle
The obvious product move is an option, off by default. This site has already argued against that pattern in the coches.net case: an option transfers an obligation to whoever ticks the box, usually without them understanding what the field enables.
Here it is more clear-cut than there, because the harm is not in one field but in the join the field permits. So there is no flag. Not behind a setting, not on request, not for a customer with a good reason.
Enforced by a test, not by a promise
A privacy claim that lives only in a README survives exactly until somebody adds a field in a hurry. So an automated test scans delivered rows for reviewer identifiers at any depth — including inside nested objects and arrays — and fails the build if one appears.
What you get instead
| Field | What it supports |
|---|---|
body | The full review text. Sentiment, topics, keyword analysis. |
rating | Star rating where the vertical has one, null where Naver computes none. |
visited_at | Visit date. Trend and seasonality analysis. |
is_receipt_verified | Whether Naver verified the transaction. The strongest quality filter available. |
photos, videos | Media attached to the review. |
That covers what competitor and reputation analysis actually needs. The one thing it cannot support is per-reviewer analysis — which is precisely the analysis that is about people rather than businesses.
The Korean framework, briefly
Korea's data protection regime is among the stricter ones, supervised by the Personal Information Protection Commission. Like the GDPR it works from a lawful basis and a purpose, and like the GDPR it does not treat public visibility as consent.
Your obligations do not disappear
Review text is written by identifiable people even without an id attached: a review can name its author, describe a specific visit, or be unique enough to trace. What you keep, for how long, and what you publish is still your decision.
The Actor removes the field that makes mass re-identification trivial. It cannot remove the judgement that comes after.
