크롬 웹스토어 반려 메일은 짧습니다. 정책 이름만 적혀 있고 코드의 어느 부분이 문제인지는 알려주지 않습니다. 그래서 받은 사람은 대개 두 가지 중 하나를 합니다. 정책 문서를 처음부터 읽거나, 억울함을 담아 이의를 제기하거나.
둘 다 시간이 오래 걸립니다. 순서를 바꾸는 편이 빠릅니다.
1. 통지문에서 두 가지만 봅니다
- 정책 이름 — 권한, 원격 코드, 사용자 데이터, 최소 기능, 스팸 중 어디인지
- 인용된 항목 — 특정 권한이나 URL, 등록 정보 항목이 따옴표로 인용됐다면 거기서 시작합니다
인용된 것이 없다면 그 카테고리 전체를 점검 대상으로 봐야 합니다. 권한 관련인데 특정 권한이 지목되지 않았다면, 개별 권한이 아니라 권한 설명들이 전체적으로 납득되지 않았을 가능성이 높습니다.
2. 반박보다 수정을 먼저 합니다
심사자가 오해했다고 생각되면 설명하고 싶어집니다. 실제로 그런 경우도 있습니다. 다만 수정한 내용이 붙은 재제출이 다음 심사에 확인할 거리를 주고, 내 판단이 틀렸을 때 손해도 적습니다.
메시지만 보내면 다음 심사도 같은 자리에서 시작합니다.
3. 지적된 줄만 고치지 않습니다
권한 하나가 지목됐다면 모든 권한을 다시 봅니다. 등록 이미지 하나가 지목됐다면 등록 정보 전체를 봅니다. 다음 심사에서 옆에 있던 다른 문제가 걸리면 또 한 사이클을 씁니다.
4. 재제출 메모는 세 가지만 씁니다
- 무엇을 바꿨는지 — 파일 경로까지 구체적으로
- 남은 것이 왜 필요한지 — 코드 설명이 아니라 사용자 입장에서
- 하지 않는 것 — 전송하지 않는다, 수집하지 않는다. 사실일 때만
정책 문구를 그대로 되풀이하거나 다음 버전에서 고치겠다는 약속은 넣지 않는 편이 낫습니다. 심사는 지금 제출한 패키지를 기준으로 합니다.
가장 흔한 세 가지
실제로 반복해서 걸리는 항목은 정해져 있습니다.
- 권한 사유가 코드 설명 — “chrome.storage를 사용합니다”가 아니라 사용자가 무엇을 얻는지를 써야 합니다
- 원격 코드 — CDN 스크립트 한 줄, 호스팅형 애널리틱스 태그가 대부분입니다. 데이터를 받아오는 것은 괜찮고, 코드를 받아 실행하는 것이 문제입니다
- 개인정보 불일치 — 처리방침, 권한 사유, 대시보드 데이터 공개 세 곳의 설명이 서로 달라서 걸립니다
항목별 상세
각 항목은 따로 정리해 두었습니다(영문). 권한 사유 작성법, 원격 코드 판정 기준, 개인정보 처리방침 요건, 반려 후 대응 순서.
제출 전에는 manifest 점검 도구로 선언한 권한과 심사에서 자주 질문받는 항목을 먼저 확인하실 수 있습니다. 무료이고 매니페스트는 브라우저 안에서만 읽습니다.
정리
통지문에서 정책 이름과 인용 항목을 찾고, 카테고리 전체를 고치고, 무엇을 바꿨는지 구체적으로 적어 재제출합니다. 이의 제기는 사실이 틀렸을 때만 하는 편이 시간을 아낍니다.
답글 남기기