open: 隠れプロキシの存在意義がわかった!

隠れプロキシの謎、というか存在する理由がなんとなく判明。
結論からいえば、どうやらPP_ConnVKK_1.33.761.1.cab(以下、長いのでConnVKKと略)が組み込む隠れHTTPプロキシはPIE専用であり、とりあえずSSL接続に関与していることが確認できました。

openからSSLのサイトにログインする場合、以前X01HTでのアクセスインターネット(以下、AIと略)を妨げる要因として紹介したことのあるHKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\EnableAutoDetect=dword:1(以下、長いのでEAD=1と略)が不可欠のようです。どうやらこれと、ConnVKKによって作成されるHKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ConnMgrExternalPath=(binary、どうやらこのバイナリデータが隠れプロキシを指しているらしい) との組み合わせによって、PIEでのみ隠れプロキシを経由させているようです。

  • AIでは、EAD=1が設定されている場合、PIEからは一切のWebブラウジング不可。
  • 無線LAN接続では、ConnVKKによって組み込まれる \Windows\wirelessmgr_service.dll(以下、ConnVKK版DLL)があると、EAD=1があってもPIEからのブラウジングが可能。SSLサイトもOK。
  • EAD=1を生かしたまま、ConnVKK版DLLをリネーム→再起動して無線LAN接続を試みるも、PIEからはブラウジング不可。
  • EAD=1を削除した状態では、AI/open/無線LANのすべてからPIEでブラウジング可能。ただしopenからはSSLが不可に。
  • ConnVKK版DLLが生きている状態では、EAD=1を削除しても無線LANで一度接続するだけでEAD=1が勝手に復活。
  • NetFrontの通常の挙動は、EAD=1を削除した状態のPIEと同一で、SSLへのアクセスは不可。ただしネフロのブラウザ設定でwebopenのプロキシを記述してやると、SSLへの接続がOKに(id:happy_esさん情報)。

つまり、webopenプロキシはopenのhttpプロトコル以外の通過制限を回避ないしは軽減するプロキシであり、openからのみ使用可能。ConnVKK版DLLは、webopenプロキシを使うかどうかをopen(webopenプロキシが必要)と無線LAN(同、不要)との間で切り替える機能を持っているようですね。
もちろん素のopenでも普通にWebを見るだけならOKなわけですが、SSLが使えないと、ここ「はてな」へのログインすらできないわけですから、やはりプロキシは通したほうがよさそうです。
しかし、コンパネの接続から「Internet」の下に直接webopenプロキシを記述すると、昨日も書いたように、ストリーミングなどが一切ダメになってしまいます。よって、webopenプロキシはPIEにのみ適用される形で組み込まれているのだろうと思います。
AI相当の仕様で定額APにすれば、こんな七面倒くさいことをする必要はないのでしょうが、まあ、守りたい何かがあるのでしょうね。それでもSSL(すべてOKでもないようですが…)をはじめとして、いろいろなプロトコルをたとえプロキシ経由ででも通そうとしてくれているのは、評価してもよいかもです。
現在open接続のActiveSyncでSSLが使えないのは、プロキシを通さない素のopenでつながっているからなのでしょうが、ひょっとしたらそれも、別のActiveSync専用プロキシによって解決を図ろうとしているのかもしれませんね。
==
ただし、ConnVKK版DLLもAIとの間では切り替えてくれないので、1台の端末を赤(もう赤ではないはずですが、新しいUSIMの色を知らないので…)の音声契約とデータ専用契約で使い分ける場合は、少し不便かもしれませんね。まあ、別の長い名前のAPNはともかくとして、音声契約でopenでなくAI接続が必要とされるシーンはそう多くないでしょうけどね。
==
と、いうわけで、一連の実験は実はHermesではなく、現在はサブ機となっているUniversal上で実施妄想ないしはフォトレタッチ中なのですが、Hermesと同じHTC製で、wirelessmgr_service.dllも共通仕様のUniversalゆえに、\Windows\wirelessmgr_service.dllもConnVKK版で実現妄想あるいはフォトレタッチできているわけです。
しかし、HTC製でもカスタマイズ内容が異なるであろうTreo750vとか、今後出てくるはずのSamsung富士通シーメンスASUSTeK製端末などでは別の対策妄想またはフォトレタッチが必要になってくるのかもしれません。