艦これ司令部室 - 専用ブラウザについて

専用ブラウザ

公式にアナウンスがありました。アドオンや専用ブラウザーの使用は厳密には規約違反とのことです。
司令部室だけでなく他のアドオンや専用ブラウザーも該当します。
例えば通信内容を見ているかどうかなどには言及していません。
誤解する人がいたので念のため、@KanColle_STAFFさん、@k2lunaticさん、@KylrIaさんは司令部室の作者ではありません。

2015/02/10の関連Tweetを引用します。

【リンガ泊地サーバ】で現在大破バグがあるのでは？という事例報告を複数頂きました。事例は全てある1名のユーザーのものです。同事例のログ解析を行いました。ご心配の提督も多いと思いますのでご報告します。『不正ツールの使用者以外で、そのような症状の発生は確認できません』でした。 #艦これ
— 「艦これ」開発/運営 (@KanColle_STAFF) February 10, 2015

ここでいう不正ツール使用者とは、BOT/マクロなどを使い不正ツールを使い、「艦これ」に不正規かつ仕様/ルール外の規約違反の方法で接続を試みるユーザーです。仕様/ルール内のみで動作する専用ブラウザは(厳密には規約違反にあたりますが)今回の説明上の不正ツールには含みません。 #艦これ
— 「艦これ」開発/運営 (@KanColle_STAFF) February 10, 2015

不正ツール使用は、規約違反です。ご使用はお辞めください。今回ご説明したような不正ツール使用者に対しては、あらゆるサポートは停止されます。また、任意のタイミングでアカウント停止その他の比較的厳しい処置をとらせて頂く場合があります。 #艦これ
— 「艦これ」開発/運営 (@KanColle_STAFF) February 10, 2015

参考までに2013/09/01にも言及されたことがありますので引用します。

【ご注意】利用規約にもある通り、マクロなどの特殊なプログラムを介して「艦これ」をプレイすることは禁止されています。そういった行為はお辞めください。通常のプレイではありえない挙動やプレイ履歴が確認された場合は、その時点でご利用の停止等の対応をさせて頂く場合があります。 #艦これ
— 「艦これ」開発/運営 (@KanColle_STAFF) September 1, 2013

@k2lunatic 厳密には規約には抵触していまうかもですが、「艦これ」開発/運営として問題視しているのは、別窓や自作(通常機能の)ブラウザではなく、「マクロ操作」「チート行為」です。これらは、現在個別に確認作業中で、確認でき次第、比較的厳しい対応をしていきます。
— 「艦これ」開発/運営 (@KanColle_STAFF) September 1, 2013

@KylrIa 厳密には規約違反ではあります…が、「艦これ」開発/運営としては、まずゲームプレイによるデータ挙動が不審なものから、確認＆対応してまいります。プライオリティとして「不正なプレイ」をしている可能性の高い方を確認してまいります。
— 「艦これ」開発/運営 (@KanColle_STAFF) September 1, 2013

特殊なプログラムを用いて「艦これ」ゲームサーバにアクセスすることは規約違反行為です。また、それらの一部は各サーバ群に極めて高い負荷をかけており、他の提督の皆さんのご迷惑となっています。現在追跡作業を行っており、恐縮ですが該当アカウントの無警告停止措置を実施して参ります。 #艦これ
— 「艦これ」開発/運営 (@KanColle_STAFF) September 27, 2013

今回高優先で厳しい対応させて頂くのは『特殊なプログラムの使用によって、意図的に「通常のゲーム進行ではない」「通常のゲームルールに則っていない」進行によって、サーバに深刻な負荷をかけている』規約違反の接続者の方です。大変恐縮ですが、ご理解頂けますと幸いです。 #艦これ
— 「艦これ」開発/運営 (@KanColle_STAFF) September 27, 2013

ちなみに司令部室では通信内容に一切手を加えていません。

技術的なこと

IEコンポーネントを使用しています。そのためインストールされているIEのバージョンに依存します。
.NET Frameworkを使用しています。Version 2.0～4.5.1で動作するはずです。4.0 Client Profileでも動作すると思います。3.5 Client Profileは諦めました。
F#言語で記述しています。F#言語は、関数型、オブジェクト指向型、および命令型の各プログラミングモデルをサポートします。
1.0.0まではFiddlerCoreを使用していました。
.NET FrameworkにはJSONパーサが複数あります。（JavaScriptSerializerとDataContractJsonSerializer。）さらにFiddlerCoreにもFiddler.WebFormats.JSONが存在します。しかし、いずれも動作が気に入らなかったので、自作したJSONパーサを組み込んでいます。
ミュート機能は.NET Frameworkで提供されないため、直接OSを呼び出しています。Windows 3.1から提供されているMixer APIを使用しています。 Windows Vista以降で提供されるCore Audio APIもありますが、どちらもソースコードの記述量が膨大になるので凹みます。ともあれ、Vista以降であれば艦これだけをミュートできます。XPではOS全体になってしまうかもしれません。
多くの資料でMIXERLINE_COMPONENTTYPE_DST_SPEAKERSをミュートする記述がありますが、0.2.4からはその元になるMIXERLINE_COMPONENTTYPE_SRC_WAVEOUTをミュートするようにしてみました。これでHDMIに対してもミュートが効けばいいのですが…。私自身環境を持たないのでこの辺りはよくわかりません。
画面の縮小表示にはIE7から搭載された方のズーム機能を使用しています。そのため、司令部室の動作にはIE7以降が必要です。ただしIE8以降を推奨します。
High DPI環境では自動的に125%拡大になるものの、ズーム倍率自体の取得方法がわからず、サイズ変更が正しく行えていませんでした。調べたところ、JavaScriptでwindow.screen.deviceXDPIを参照することで取得できることがわかりました。Internet Explorerではscreen.deviceXDPI / screen.logicalXDPIが拡大倍率を表しますが、 IEコンポーネントの場合、screen.logicalXDPIの値が誤っているため、96dpiでハードコーディングしています。
正式な対応方法としてはWebBrowserクラスを派生させる必要があることが判明しました。しかしながら、F#は言語仕様によりinner classを作れないため派生クラスを記述できないという壁にぶつかっています。そのため、画面サイズが1024以下の場合に落ちる問題を根本解決できずにいます。
発想の転換で、現在値を無視して常に上書きすることで派生クラスを不要にした上でDPI依存しないように実装できました。
スクリーンショットを保存するにあたってFlashが置かれているembed要素を取得し、IViewObject::Draw()を使ってBitmapに出力するようにしました。こうすることでスクロール位置や画面サイズに依存せず、スクリーンショットが撮れるようになりました。
Twitterへの画像投稿を実装するにあたって、OAuthプロトコルもF#で実装しました。本来はBasic認証と同様に透過的に署名（Authrizationヘッダー）を出力できるはずなのですが、 OAuth認証がHTTP認証の仕様に微妙に沿っていない（401 Unauthorizedが返されない）ため実現できませんでした。 Twitterが採用しているOAuth 1.0aの問題であり、OAuth 2.0では状況が変わってるかも。

専用ブラウザ

技術的なこと

Credit