iモードが契約者IDを非公式サイトに対してもデフォルトで自動送信へ 97
プライバシーの問題か 部門より
jbeef 曰く、
(つづく…)2月28日に発表されたNTTドコモの「重要なお知らせ」によると、3月31日から、新たに「iモードID」なる契約者固有IDの通知機能が提供開始されるという。iモードではこれまでに、公式サイトにだけ自動送信するユーザID「UID」と、ユーザの同意確認を毎回必要とする端末ID(携帯電話製造番号又はFOMAカード製造番号)の送信機能を提供してきたが、さらに別のIDが提供されることになる。このIDは、「UID」とは異なりドコモの課金代行の利用には使えないが、用途としては、非公式サイトにおいて以前に訪れたユーザを同定することでログインを自動化することなどが想定されているようだ。
携帯電話の契約者固有IDをめぐっては、2005年4月のストーリ「 EZwebのサブスクライバIDが4/14から非通知設定可能に」にあったように、プライバシー上の問題が認識されている。auのEZwebでは、「サブスクライバーID」と呼ばれる（現在は「EZ番号」と改名）契約者固有IDがすべてのサイトに常時送信されており、かつては止めることさえできなかったが、ワンクリック不当請求の横行などに配慮して、2005年4月から設定で止められるようになっている。また、iモードでは、当初公式サイトにしかIDを送信しなかったのを、503iシリーズ以降で端末IDの機能を新設した際に、送信前にユーザの同意確認を必要とするよう配慮して設計されていた。
技術的には、自動ログインのような機能を実現するためなら、契約者固有IDの送信がどうしても必要というわけではない。例えば、送信先サイトごとに別のIDが送信されるように工夫することでプライバシー上の問題は軽減できる。また、一度許可したサイトにしか送信しないようにするという工夫も考えられる。今回始まる新しいIDがそうした対策をとっているか、NTTドコモに電話で確認したところ、通知されるIDは任意のサイトに対して同一のもので、サイトが要求すれば最初から確認なしに送信されるとのことだった。
NTTドコモは、今回の仕様変更にあたって、「重要なお知らせ」として告知しているように、プライバシー上の問題が存在することは認識しているようで、「お客様ご利用上の注意」として次のように注意喚起している。
通知が嫌な人は始まったら設定を変更しよう。iモードID通知設定は、お客様の利便性を考慮し初期設定については「通知する」設定となっております。通知を希望されないお客様は「通知しない」に変更していただく必要があります。
サイトごとに異なるものにすればいいのに (スコア:4, すばらしい洞察)
今まで使っているIDとサイトのIPアドレスを適当に連接して
ハッシュ取るだけでいいと思うんだが。
DNSラウンドロビンしてるサイトだとこまる？
でもそんなの普通サイト側で紐付けるとか工夫するでしょ。
屍体メモ [windy.cx]
Re:サイトごとに異なるものにすればいいのに (スコア:2, すばらしい洞察)
唯一性？ (スコア:1, 参考になる)
確かに、ハッシュテーブルに使うようなハッシュ関数 [wikipedia.org]のことなら全然唯一性がないのはおっしゃる通りですが、Cryptographic hash function [wikipedia.org]の意味での「ハッシュ」なら暗号学的な意味での唯一性の保証がありますよ。
2の60乗分の1とかの天文学的な確率で小さいだけでゼロではないといえばそうですが、それが駄目だと言ったら、電子署名法も無効にしないといけなくなっちゃいます。
昨今MD5などで衝突の脆弱性が話題になってはいますが、弱衝突性ではなく強衝突性の話ですし、いずれにしてもそれらは故意に衝突させる攻撃の話ですから、このストーリーの用途では脅威になりません。
変えてもたいした意味はない (スコア:0)
Re: (スコア:0)
たいしたコストも掛からないし、
それでIDの結び付けによる行動追跡等が防げるなら、
十分なメリットがある。
もっと根本的なところで (スコア:4, すばらしい洞察)
もしかしてもう改善されてるのかな?
非公式サイトにわざわざ公式サイトとは別のID(と便宜上簡略化しときます)を発行するような
仕組みを導入する以前に、クッキーへの対応のほうが先だろうと思うのですが。
それに、わざわざ非公式サイトのIDと公式サイトのIDを別にすることに説得力を持たせるなら
その違いはどういうもので、どういうときに違う必要があるのか、
を利用者に徹底的に周知するべきと思いますが、おそらくそれもしないでしょうし。
総務省の意向では？ (スコア:4, 興味深い)
iモード ID とGoogle Adsense (スコア:3, すばらしい洞察)
googleと提携した影響のひとつかもしれませんね。
参考リンク
iモード ID がモバイルコマースに与える効果を読み解いてみる [internet.com]
Re: (スコア:0)
誰がどこで何を買ったかが iモードID で全部把握されるようになるということ？
あと、誰がどのページを見たかも全部広告会社に把握されるようになるということ？
Re:iモード ID とGoogle Adsense (スコア:1)
どんな広告をクリックしたかはgoogle側で全部把握されます。
広告主側はどんなiモードIDで何を買ったかが全部把握されますので、iモードIDを含むデータベースを複数の広告主で共有されることは想像できますね。これは個人情報保護法で定めるルールに従って利用（共有）してほしいと思います。
誰がという点はドコモが契約者（閲覧者）の情報を開示するとか、閲覧者がフォームで個人情報を入力したりするとかで把握できますが、それはiモードIDがない現状でも同じです。
>誰がどのページを見たかも全部広告会社に把握されるようになるということ？
Adsenseの広告が貼ってあるページなら、どのページを見たかgoogleが把握できるかもしれません。このあたりはちょっと自信がないです。
個人情報がよくわからない仕組みで他者に渡ることには確かに不安感を覚えますし、個人情報は利用目的の範囲で（必要最低限の個人情報を）収集するべきというルールから考えると、ほかの方がおっしゃるようにもっと範囲を狭くすることもできるのでしょうけれど、個人情報の有用性（ここでは前のコメントで示したリンク先の記事のようなこと）を考えると、iモードIDくらいならいいのではないかと思われます。
以上は、あまり考えないで書きました。個人的な感想ですので、突っ込まれると苦しいです。
iモードIDの蓄積と開示にも一定の制限があったほうがいいということでは？ (スコア:1)
このとき、サイトごとに異なるIDではないiモードIDだと、「ああ、うちのユーザhogeはあのサイトにアクセスしているのか」ということが分かることになります。そういう紐づけがいろんなところでなされていって個人情報の特定につながりはしないか、という懸念ではないでしょうか。
もっともこういうソーシャルエンジニアリングを完全に防ぐなんてことはできないので、気にしだすときりがないという意見もあるでしょうが。
屍体メモ [windy.cx]
Re:iモードIDの蓄積と開示にも一定の制限があったほうがいいということでは？ (スコア:2, 参考になる)
個人情報の保護に関する法律
第二条 この法律において「個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの（他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。） [cao.go.jp]
今回のは個人を識別するためのIDですよね。だから、個人情報。
氏名やメールアドレスは含まれていないから個人情報じゃないというのは、個人情報保護法のド素人。
Re:iモードIDの蓄積と開示にも一定の制限があったほうがいいということでは？ (スコア:1)
違う、携帯電話(もしくはFOMAカード)を識別する為のIDでしかない。
個人の特定まではこのIDだけでは不可能。
DoCoMoの持っている契約者情報と照らし合わせて初めて個人の特定が出来る。
しかし、その情報は容易に照会できるものではないので、個人情報とは言えない。
Re:iモードIDの蓄積と開示にも一定の制限があったほうがいいということでは？ (スコア:1, 興味深い)
「次世代移動体通信システム上のビジネスモデルに関する研究会」 報告書（案）に対する意見書 [soumu.go.jp]より
報告書案というのはこれ [soumu.go.jp]かな。 この研究会の人たちは Liberty とかの活動を知らないのかな。「ユーザID」を直接送信しようとするからやっかいなことになるわけで。こういう方式は絶対欧米には拒否されるのは歴史から学べるるところなのに。技術を知らない人が指針を決めると国がダメになる典型だな。Re:iモードIDの蓄積と開示にも一定の制限があったほうがいいということでは？ (スコア:1)
しかし、それが法律上の「個人情報」なのかは別問題。
ジェイフォンはプライバシーの問題を指摘しているだけで、個人情報だとは言って無い。
報告書案で「ユーザＩＤは、同法律案の個人情報に該当する」と書かれているようだが、その少し前の文章では「ユーザＩＤそれ単体では個人を特定することはできない」とも書いてある。
この報告書案内で矛盾している事から、あまり信用しないほうが良いかも。
Re:iモードIDの蓄積と開示にも一定の制限があったほうがいいということでは？ (スコア:1)
技術を正しく理解していないからそう思うだけでは？
Re:iモードIDの蓄積と開示にも一定の制限があったほうがいいということでは？ (スコア:1)
このiモードID単体で、個人の特定ができるという根拠として出された資料なんですよね。
もし、この報告書のいう「個人情報にあたる」という意味が、「他の情報と容易に照合」によるものなら、iモードIDが個人情報にあたるという根拠にはならないですね。
Re:iモードIDの蓄積と開示にも一定の制限があったほうがいいということでは？ (スコア:2)
もし、報告書にあるIDが「他の情報と容易に照合できる」ものであるなら、iモードIDと同等のものではない。
iモードIDで個人を識別できるのは、DoCoMoだけ。
したがって、DoCoMoの社内では個人情報として扱わなくてはいけない。
しかし、社外にiモードIDだけを出す場合は、個人情報としては扱わなくて良い。
Re:iモードIDの蓄積と開示にも一定の制限があったほうがいいということでは？ (スコア:1)
提供されませんってば。
個々のiモードサイトが、独自に住所氏名とiモードIDを紐付けしたなら、そのiモードサイト内では個人情報として扱う。
しかし、やはりそのサイトの外では、容易に照合は出来ない事に変わり無い。
したがってDoCoMoにとっては、外に対してはiモードID単体ならば個人情報として扱う必要は無い。
既に個人情報とiモードIDの紐付け済みのiモードサイトに対しては、相手が既に手にしている個人情報なので提供に関して問題は生じません。
ただし、もしも、本来あってはいけない、容易に照合できるような不祥事が起きたらという事態を心配するのは正しいです。
ただ、それは、将来「個人情報」になる可能\\\性が無いわけじゃないというだけであって、今現在個人情報だという訳じゃない。
程度の差はあれ、スラドのIDも、何かの事情で個人情報との紐付けが提供されてしまったら、個人情報になる可能\\\性があるってのと同じもの。
なので、DoCoMoがiモードIDを個人情報ではないとして扱う事に対して、現状は何も言えない状態。
Re:iモードIDの蓄積と開示にも一定の制限があったほうがいいということでは？ (スコア:1)
ご指摘ありがとうございます。
>「うちのサイトにアクセスした人のiモードIDを発表します！ジャジャーン」
実務的には、個人情報ではない個人に関する情報であればどのように扱ってもいいということは個人の権利利益を保護するという法の趣旨に沿わないので、事業者は個人情報と同じように注意を払って取り扱いをすることになるかと思います。
実際にはiモードIDだけ発表されたり漏洩したりということは少なくて、閲覧者の氏名や電話番号も同時に発表されたり漏洩したりということがほとんどだと想像します。
>紐づけがいろんなところでなされていって個人情報の特定につながりはしないか、という懸念
こういう懸念はどの程度の現実性があるのでしょうね？
今の個人情報保護法を見ると、事業者が法に従ったり自主的なルール作ったりすることで、個人の権利利益が保護されるという構造になっているのですが、そういう個人情報保護の対策をしない事業者や、ソーシャルエンジニアリングをするような事業者が多く出てきた場合、それを取り締まる機能はとても弱いので、その懸念が現実になれば今の個人情報保護法では対応できないように思います。
#専門家でない者が資料に基づかずコメントを書いているとぼろぼろとほころびが出てきますので、ご容赦を。
Re:個人情報保護法? (スコア:1)
一言で言うと、ぐぐったらいいと思う。というかググレカス。
Re: (スコア:0)
ケータイ向け広告の世界では、月間ユニークといって、訪問者が一回目であるか二回目であるかによって、広告経由のアクセスであっても支払いが発生しない場合があるというのが、不正防止のための慣行としてあるので、その関連ではないでしょうか。
DoCoMoだと公式以外では、そのユーザが月内ユニークかどうか判断する方法が、利用者の利便性を併せて考えると現在のところ方法が無いというのが実情ですので。
要は permanent cookie ねぇ (スコア:1)
これはいわば個人情報を提供させるのだから、デフォルトで開示ではなく、事前に顧客に許可を取るのがスジでは？ それをしないという事は、やはり利用者の便宜というよりビジネス上の益になるからという判断でしょうね。
Re:要は permanent cookie ねぇ (スコア:1, おもしろおかしい)
５０００に満たないようにサイトを運営して、個人情報を名簿業者に販売するのは合法。
そうすると、この手のIDとひもづけられたん個人情報が合法的に一人歩きするのです。
Re:要は permanent cookie ねぇ (スコア:1)
Re:要は permanent cookie ねぇ (スコア:2)
- NTTの電話帳に住所・氏名を載せている。
- 家の固定電話の番号が何らかの方法で知られる。
そうなれば、固定電話の番号だけを手がかりに家庭が特定でき、住所・世帯主が判ります。識別が出来た上で、どこまで個人の情報が引き出せるかは、識別情報とどんな情報が結びついているかどうかで決まりますけど。でも「家の電話番号だけで個人の住所・氏名が特定できる人も存在する」のであれば、個人情報として扱うべきでしょう。無理やり考えた例え話をすると、例えばアダルトグッズを電話で注文してきたお客さんのリストがあって、「名前のところは消しました。電話番号の情報だけですから個人情報ではありません」としてWebで公開したら大変な事になりますよね。
だから、個人情報の保護に関する法律第二条では
この法律において「個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの（他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。）
とあるわけで。特定の個人を識別することができるものなんですね。「iモードID」は契約者固有IDだから、モロに個人情報。気に入らないかもしれないけど、個人情報保護法上、そして、技術的にはそうです。
Re:要は permanent cookie ねぇ (スコア:1)
個人の区別は可能でも、それが「特定の個人」である事までは判らないって事です。
固定電話の例では、電話帳という入手の容易な情報との照合によるものです。
「iモードID」の場合、そういった容易に照合できるものがありません。
ちなみに、固定電話でも、電話帳等に載ってて容易に称号できる人の電話番号は個人情報になりますが、
そういった情報が無い電話番号なら個人情報になら無いと思います。
他にも、スラドのIDも、個人の識別は可能ですが、基本的に特定の個人までは判らないので個人情報じゃないです。
ところが、このスラドのIDに、本名とか他の情報と照合する事で誰だか判ってしまう情報を入れている人がいます。
そういう人の場合、スラドのIDも個人情報とみなされます。
たとえ公開されている情報でも、個人情報は守る必要があるので注意が必要です。
Re:要は permanent cookie ねぇ (スコア:1)
会社のメールアドレス等の場合、名前や所属会社名が入っています。
そういった情報から個人の特定が可能です。こういうメールアドレスは個人情報となります。
しかし、メールアドレスからそういった情報が得られない場合、個人情報とはならないのです。
>では「iモードID」と「メールアドレス」ではこの観点でどのような違いがあるのでしょうか。
「iモードID」は、後者の個人情報とは見なされないメールアドレスと同様だと思います。
Re:要は permanent cookie ねぇ (スコア:2)
答えは「個人を特定できる場合があるから全体を個人情報として扱うしかない」でしょう。
メールアドレス等の個人識別性 (スコア:2)
個人情報保護の関係者では有名な宇賀克也先生の「個人情報保護法の逐条解説第２版」３４頁では
とされています。
また、株式会社シーピーデザインコンサルティングの鈴木靖・當摩裕子の「個人情報保護の実務と漏洩対策防止策のすべて」１５１頁では特定の個人が識別可能な情報の具体例としてメールアドレスを挙げ、
とされています。
引用の分量が大きくなってしまいましたが、とりあえず調べた結果をあげておきます。
Re:メールアドレス等の個人識別性 (スコア:1)
「電子メールを暗号化すれば、外見上は容易に解読ができない記号の羅列であるから個人を識別することはできないのでは？」という疑問に先回りして答えているのではないかと想像します。
この本は、個人情報保護法全面施行の１年以上前の２００４年２月２５日に初版が発行され、しかも「運用上の問題について、より詳しい内容とするように努めた」という方針があったため、とにかく疑問があれば言及しようとしているのではないでしょうか。
Re:要は permanent cookie ねぇ (スコア:1)
しかし、iモードIDはメールアドレスと違って、個人情報で無いものだけですから、個人情報として扱う必要は無いです。
Re:要は permanent cookie ねぇ (スコア:2, すばらしい洞察)
その機能はプライバシーの問題があるとも思われます、
だから利用者の方には許可を取ります、
という話であれば
デフォルトではその機能はOFFにしておき利用者への周知のレスポンスとして
利用者自身の手でONにする、が基本です。
今回はそうではなくデフォルトがONのようですから、
利用者の許可を取る取らないの次元ではなく
ドコモ側の都合で可能な限り有効にする機能として導入しますと受け取るべきです。
もちろん、それが良い悪いかはまた別の問題。
Re:要は permanent cookie ねぇ (スコア:3, 興味深い)
- スパイウェアとは？ [higaitaisaku.com]
- トラッキングクッキー、スパイウェアクッキーとは？ [gozaru.jp]
- ブログからFUDへ？ 眞鍋かをりは30個の「スパイウェア」のうちcookieの数を明らかにせよ [takagi-hiromitsu.jp]
- 追跡クッキー (サードパーティ クッキー)について
[shareedge.com]
- Cookieはなぜスパイウェアとして検出されるの？ [mecha-security.com]
もしセキュリティベンダーのコンピュータ・アソシエイツやタレントの眞鍋かをりさんだったらスパイウェア言う [mycom.co.jp]でしょうねぇ。だからDoCoMoは「ユーザーには積極的に知らせていませんが、3/31 からスパイウェアクッキーを携帯から送信するようにシステムを変更します。嫌なら特定の操作をしてください」とでも説明した方がわかり易いでしょう。(笑)
パニックる事はありませんが、利便性と引き換えにセキュリティはリスクに晒されます。以下のように、容易に想定される問題にどう対処するのかが説明されていません。こういう事が技術的には可能だからです。
- サイトAで住所、氏名を入力
- サイトBでIDとパスワードを入力
- サイトAとサイトBの情報があれば、サイトCではユーザーがアクセスしてきただけで、住所も氏名もIDもパスワードも特定できる。
これで、- 住所、氏名を入手する目的で懸賞サイトなどを立ち上げる。
- 閲覧したら実はアダルトサイトで、「入会ありがとうございました！」的な良くある話に、今度は前述のサイトから収集した住所、氏名を「名寄せ」して、それを元に支払いを要求する。
という事件は「起きて当然」でしょう。どう対策するのでしょうか？ショッピングサイトの運営に携わる人間が個人情報を密売した事件って、以前にもありませんでしたか？ だからこそ今までは、そういう被害の歯止めとして契約者固有IDの通知を公式サイトに限定していたのですよね。それを、3/31 から非公式サイトにおいても契約者固有IDを通知する、と。もう、これでは非公式サイトを信用するしかありませんねぇ。「どうか悪用しないでください」と。
「ログインを自動化する」って事が可能になる技術なんだから、セキュリティーが下がっている事だって意味は解るでしょ？ これで便利になったと言われてもねぇ。詐欺被害に遭い易くなるから、ユーザーに許可を取った上で契約者固有IDを通知すべき内容ですね。あえてそうしなかったのは、きちんと説明すれば契約者固有IDの通知をためらうユーザーが多く、ビジネスにならないという判断だから「聞いてられるか」という判断でしょう。時々被害が発生したら、「説明はしてある「詐欺の脅しに屈する方が悪い」」「個人情報を密売して詐欺をするサイトが悪い」で個別に対応する方が、新たに広がるビジネスチャンスを考えれば有利という事でしょう。
Re:要は permanent cookie ねぇ (スコア:1)
良い悪いの問題とは少し違いますし、
「問題が起こったらどうするんだ」「利便性が落ちたらどうするんだ」は正直水掛け論になりがちです。
ただ、それ以前の次元で言えることとして、
たとえばサブスクライバIDというもので同列に扱われることの多いauは、
基本開けていた。その後セキュリティに配慮して閉じられるようにした。
でも基本開けていたポリシーだったし、デフォルトは開いている、閉じたい人は明示的に自分で閉じる。
これはポリシーとして一貫しており、良い悪いの問題とは別の次元で分かりやすい状況です。
(本件に限って言えば)ドコモは基本閉じていた、これもポリシー。
ところが今度「こちらで勝手に開けますね」と言い出し、実際勝手に開けます。
これではポリシーが変わってしまっているし、利用者への周知はまったく足りないまま押し切るでしょう。
他の方も指摘しているgoogleとの協業などの流れの中で、利益を出すためにポリシーを変えてしまったわけです。
デフォルトをONにする、OFFにするということの意味はドコモであれば心底分かってることのはずなんですが……。
ってところは強く思いますね。
よほど利益に結びつくと期待しているのでしょうが、いわゆるカネに目がくらんだと変わりませんから。
Re:要は permanent cookie ねぇ (スコア:2, すばらしい洞察)
「セキュリティと利便性は常に相反する」は偽です。
なぜなら、 「セキュリティを維持したまま利便性を増大させる方法が存在する」場合もあるからです。
実際今回のケースはタレコミにあるように「送信先サイトごとに別のIDが送信されるようにする」という方法があるわけでしょ。解決策があるのに対策せずに「セキュリティと利便性は相反するものですから」と思考停止するのは、「良い悪いの問題」で言えば、悪いことですね。「不作為の責任」というやつですか。
Re:要は permanent cookie ねぇ (スコア:1)
>「送信先サイトごとに別のIDが送信されるようにする」という方法があるわけでしょ。
これがすでに「利便性を落とす」要素を含んでいることは
上で他の方が論議されているところを見ても明らかです。
非公式サイト側のURL、ドメインやサーバ、IPアドレスその他は
サイト運営側の都合でドコモが認識し得ない範囲を超えて変わりうるものです。
それらを超越して「同じサイト運営者のサイトであれば個別のIDを送信する」が実装できるでしょうか？
その負荷は？すべての対象サイトへのIDの全体としての唯一性は保証するの？
(対象サイトのURLが変わったら過去の他の利用者と重複した、なんてのも問題のタネですね)
などの論議をなしに「これが解決策だ」と言っても無意味です。
そしていくら議論しようが、実装には手間暇も負荷も面倒もかかることは事実として残ります。
>解決策があるのに対策せずに「セキュリティと利便性は相反するものですから」と
>思考停止するのは、「良い悪いの問題」で言えば、悪いことですね。
>「不作為の責任」というやつですか。
上記の通り、論議もなしに一方的に「これが解決策だ」と言っても無駄なんです。
だからこそ
>「問題が起こったらどうするんだ」「利便性が落ちたらどうするんだ」は正直水掛け論になりがちです。
と書いておきました。
実際水掛け論になってますね、私とあなたで。
良い悪いの問題ではないことを理解するっていつも難しい。
Re:要は permanent cookie ねぇ (スコア:1)
あらかじめ「水掛け論になります」
と言った自分に対して水掛け論を持ち出しても無駄でしょう。
良い悪いの問題ではないことを理解するっていつも難しい。
Re:要は permanent cookie ねぇ (スコア:2, すばらしい洞察)
銀行とかSSLサイトでは使ってはいけない技術 (スコア:1, 興味深い)
携帯キャリアのIPアドレスにアクセス制限するとかよくいいますが、少なくともSSLサイトだと駄目ですね。高木浩光氏が サブスクライバーIDをパスワード代わりに使うべきでない理由 [takagi-hiromitsu.jp] というのを言っています。要点だけ言うとこの図 [takagi-hiromitsu.jp]ですね。SSLが必要になるような回線でつないでいるなら、間に入って送信できちゃうと。SSLはこういうのの防止にあるわけで。
Re:銀行とかSSLサイトでは使ってはいけない技術 (スコア:2, 興味深い)
ちなみにsoftbankもSSL通信時はsecure.softbank.ne.jpを経由しないとx-jphone-uidは送信されません。
Re:銀行とかSSLサイトでは使ってはいけない技術 (スコア:1)
コンテンツ側がほとんど使ってくれないという……（苦笑）
# おいらも一応証明書だけはもらったけど、一回も使ったこと無い
ドコモ端末のSSL証明書によるクライアント認証機能 (スコア:1)
ちゃんと運用している上にこのサービス自体は無料で提供してくれるという太っ腹ぶりな割には全然使われてないですよねえ。
結構いけてると思うんだけどなあ。
Re:銀行とかSSLサイトでは使ってはいけない技術 (スコア:1)
電話とサーバー間が暗号化される必要があるのではないでしょうか？
User-Agentに付加するのか？ (スコア:0)
#YBBみたいな事実上の固定IPの人と同程度の晒され具合だからまあいいのか。
Re:User-Agentに付加するのか？ (スコア:5, 参考になる)
現在公式サイト向けではuid=NULLGWDOCOMOというパラメータをつけると、DoCoMoのゲートウェイのほうで変換されて実際のCGI等ではこのUIDが書き換えられて取得できるようになります。
（このとき、端末ブラウザ機能のURL表示を見るとNULLGWDOCOMOとなっていて、ユーザからはUIDは分かりません）
また、<a href="hogehage.cgi" utn> などとすると、遷移先で端末IDが取得できるようになります。(端末IDはUser-Agentにつきます)
auでは X-UP-SUBNO (HTTP-X-UP-SUBNO) というヘッダでUIDが取得できるようになっています。
これは公式・非公式に限らず端末設定で許可している限りどこでも同じIDが取得できます。
auにもUIMカードがありますが、差し替えにはショップで対応してもらう必要があるため、端末IDという概念は今のところありません。
SoftBankでは X-JPHONE-UID (HTTP-X-JPHONE-UID) というヘッダでUIDが取得できるようになっています。
これは公式資料の技術資料HTTP編で確認できます。 [softbankmobile.co.jp]
非公式サイトでも取得できるかは覚えていませんが、古い端末では他に必要なパラメータ（公式サイト向け）があり、これを指定しないと取得できなかったりします。（このときのパラメータは端末からは確認できません）
SoftBankの端末IDもDoCoMo同様にUser-Agentから取得できますが、DoCoMoのutnのような指定は必要ありません。
携帯なので勝手サイトでは端末IDでも充分かもしれませんが、UIDが分かれば複数の端末でUIMカードを差し替えながら使ってるユーザも追跡できます。 勝手サイト製作者としては今回の変更で提供できるサービスの幅が広がるように感じていますが、/.Jでは慎重な意見が多いみたいですね。
# 念のためACで
Re:User-Agentに付加するのか？ (スコア:3, 興味深い)
これは違うよ。同一SIMチップの場合はユーザが任意に入れ替えることが可能。
ただし、既に一度SIMを認識させた端末で別のSIMを認識させようとした場合のみ、
ショップでの機種変更（要事務手数料）が必要となる。
ドコモのように自由に入れ替えることができないのが非難されてますね。
Re:User-Agentに付加するのか？ (スコア:1)
（あまり見ることはなくなりましたが）PDCの人がFOMAに
機種変更した場合って、新端末IDはどうなるんでしょうかねぇ？
（公式サイト（uid=NULLGWDOCOMO）だと、
PDCユーザのIDは 00XXXXXXXXXX
FOMAユーザのIDは 01XXXXXXXXXX
となっており、
PDC-->FOMAに機種変した場合は、頭二桁だけ変わるようになっています。
＃自分のブラウザから公式サイト（自社開発してるサイトね）を見るときは、
＃いつもオミトロン使ってUID偽装してます。
Re:User-Agentに付加するのか？ (スコア:1)
Re: (スコア:0)
# 書いてから気づいたのですが、どこかにUser-Agentに付けるという資料がありますか？
# DoCoMo端末の場合…特に既存端末について、User-Agentの仕様を変更するのは非常に影響が大きいため、そういうことはしにくいと思うのですが。
またSoftbankについては、2.5世代端末以降は公式サイトではなくてもサブスクライバIDと同等のものが取れるようになってますが、このタレコミだとソレについては言及していないのがアンバランスな印象。
まぁこれも設定で拒否できますけどね。やってる人なんて極少数というのはおいておいて。