Skip to content

Counsel Prep Brief — TwoMore v2 Privacy Policy + Terms of Service

For: Korean privacy / IT-law counsel engagement Subject: Pre-counsel review of KR-1.0.0 privacy policy + terms of service Status: Archived Prepared: 2026-05-19 Author: Engineering team self-audit against PIPA / 정통망법 / 위치정보의 보호 및 이용 등에 관한 법률

Purpose of this brief

This document is not a substitute for counsel review. It's a structured pre-pass: 25 findings against the published Korean legal frameworks, each annotated with the engineering fix already applied (if any), the remaining question for counsel, and the file/line where the issue lives.

The goal is to reduce counsel's first-pass turnaround time by removing obvious bugs (typos, missing contact details, placeholder text) before they read the documents — so the counsel hours go toward judgment calls, not basic completeness.

Documents under review

DocumentPathLinesStatus
개인정보 처리방침 (Privacy Policy)packages/features/profile/src/privacy-screen.tsx424KR-1.0.0, effective 2026-05-18
이용약관 (Terms of Service)packages/features/profile/src/terms-screen.tsx211KR-1.0.0, effective 2026-05-18
Purpose catalog seedsupabase/migrations/00172_seed_kr_purpose_catalog.sql476 purposes seeded
Policy URL migrationsupabase/migrations/00176_update_policy_urls.sql31All URLs now point to in-app deep-link routes

Operational facts counsel should know

  • Cross-border PI processors: Supabase Inc. (US, AWS us-east), Functional Software Inc. (Sentry, US, GCP), Expo Inc. (US, AWS). All three are §28-8 entrustment cases (위탁), NOT §17 third-party transfers. None re-sell user data.
  • Korean processors (no §28-8 disclosure required): Naver Cloud Platform (지도/지오코딩), Daum 우편번호 (주소 검색). Both Korean data centers.
  • Under-14 enforcement: Client-side onboarding block + server-side BEFORE INSERT/UPDATE trigger reject_under14_birth_year (migration 00186). Defense-in-depth on both layers. No 법정 대리인 동의 mechanism implemented.
  • Marketing consent split: Two separate purpose keys — marketing_push (general) and marketing_push_night (21:00–08:00 KST window per 정통망법 §50-8). Annual re-confirmation cron at 02:00 KST per migration 00171.
  • GPS feature: useGpsCheckin (attendance) + useGpsDefaultRegion (region default). Server-side 200m radius + ±2h time window in migration 00131/00136. lbsc.kr 위치기반서비스사업자 신고 not yet filed — see Pre-launch Checklist #3.
  • PIPA §35-2 export: export-user-data edge function returns full JSON. Rate-limited to 3 calls per hour per user.
  • PIPA §29 audit log: pi_access_log table + record_pi_access SECDEF RPC writes a row on every cross-user PI read (migration 00185).
  • PIPA §21 deletion: delete_account_atomic SECDEF RPC (migration 00186). Atomic in one transaction: deleted_at + push_token clear + consent revocations + audit row. The 30-day anonymization cron (anonymize_withdrawn_profiles) handles full PII erasure after the grace period.

Findings

Privacy Policy — Critical

P-CRIT-1: Expo Inc. cross-border §28-8 contact missing

  • File: privacy-screen.tsx:182
  • Issue: §28-8(1)(7) requires the 수탁 업체 개인정보 담당자 contact (email or phone). Row currently shows only the privacy-policy URL.
  • Engineering fix applied: Updated to privacy@expo.dev per Expo's documented contact.
  • Counsel question: Confirm this email is the correct §28-8 contact under Korean disclosure standards. If Expo doesn't accept legal notices at that address, we need to substitute.

P-CRIT-2: Marketing consent re-confirmation disclosure missing

  • File: privacy-screen.tsx — no current section covers this
  • Issue: 정통망법 §50-7 requires 24-month re-consent for marketing communications. Migration 00171 implements an annual reconfirmation cron at 02:00 KST. Privacy policy doesn't disclose this practice.
  • Engineering fix applied: None — pending counsel guidance on whether to add a new section or extend §1 ⑤.
  • Counsel question: Where is the canonical location for this disclosure? Most Korean ToS templates put it in the 개인정보 처리방침 §1 (처리 목적) as a sub-clause under marketing.

P-CRIT-3: 14세 미만 not disclosed in Privacy §2

  • File: privacy-screen.tsx:58-80
  • Issue: Privacy §2 lists collected PI items but doesn't state the 14-and-up age restriction. PIPA §22-2 requires disclosure of children's privacy practices. Terms §6 covers it, but the Privacy Policy should mirror.
  • Engineering fix applied: None — pending counsel.
  • Counsel question: Confirm we don't need a dedicated 아동의 개인정보 처리 section in the Privacy Policy. Terms §6 may be sufficient if Privacy §1 ① references "14세 이상 회원" language.

Privacy Policy — High

P-HIGH-1: PIPA §15(1) per-item legal basis mapping

  • File: privacy-screen.tsx:43-95 (§1 + §2 + §3)
  • Issue: Many Korean privacy policies cross-reference each PI item to a specific processing purpose + legal basis (계약 이행 / 동의 / 법령상 의무 / 정당한 이익). Current text describes purposes (§1) and items (§2) separately without the mapping.
  • Engineering fix applied: None.
  • Counsel question: Is the cross-reference table a hard requirement or a stylistic preference? KCC enforcement actions in 2024–2025 have flagged its absence — confirm.

P-HIGH-2: Password hash storage not disclosed

  • File: privacy-screen.tsx:62-80
  • Issue: Email/password login path stores a bcrypt password hash in Supabase Auth. The 처리 항목 list mentions email but not the password (or its hashed form).
  • Engineering fix applied: None.
  • Counsel question: Should "암호화된 비밀번호" be added to §2 [필수]? Convention varies.

P-HIGH-3: §29 안전성 확보조치 incomplete vs KCC standard 9 items

  • File: privacy-screen.tsx:215-232
  • Issue: KCC 안전성 확보조치 기준 (2024년 9월 개정) lists 9 required items. Current §9 covers 5: 데이터 암호화, 접근 통제(RLS + MFA), 접근 기록, 자체 점검, 취급자 최소화. Missing: 내부 관리계획, 악성 프로그램 방지, 물리적 안전 조치, 재해·재난 대비.
  • Engineering fix applied: None.
  • Counsel question: Confirm the 4 missing items must be disclosed even if the underlying control is the cloud provider's responsibility (Supabase / AWS).

P-HIGH-4: lbsc.kr 위치기반서비스사업자 신고번호 placeholder missing

  • File: privacy-screen.tsx:43-56 (§1 mentions GPS but no 신고번호)
  • Issue: Once the KCC filing completes (pre-launch-checklist.md §3), the assigned 신고번호 must be published in the Privacy Policy. Currently no placeholder.
  • Engineering fix applied: Added a TODO marker section in §1 with [신고번호: 신고 진행 중 — 신고 완료 후 갱신].
  • Counsel question: Verify exact format the KCC expects for the 신고번호 disclosure.

P-HIGH-5: PIPA §35-2 rate limit not disclosed

  • File: privacy-screen.tsx:189-201 (§7)
  • Issue: The export-user-data edge function rate-limits to 3 calls/hour per user. A user invoking their §35-2 right at scale could hit a 429 with no advance disclosure.
  • Engineering fix applied: None.
  • Counsel question: Is a rate limit on §35-2 portability requests permissible? If yes, must we disclose? If we should remove the limit, what about DoS protection on the export edge function?

P-HIGH-6: Aggregate/anonymized data retention indefinite — not disclosed

  • File: privacy-screen.tsx:81-95 (§3)
  • Issue: After full anonymization (30 days post-withdrawal), the underlying numeric records (ELO history, match counts, leaderboard contributions) persist indefinitely. §3 doesn't disclose this.
  • Engineering fix applied: None.
  • Counsel question: Standard Korean privacy-policy language for "비식별·익명화된 데이터는 통계 목적으로 영구 보관할 수 있음" — confirm exact phrasing.

Privacy Policy — Medium

P-MED-1: §7 10 영업일 vs 10일

  • File: privacy-screen.tsx:199 and :258
  • Issue: PIPA §38 specifies "10일 이내" (calendar days, not business days). "10 영업일" creates ambiguity that PIPC enforcement may flag.
  • Engineering fix applied: Changed both occurrences from "10 영업일" to "10일".

P-MED-2: §5 위탁 계약 종료 시 파기 절차 disclosure missing

  • File: privacy-screen.tsx:109-141
  • Issue: §5 lists 수탁 업체 + 보유 기간, but doesn't disclose what happens to data after the contract ends. Counsel may want explicit "위탁 종료 시 수탁사 보유 데이터 즉시 파기 보장" language.
  • Engineering fix applied: None.
  • Counsel question: Stylistic preference vs hard requirement.

P-MED-3: OS-permission disclosure (notification + location)

  • File: privacy-screen.tsx — no dedicated section
  • Issue: App requests notification + foreground-location permissions. The 자동 수집 in §2 mentions push token but not the permission gate.
  • Engineering fix applied: None.
  • Counsel question: Add a 권한 안내 section, or is §2 + §10 (자동수집장치) sufficient?

Terms of Service — High

T-HIGH-1: §6 14세 미만 가입 차단 — 기술적 조치 명시

  • File: terms-screen.tsx:78-81
  • Issue: Current text says "법정 대리인 동의 수집 절차를 갖추지 않았으므로 14세 미만의 가입 신청을 받지 않습니다." Clearer to also state that a server-side trigger (migration 00186) technically blocks the registration. The current wording could be read as a policy stance without enforcement.
  • Engineering fix applied: None.
  • Counsel question: Standard Korean ToS language for "기술적 조치를 통해 차단" — does adding this language strengthen our PIPA §22-2 compliance posture?

T-HIGH-2: §12 관할 법원 conditional structure

  • File: terms-screen.tsx:142-144
  • Issue: Current: "회사의 주소지가 서울특별시에 소재하는 경우, 서울중앙지방법원을 제1심 전속 관할 법원으로 합니다." The conditional is awkward — either 서울중앙 is the venue or it isn't.
  • Engineering fix applied: Simplified to standard Korean ToS clause: "회사의 본점 소재지를 관할하는 법원을 제1심 전속 관할 법원으로 합니다."
  • Counsel question: Confirm the simplified form is preferable.

Terms of Service — Medium

T-MED-1: §10 결제 및 환불 placeholder

  • File: terms-screen.tsx:122-128
  • Issue: Current "유료 서비스 미제공 시 본 조항은 적용되지 않습니다." Will need full restructure when Portone v2 + Phase 7 payments ship.
  • Engineering fix applied: TODO marker added.
  • Counsel question: When Phase 7 ships, what payment-clause structure best satisfies 전자상거래법 + 약관 규제법?

T-MED-2: §3③ 약관 변경 공지 channel

  • File: terms-screen.tsx:46-48
  • Issue: "서비스 내 공지 화면에 적용 일자 30일 전부터" — but the app doesn't yet have a dedicated 공지사항 screen. Push notification + in-app modal are the implemented channels.
  • Engineering fix applied: None.
  • Counsel question: Add specific channel disclosure ("푸시 알림 + 인앱 모달") or keep generic?

Cross-references and pre-launch dependencies

  • Pre-launch Checklist #1 (CPO contact): privacy-screen.tsx:254-257 — placeholder values blocked until founder/CTO confirms real values.
  • Pre-launch Checklist #3 (lbsc.kr 신고): Privacy §1 must reference the eventual 신고번호 after filing completes.
  • Pre-launch Checklist #2 (counsel review): This brief is the input to that engagement.

Engineering fixes applied in this pass

Pre-counsel cleanup commit (will be referenced when counsel review starts):

  1. ✅ P-CRIT-1: Expo privacy@expo.dev added
  2. ✅ P-HIGH-4: lbsc.kr 신고번호 placeholder added to §1
  3. ✅ P-MED-1: 10 영업일 → 10일 (both occurrences)
  4. ✅ T-HIGH-2: 관할 법원 simplified

All other findings (the substantive Korean-legal-text additions) are intentionally left for counsel because they involve drafting decisions that AI shouldn't make on a regulated document.

Counsel deliverables requested

When you engage with this brief:

  1. Confirm or override each engineering fix listed above.
  2. Apply the substantive additions for HIGH findings P-HIGH-1, P-HIGH-2, P-HIGH-3, P-HIGH-5, P-HIGH-6, P-CRIT-2, P-CRIT-3, T-HIGH-1, T-MED-2, P-MED-3, P-MED-2.
  3. Bump version to KR-1.0.1 once changes are applied.
  4. Sign a docs/counsel-review-log.md entry with date, reviewer name + license number, and the diff range reviewed (a counsel-review log is the audit trail PIPC will want).

Cross-reference: ISO/IEC TS 27560:2023 alignment

user_consent.evidence JSONB column already follows the ISO/IEC TS 27560:2023 consent-record schema. No counsel action needed; this is mentioned only so the reviewer knows the consent ledger structure is standards-aligned even if the privacy policy text isn't yet.

Markdown remains the source of truth. Run yarn docs:check before handoff.