雑記

◆ [FreeBSD] 7.3-RELEASEでのソフトウェアRAIDの書き込み速度比較

7.3でataraid, gmirror/gstripeおよびZFSによるRAIDの書き込み性能を比べてみました。

OS

FreeBSD 7.3 amd64

CPU

Core2 Duo E6700(2.66GHz)

M/B

Intel DG33TL

Mem

DDR2-800 6GB(一部2GB)

HDD

Hitachi HTS545050B9A300 x 4

上記環境でddによる/dev/zeroからの1GB連続書き込み

# dd if=/dev/zero of=/mnt/xxx/t.img bs=1024000 count=1024

を10回試行したときの最大/最小値を比較。ad, ar, gm/gsではパーティションは切らずに、

 # newfs /dev/ad8
 # mount /dev/ad8 /mnt/xxx

のようにディスク全体をnewfsして直接マウントした。

[border]

device＼type	2台stripe	3台stripe	4台stripe	raid01	raidz1	raidz2
ad(HDD単体)	[tright]71.1 / 67.9MB/sec
ar	82.1 / 74.8	101.4 / 93.4	120.4 / 110.1	82.3 / 75.8	×	×
gm/gs	104.9 / 96.8	136.1 / 128.4	159.3 / 145.6	106.6 / 97.8	×	×
zfs(6G)	307.7 / 189.9	380.2 / 217.0	402.9 / 289.3	295.8 / 187.8	223.5 / 132.5	151.7 / 94.9
zfs(2G)	-	-	219.1 / 118.7	128.7 / 121.4	102.7 / 95.7	67.9 / 59.7

• 表には載せていないがarおよびgm/gsはメモリ搭載量でスコアに変化なし
• ZFSはメモリ搭載量にパフォーマンスが影響を受ける(2Gの2/3台stripeは取り忘れ)
• 余談だが、arのdelete, createでリブートの必要が無くなり、ハンドリングがだいぶ改善されている

というわけで、スコアだけ見ればZFSが圧勝で、4台のraid6でも他のデバイスでの同じ台数のstripeに匹敵するほどでした。これはちょっと意外。ただしZFSは以下の点が気になります。

• スコアのムラが大きく、また一定しない
• スコア自体がHDD単体時の71*4=284MB/secを超えているのが、どういう理屈によるものなのか心配^J(設定はcompression=off, compressratio=1.00x)

◆ 追試(5/10)

上の実験、/dev/zeroではパリティの計算が一瞬で終わってしまいちゃんとした比較にならないかもしれないと思い、追試してみました。サンプルとしてパッと思いつくのは/dev/randomですが、読み出しがボトルネックになるので、tmpfsを使ってメモリ上にサンプルを準備します。

/etc/fstabを編集して最大1.5GB分の領域を確保

 tmpfs /tmp tmpfs rw,mode=1777,size=1610612736 0 0

1GBのファイルを準備

 # dd if=/dev/random of=/tmp/t.img bs=1024000 count=1024

この/tmp/t.imgを使って書き込み速度を計測してみました。メモリ容量が速度に影響するのは上の実験で分かっているので、比較のために/dev/zeroの速度も測りました。

[border]

file＼raid	raidz1	raidz2
/dev/zero	173.0 / 137.0	110.1 / 63.8
random	260.1 / 187.2	109.3 / 96.2
zero	261.6 / 151.0	108.2 / 102.6

ご覧の通り、/dev/zeroのraidz1は不思議な速度低下をしたので、/dev/zeroから生成した/tmp/t.imgを使った実験も行って表の一番下の行に記載しました。tmpfs使った以外は上の実験と条件変わらないはずなので、ちょっと謎です。

さておき、結果的にはファイルの内容が0-fillでもランダムな値でも速度的には変わらないようでした。前回の実験と値がけっこう変わってますが、これはtmpfsを使った影響とみればいいのかな？

◆ [VMware] Nagios+sshでVMware ESXi ホストの LSI(3ware) 9650SE RAIDの状態を監視する

VMware ESXiを9650SEコントローラを載せたマシンにインストールすると、vSphereからもSNMP trapを使っても状態監視が出来ません。唯一の手段として、LSIのサポートページからダウンロードできるtw_cliをインストールして、sshでログインしたコンソールで実行するという方法がありますが、いちいちそんな手間をかけるのはめんどくさい。といっても、sshでアクセスしてコマンド使って状態確認できる状況なら、あとはそれを自動化するだけだよねぇ。ということでやってみました。

;ESXiホストへのドライバのインストール

(((

9650SEのドライバは標準ではインストールされていないので、LSIのサポートページに従ってドライバをインストールします。 )))

;sshdの有効化

(((

9650SEのドライバをインストールしてESXiを再起動したら、次の手順でsshdを有効化します。

1. コンソール画面で<Alt>+F1を押す
2. "unsupported"と入力してシェルを起動する
3. "vi /etc/inetd.conf"を実行してsshのコメントを外す
4. シェルを抜け、VMwareを再起動する

)))

;SSH公開鍵の作成とコピー

(((

監視を自動化するためには、sshの認証を通過するような仕込みをする必要がありますが、スクリプトにrootの生パスワードを書いたり、パスワード無しのアカウントを利用するのはさすがに論外なので、パスフレーズ無しのSSH公開鍵を使った公開鍵認証を使うことにします。

 % ssh-keygen -N "" -f id_vmware

上記コマンドを実行すると秘密鍵(id_vmware)と公開鍵(id_vmware.pub)が生成されます。

生成した公開鍵をとりあえずVM ホスト(vmhost)にコピーします。

 % scp id_vmware.pub root@vmhost:

)))

;tw_cliのダウンロードとコピー

(((

LSIのサポートページの下の方に、tw_cli.zipがあるのでダウンロードして解凍後、コピーします。

 % unzip tw_cli.zip
 % scp tw_cli root@vmhost:

))) ;vmhost側の準備

(((

vmhostにログイン

% ssh root@vmhost
root@vmhost"s password: [パスワード入力]
(ここに注意書きがずらずらと表示される)
~ # 
tw_cliを/sbinに移動
 ~ # mv tw_cli /sbin/
SSH公開鍵を/.ssh/authorized_keysにリネーム
 ~ # mkdir /.ssh
 ~ # chmod 700 /.ssh
 ~ # mv id_vmware /.ssh/authorized_keys

;より安全な設定

このように公開鍵を単純にauthorized_keysにリネームしても良いのですが、公開鍵の行頭に「command="/sbin/tw_cli /c6/u0 show" 」と記述すると、この公開鍵を使ったログイン時には、クライアントから指定されたコマンドは無視されて必ずcommand=で設定したtw_cliコマンドが実行されるようになります。^J後述するスクリプトも修正する必要がありますが、万が一秘密鍵を盗まれても余計なコマンドを実行できないようにしたければ、そのような設定も可能です。

ここまででいったんログアウトして、テストしてみます。

 ~ # exit

))) ;テスト

(((

監視サーバからvmhostにid_vmwareを使ってパスフレーズ無しでtw_cliを実行できるかテストします。

% ssh -i id_vmware root@vmhost /sbin/tw_cli show
The authenticity of host "vmhost (xxx.xxx.xxx.xxx)" cant be established.
DSA key fingerprint is ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added "vmhost" (DSA) to the list of known hosts.
　
Ctl   Model        (V)Ports  Drives   Units   NotOpt  RRate   VRate  BBU
------------------------------------------------------------------------
c6    9650SE-4LPML 4         2        1       0       5       1      -
　
%

後ほどNagiosの設定で使うので、vmhostのホスト鍵を抜き出しておきます。

 % grep vmhost ~/.ssh/known_hosts > /tmp/vmhost_key

))) ;Nagiosの準備

(((

Nagiosを実行するユーザーのホームディレクトリを調べてSSHの秘密鍵とvmhostのホスト鍵をコピーします。

 # grep nagios /etc/passwd
 nagios:*:181:181:Nagios pseudo-user:/var/spool/nagios:/sbin/nologin
 # mkdir /var/spool/nagios/.ssh
 # mv id_vmware /var/spool/nagios/.ssh/
 # cp /tmp/vmhost_key /var/spool/nagios/.ssh/known_hosts

check_raid_vm9650をダウンロードしてNagiosのプラグインディレクトリにコピーします。

 # cp check_raid_vm9650 /usr/local/libexec/nagios/

コピーしたスクリプト30行目付近の以下の箇所を編集して、秘密鍵の場所とvmhostへの接続のための設定を行います。

 IDF="/var/spool/nagios/.ssh/id_vmware"
 REMOTE_USER="root"
 REMOTE_HOST="vmhost"
 REMOTE_PORT="22"

編集したスクリプトをテストします。

 # /usr/local/libexec/nagios/check_raid_vm9650 -c 6 -p 0
 OK - disk 0 [u0] 931.51GB SN:XXXXXXXX

成功したら、SSH関連のファイルのオーナーとパーミッションを修正します。

 # chown -R nagios:nagios /var/spool/nagios/.ssh
 # chmod -R 700 /var/spool/nagios/.ssh

))) ;Nagiosの設定

(((

監視スクリプトのテストに成功したら、Nagiosの設定ファイルを編集して、RAIDコントローラの監視設定を行います。以下に設定サンプルを示します。 ;チェックコマンド

ユニットの状態とポートの状態を監視するコマンドの定義です。

define command{
   command_name   check_raid_vm9650_unit
   command_line   $USER1$/check_raid_vm9650 -c $ARG1$ -u $ARG2$
   }

define command{
   command_name   check_raid_vm9650_port
   command_line   $USER1$/check_raid_vm9650 -c $ARG1$ -p $ARG2$
   }

;ホスト

vmhostの定義です。pingにより死活監視されますので、pingで到達不可能な場合はcheck_sshを使ったSSHによる死活監視にすると良いでしょう。

define host{
   use                  generic-host
   host_name            vmhost
   alias                VMware Server
   address              xxx.xxx.xxx.xxx
   notification_period  24x7
   notification_options d,u,r
   }

;サービス

RAIDユニットとポート(HDD)の状態を監視するための定義です。ポートはHDDの数だけ0,1,2,...と記述します。

define service{
   use            generic-service
   host_name   vmhost
   service_description 9650SE unit0
   contact_groups       admins
   check_command        check_raid_vm9650_unit!6!0
   }
define service{
   use            generic-service
   host_name   vmhost
   service_description     9650SE port0
   contact_groups       admins
   check_command        check_raid_vm9650_port!6!0
   }
 :

)))

Nagiosの監視画面で、以下のようにスクリプトのテスト結果と同じ内容がStatus Information欄に表示されれば設定完了です。

;oem.tgzへのファイル追加

(((

これだけでは、VMwareを再起動したときに/sbin/tw_cliや/.ssh以下のファイルが消えてしまうので、最後にoem.tgzに対して今回コピーしたファイルを追加します。

~ # mkdir /tmp/oem
~ # cd /tmp/oem
~ # tar zxpf /bootbank/oem.tgz
~ # rm .emptytgz        (oem.tgzの中身が.emptytgzだけの場合)
~ # cp -rp /.ssh .
~ # mkdir sbin
~ # cp -p /sbin/tw_cli sbin/
~ # tar zcf /tmp/oem.tgz .
~ # cp /tmp/oem.tgz /bootbank/
~ # cd /tmp
~ # rm -rf oem

)))

◆ WASForum2010

参加してきましたので、自分なりのまとめや感想など書いてみます。

オープニングセッション

• これまでのセキュリティ問題に関する議論はサーバ・デベロッパ重視
• ユーザーに目を向けよう
• ブラウザの「派手さ」とユーザーの「上手さ」：専門家は地味なブラウザ(w3mとか)を好み、下手なユーザは派手なブラウザを好む
• 3つの危険
  • あそびとしごと、まぜると危険：あそびにはFirefox、しごとにはChromeとか使い分けよう
  • パスワードの使いまわし危険：2要素認証とかクライアント証明書とか…
  • もう一つはメモし忘れた
• 危険をどうやって伝えるのか？^Jということで以降のセッションに続く

ユーザの「上手い」「下手」は、セキュリティ意識の高さといった意味合いで使っているようでした。で、「上手い」ユーザーが地味なブラウザを使うというのは良いとして、「専門家」はもう一歩踏み込んであえて「派手な」ブラウザを使うようにしないと、「下手な」ユーザーがさらされている危険に気づかないのでは？と思ったり。挑発的なことを書いてしまうと、今回のメインテーマであった携帯認証の危機的な状況にしたって、「上手い専門家」がこれまで携帯の利用を避けていた結果、今こうなっちゃってるという側面が無いとも言えなくもないわけじゃないんじゃないかと思わなくもないわけで。

国民のためのウェブサイトを運営するID認証の舞台裏

Yahoo! Japan IDについてのお話

• 概要
  • アクティブユーザ数・登録数など
  • ログイン試行数に対してエラー(失敗)が1割程度
    • ID/パスワードの不整合がほとんど(それ以外って何だ？）
    • 内部：外部サービス比(内部がほとんど）
  • パスワードの再確認の割合
• ニーズへの対応
  • サービス数150以上
  • 子供向けID(Yahoo! KIDS)ではかなり気を使っている
• セキュリティ
  • ログイン三兄妹
    • ログイン履歴：成功・失敗とうの履歴を表示^J正規ユーザーへのサービスと言う側面と、悪意のあるユーザに対する警告(変なことすると記録が残るぞ！)という側面
    • ログインアラート：変なアクセスを感知してメールで通知＆ブロック用のURLを提示→クリックして開くだけでアクセスをブロックできる
    • ログインシール：ユーザーが登録した秘密の文字列をシールとしてWebページ内に表示することにより、フィッシングサイトの判別に利用(フィッシングサイトでは、正しいシールが表示されない)
  • 残念ながら利用率は低い
    • デフォルト(強制的な)機能ではない
    • かといって勝手に有効化するわけにも行かない(メール通知がうざいとか)
  • 新しい仕組みの検討
    • リスクベース認証
  • 「利便性を保ちつつ全てのユーザーを守りたい」を目標に
• オープン化とプライバシー
  • OpenIDとOAuthへの対応：同意画面による提供属性の確認と選択
  • 連携レベル：IDのみ、属性、決済、ポイント
  • どの属性情報をどの外部サービスにどういったルールで提供するか？
    • 本人に結びつく物と仮想的なユーザーの情報
    • 公開レベル区分：同意による公開、同意後に審査の上公開、非公開
    • 現状は独自に判断：横の連携や共通ルール化できると良いのだが…

実務ベースの具体的な数字や資料が出てきてとてもためになるセッションでした。連携レベルとか公開レベル区分とかはパブリックにしてしまって、デファクトスダンダード化を狙うというのも手じゃないかなあと思いました。

OpenIDのモバイル対応 〜 認証基盤連携フォーラムの取組み他から

認証基盤連携フォーラムの偉い人(?)のお話でした。

• Digital Identityとは
  • 文献：Phill Windley 'Digital Identity'
  • Identity Attribute:形質、属性、関係性(Wiiで言うところのmiiがそれに近い、身体的特徴のイメージ化やWii-netでの他ユーザーとのつながりまで含んだモノ)
• 認証基盤連携フォーラム：2009年総務省から実験の受託
  • キーワード：「分散&連携」「ユーザー中心」「硬化用」「信頼&評判」
• モバイルからのOpenIDの利用：開けない! GET URL長すぎ。
• 属性連携の評判は良い(9割以上が利用したい)^Jただし、情報提供先サイトの信憑性についての情報が欲しいとの要求も高い→OITFモデル
• Artifact Binding WG:
  • デモ：https://openid4.us/
  • magic signatureを使った署名
  • 秋ごろには固まるかな…
  • ASCIIの国の人が考えた仕様なので…：スクリプト表現案の工夫
• Q&A
  • SAMLとの違い、Atrifact Binding(AB)および全体として
    • ABはSAMLのものをOpenIDでも出来るようにした
    • ○○(聞きそびれ、文脈からしてSAMLかな)はDiscoveryベース
    • OpenIDの方が実装が簡単
  • 認証基盤連携フォーラムのその他の活動
    • OpenIDとSAMLの相互運用性確保
      • 認証結果のやり取り
      • Yahoo! IDでGoogle Appsにログイン
    • IdP間のIdentity移行の課題の検討：
      • これまではSP=IdPで、サービスの終了と同時にID破棄で済んでいた
      • IdPがサービス終了したときに、アカウント情報をどうするのか？^J→継続性を保証するための組合(?)で加盟組織についてはサービスの継続性を確保済み
    • 利便性の検討
      • デバイス間でのセッション引継ぎ：モニターテスト済み。おおむね好評
    • 今の携帯の固有ID方式は駄目だよね
    • 携帯キャリアのIdP化への道はあるのかも

このセッションも含め、全体的にSAML(Shibboleth)をスルーしているのが個人的には非常に不思議な印象を受けました。SAMLとの違いを聞かれた時の答えもいまいちはっきりしなかったし、議論の中で先日書いたような話にかなり近い話をしているのに、概念レベルで留まっていて、ShibbolethでのeduPersonTargetedIDについての言及が一切ないあたりからして、ひょっとしてOpenIDな人たちは一生懸命に車輪の再発明してるんじゃないかという気が。だとすると非常にもったいない話ですが、とっくに検討済みで、なんか問題があるので別の解決を目指してるだけかもしれません。

ケータイ2.0が開けてしまったパンドラの箱

かんたんログインの話でした。どこまで書いていいのか分からないので、差しさわりのないことだけ。

• かんたんログインのおさらい
  • 端末固有IDは秘密情報ではない
  • 端末固有IDやHTTPリクエストのヘッダは書き換え出来ないのが前提
  • ところが…
• テーマ：携帯端末にHTTPヘッダを書き換える機能がない、のか？
  • docomoのJavaScriptでsetRequestHeader()が使えるんじゃ？ということで調査^J→サービス再開後は使えなくなってた
  • DNS Rebindingによる攻撃：アドバイザリ公開済み
    • 対策：リクエストヘッダのHostフィールドをチェックする
    • Hostフィールドを書き換える方法はないのか？^J(以下略)

結構怖いお話でした。ちなみにスマートフォンとその開発キットを使えばヘッダなんて書き換え放題ってのはご存知なのかな？Symbian OSならPythonで開発できるので実験とか楽そうなんですが。その前にNokia撤退という壁がありますが。

どうするケータイ認証

ケータイ認証の問題点とその影響について。

• 携帯電話で使われているID：契約者固有IDと端末固有ID
• 端末固有IDによるかんたんログインはやっちゃ駄目(2009年夏)
• 契約者固有IDは安全か？
  • CGIの仕様による'-'と'_'の混乱
  • SSL接続ではキャリアによるヘッダチェックが出来ない(通信が暗号化されているため)
• cookieベースの「次回から自動的にログイン」機能で十分では？
  • クッキー食えないのはdocomoだけ
  • iモード端末1.0だけ特別扱いする
• なぜいまさら騒ぐのか？^J→携帯認証の悪しき習慣が一般サイトにまで波及する恐れ
  • 携帯電話のIDが国民ID的な機能を持ちつつある^J→そこでかんたんログインのような間違った方式が一般的になるのは非常に危険(後戻りできなくなる)
  • Webサイト側で対策を迫られる可能性(やってられないなどとは言えず、そろそろ心構えしておく必要がある)

「端末固有IDをかんたんログインに使わない」という結論が出たのは去年の夏の話だ、ということでしたが、OpenPNEとか最新版でも端末固有IDを使ったかんたんログインが有効になってて、ソフトバンクどうしならなりすましし放題なのはどういう決着をしてそうなっちゃったんでしょうか。ユーザーが端末側の設定でonにしなければ端末固有IDは送信されないので、ユーザーの自己責任ってことなのかな。

OAuthとWEBサイト運営のエコシステムに潜む罠

OAuthのお話でした。

• エコシステム：特定業界の収益構造をさす言葉
• 認証(AuthN)と認可(AuthZ)の違い
• Twitterのエコシステム
  • 連携の手法
    • ID/パスワードを連携サイト側で預かる^J→預けたサイトでは生パスワード保存になるので危険
    • Basic認証^J→6月末廃止(ログアウトできない)
  • OAuth：認可の委譲
  • OAuth1.0の問題：Session Fixation^J→1.0aで対策済み
  • デスクトップアプリではxAuthを使う

パスワードを第三者に預けさせる状態でスタートしてブラッシュアップしていったってのはある意味すごいです。

“Web2.0”におけるセキュリティ 〜 セキュアなWeb2.0環境の構築とは

駆け足でメモが追いつかず。脅威を7つに分類して、それぞれの説明と対策について。網羅性やサンプルがすごく充実してました。資料を後で公開してもらえると言うことだったので楽しみです。

SDL脅威分析の方法とWindows Live IDにおけるアプローチ

Security Development LifecycleとLive IDの解説

• SDL
  • セキュリティアプローチはパッシブモードからプロアクティブモードへ
  • 攻撃はどこ(内)からでも来る
  • 信頼の境界線
  • STRIDE
• Live IDデモ
  • 渡すのはIDだけ、属性を受け取りたい場合はDedicated版を利用する

Live IDのOpenIDサポートってどんな状況なんでしょうか？なんか2008年に発表したっきりで、ベータ版のサイトは500になっちゃってるし。最近、DreamSparkがShibbolethに対応してるのを知ったのですが、乗り換えたのかな。

まとめ

ということで、全体的に非常に濃い内容で、満足のいくイベントでした。なんか回し者のような感想になってしまいましたが、ShibbolethはOpenIDとあわせて勉強しておいて損はないシステムだと思います。

◆ ソフトバンクでの端末固有ID(製造番号)と契約者ID(ユーザーID)の説明

修正履歴

5/31：機種名typo"702SHf"→"703SHf"、まとめ、コメント、他

契約者固有IDや端末固有IDについて、ソフトバンクや端末メーカーがユーザーに対してどのような説明をしているのか調べてみました。特に狙っていたわけではなく、単に状況を整理するだけのつもりだったのですが、見えてきたのは業界を挙げて間違った方向に進んでいるという悲しい現実でした。

簡単に状況をまとめておくと、次のような感じになります。

• ソフトバンクでは利用者を識別可能なIDとして、ウェブサイト提供者に対してユーザID(契約者固有ID)と製造番号(端末固有ID)の2種類を通知可能にしている
• ユーザIDは携帯電話からの通信がソフトバンクのゲートウェイ(中継所)を通過する際に付与される。詐称についての対策もされているので、ソフトバンクの他の利用者への成りすましはできないだろうと言われている
• 製造番号は通信の際、携帯電話がUser Agentに埋め込んで通知する。携帯電話に組み込まれているアプリケーションを使う限りその改竄は難しいが、携帯電話をモデムとして利用してPCのブラウザを使ったり、いわゆるスマートフォンで独自のプログラムを動かすことによりUser Agent製造番号は自由に書き換えることができる
• このため、.orangered.製造番号だけを鍵として使うような認証の仕組みは破たんしており、そのようなサービスでは、悪意のある人間が他人に成りすまして利用することが可能な状態となっている
• 携帯電話の利用者でできる対策としては、マニュアルを読んで製造番号通知の設定をoffにする。その結果使えなくなったサービスをどうしても使いたい場合は、下にある良くある質問の2つ目の説明を読んで、製造番号ではなくユーザーIDを送信するように設定する

また、今回の調査の結果を一言でまとめると以下の通りです。

.orangered.マニュアルを読む限り、2008年夏以降に発売されたソフトバンクの携帯電話は、おそらく全ての機種で製造番号の通知がデフォルトでonになっている

以下、調査結果です。

利用規約

「改訂日：2010年5月1日」のソフトバンクのウェブ利用規定（魚拓）では、ソフトバンクがコンテンツ提供者に通知するIDについて、以下のように記載されています。

ソフトバンクでは契約者固有IDのことを「ユーザーID」、端末固有IDのことを「製造番号」と称しているようです。

製造番号の方にだけなぜか通知を拒否するための具体的な手順が記載されています。これは機種によってはデフォルトで有効になっていることに配慮しての措置かもしれません。

サポート情報(よくある質問)

続けてソフトバンクのサポートサイトにある良くある質問での説明を調べたところ、以下の2つが見つかりました。

「ユーザーＩＤ・製造番号・固体識別番号を通知してください」と表示されます。（魚拓）

ユーザーIDの説明ではじまりますが、最後の「おもな操作方法」としては製造番号通知の設定方法のみ記載されています。

［ウェブ］「ユーザIDを通知してください」と表示されてしまいます。解決方法はありますか？（魚拓）

ユーザーID、製造番号の両方について詳しい説明があります。

1つ目の回答にだけXシリーズの取扱説明書へのリンクがあり、一見こちらの方が新しいように見えますが、製造番号・ユーザーIDの両方についてきちんと説明しているのは2つ目の方です。

取扱説明書

最後にソフトバンクのお客様サポートページ内にある製品の一覧からダウンロードできる取扱説明書から、ユーザーIDと製造番号の説明や初期設定がどうなっているのかを調べました。

まず大きな点として、802Nなどもっとも古い時代の物は用語的に微妙でしたが、それ以外のすべての機種の取扱説明書にはユーザーID(契約者固有ID)の通知設定に関する記載はありませんでした。このため、以下では製造番号通知のみについて書きます。

説明書の記載が「vodafone live!」の時代と「Yahoo!ケータイ」の時代、および「Xシリーズ（スマートフォン）」で分けてあります。表には古い機種から順に記述してあるので、下に行くほど新しい機種になります。また、表には以下の情報を記載しました。

.flat.

機種名

電話の機種名

デ

デフォルトの製造番号通知設定値(on/offと明記してあるものは、「説明」欄の画像中に記載が無いものでも、他のページに初期値が記載されているのを確認済みです)

目

目次に「製造番号通知」の項目があるかどうか

索

索引に「製造番号通知」の項目があるかどうか

説明

説明書内の記述(クリックするとその記述を含むページを表示します)

Softbank 3G(vodafone live!)

• 当初は製造番号を「ユーザID」と称しており、後半から(Nokiaを除き)「製造番号」という呼称に統一している
• この時代の機種では、取扱説明書に明記してあるものについては、初期値はすべてoffになっている。

.border tc.

機種名	.s.デ	.s.目	.s.索	.s.説明	機種名	.s.デ	.s.目	.s.索	.s.説明
702NK	?	×	×		702MO	-	×	×	-
802SE	?	○	○		702sMO	-	×	×	-
902SH	off	○	○		802SH	off	○	○
802N	off	○	○		902T	off	○	○
703SH	off	○	○		903SH	off	○	○
903T	off	○	○		803T	off	○	○
703N	off	○	○		703SHf	off	○	○
702NKII	?	×	×		804SH	off	○	○
904T	off	○	○		804SS	off	○	○
904SH	off	○	○		804N	off	○	○
905SH	off	○	○		705T	off	○	○
705SH	off	○	○		804NK	?	×	×

Softbank 3G(Yahoo!ケータイ)

• 機種名を、デフォルトで通知onと記載されている機種はオレンジ、明記されていないが通知onと思われる機種は青とした
• ワンセグ対応機種では、データ放送(TV)受信時に製造番号を通知する設定も可能になっている
• シャープの機種で「読本」とあるのは、.orangered.サポートサイトからダウンロードして読むドキュメント。
• 新しい機種ほど以下の傾向がある
  • 目次への不掲載
  • 製造番号に関する説明書きの簡略化・削除
  • 索引への不掲載

.border tc.

機種名	.s.デ	.s.目	.s.索	.s.説明	機種名	.s.デ	.s.目	.s.索	.s.説明
910T	off	×	○		705P	off	×	○
811SH	off	○	○		810SH	off	○	○
705SC	off	○	○		706SC	off	○	○
810T/811T/^J813T	off	○	○		705N	off	○	○
910SH	off	×	○		911SH	off	×	○
707SC/709SC	off	○	○		705NK	?	×	×
812SH/813SH	off	×	○		812T	off	×	○
706P	off	×	○		708SC	off	○	○
706N	off	○	○		911T	off	×	○
707SC2	off	○	○		912SH	off	×	○
805SC	off	△	○		810P	off	×	○
814SH/815SH	off	×	○		814T/815T(fanfun.)	off	×	○
812SHs(GENT)	off	×	○		913SH(FULLFACE)	off	×	○
912T	off	×	○		816SH	off	×	○
705Px	off	×	○		820P	off	×	○
920SH	?	×	×	取扱説明書：^J^J読本：^J	821P(MIRROR)	off	×	○
820SH/821SH(THE PREMIUM)	?	×	×	取扱説明書：^J^J読本：^J	913SH G(TYPE-CHAR)	off	×	○
822SH(THE PREMIUM)	?	×	×	取扱説明書：^J^J読本：^J	920T	off	×	○
812SH sII(GENT)	off	×	○		920SC(PHOTOS)	off	×	○
820T(コドモバイル)	off	×	○		820SC	off	×	○
822P	off	×	○		822T	off	×	○
920P	off	×	○		.orangered.821T(かんたん携帯)	on	×	○
823SH(THE PREMIUM TEXTURE)	?	×	×	取扱説明書：^J^J読本：	921SH(FULLFACE2)	?	×	×	取扱説明書：記載なし^J読本：
921T	off	×	○		920SH YK(株ケータイ)	?	×	×	取扱説明書、読本は920SHと同じ
922SH(インターネットマシン)	?	×	×	取扱説明書：記載なし^J読本：	821SC	off	×	○
815T PB(フォンブレイバー)	off	×	○		.orangered.823P(Tropical)	on	×	○
.blue.825SH(PANTONE SLIDE)	?	×	×	取扱説明書：記載なし^J読本：^J	.orangered.820N/821N/^J821N GLA	on	×	○
.blue.824SH(THE PREMIUM^JWATERPROOF)	?.super tsmall.*2	×	×	取扱説明書：記載なし^J読本：^J	.blue.923SH	?.super tsmall.*2	×	×	取扱説明書：記載なし^J読本：^J
.orangered.824P(MIRROR II)	on	×	○		.orangered.921P	on	×	○
.orangered.823T/824T	on	×	○		.blue.830SH(NEW PANTONE)	?.super tsmall.*2	×	×
.blue.830SH s(GENT)	?.super tsmall.*2	×	×	830SHと同じ	.orangered.830P	on	×	○
.orangered.830CA	on	×	○		.blue.930SH	?	×	×
.orangered.930SC(OMNIA)	on	×	○		.blue.931SH(AQUOSケータイ FULLTOUCH)	?.super tsmall.*3	×	×
.orangered.830T(fanfun.2)	on	×	○		.orangered.831T(fanfun.petit)	on	×	○
.orangered.930P(VIERAケータイ)	on	×	○		.blue.932SH(AQUOSケータイ)	?.super tsmall.*3	×	×
.blue.831SH/831SH KT/^J831SH s(GENT)	?.super tsmall.*3	×	×		.orangered.830N	on	×	○
.orangered.930CA(EXILIMケータイ)	on	×	○		.orangered.831P	on	×	○
.orangered.731SC	on	×	○		.orangered.832P	on	×	○
.blue.933SH(AQUOS SHOT)	?.super tsmall.*3	×	×		.blue.934SH(mirumo)	?.super tsmall.*3	×	×
.orangered.930N	on	×	○		.orangered.931SC(OMNIApop)	on	×	○
.orangered.832T(かんたん携帯)	on	×	○		.orangered.931P(VIERAケータイ)	on	×	○
.blue.935SH(THE PREMIUM^JWATERPROOF)	?.super tsmall.*3	×	×		.blue.832SH	?.super tsmall.*3	×	×
.blue.936SH(SOLAR HYBRID)	?.super tsmall.*3	×	×		.orangered.831N	on	×	○
.orangered.830SC(EMPORIO ARMANI)	on	×	○		.blue.832SH s(GENT)	?.super tsmall.*3	×	×
.orangered.740SC	on	×	○		.blue.940SH	?.super tsmall.*3	×	×
.orangered.931N	on	×	○		.orangered.940SC(OMNIAvision)	on	×	○
.blue.941SH(AQUOSケータイ^JFULLTOUCH)	?.super tsmall.*3	×	×		.orangered.840P^J(for BIZ/COLOR LIFE)	on	×	○
.orangered.940P(VIERAケータイ)	on	×	○		.orangered.940N	on	×	○
.blue.840SH(Jelly Beans)	?.super tsmall.*3	×	×		.orangered.941P(VIERAケータイ)	on	×	○
.blue.942SH(THE PREMIUM5)/^J942SH KT	?.super tsmall.*3	×	×		.orangered.841P	on	×	○
.blue.943SH(AQUOSケータイ)	?.super tsmall.*3	×	×		740N(コドモバイル)/741N	Web閲覧機能なし
.blue.841SH s	?.super tsmall.*3	×	×

Xシリーズ

Xシリーズでは製造番号、ユーザーID共に全ての機種で説明がありませんでした。Yahoo!ケータイは閲覧できないというアナウンスも出ているので、これは予想通りの結果です。

.border.

機種名	製造番号	ユーザーID	機種名	製造番号	ユーザーID	機種名	製造番号	ユーザーID	機種名	製造番号	ユーザーID	機種名	製造番号	ユーザーID
X01HT	×	×	X02HT	×	×	X01T	×	×	X03HT	×	×	X02NK	×	×
X04HT	×	×	X05HT	×	×	X01SC	×	×	X02T	×	×	X06HT	×	×