アカウント名:
パスワード:
１）ユーザーＩＤの利活用の推進 現在、モバイルビジネスにおいては利用するコンテンツやネットワークごとに異なる認証方式を用いている。このため、利用者がコンテンツを利用する場合、これに対応した相異なるユーザーＩＤとパスワードを入力することが必要である。しかし、ユビキタス化が進展する中、１回のユーザー認証により複数のコンテンツやネットワークを利用できるようになれば、利用者利便が著しく向上することが期待される。 現在、携帯端末でのコンテンツの利用においては、携帯端末の端末認識番号や電気通信番号（電話番号）をユーザーＩＤとして利用して利用者の認証を行い、課金等を行っている場合が多い。この仕組みは利用者側からみればＩＤの入力を省略でき、利便性が高いものである。しかし、このユーザＩＤは利用者が事業者を変更すると、番号ポータビリティが実現している電話番号とは異なり、変更される状況にある。また、各事業者ごとにユーザＩＤの運用基準が異なっている。 このため、コンテンツプロバイダは、利用者が通信事業者を変更するとＩＤが変更されて認証ができなくなる等、必ずしもオープンな環境が実現していない。また、一般に利用者が公式サイト上のコンテンツプロバイダから有料コンテンツの提供を受ける場合、利用者、コンテンツプロバイダ、通信事業者の三者間の契約となる旨が各通信事業者の契約約款で規定されている。このため、利用者が通信事業者の変更を行うと、利用者とコンテンツプロバイダとの間の契約も自動的に解約され、新たに契約を締結することが必要となっている。 したがって、ＩＤポータビリティを実現するため、研究開発や標準化を含む技術的な観点からの検討に加え、ＩＤポータビリティを利用した様々なサービスが創出されることから,費用面・制度面からの検討を同時並行的に進め、２０１０年の時点で実現する方向で結論を得ることが望ましい。その際、ＳＩＭカードを携帯端末に限らず広くネットワークに接続される多様な端末において、ユーザーＩＤを認証するためのツールとして活用することについても具体的な検討を進めていくことが適当である。
現在、モバイルビジネスにおいては利用するコンテンツやネットワークごとに異なる認証方式を用いている。このため、利用者がコンテンツを利用する場合、これに対応した相異なるユーザーＩＤとパスワードを入力することが必要である。しかし、ユビキタス化が進展する中、１回のユーザー認証により複数のコンテンツやネットワークを利用できるようになれば、利用者利便が著しく向上することが期待される。
現在、携帯端末でのコンテンツの利用においては、携帯端末の端末認識番号や電気通信番号（電話番号）をユーザーＩＤとして利用して利用者の認証を行い、課金等を行っている場合が多い。この仕組みは利用者側からみればＩＤの入力を省略でき、利便性が高いものである。しかし、このユーザＩＤは利用者が事業者を変更すると、番号ポータビリティが実現している電話番号とは異なり、変更される状況にある。また、各事業者ごとにユーザＩＤの運用基準が異なっている。
このため、コンテンツプロバイダは、利用者が通信事業者を変更するとＩＤが変更されて認証ができなくなる等、必ずしもオープンな環境が実現していない。また、一般に利用者が公式サイト上のコンテンツプロバイダから有料コンテンツの提供を受ける場合、利用者、コンテンツプロバイダ、通信事業者の三者間の契約となる旨が各通信事業者の契約約款で規定されている。このため、利用者が通信事業者の変更を行うと、利用者とコンテンツプロバイダとの間の契約も自動的に解約され、新たに契約を締結することが必要となっている。
したがって、ＩＤポータビリティを実現するため、研究開発や標準化を含む技術的な観点からの検討に加え、ＩＤポータビリティを利用した様々なサービスが創出されることから,費用面・制度面からの検討を同時並行的に進め、２０１０年の時点で実現する方向で結論を得ることが望ましい。その際、ＳＩＭカードを携帯端末に限らず広くネットワークに接続される多様な端末において、ユーザーＩＤを認証するためのツールとして活用することについても具体的な検討を進めていくことが適当である。
違う、携帯電話(もしくはFOMAカード)を識別する為のIDでしかない。 個人の特定まではこのIDだけでは不可能。
「次世代移動体通信システム上のビジネスモデルに関する研究会」 報告書（案）に対する意見書 [soumu.go.jp]より
ジェイフォン東日本株式会社 ２． ユーザIDについて ユーザIDに関しては報告書（案）にも述べられているとおり、ユーザのプライバシーと密接な繋がりがあるため、その取り扱いについては十分慎重であるべき。現在、ドコモやJ-フォンが公式サイトに限ってユーザIDを提供しているのもそのためである。ユーザIDに強いセキュリティをかけることはキャリアとして今後も更に検討して行くべき事項だが、現在のシステムを改善することによってサービス全体のコストが高くなりすぎるのも、小額コンテンツを取り扱うと言う点からは現実的ではない。 コンテンツ提供者自身はユーザIDを直接不当に利用するものではなくても、獲得したユーザIDを他者に転売するなどして利益を稼ごうとするものは存在しうるし、社員管理の徹底がなされていない企業では不心得な社員による情報の流失も十分想定される。
アンケート等の簡単な方法で個人情報をデータベース化し、インターネット上の行動とそのデータベースを結びつけるのにユーザＩＤを用いれば、本人の知らないうちにプライバシーに立ち入ることができる。電話番号から生成されるいわゆるソフトＩＤに関しては、専門知識のある人ならＩＤ から電話番号を簡単に解析できる。ハードＩＤは電話番号とは無縁なので、電話番号が解析されることはないが、追跡等を受けるリスクは、ソフトＩＤと替わらない。 「個人情報の保護に関する法律案」の下では、ユーザの個人情報を、その「同意」を得ずに通信キャリアがコンテンツプロバイダ等に提供することは原則違法である。ユーザＩＤは、同法律案の個人情報に該当することから、ユーザの「同意」なしにはコンテンツプロバイダ等に提供できない性格の情報である。一方で、ユーザＩＤは、ユーザが便利なサービスを受けようとすると、コンテンツプロバイダ等に提供を要する情報である。したがって、一律の提供禁止や、煩わしいだけの「同意」取付けは、ユーザの利益に反することから、ユーザにとって分かりやすく信頼に足りる「同意」に関するルール作りとその実践が求められている。 ユーザの「同意」は、当該ユーザが提供に伴うリスク等を理解、承知した上で行われる必要がある。少なくともそうみなし得るのに十分な手続き等が措置されていなければならない。このような手続き等を現実の利用シーンに単純に反映させると、煩雑で面倒な操作が必要になり、サービス価値を著しく減殺し、単にユーザを遠ざけるだけに終始しかねない。ユーザの「同意」に関するルールは、ユーザが被るリスクをできるだけ小さくしながらも、手続きが煩わしかったり余計なコストが生じたりしてユーザの利益に反するようなことのないようにすることが望ましい。 個人情報の保護と利用をバランスさせるルールの下で、ユーザＩＤに限って提供を可能とし、先の評価システムの構築を通じてルールが遵守される仕組みを迅速に構築することを目指すべきであろう。ユーザの「同意」を約款で取り付けるために評価システムをうまく使えば、対策拡大に伴うユーザ保護はもちろんのこと、今日通信キャリアが抱えているリスクを軽減することができるはずである。
Ｑ２ －３ メールアドレスは、個人情報に該当しますか。Ａ 個人の氏名等を含んだリストがあり、その１項目としてメールアドレスが含まれている場合、リストは全体として、また、メールアドレスはその一部として、個人情報に該当します。 また、メールアドレスのみであって、ユーザー名及びドメイン名から特定の個人を識別することができる場合、そのメールアドレスは、それ自体が単独で、個人情報に該当します。 一方、記号や文字がランダムに並べられているものなど、特定の個人を識別することができない場合には、別に取り扱う名簿などとのマッチングにより個人を特定することができない限り、個人情報には該当しません。
個人識別の可否は、当該情報を取り扱う者ごとに異なりうる相対的なものである。例えば、メールアドレスは、一般的には個人識別性を有しないが、当該本人が契約するプロバイダーにとっては他の情報と容易に照合して個人識別が可能な個人情報といえよう。同様に、秘匿機能を持たせるため、相手方の公開鍵で暗号化して個人に関する情報を送信した場合、一般的には個人識別性はないが、送信先の相手方は、事故の秘密鍵で容易に復号しうるから、送信先との関係では個人識別性が肯定されよう。
意味のないアルファベットの羅列など、メールアドレスだけでは個人が識別しがたい場合がありますが、「氏名＠会社名．ｃｏ．ｊｐ」といった個人が識別できる場合もあります。さらに、生活者は自分にアクセス可能な情報は、自己の個人情報として捉えています。事業者内で個人情報保護を推進するうえでは、メールアドレスは個人情報として取り扱った方が無難です。
先日下院を通過した SPY ACT法案では、このサードパーティクッキーなどによる情報収集を違法としてします。
「ログインを自動化する」って事が可能になる技術なんだから、セキュリティーが下がっている事だって意味は解るでしょ？ これで便利になったと言われてもねぇ。詐欺被害に遭い易くなるから、ユーザーに許可を取った上で契約者固有IDを通知すべき内容ですね。あえてそうしなかったのは、きちんと説明すれば契約者固有IDの通知をためらうユーザーが多く、ビジネスにならないという判断だから「聞いてられるか」という判断でしょう。時々被害が発生したら、「説明はしてある「詐欺の脅しに屈する方が悪い」」「個人情報を密売して詐欺をするサイトが悪い」で個別に対応する方が、新たに広がるビジネスチャンスを考えれば有利という事でしょう。
セキュリティと利便性は相反するものですから、 良い悪いの問題とは少し違いますし、 「問題が起こったらどうするんだ」「利便性が落ちたらどうするんだ」は正直水掛け論になりがちです。
「セキュリティと利便性は常に相反する」は偽です。 なぜなら、 「セキュリティを維持したまま利便性を増大させる方法が存在する」場合もあるからです。
実際今回のケースはタレコミにあるように「送信先サイトごとに別のIDが送信されるようにする」という方法があるわけでしょ。解決策があるのに対策せずに「セキュリティと利便性は相反するものですから」と思考停止するのは、「良い悪いの問題」で言えば、悪いことですね。「不作為の責任」というやつですか。
携帯キャリアのIPアドレスにアクセス制限するとかよくいいますが、少なくともSSLサイトだと駄目ですね。高木浩光氏が サブスクライバーIDをパスワード代わりに使うべきでない理由 [takagi-hiromitsu.jp] というのを言っています。要点だけ言うとこの図 [takagi-hiromitsu.jp]ですね。SSLが必要になるような回線でつないでいるなら、間に入って送信できちゃうと。SSLはこういうのの防止にあるわけで。
iモード対応サイトにおいて、アクセス先URL内に予めiモードID用のパラメータを記述しておくことにより、お客様がサイトアクセスした際にiモードIDの通知が行われます。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
サイトごとに異なるものにすればいいのに (スコア: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と同等のものが取れるようになってますが、このタレコミだとソレについては言及していないのがアンバランスな印象。
まぁこれも設定で拒否できますけどね。やってる人なんて極少数というのはおいておいて。