ノート道具を作る

Chrome拡張を公開したら、自宅の住所も公開されていた

拡張機能のストアページを下まで見たら、自宅の住所が表示されていた。利用者のデータを外に出さない設計は何度も確認していたのに、公開する側である自分の情報がどこまで出るかは確認していなかった。トレーダーの申告を見直すまでの記録。

道具を作る 開発記録

Read this note in English

薄い紫の背景に白いカードが立ち、文字のない灰色の線が並んでいる。カードの下端からは、濃いインディゴの細い帯が一本だけ手前にはみ出している

拡張機能を公開したあと、自分のストアページを開いて確認していました。説明文が意図どおりに表示されているか、スクリーンショットの順番は合っているか。そういう確認のつもりでした。

ページを下へ進むと、見覚えのある住所がありました。自宅の住所でした。

利用者の情報には気をつけていた

Legacy Tools では、利用者が入力した内容を外部へ送信しない拡張機能を作っています。処理はブラウザの中で行う。必要以上の権限を要求しない。入力した文章も検出結果も集めない。

この点は、実装中も、ストアへ提出するときも、繰り返し確認しました。利用者のプライバシーを扱う道具を出す以上、曖昧にはできない部分だと考えていたからです。

その一方で、公開する側である自分の情報が、ストア上でどこまで表示されるのかは確認していませんでした。利用者の情報を外に出さないことばかり見ていて、自分の住所が外に出る経路のほうを見ていなかった、ということになります。

トレーダーという申告項目

Chrome Web Store で拡張機能を公開するとき、開発者は自分が「取引業者」か「非取引業者」かを申告します。

ここでいう取引業者は、株式などを売買する人という意味ではありません。仕事や事業に関係する目的で活動している公開者を指します。自分はこの項目を取引業者として設定し、確認を進めました。

その後、確認に使われた住所が、公開した拡張機能のページに表示されていました。

FAQを読むと、取引業者は法的名称、連絡先の電話番号、住所などを提供し、確認された情報は掲載ページの下部で公開される、と書かれています。公開されても問題のない住所を使うように、という注意も添えられていました。

書かれていたことではあります。ただ、申告画面を進めていたときの自分は、本人確認のための情報を登録しているつもりでした。それが利用者から見える情報になる、という形では想像できていませんでした。

気づいたときには、すでに一度公開されていました。

非取引業者を選べばよい、という話ではなかった

住所が出るなら非取引業者にすればいい、と最初は考えました。

ただ、これは住所を表示するかどうかを選ぶプライバシー設定ではありません。住所を出したくないという理由だけで実態と違う申告をするのは、順番が逆だと思いました。

そこで、申告画面の説明をもう一度読みました。

欧州経済領域(EEA)の消費者保護法に関して、パブリッシャーのアカウントが取引業者とみなされるか、非取引業者とみなされるかを宣言します。

判断の基準は「この市場で締結される契約に関して、専門的な目的で活動しているか」でした。開発者としての実績や、道具を作った動機の話ではありません。

Legacy Tools の拡張機能は、現在すべて無償で公開しています。ストア上で売買の契約を結んでいません。この基準に照らすと、非取引業者のほうが実態に合っていました。

Developer Dashboard の設定で申告を変更すると、住所の表示はすぐに消えました。

つまり、問題は住所そのものではなく、実態と合っていない申告によって、本来なくてよい掲載が出ていたことでした。

ここまでのうち、住所が表示されていたことと、申告を変えたら消えたことは実際に起きたことです。申告画面の文言は自分で読んで確認した内容で、以下はそこから考えたことになります。

消えたのは、いまの状態だけ

これで解決したとは思っていません。

ストア上で課金する場合は、専門的な目的での契約に当たると考えられるので、そのときは取引業者として申告することになるはずです。同じ住所の問題が戻ってきます。これは申告画面の文言から自分が読み取った解釈で、課金時の条件そのものを確認したわけではありません。

そして、Developer 登録に使ったアカウントは、あとから選び直せない部分があります。将来課金する可能性があるなら、最初の登録の時点で、公開されてよい名義・住所・連絡先を持ったアカウントである必要がありました。

拡張機能を作り始めたとき、考えていたのは主に機能のことでした。何を検出するか、どの権限が要るか、どの画面で動かすか、入力内容をどう扱うか。

名義、住所、電話番号、問い合わせ先は、完成したあとにストアへ登録する事務作業だと思っていました。実際には、これも設計の一部でした。決めておくべきだったのは、このあたりです。

  • 誰を正式な公開主体にするか
  • 個人名義で出すのか、事業上の名義を用意するのか
  • 公開してよい住所をどう用意するか
  • 個人用と公開用の電話番号やメールアドレスを分けるか
  • 問い合わせを継続して受けられる状態にできるか

Chrome拡張のコードを書く技術とは関係のない話です。ただ、個人で公開を続けられるかという点では、コードより先に決めておく必要がありました。

見えていなかったのは、住所だけではなかった

拡張機能本体を多言語化しただけでは、ストアページの多言語対応は終わりません。説明文とスクリーンショットは、対応する言語ごとに登録します。

日本語・英語・中国語の3言語で5枚ずつ用意するなら、スクリーンショットだけで15枚になります。各言語で内容と順番を揃え、実際のストアページでどう見えるかを確認する作業も要ります。

画像や掲載情報を直したときも、Webサイトのように変更がすぐ反映されるとは限りません。再び審査を待つことがあります。

こうした作業は、申請画面を見ている段階では軽く感じられました。実際に公開されて、自分のストアページを利用者と同じ画面で見てから、重さが分かりました。

公開とは、どこまで見せるかを決めることだった

自宅の住所が公開されていることに気づいたときは、率直に怖いと感じました。

ただ、これは Chrome Web Store だけの特殊な落とし穴ではないとも思います。個人で何かを公開するとき、サービス名や製品名の後ろには必ず公開者がいます。

利用者に何を見せるか。どの言語でどう説明するか。直したとき、反映までの時間をどう見込むか。そして、誰がどの情報を伴って公開するのか。そこまで含めて決めることが、公開の準備でした。

小さな道具でも、長く公開するつもりなら、公開者自身の情報をどう扱うかを先に決めておく。コードを書き始める前には考えていなかった、公開する側のプライバシーの話です。

タグ: Chrome Web Store・個人情報・公開準備

← ノート一覧へ