パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

iモードが契約者IDを非公式サイトに対してもデフォルトで自動送信へ」記事へのコメント

  • 同一サイト内では個人の閲覧行動がトレースできますね。何年後に見に行ってもIDは同じだし。個人を識別できるから個人情報として扱う方が望ましいだろうけど、サイト運営者がそこまでやるかな。「名寄せ」の問題もあるわけだし。

    これはいわば個人情報を提供させるのだから、デフォルトで開示ではなく、事前に顧客に許可を取るのがスジでは? それをしないという事は、やはり利用者の便宜というよりビジネス上の益になるからという判断でしょうね。
    • Re:要は permanent cookie ねぇ (スコア:1, おもしろおかしい)

      by Anonymous Coward on 2008年03月30日 19時45分 (#1322083)
      いろんなところでいわれてますが、個人情報は5000個たまらないと保護する義務はないのです。

      5000に満たないようにサイトを運営して、個人情報を名簿業者に販売するのは合法。
      そうすると、この手のIDとひもづけられたん個人情報が合法的に一人歩きするのです。
      親コメント
    • 携帯毎に個別に認識できるというだけで、個人の特定までは出来ないから、個人情報では無いのでは?
      親コメント
      • 「名寄せ」つまり他の情報と容易に照合する事を例えで説明すると、
        • NTTの電話帳に住所・氏名を載せている。
        • 家の固定電話の番号が何らかの方法で知られる。
        そうなれば、固定電話の番号だけを手がかりに家庭が特定でき、住所・世帯主が判ります。

        識別が出来た上で、どこまで個人の情報が引き出せるかは、識別情報とどんな情報が結びついているかどうかで決まりますけど。でも「家の電話番号だけで個人の住所・氏名が特定できる人も存在する」のであれば、個人情報として扱うべきでしょう。無理やり考えた例え話をすると、例えばアダルトグッズを電話で注文してきたお客さんのリストがあって、「名前のところは消しました。電話番号の情報だけですから個人情報ではありません」としてWebで公開したら大変な事になりますよね。

        だから、個人情報の保護に関する法律第二条では
        この法律において「個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの(他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。)

        とあるわけで。特定の個人を識別することができるものなんですね。「iモードID」は契約者固有IDだから、モロに個人情報。気に入らないかもしれないけど、個人情報保護法上、そして、技術的にはそうです。
        親コメント
        • 「iモードID」は、他の「iモードID」を使ってる人との区別は出来ますが、どこの誰なのかという「特定の個人の識別」まではできません。
          個人の区別は可能でも、それが「特定の個人」である事までは判らないって事です。

          固定電話の例では、電話帳という入手の容易な情報との照合によるものです。
          「iモードID」の場合、そういった容易に照合できるものがありません。

          ちなみに、固定電話でも、電話帳等に載ってて容易に称号できる人の電話番号は個人情報になりますが、
          そういった情報が無い電話番号なら個人情報になら無いと思います。

          他にも、スラドのIDも、個人の識別は可能ですが、基本的に特定の個人までは判らないので個人情報じゃないです。
          ところが、このスラドのIDに、本名とか他の情報と照合する事で誰だか判ってしまう情報を入れている人がいます。
          そういう人の場合、スラドのIDも個人情報とみなされます。

          たとえ公開されている情報でも、個人情報は守る必要があるので注意が必要です。
          親コメント
          • by Anonymous Coward
            > 固定電話の例では、電話帳という入手の容易な情報との照合によるものです。
            >「iモードID」の場合、そういった容易に照合できるものがありません。

            では「iモードID」と「メールアドレス」ではこの観点でどのような違いがあるのでしょうか。

            • 内閣府の個人情報保護法に関するよくある疑問と回答 [cao.go.jp]が判りやすかったので、引用します。

              Q2 -3 メールアドレスは、個人情報に該当しますか。

              A   個人の氏名等を含んだリストがあり、その1項目としてメールアドレスが含まれている場合、リストは全体として、また、メールアドレスはその一部として、個人情報に該当します。
                また、メールアドレスのみであって、ユーザー名及びドメイン名から特定の個人を識別することができる場合、そのメールアドレスは、それ自体が単独で、個人情報に該当します。
                 一方、記号や文字がランダムに並べられているものなど、特定の個人を識別することができない場合には、別に取り扱う名簿などとのマッチングにより個人を特定することができない限り、個人情報には該当しません。


              会社のメールアドレス等の場合、名前や所属会社名が入っています。
              そういった情報から個人の特定が可能です。こういうメールアドレスは個人情報となります。
              しかし、メールアドレスからそういった情報が得られない場合、個人情報とはならないのです。

              >では「iモードID」と「メールアドレス」ではこの観点でどのような違いがあるのでしょうか。

              「iモードID」は、後者の個人情報とは見なされないメールアドレスと同様だと思います。
              親コメント
              • 思うのは自由ですが…では、たくさんのメールアドレスを記録したファイルがあるとしましょう。メールアドレスの中には、個人の氏名をそのまま表す方法で決められたメールアドレスがあってドメインから個人が特定できるものもあるし、記号や文字をランダムに並べて生成したメールアドレスがあります。さて、このメールアドレスを記録したファイル(個人情報に該当するメールアドレスと、個人情報に該当しないメールアドレスの両方が含まれる)は個人情報として扱うべきでしょうか?

                答えは「個人を特定できる場合があるから全体を個人情報として扱うしかない」でしょう。
                親コメント
              • by Anonymous Coward
                > 「iモードID」は、後者の個人情報とは見なされないメールアドレスと同様だと思います。

                逆にいえば「個人情報とみなされるメールアドレス」と同じ状態になる、つまりどこか1か所からでも個人の情報と結びついたものが公開されればそのとたんに「iモードID」単体で個人情報となりうるということでよいですか?

                ということを気にしている人が多いのだと思っていますが。
              • どこにこのコメントを置くか迷ったのですが、とりあえずここにします。

                個人情報保護の関係者では有名な宇賀克也先生の「個人情報保護法の逐条解説第2版」34頁では

                個人識別の可否は、当該情報を取り扱う者ごとに異なりうる相対的なものである。例えば、メールアドレスは、一般的には個人識別性を有しないが、当該本人が契約するプロバイダーにとっては他の情報と容易に照合して個人識別が可能な個人情報といえよう。同様に、秘匿機能を持たせるため、相手方の公開鍵で暗号化して個人に関する情報を送信した場合、一般的には個人識別性はないが、送信先の相手方は、事故の秘密鍵で容易に復号しうるから、送信先との関係では個人識別性が肯定されよう。

                とされています。

                また、株式会社シーピーデザインコンサルティングの鈴木靖・當摩裕子の「個人情報保護の実務と漏洩対策防止策のすべて」151頁では特定の個人が識別可能な情報の具体例としてメールアドレスを挙げ、

                意味のないアルファベットの羅列など、メールアドレスだけでは個人が識別しがたい場合がありますが、「氏名@会社名.co.jp」といった個人が識別できる場合もあります。さらに、生活者は自分にアクセス可能な情報は、自己の個人情報として捉えています。事業者内で個人情報保護を推進するうえでは、メールアドレスは個人情報として取り扱った方が無難です。

                とされています。
                引用の分量が大きくなってしまいましたが、とりあえず調べた結果をあげておきます。
                親コメント
              • by Anonymous Coward

                同様に、秘匿機能を持たせるため、相手方の公開鍵で暗号化して個人に関する情報を送信した場合、一般的には個人識別性はないが、送信先の相手方は、事故の秘密鍵で容易に復号しうるから、送信先との関係では個人識別性が肯定されよう。
                この部分、意味不明ですね。単に暗号化メールで個人情報を提供した場合の話ですよね。そんなの普通に提供していると解されるのは当たり前なのに、「公開鍵」だの関係のない技術用語持ち出して、おかしいんじゃないのかと。だいたい、「同様に」ってどこが同様なんだ?

                こんな非論理的な本が有名なの?

              • 私も実際の意味はよく分かりませんが、ここでは個人識別性の話になっているので、
                「電子メールを暗号化すれば、外見上は容易に解読ができない記号の羅列であるから個人を識別することはできないのでは?」という疑問に先回りして答えているのではないかと想像します。
                この本は、個人情報保護法全面施行の1年以上前の2004年2月25日に初版が発行され、しかも「運用上の問題について、より詳しい内容とするように努めた」という方針があったため、とにかく疑問があれば言及しようとしているのではないでしょうか。
                親コメント
              • そうですね、実際メールアドレスは個人情報として扱うのが当たり前になってます。

                しかし、iモードIDはメールアドレスと違って、個人情報で無いものだけですから、個人情報として扱う必要は無いです。
                親コメント
    • by Anonymous Coward
      >事前に顧客に許可を取るのがスジでは? 今までDoCoMoがまさにそういう方法を取ってきたの知って言ってるのでしょうか?
      • by matma (34555) on 2008年03月30日 17時49分 (#1322039)
        新しい機能が提供されます、でも弊社のプライバシーポリシー上
        その機能はプライバシーの問題があるとも思われます、
        だから利用者の方には許可を取ります、

        という話であれば
        デフォルトではその機能はOFFにしておき利用者への周知のレスポンスとして
        利用者自身の手でONにする、が基本です。

        今回はそうではなくデフォルトがONのようですから、
        利用者の許可を取る取らないの次元ではなく
        ドコモ側の都合で可能な限り有効にする機能として導入しますと受け取るべきです。

        もちろん、それが良い悪いかはまた別の問題。
        親コメント
        • by Technical Type (3408) on 2008年03月30日 20時22分 (#1322105)
          契約者IDは、コンピューターの世界で言う所の「第三者クッキー」「トラッキングクッキー」「スパイウェアクッキー」に該当しますね。 もしセキュリティベンダーのコンピュータ・アソシエイツやタレントの眞鍋かをりさんだったらスパイウェア言う [mycom.co.jp]でしょうねぇ。

          だからDoCoMoは「ユーザーには積極的に知らせていませんが、3/31 からスパイウェアクッキーを携帯から送信するようにシステムを変更します。嫌なら特定の操作をしてください」とでも説明した方がわかり易いでしょう。(笑)

          パニックる事はありませんが、利便性と引き換えにセキュリティはリスクに晒されます。以下のように、容易に想定される問題にどう対処するのかが説明されていません。こういう事が技術的には可能だからです。

          • サイトAで住所、氏名を入力
          • サイトBでIDとパスワードを入力
          • サイトAとサイトBの情報があれば、サイトCではユーザーがアクセスしてきただけで、住所も氏名もIDもパスワードも特定できる。
          これで、
          • 住所、氏名を入手する目的で懸賞サイトなどを立ち上げる。
          • 閲覧したら実はアダルトサイトで、「入会ありがとうございました!」的な良くある話に、今度は前述のサイトから収集した住所、氏名を「名寄せ」して、それを元に支払いを要求する。
          という事件は「起きて当然」でしょう。どう対策するのでしょうか?

          ショッピングサイトの運営に携わる人間が個人情報を密売した事件って、以前にもありませんでしたか? だからこそ今までは、そういう被害の歯止めとして契約者固有IDの通知を公式サイトに限定していたのですよね。それを、3/31 から非公式サイトにおいても契約者固有IDを通知する、と。もう、これでは非公式サイトを信用するしかありませんねぇ。「どうか悪用しないでください」と。

          「ログインを自動化する」って事が可能になる技術なんだから、セキュリティーが下がっている事だって意味は解るでしょ? これで便利になったと言われてもねぇ。詐欺被害に遭い易くなるから、ユーザーに許可を取った上で契約者固有IDを通知すべき内容ですね。あえてそうしなかったのは、きちんと説明すれば契約者固有IDの通知をためらうユーザーが多く、ビジネスにならないという判断だから「聞いてられるか」という判断でしょう。時々被害が発生したら、「説明はしてある「詐欺の脅しに屈する方が悪い」」「個人情報を密売して詐欺をするサイトが悪い」で個別に対応する方が、新たに広がるビジネスチャンスを考えれば有利という事でしょう。

          親コメント
          • by matma (34555) on 2008年03月30日 20時42分 (#1322110)
            セキュリティと利便性は相反するものですから、
            良い悪いの問題とは少し違いますし、
            「問題が起こったらどうするんだ」「利便性が落ちたらどうするんだ」は正直水掛け論になりがちです。

            ただ、それ以前の次元で言えることとして、
            たとえばサブスクライバIDというもので同列に扱われることの多いauは、
            基本開けていた。その後セキュリティに配慮して閉じられるようにした。
            でも基本開けていたポリシーだったし、デフォルトは開いている、閉じたい人は明示的に自分で閉じる。
            これはポリシーとして一貫しており、良い悪いの問題とは別の次元で分かりやすい状況です。

            (本件に限って言えば)ドコモは基本閉じていた、これもポリシー。
            ところが今度「こちらで勝手に開けますね」と言い出し、実際勝手に開けます。
            これではポリシーが変わってしまっているし、利用者への周知はまったく足りないまま押し切るでしょう。
            他の方も指摘しているgoogleとの協業などの流れの中で、利益を出すためにポリシーを変えてしまったわけです。

            デフォルトをONにする、OFFにするということの意味はドコモであれば心底分かってることのはずなんですが……。

            ってところは強く思いますね。
            よほど利益に結びつくと期待しているのでしょうが、いわゆるカネに目がくらんだと変わりませんから。
            親コメント
            • by Anonymous Coward on 2008年03月30日 21時05分 (#1322121)

              セキュリティと利便性は相反するものですから、 良い悪いの問題とは少し違いますし、 「問題が起こったらどうするんだ」「利便性が落ちたらどうするんだ」は正直水掛け論になりがちです。
              詭弁ですね。それは頭の悪い人同士の議論です。

              「セキュリティと利便性は常に相反する」は偽です。
              なぜなら、 「セキュリティを維持したまま利便性を増大させる方法が存在する」場合もあるからです。

              実際今回のケースはタレコミにあるように「送信先サイトごとに別のIDが送信されるようにする」という方法があるわけでしょ。解決策があるのに対策せずに「セキュリティと利便性は相反するものですから」と思考停止するのは、「良い悪いの問題」で言えば、悪いことですね。「不作為の責任」というやつですか。

              親コメント
              • >実際今回のケースはタレコミにあるように
                >「送信先サイトごとに別のIDが送信されるようにする」という方法があるわけでしょ。

                これがすでに「利便性を落とす」要素を含んでいることは
                上で他の方が論議されているところを見ても明らかです。

                非公式サイト側のURL、ドメインやサーバ、IPアドレスその他は
                サイト運営側の都合でドコモが認識し得ない範囲を超えて変わりうるものです。
                それらを超越して「同じサイト運営者のサイトであれば個別のIDを送信する」が実装できるでしょうか?
                その負荷は?すべての対象サイトへのIDの全体としての唯一性は保証するの?
                (対象サイトのURLが変わったら過去の他の利用者と重複した、なんてのも問題のタネですね)
                などの論議をなしに「これが解決策だ」と言っても無意味です。

                そしていくら議論しようが、実装には手間暇も負荷も面倒もかかることは事実として残ります。

                >解決策があるのに対策せずに「セキュリティと利便性は相反するものですから」と
                >思考停止するのは、「良い悪いの問題」で言えば、悪いことですね。
                >「不作為の責任」というやつですか。

                上記の通り、論議もなしに一方的に「これが解決策だ」と言っても無駄なんです。
                だからこそ
                >「問題が起こったらどうするんだ」「利便性が落ちたらどうするんだ」は正直水掛け論になりがちです。
                と書いておきました。

                実際水掛け論になってますね、私とあなたで。
                良い悪いの問題ではないことを理解するっていつも難しい。
                親コメント
              • by Anonymous Coward
                なんか水掛け合ってる横から失礼しますけど、
                「セキュリティと利便性は相反する」ってのは一番の基本だと思います。

                というか、どこかを絞って安全を得るのがセキュリティなわけですから、
                全く利便性を失わずに安全性を上げられる方法があるとしたらセキュリティ技術者は必要ありません。

                「利便性」をユーザーの一極で考えると見た目上手間が変わらないように見えることもあるのでしょうけど、
                セキュリティにおいては利便性はユーザーだけでなくサービス提供者、さらには見知らぬ第三者など考えうる全員の利便性も考慮に入れるものなのですから。
              • by Anonymous Coward

                非公式サイト側のURL、ドメインやサーバ、IPアドレスその他は サイト運営側の都合でドコモが認識し得ない範囲を超えて変わりうるものです。

                同一のサービスはドメイン名を変更しないべきです。ドメイン名が変わるなら、別のサービスとして登録手順からやりなおすのが元々当然です。

                すべての対象サイトへのIDの全体としての唯一性は保証するの?

                ID内にドメイン名を含ませればよい。インターネットのプロトコルはよくそれを採用していますね。SIPとかでもそう。

                などの論議をなしに「これが解決

              • 「べき」で言い始めたらキリがありません。

                あらかじめ「水掛け論になります」
                と言った自分に対して水掛け論を持ち出しても無駄でしょう。

                良い悪いの問題ではないことを理解するっていつも難しい。
                親コメント
              • by Anonymous Coward

                「べき」で言い始めたらキリがありません。 水掛け論を持ち出しても無駄でしょう。
                何も工夫するなということ?世の中を安全にしようなんて無意味だと?

                良い悪いの問題ではないことを理解するっていつも難しい。
                安全を無視するのは悪いことですよ。
                ていうか「良い悪いの問題ではない」って意味不明なんですが、そう言っていると何か満足できるの?
              • by Anonymous Coward

                同一のサービスはドメイン名を変更しないべきです。ドメイン名が変わるなら、別のサービスとして登録手順からやりなおすのが元々当然です。

                youtubeやニコニコ動画に同じ事を言えますか?
              • by Anonymous Coward
                2つのドメイン名を使っているとうだけで、変更はしていないですね。
                2つのドメイン名を使う場合は、初回登録時に両方に対して登録処理をすればいいだけの話。
              • by Anonymous Coward
                はぁ? 2つ?
              • by Anonymous Coward
                3つだろうが同じことです。

                で、ドメイン名をいくつ使っているというのですか?
              • by Anonymous Coward
                技術が分からないなら黙っていたら良いと思います。
              • by Anonymous Coward

                全く利便性を失わずに安全性を上げられる方法があるとしたらセキュリティ技術者は必要ありません。
                ええ?!利便性を損なわずに安全性を上げる技術を開発するのがセキュリティ技術者ですよ?

                あなたが言うのは、セキュリティ管理者のことでは?
                技術力が無くて管理するだけのセキュリティ事務員。

              • by Anonymous Coward
                ただの煽りかと思いきや
                なるほど、そういう考え方もあるのかと思った。

                おそらくは、たとえば弱い暗号鍵を新しい暗号鍵で置き換えるケースなどを想定されているのかもしれませんが
                実はそういう場合でも往々にして「計算速度」という形で利便性は下がっているのです。
              • by kamiyan (10895) on 2008年03月31日 16時43分 (#1322560) ホームページ
                それならばせめて 「セキュリティと利便性とコストは相反する」と言って下され
                親コメント
          • by Anonymous Coward
            固定IPアドレスなPCに対しても同じことできるんだけど、何でそっちは無視?
            • by Anonymous Coward
              全部のIPアドレスがそうなら問題にされるでしょうけど、IPv4ではそうなっていませんから。
              一部のISPが固定にしてるってのが問題だとすれば、個々の事業者の問題ですからね。使ってる人が抗議すればいいことだし、他のISPに乗り換えればいいことだから。

              一方IPv6では、当初の仕様では下位48ビットがMACアドレスになるってことで問題にされました。で、RFC 3041: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [ietf.org]ってルールができたわけです。

              日本の携帯事業者が世界に進出しようとしても、こういうユーザIDの規格だとIETFに受け入れられないでしょう。ITUだとどうかは知りませんが。EUなんかはcookieさえ規制しようとするところですし。

UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie

処理中...