FANDOM


検証データベースとは、検証DB提携ツールによって収集されたデータを集積するための、『艦これ検証部』が所有するデータベースである。
諸問題により、現在は停止中。
受信/送信のプログラムの構造、情報の集積方法他数々の問題を抱えており、データベースの体を成していないとして、「DustBox」と揶揄されているのが現状だ。

ここでは、検証DBの何が問題なのか、それによってどんな被害が生じる可能性があるのかを解説する。

はじめに編集

ktgohan氏 より、埋め込みなら転載・引用の許可を頂いたのですが、Wikiaではツイートの埋め込みが出来ない模様(タイムラインは出来る)なので、こちらのツイート等を参考にしつつ、問題点を洗い出していきます。

このデータベースは何を集めているのか編集

ほぼ全てのJSON。例外となっているのは、アクセストークン値と呼ばれる、ユーザーIDとパスワードによって認証された「アカウント識別情報」のみであり、専ブラ側で破棄している。

これは、DMMログインの度に発行されなおすものの、仮にDBに残されていたとしたら、そのデータを元にして、他者がそのデータの持ち主に成りすまして艦これを弄りかねないという、とんでもない代物と認識してもらって良い。

専ブラ側の処理としては、このアクセストークン値を破棄した上で、それ以外の全てのデータを送信するという、些か乱暴なデータ取りを行っている。

これは、艦これAPIの仕様変更があった際、そのデータが拾えなくなるのを危惧してこんな仕様にしてるらしいのだが・・・。

これの何が危ないのか編集

大きく分けて3点。

送信側の問題編集

先程、このアクセストークン値は破棄した上で送信すると書いたが、逆に言えばやっているのはそれだけである。

送信プログラムの核となっているKCVDB.Client.dll側では、アクセストークン値の破棄を行っていない為、悪意のある、または知識のない製作者がこの破棄処理を怠ったプログラムを作った場合、容易に漏洩するという事である。

また、DMMが何かのはずみでこのアクセストークン値仕様の変更を行った場合、対応専ブラは仕様変更に対応するまでは、この仕様変更されたアクセストークン値まで、全部検証DBに垂れ流される事になるのである。

この様な変更は、基本サイレント修正(真っ当なユーザーなら、一切害が無いし、意識する必要も無い為)であり、専ブラ作者としては早急に対応するではあろうが、そんなのはユーザーは基本知らないので、セキュリティ的には極めて危険かつ、DMMにも被害が及びかねない事態になるのである。

受信側(DB)の問題編集

受信側のDBにおいて、アクセストークンの破棄漏れや、上述の様な仕様変更があったとしても、このDB、そういったデータの破棄手段を一切組まれておらず、受信したデータを整理するだけ整理して、ひたすら貯め込むという、雑極まりない作りとなっている。

この破棄手段がないというのは、悪意のあるプログラム製作者によって、偽データを送られかねないという、データ精度の問題にも関わってくる。

やりようによっては、1-1で大和ドロップや、ALL30の建造で親潮の建造の偽装データを差し込むといった事も出来るという事である。

また、10000人超え(後に延べ人数と判明)という膨大な数は、検証部としても考えてなかった上に、データ量・サーバー代の試算を一切してなかったという、丼勘定。

そして、春イベに間に合わせる為だけの為に急ぎ運用した影響で、DBに置く予定の解析プログラムはおざなりにしており、運用状態は、ただひたすらデータを貯め込むだけ。そして解析はサーバー側でやりたいのに、おざなりだった影響で、こしあん氏が態々1日100Gというデータを落として解析するという、とんでもない処理をしている。

これは後述の問題にも関わるが、個人情報同然のデータを、ローカルに落として処理しているという事であり、例えるなら、社外持ち出し禁止の書類を頻繁に持ち出しして処理しているという事に等しい。

また、ここまでDBとして扱っているのだが、実態はTable Storage(構造型データセットを格納するもの、NoSQLの運用も可能)ではなく、Blob Storage(非構造化オブジェクトデータを格納するもの、任意のデータを保存するだけのもの)。DBとは名ばかりで、置き場所でしかないという代物なのである。ただし、こちらは後の日刊びいかめにおいて、得たjsonをサーバー内で走らせる事により、プレイ状況の再現を試みる事を考えていた為、一応の妥当性は判明している。

管理者の問題編集

ここまででも割と大概なのだが、これらの雑な管理・システムは、のいじ氏を初めとする検証部が構築したのは言うまでもない。

そしてDBに貯め込んであるデータは、言うまでもなく送信した各提督の個人情報の塊である。

彼らは様々な理由で、時には面白半分でデータを落として、おもちゃとして扱っているのである。

のいじ氏が行った、16年春イベE6ボスのダメージコンテストは、その典型例であろう。

のいじ氏は、以前より他人の課金を極めて気にする傾向があり、DBを分析して、課金アイテムランキングを作りたいだの言ってみたり、彼がイベントのRTAを主催しているのも、RTA参加者がどれ位散財したかを知りたいが為だったりするのである。(最も彼のRTA参加者は、まともに答えないのが多数との事だが。)

また、DBのデータのダウンロードには専用のソフトがあったのだが、検証部のSkypeグループチャットにソフトが貼られており、チャット参加者なら誰でも落とせる様になっていた事、そのソフトの中にアクセスの為のIDとPWが埋め込まれていた事も判明。

この様な運用で、データを預けるだけの信用が、彼らにどれ位あるかというと・・・。

そして、これだけ炎上し、DMMからも勧告が出ているというのに、このDB運用は6/22まで続いていた。

猫でもわかる、被害予測の具体例編集

ここまで長々と書き記したが、「長げーよ」「わかんねえよ」という声もあると思うので、起こりうる具体例を挙げる。

セキュリティ的な被害予測例編集

  • アクセストークン漏れによる、艦これアカウント乗っ取り。自分の艦隊が他人に好き放題される可能性がある。
  • 課金状況の漏洩。指輪やネジを買ったデータは、当然の如くダダ漏れである。特にのいじ氏はこの課金状況に執着があり、当たり前の様に彼に情報を漁られている可能性がある。

プライベート的な被害予測例編集

  • 艦隊の行動履歴。ほぼ全データが送られているという事は、各自のプレイスタイルが赤裸々に残されているのである。これがどれ位拙い、または恥ずかしい状態になるのかというと・・・(2例ほど)
    • 戦果稼ぎである5-4の周回数等が、彼らの手に渡る。EO砲始め、戦果のボーダーが見破られるのは勿論、それを参考にしたより効率的な周回も分析される。検証部からの離脱者ではあるが、びいかめ氏はデータが貯まったら、このデータを元に、下手すると5-4周回BOTの製作にすら繋がりかねない、詳細な対5-4分析を行おうと考えていた。
    • 母港での行動も割と筒抜けである。つまり、嫁艦を中大破させて(当然、指輪の有無もデータにある)、母港で待機したりしたままにすると、それがしっかりDBの記録として(正しくはその間、母港で出来る操作が無いという情報が)残されてしまうのである。その間の変な間が全部記録されているという事は・・・。(6月7日、コメント指摘により修正)

「消費者による確率情報の調査」と検証DB 編集

確率によって何らかの要素が左右されるゲーム、特にそこに課金モデルが結びつくゲームについては、「表示されていない確率が知りたい」という消費者側の欲求は何らおかしなことではなく、阻害されてはならないものである。他のゲームでもしばしば議論に挙がる部分であることは間違いない。

しかし、この検証DBについてはその実装が常軌を逸したものであり、諸問題を指摘されても検証部は対応を怠ってきた。ゲームサーバーと専用ブラウザ間で情報を集積する実装は検証DB以外にも存在するが、DMMから警告を受けたことが明らかになっているのはこの検証DBである。検証DBの存在は、最終的には「確率を知りたいユーザー」の行動を却って妨げ、害を及ぼす可能性が極めて高い。

確かに本問題は、艦これ運営ひいてはDMMが「外部ツールの全面禁止」を持ち出す可能性を孕んでいたことも事実である。しかし、仮に検証部の活動が成功を収めていた場合、運営に対する圧力団体の確立検証結果の独占という、ユーザーにとって迷惑極まりない組織が誕生していたであろう。ご覧の通り、検証部代表者からして様々な問題を抱えているのだから。また、追及側の人々には「この運営ならそこまでの強硬策を取ることはないだろう」というある種の信頼感が存在している。万が一「確率情報の調査手法」に対し何らかの制約を強化するのであれば、そちらにも反対する姿勢は存在することを明記しておく。

参考資料 編集

広告ブロッカーが検出されました。


広告収入で運営されている無料サイトWikiaでは、このたび広告ブロッカーをご利用の方向けの変更が加わりました。

広告ブロッカーが改変されている場合、Wikiaにアクセスしていただくことができなくなっています。カスタム広告ブロッカーを解除してご利用ください。

FANDOMでも見てみる

おまかせWiki