最新 追記

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 966   昨日: 2734

2010年05月01日

共用SSLサーバの危険性が理解されていない

さくらインターネットの公式FAQに次の記述があるのに気づいた。

  • [000735]共有SSLの利用を考えていますが、注意すべき事項はありますか?, さくらインターネット よくある質問(FAQ), 2010年2月10日更新(初出日不明)

    Cookieは、パスなどを指定することができるため、初期ドメイン以外では共有SSLを利用している場合にCookieのパスを正しく指定しないと、同じサーバの他ユーザに盗まれる可能性があります

    (略)

    上記については、「同サーバを利用しているユーザだけがCookieをのぞき見ることができる」というごく限定的な影響を示していています。また、Cookieの取扱いについて、問い合わせフォームやショッピングカート等、ビジネス向けのウェブコンテンツを設置されていなければ特に大きな問題とはなりませんが、個人情報を取り扱われる管理者であれば一読いただきたい内容であると判断し、掲載しています。

    画面キャプチャ

「ごく限定的な影響」というのはどういうつもりなのか疑問*1だが、この注意書きをちゃんと載せているあたりは、さすがはさくらインターネットと言える*2。しかし、「安全な設定」として紹介されている以下の記述は誤りであり、全く安全でない。

パス /example.com/

https://secure101.sakura.ne.jp/example.com/ のCookieは https://secure101.sakura.ne.jp/hoge.net/ のCGIでは取得できない。

Set-Cookie: における「path=...」指定は、じつはセキュリティ上何の効果もない*3ことが昔から知られている。

私が知ったのは2001年11月のことで、セキュリティホールmemoメーリングリストの[memo:2016]で以下のように書いている。

From: TAKAGI Hiromitsu <takagi.hiromitsu@aist.go.jp>
Subject: [memo:2016] クロスサイトスクリプティングとcookieの有効path
Date: 2001年11月26日 17:03:58 JST

(略)

クロスサイトスクリプティング対策として

| cookieの有効pathを設定するとよい
| - サイトの一部でしか使用しないcookieはpathの有効範囲を絞って発行す
|   ることで、クロスサイトスクリプティングの影響範囲を狭められる

と書きましたが、これは有効な対策にならないことがわかりましたので、この
場をお借りして、訂正します。

以下、なぜ対策にならないかの説明です。

必要なCookie、例えば「sessionid」を
  Set-Cookie: sessionid=1234567890; path=/serviceA/cgi/;
で発行したとします。

このcookieは、
  http://example.com/serviceA/cgi/foo.cgi
のページに埋め込まれたスクリプトからはアクセスできますが、
  http://example.com/serviceB/cgi/foo.cgi
や、
  http://example.com/foo.html
のページに埋め込まれたスクリプトからはアクセスできなくなります。これが
Set-Cookie: のpath指定のはたらきです。

ここで、
  http://example.com/serviceB/cgi/foo.cgi
にクロスサイトスクリプティング脆弱性があったとしましょう。例えば、
  http://example.com/serviceB/cgi/foo.cgi?<SCRIPT>...</SCRIPT>
にアクセスするとそのページ上でこのスクリプトが動いてしまうとします。

そのスクリプトから目的のcookieにアクセスしようとしても、上に説明したよ
うに、「path=/serviceA/cgi/」の指定されたcookieにはアクセスできません。

ところが、ここで、<FRAMESET>を使ってダミーのFRAME (pathがcookieの有効
パスと同一) を生成されると、そのFRAMEのdocument.cookieにアクセスされて
しまい、目的のcookieを盗られてしまいます。

 http://example.com/serviceB/cgi/foo.cgi?<FRAMESET><FRAME NAME="subframe"
 SRC="/serviceA/cgi/bar"><FRAME SRC=foo.cgi?<SCRIPT>alert(parent.subframe.
 document.cookie)</SCRIPT>"></FRAMESET>

こんな感じです。parent.subframe.document. とフレームを辿ることによって、
異なるpathに限定して発行されたcookieにアクセスできてしまいます。

この手法は、先日の、Marc Slemko氏の「Microsoft Passport to Trouble」
http://alive.znep.com/~marcs/passport/ で知りました。

このときは、クロスサイトスクリプティング脆弱性への保険的対策としてのpath指定の無効性について述べているが、クロスサイトスクリプティング脆弱性の有無によらず、ホスト名が同一の共用サーバ上で、パス名で区切られた領域に異なる利用者によるページが混在する場合においても同様である。

通常のレンタルサーバでは、今日ではほとんどの場合、ホスト名で利用者を分けている*4ため、この問題の影響を受けないが、SSLの共用サーバとなると、サーバ証明書を1つで済まそうとするためか、同じホスト名のサーバ上にパス名で分けて提供するところが後を絶たない。

同じホスト名のサーバ上にパス名で分けている場合でも、たとえば、2009年6月27日の日記で示した共用SSLサーバでは、事前に用意された入力フォームしか設置することができないものであるため、この問題の影響を受けない。また、2009年8月26日の日記で示したエコポイントの申請画面が置かれたセールスフォースの件では、eco-points.secure.force.com というホスト名で分けられているため、この問題の影響を受けない。(ただし、これらには別の問題があり、その点については、それぞれの日記に書いている。)

さくらインターネットの場合は、自由にCGIプログラムを設置できるというくらいであるから、JavaScriptの記述は自由なのだろう。そうすると、さくらインターネットが挙げている以下のケース

https://secure101.sakura.ne.jp/example.com/ のCookieは https://secure101.sakura.ne.jp/hoge.net/ のCGIでは取得できない。


は、実際には、たとえ example.comがpath指定無し、あるいは「path=/example.com/」の指定でcookieを発行していたとしても、攻撃者は、https://secure101.sakura.ne.jp/hoge.net/ 上に以下のようなスクリプトを設置することで、example.comのcookie等を取得することができてしまう。

<iframe src="/example.com/" name="foo"></iframe>
<ul>
<li><a href="javascript:alert(foo.document.cookie)">Get cookie</a>
<li><a href="javascript:alert(foo.document.body.innerText)">Get text</a>
<li><a href="javascript:alert(foo.document.body.innerHTML)">Get html</a>
</ul>

この例にあるように、取得できるのはcookieだけではない。cookie(やBASIC認証など)を用いてログイン状態となっているページのコンテンツ(秘密であるはずの)も取得できてしまうし、コンテンツの内の入力欄やボタンを操作して、あらゆる不正な操作が可能になってしまう。

これはWebセキュリティの基本で、same-origin policyの「origin」はホスト名で区分される*5ものであって、パス名では区分されないことを忘れてはいけない。

では、同じホスト名の共用サーバ上(他の利用者が自由にCGIやJavaScriptの記述ができるところ)において、どういうことならやっても安全か(共用する他の利用者に攻撃される余地がないか)というと、それはなかなか簡単に結論がでない。仮に条件を示せたとしても、利用者に理解可能なものにはならないと思われるので、そもそもこのような共用SSLサーバのサービスはやめるべきだろう。少なくとも、ホスト名で分けて*6、サーバ証明書を一枚で済ませたいならワイルドカード型の証明書を使えばよい。

追記

さくらインターネットの場合、ホスト名で利用者を分けた共用SSLが、既に追加料金なしに利用できるようになっていた。FAQのページで「初期ドメイン」と呼ばれているもの。それならば、パス名で分けた共用SSLは廃止して、「初期ドメイン」方式へ移行するよう利用者に呼びかけるべきだろう。

*1 このような不正直な表現をする事業者を信頼できるだろうか。

*2 何ら注意書きしていない共用SSLサーバ提供事業者ばかりである中で。

*3 同じ名前のcookieを共存させることができるくらいしか、pathを分けることの意味はない。

*4 パス名で分けているところでは、ページ内にJavaScrpt等を記述させないための対策(広義のクロスサイトスクリプティング対策)がとられている。たとえば、はてなダイアリーがそれに該当する。

*5 正確には、hostとschemeとportによって区分される。

*6 その場合でも、2009年6月27日の日記2009年8月26日の日記で示した問題点は残る。

本日のリンク元 TrackBack(1)

2010年05月06日

ケータイIDに添えて年齢情報も送信されるようになる?

4月9日、「利用者視点を踏まえた(略)諸問題に関する研究会」の第二次提言案が公表された。

この提言案には重要な論点が複数含まれている。特に、今このタイミングで一般市民が広く察知して議論を深めておく必要性が高いと私が思うのは、「I CGMに関する検討について」の「2.青少年保護に向けた取組強化について」の「利用者年齢認証の確実化」の部分。

ここに書かれている文章はクネクネクネクネして文章の論理構造を把握しづらいものになっているので、以下に階層的箇条書きでまとめてみる。(脚註は私によるツッコミ。今時間がないので後日追加する予定。)


年齢認証の確実化を巡る課題

  • 趣旨:SNSなど(以下「CGM」という)の年齢で機能に制限を設けているケータイ向けのサービスについて、「悪意のある成年が青少年と偽り、又は青少年が成年と偽ることにより機能制限等を免れるといった年齢詐称に伴う弊害が指摘されており*1、年齢認証の確実化に向けた取組の強化が求められている。」
  • 誰が年齢認証を担うか
    • 基本的にはCGM運営者自らが行うのが望ましい。
      • 既に大手CGM事業者による自主的取組みの例もある。
        • しかし、CGM事業者による方法では、オンラインで年齢確認をすることになるので、対面ではないから、詐称の可能性が高いという指摘がある*2
          • でも、オンラインサービスであっても、対面確認や書面確認も可能だとの指摘もある*3のだから、引き続きそれを追求していくべきところ。
            • しかし、商取引等の契約を伴わない一般のコミュニケーションの場において、対面確認等を求めるというのは「有効かつ妥当か」という課題が指摘されている*4
      • 青少年のCGMの実態として複数のCGMを連携して使うのが主流だから、1つのサイトで年齢認証を行うことが「どれほど有効か」とする課題も指摘されている*5
      • オンラインで年齢認証する方法は主に、クレジットカードや運転免許証を用いたもので、これは成年であることの確認であって、その方法が青少年向けCGMに適用できるかどうか。そもそも「青少年オンラインコミュニケーションをどのように位置づけるか」、「バランスの取れた検討が求められる。」
      • CGM運営者による年齢認証だけでは、厳格な年齢認証を行うサイトとそうでないサイトとの間で利便性に差が生じて、青少年が前者を避けるようになるだろうから、認証を行わないサイトが潜在化して、CGM運営者の自主的取組みの促進が阻害されるおそれがある。
    • したがって、自主的取組みの推奨が前提であるけども、実効性の高い年齢認証の実現のため、「インターネット回線契約を締結する携帯電話事業者等について検討することが有益」。
  • 誰が年齢認証されるのか
    • CGM運営者が認証するときは、当該サイトの閲覧者。通信回線契約提供者が認証するときは、インターネット接続の利用者。
    • インターネットに関係した青少年の福祉犯被害の多くが携帯電話等からのアクセスと指摘されている(出典:警察庁統計)ことから、「少なくとも現時点における検討としては、まずは携帯電話等の利用者を対象とすることを検討」
  • 既存の取組み
    • 2009年6月以降、大手SNS運営3社が、年齢認証の確実化として、フィルタリングを実装した携帯端末からのアクセスを認識して、当該利用者を18歳未満とみなして機能制限する「フィルタリング連動型年齢認証」を実施している。
      • しかし、この方法では、現状で携帯電話フィルタリングの普及率が十分に高くない(特に高校生)ことから、確実性が十分でない。
        • 特に、フィルタイリングを実装していない利用者ほど、インターネット上の違法・有害情報への危機対応能力や問題意識が低いと予想されることから、この方法では、保護の必要性が高い利用者層を除外してしまう。
      • また、携帯電話フィルタリングは、法人契約でも実装することがあるし、青少年だった者が成年になっても継続利用することがあるので、「青少年以外からの利用に対して必要以上の制限となりかねない。」
      • フィルタリング実装の有無では18歳未満か否かしか判別できない。CGM運営者側は、より細かい年齢設定に基づく機能制限を行おうとしており、これでは足りないとの指摘もある*6
        • しかし、実際にどの程度の年齢情報が必要かはサイトごとに異なり一概に不足とはいえない。
        • また、今後、年齢層別のフィルタリングが普及すれば、それを活用できる余地がある。
      • この方法では、成年が青少年のふりをする目的で、フィルタリングを実装するという詐称方法があり、この詐称を判別できない。
        • しかしそれを言うなら、悪意ある成年による詐称リスクは、この方法に限らず存在するとの指摘も可能。
    • いずれにせよ、CGM運営者が自ら年齢認証の確実化に向けて強化することが推進されるべき。
      • しかし、フィルタリングの普及によって青少年に配慮していないCGMサイトが閲覧不可になっていくであろうから、フィルタリングの普及に伴って本認証システムの意義は薄まっていくと予想される。
      • 一方、フィルタリングでも閲覧可能なサイト(第三者機関認定サイトなど)においては、「フィルタリングの有無より粒度の小さい年齢情報が求められるともいえよう。」
    • 「したがって、本取組みは、フィルタリング普及の過渡期の取組みとして位置づけ、より確実な年齢認証の実現に向けた関係者による取組みの強化が望まれる。」
  • 新たな取り組みの方向性
    • 「CGM運営者のみによる認証に一定の限界があることを踏まえ」、「携帯電話事業者等も含めた関係主体の協調による新たな取組みの検討の必要性が指摘されている。*7
    • 携帯電話事業者のなかには、自主的取組みとして利用者年齢情報を取得しているところもあり、そこで得られた情報は、サイト利用者が登録する情報に比較して、「真正性が高いと想定されている。」
    • 「こうしたことから、CGM運営者のみによる情報取得に対する補完的役割として、携帯電話事業者等が取得した比較的真正性の高いと想定される年齢情報をCGM運営者が活用する方策について検討することが求められている。」

携帯電話事業者とCGM運営者の協調による年齢認証の課題

  • 年齢情報と個人情報保護法との関係を整理し、個人情報の取得・活用に伴う関係法令を遵守しつつ実施されることが望ましい。
    • 利用者年齢情報の位置づけ
      • 携帯電話事業者等においては、利用者や保護者に対して、青少年利用者の生年月日又は実年齢の申告を求めることが想定され、この場合、年齢情報は利用者の氏名等との照合により特定の個人を識別し得る属性情報となるため、個人情報として個人情報保護法の関連規定の規律が及ぶ。
      • 他方、CGM運営者では、生年月日や実年齢、年齢層等の年齢情報を特定の個人が識別可能な形で提供される場合には当該情報は個人情報となるが、特定の個人が識別できない形(例:携帯電話サービスの契約者固有IDとは関連付けられているが、氏名等との結合が不可能なもの)により提供される場合(例えば、CGMサイトにアクセスした携帯端末の契約者固有IDに基づいて、CGM運営者が携帯電話事業者に対して行う照会に対して年齢情報が提供される場合)にはその限りではない」(個人情報には該当しないため、個人情報保護法の関連法規の規律が及ばない)
        • ただし、単独では特定の個人を識別できなくても、他の情報と容易に照合することにより個人を識別可能な場合については個人情報保護法の適用を受けるため、CGM運営者が自ら管理する利用者情報(例:会員氏名)と関連づけることが可能である場合、当該情報には容易照合性が認められると考えられる。」
      • 年齢情報の粒度(実年齢か、18歳未満か否かといったきめの細かさの程度)によって、その情報の法的位置づけが変わるかというと、個人情報保護法上は個人情報識別性の有無に影響しないため関係がない。
        • が、プライバシー保護やセキュリティ確保の関連からは、必要以上の情報のやりとりが行われることは望ましくない。
    • 携帯電話事業者等による年齢情報の取得時
      • 情報の利用目的について顧客に十分な説明を行うことが必要。
      • 青少年の利用者や保護者は、自らが提供する年齢情報がどこに提供されるのか、「的確に把握・管理していくことが望ましい」。
        • しかし、年齢情報の提供先であるCGM運営者の適格性について個別に判断することは困難。
        • しかも、提供先の範囲は「不断に変わり得る」
      • よって、「実運用上は携帯電話事業者等による管理に委ねられる部分が多くなる」
      • したがって、提供先主体の選定基準(適格性の判断基準)は「なるべく明確かつ透明であることが望ましい」
        • 例えば、顧客からの照会に対して、携帯電話事業者は、利用者年齢情報の提供先CGM運営者の名称を開示する等の取組みが考えられる。
      • 個人情報保護法では同意取得が求められるが、事前通知を要件としてオプトアウトの手続きもあるが、2つの理由からオプトインによる取得が望ましい。
        • 年齢情報の取得時に利用者と接触するのだから、そのときに同意を得るのが合理的だから。
        • 利用者視点を踏まえればオプトインの方がより丁寧な対応だから。
      • 具体的な対応としては次。
        • 新規契約や機種変更など、青少年又は保護者が来店するときには、年齢情報について説明して第三者提供に同意を得ることが考えられる。
        • 他方、一部携帯電話事業者に見られる、既に年齢情報を登録済みの利用者に対しては、第三者提供の同意を得る必要があり、SMSでの案内や、請求書同封物を通じた案内など何らかの手法が必要。(未成年による同意の効力についての脚註あり)
    • 携帯電話事業者等からCGM運営者への年齢情報提供時
      • 年齢情報の提供先の選定基準(適格性の判断基準)が明確かつ透明となっていることが望ましい。
      • 加えて、現にどのような主体に提供されているか、そしてその主体による適切な取扱いが確保されていることについて、利用者が容易に知り得る状態にあることが期待される。
      • 「提供時の仕様が決定される際には、セキュリティ確保の観点から、専門家による点検や確認といったプロセスを踏まえる等、年齢情報の適切な取扱いが行われるよう、あらかじめ検討に必要かつ十分な準備期間を置くことが求められる。」
      • 提供する年齢情報をどの程度の粒度とするかが問題となる。
        • 正確性や更新可能性の観点からは、生年月日が取得されることが望ましい。
          • しかし、当該情報の必要性と、「個人情報(又はプライバシー)保護の要請のバランスを適切に確保する水準を見いだしていくことが求められる。」
          • この点について、年齢情報が個人の属性に関する重要な情報であること、本取組みのそもそもの目的に照らし、青少年の福祉犯被害防止の観点から、CGM運営者の機能制限や注意喚起の取組みにとって必要最小限の粒度に留めることが必要と考えられる。
      • 実現方法として、次などが考えられる。この方法について「容易に知ることのできる状態を確保することが望ましい。」
        • 携帯電話事業者が、データベースを一定の年齢層に分類した上で、提供する。
        • CGM運営者からの照会に対して、携帯電話事業者が一定の年齢層による回答をする。
    • CGM運営者による年齢情報の活用時
      • 利用する年齢情報が個人情報に該当する場合は、個人情報保護法の関連規定を遵守する必要性があるため、年齢情報の利用目的の明記やプライバシーポリシーの改訂が必要。
      • 個人情報に該当しない場合であっても、「年齢情報は利用者にとってセンシティブな情報の一つでもあることから、個人情報の適正な取扱いを求める個人情報保護法に基本理念に基づき、適正な取扱いや利用者への周知について配慮することが求められる」*8
  • 携帯電話事業者等とCGM運営者の役割分担
    • 年齢情報の提供に際して、携帯電話事業者等とCGM運営者の間で締結される契約において、以下の項目について可能な限り明確化が図られる必要がある。
      • 提供システムの構築等に伴うコスト負担
      • 年齢情報の真正性に関する挙証責任の所在
        • CGM運営者による年齢認証を補完する自主的取組みであり、利用者等に強制力を持つものではなく、任意の年齢情報の申告を求めるものであるから、完全な真正性を担保することは不可能であり、真正性について携帯電話事業者が挙証責任を負うことのないようにするべき。
      • 個別サイトの顧客対応の所在
        • 苦情対応は当該サイトにおいて処理することが望ましい。
      • 年齢情報の利用目的、目的外利用の禁止
        • 「個人情報取扱事業者として当然に遵守すべき義務であるものの、両者間においてあらかじめ禁止事項や利用目的等を明記することにより責任の所在や内容を明確化することも有効である。」*9
      • 年齢情報の安全な管理
      • 適格性判断基準の遵守

その他の課題

  • 以下の課題がある。
    • 確実性の向上
      • 民間の自主的取組みとして実施される場合、年齢情報の真正性を完全に担保することは原理的に不可能であるが、確実性を少しでも高める観点から関係者が協力して漸進的な取組みを進めていくべき。年齢情報の任意申告要請に応じない青少年利用者への対策として、例えば以下など。
        • 携帯電話事業者が、新規契約の店頭での説明で、機能制限を実装しないことによる福祉犯被害の危険性を説明することで、申告を促す方法。
        • CGM運営者が、年齢情報を登録していない端末からのアクセスに対して、年齢情報を申告すべき旨を画面上で表示し、デフォルトで機能制限を行う等。
    • 利用実態の把握
      • 「親ケータイ」(家族名義の携帯電話が青少年によって使用されている携帯電話)の問題が指摘されており、実態把握が期待される。
  • この取組みは、未成年が成年のふりをして利用することを制限するものであり、危機対応能力の低い青少年が被害に対する問題意識の欠如から成年のふりをすることに伴う被害を防止する上では有効な取組み。
  • しかし、サイト上で「18歳未満であると詐称している利用者」が、年齢の認証の結果18歳以上と判別された場合に、CGM運営者としては、それが本人(18歳以上の詐称者)なのかその子供(18歳未満の正当な利用者)なのか判定することは非常に困難。
    • これの問題は「親ケータイ」の実態把握が進むことで徐々に改善していくと期待される。
    • しかし、「悪意ある成年が未成年のふりをして異性交際を誘引しようとする行為を有効に阻止できないとも指摘されており*10、何らかの方策の検討が求められている。」


と、以上の内容になっており、あちこちの誰かからいろいろな要求を出されて、けっきょく何も結論を出せていない状態になっているように見受けられる。

そもそも、「指摘されている」とか言いながら、出典を示しておらず、いったい誰がそのような要求をしているのかが明らかにされていない。この研究会は、親会は公開の場で行われている(傍聴が可能)が、それぞれのWG(ワーキンググループ)は非公開で行われており、密室でこのような文書が作成されているため、なぜこうなったのかが不明である。

私は、小さなIDプロバイダーが年齢情報を属性情報として提供するというのは、その事業者の自由(一定の秩序の下で)だと思うが、電気通信事業という社会のインフラであり、かつ寡占事業である、携帯電話事業において、このような重大な決定が、非公開の場で実質的に決められていくことに危機感を覚える。

ツッコミどころは多々あるので、パブリックコメントで意見を提出したい。

パブリックコメントの提出期限は、冒頭のリンク先にあるとおり、5月10日午後5時必着(郵送なら同日消印有効)とのこと。

*1 [要出典][誰?]

*2 [要出典][誰?]

*3 [要出典][誰?]

*4 [要出典][誰?]

*5 [要出典][誰?]

*6 [要出典][誰?]

*7 [要出典][誰?]

*8 この記述は、個人情報保護法に基本理念に基づいて保護されるべきものが、現行法では個人情報保護法の適用外になっているという、法の不備の存在を露呈させている。

*9 個人情報取扱事業者に該当しない場合は? 契約者固有IDのみを用いる場合など、個人情報保護法の提供外となる場合はどうなの?

*10 [要出典][誰?]

本日のリンク元 TrackBacks(2)

2010年05月08日

2ちゃんねるが日本のインターネット終了の引き金を引くか

一昨年、

これを書いたとき、ケータイから一般のインターネット端末へと青少年の使用端末が移行するであろう近い将来、青少年ネット規制法の改正によって、日本のインターネットが強制終了となるというシナリオを想定した。スマートフォンが開花しつつある今、その運命の分かれ目は間近に迫っている。

そういう岐路に立たされている今、一昨日の日記「ケータイIDに添えて年齢情報も送信されるようになる?」に書いたように、青少年の保護を口実に、年齢情報までインターネット接続事業者に送信させようという動きが出てきている。総務省研究会の提言案自身が述べているように、悪いことをしようとする者を排除することはできないわけで、いくらかハードルを上げることで悪事のコストを高めることはできるだろうけども、それは結局いたちごっこになる。ひとたび年齢情報送信のような施策をとれば、不完全だという理由で、さらに完全な策を求める者が出てきて、次々とより厳格な策をとらざるを得なくなっていくだろう。そうこうするうちに、青少年の一般インターネット接続への移行が完了するが、そのとき、この施策に頼り切ってしまったSNS事業者達は、次に何を要求してくるだろうか。

いろいろ耳にするところでは、年齢認証の他にも、ケータイIDの変更を不可能にしてほしいと要求している人たちがいるらしい。そのような要求は表沙汰になっていないが、auのEZ番号やdocomoのiモードIDが、EZwebやiモードの解約と再契約によって容易に変更できる*1ことに対し、「ひどいよね」と、携帯電話事業者を非難しているという話を耳にした。

ケータイIDの変更を不可能にせよとする要求は、このところ、2ちゃんねる掲示板からも出てきかねない状況になっている。「2ちゃんねる携帯電話大規模規制に関するまとめwiki」などにまとめられているように、昨年の暮れから、携帯電話による2ちゃんねるへの書き込みが大規模に規制され続けており、docomoやauは、キャリア丸ごと規制され続けている。2ちゃんねるでは、悪質な利用者をiモードIDやEZ番号で特定して規制できるようになっているが、悪質な利用者が、iモードIDやEZ番号を頻繁に変更しながら悪事をはたらいているため、丸ごと規制せざるを得なくなっているらしい。

2ちゃんねるは、たかが一掲示板と言うには済まないレベルの影響力を持っているようで、たとえば、「jigブラウザ」までもがiモードIDを送信するようになっているのは、2ちゃんねる運営からの要請にjigブラウザの開発元が応じたことによるものだった。

805 名前: root▲▲ ★ 投稿日: 2008/06/01(日) 20:56:53 ID:???0 BE:3830876-DIA(100512)

・ibisブラウザ・jigブラウザの中の人へ:

NTT Docomoの端末の場合、これまでの端末シリアル番号にかわり、
iモードIDを送っていただくように変更いただくこととなりました。

同期をとって対応しようと思いますので、
すみませんが、準備のほう、よろしくお願いいたします。

(現在はまだ書き込み出来ますが、
近日中にbbs.cgi的にiモードIDを送っていただかないと書けなくする予定です)

827 名前: root▲▲ ★ 投稿日: 2008/06/02(月) 16:18:13 ID:???0 BE:730324-DIA(100512)

>>805 については、ibis, jig の中の人のご降臨待ちです。

今週末までに何らかの形でご降臨いただけない場合は、
該当ブラウザからの書き込み機能の停止もありえますです、、、。

830 名前: ◆w0gEWSRfYU 投稿日: 2008/06/02(月) 21:37:14 ID:tYiQLE9Z0

>>827
お世話になっております。
株式会社jig.jpの菊池です。

ご連絡が遅くなりまして申し訳ございません。
iモードID対応の件了解致しました。

弊社側の対応としては、iモードIDに対応したものを今週の木曜日(6月5日)にアップしたい
と考えております。
(略)

2ch特化型サーバ・ロケーション構築作戦 Part28, 2ちゃんねる 運用情報

しかし、2ちゃんねる側で(その目的のために)必要としている要求を満たすには、iモードIDのような性質のIDは、過大なものであって、必要なものではない。2週間程度で自動的に変わる独自IDでもよいわけだし、ましてや全サイト共通のIDである必要は全くない。そういった工夫をしたIDの送信を求めてもよかったはずだが、そうではなかった。*2

今もdocomoやauに対するキャリア全域規制が続いているが、このまま利用者の不満が募れば、iモードIDやEZ番号の変更を不可能にしてくれという要請が、キャリアに対して突き付けられることになりかねない。

2ちゃんねるの運営は、たしか、技術的にわりとよくわかった人たちによって取り仕切られていたはずと思う。ならば、影響力あるコンテンツプロバイダーとして、プライバシー上の問題が小さくかつ悪質利用者の排斥にはそこそこ十分に有効な、新しいIDの創設を促すよう、キャリアに働きかけてはくれないものだろうか。

追記

ちなみに、「終了する」というのは、そのような悪質行為の横行する場(掲示板やSNS等)のことを言っているのではなく、それらとは別の善良なサービス(中小企業のECサービス等)のことを指して言っている。なぜそれらが(巻き添えを食らう形で)「終了する」のかについては、「日本のインターネットが終了する日」の「契約者固有ID送信時代の安全なケータイWeb利用リテラシ」の部分で書いている。

*1 2008年7月10日の日記では、iモードIDについて、「「基本的にお客様にずっと通して使って頂くもの」とのことで、ID変更手続きは存在しない。」と書いたが、そうではなかったらしい。

*2 ちなみに、Googleなどが必要としている、広告の不正クリック対策の用途でも、このような仕様のIDで十分なはずである。(Googleのようなお利口さんが集結した会社なら、当然そういうことはわかっているよね?)

本日のリンク元 TrackBacks(100)

2010年05月11日

利用者視点ICT諸問題「利用者年齢認証の確実化」パブリックコメント提出意見

前々回の「ケータイIDに添えて年齢情報も送信されるようになる?」の件、パブリックコメントに以下の意見を提出した。


利用者視点を踏まえたICTサービスに係る諸問題に関する研究会 第二次提言(案)に対する意見

■意見1: セキュリティ上の欠陥を解決しない限り年齢情報の送信をしてはならない
(CGMに関する検討、利用者年齢認証の確実化)

要旨

以下の2つの要件のいずれかが満たされない限り、送信された年齢情報は不特定サイトが入手可能になってしまう。したがって、以下の2つのいずれかが満たされない限り、年齢情報の送信を実施してはならない。

(a) 携帯電話事業者が契約者固有IDの不特定サイトへの送信を中止する(公式サイトへの送信に限る)こと。
(b) 年齢認証の結果を反映して表示されるWebページの全てについて、その反映内容が他のサイトから参照されることがないよう、技術的対策を完全に実施する(その技術仕様を公表する)こと。

理由

提言案は、携帯電話事業者がCGM運営者へ年齢情報を提供するにあたって、提供先の選定基準(適格性の判断基準)を明確にすることが望ましいとしているように、この年齢情報の提供は、選定された(適格性のある)一部のWebサイトに対してのみ送信されることを前提としている。したがって、選定されたWebサイト以外がその年齢情報を取得することができるならば、それはセキュリティ上の欠陥(脆弱性)であるということになる。

一方、提言案にも書かれている、大手SNS運営3社により2009年から実施されている「フィルタリング連動型年齢認証」は、他のWebサイトにおけるフィルタリング適用の有無を、画面上に埋め込んだ当該サイトの画像等へのリンクの表示状況等によって判別している。これは、フィルタリングの有無(未成年か成年か)という2値での判別ではあるものの、年齢に関する情報を反映して生成されたWebページの情報が、他のWebサイトから取得できることを意味している。

すなわち、既に現時点においても、フィルタリングの有無(未成年か成年か)という年齢に関する情報は、不特定のWebサイトで取得可能な状態にあるといえ、問題は既に存在しているとも言えるが、これは、2値での判別にすぎないこと、また、フィルタリングの有無が必ずしも未成年か成年かの区別に対応しているとは限らないことから、この事態の問題性は比較的小さいものとして、社会に許容されていると考えられる。

しかし、今回の提言案が検討している携帯電話事業者による年齢認証は、確実性の高い年齢情報を送信することになるものであるし、また、より粒度の細かい年齢情報の送信を検討しているものであるから、それらの年齢情報が「フィルタリング連動型年齢認証」と同様の手法によって、他の不特定のWebサイトから参照可能であるならば、それは許容されないレベルの問題であり、セキュリティ上の欠陥(脆弱性)である。

このような、他のWebサイトの情報を部分的に取得できてしまう事態は、従来、一般のインターネットのPCサイトにおいても同様に存在してきたものであるが、その場合には、取得できたとしても、それが誰のアクセスによるものかは不明であるため、たいていの場合、問題視されることがなかった。しかし、今日の携帯電話の場合、すべての携帯電話事業者において、アクセス者の契約者固有IDを取得することが可能となっているため、不特定のWebサイトが、他サイトから取得する年齢情報を契約者固有IDに紐付けて収集、蓄積することが可能である。

契約者固有IDは、それ単体では、個人情報保護法に言う「個人情報」には該当しないのかもしれないが、通常のIPアドレス等とは異なり、特定の個人に直接に連結して生成されているものである。もし仮に、「契約者固有IDは個人を特定しないので、年齢情報がそれに紐付けられても問題がない」とする主張が正しいと仮定すると、今回の提言案で検討されている「契約者固有IDを携帯電話事業者に送信して問い合わせると年齢情報が返答される」という仕組みも「不特定サイトからの問い合わせに返答しても問題がない」という帰結になるはずである。しかし、提言案は、そうした問い合わせへの返答を、選定された(適格性のある)一部のWebサイトに限定するとしているのであるし、その理由は、p.24の「CGM運営者における年齢情報の活用時について」に書かれた「仮に個人情報取扱事業者に該当しない場合であっても、年齢情報は利用者にとってセンシティブな情報の一つでもあることから、個人情報の適正な取扱いを求める個人情報保護法の基本理念に基づき、適正な取扱いや利用者への周知について配慮することが求められる」という趣旨によるものであろう。したがって、たとえ契約者固有IDがそれ単体で「個人情報」に該当しないものであっても、不特定のWebサイトが、契約者固有IDと年齢情報とを紐付けて収集できてしまうことは、提言案の前提を満たさない、セキュリティ上の欠陥(脆弱性)である。

よって、携帯電話事業者による年齢情報の送信を実施するには、次の2つの要件のいずれかが満たされなければならない。

(a) 携帯電話事業者が契約者固有IDの不特定サイトへの送信を中止する(公式サイトへの送信に限る)こと。
(b) 年齢認証の結果を反映して表示されるWebページの全てについて、その反映内容が他のサイトから参照されることがないよう、技術的対策を完全に実施する(その技術仕様を公表する)こと。

今日の携帯電話は、JavaScript機能を搭載した端末が増えてきており、そうした機種においては、(b)で示された「反映内容が他のサイトから参照されることがない」を実現する方法が、必ずしも容易ではなく、少なくとも、各Webサイト運営事業者の自主的な取組みに任せておいて解決するほどに自明なことではない。

したがって、(a)の要件が満たされないのであれば、(b)の技術的対策を完全に実施するための技術仕様が公表されることが必要であり、それができないのであれば、年齢情報の送信をしてはならない。

■意見2: (以下略)


以下、昨年の関連報道。

以下、今回の件の関連報道。

  • 交流サイト、年齢確認を強化 携帯電話会社が情報提供, 朝日新聞, 2010年4月7日

    (略)年齢確認の強化は、有識者などでつくる総務省の作業部会が6日に提案し、通信会社とSNS運営会社双方が受け入れる意向を示した。

    年内をめどに、通信会社が契約時などに確認した携帯電話利用者の年齢に関する情報を、利用者の同意を得た上でSNSやゲーム、自己紹介サイト「プロフ」を運営する各社に提供する。生年月日を含めるかなどの詳細は今後詰める。総務省によると、通信会社が犯罪防止目的で個人情報を第三者に提供するのは異例という。(略)

本日のリンク元 TrackBacks(3)

2010年05月12日

KDDIの固体バカが言う「EZ番号はプライバシーに関する情報ではない」

これまで、契約者固有ID(サブスクライバID)について、それ単体では「個人情報」(日本の個人情報保護法が言う)に該当しないという法解釈は存在した。それは、個人情報保護法がそういう法律だから(プライバシー保護の法律じゃないから)そういうものだという話*1だった。それでも、4月3日の日記にも書いたように、ウィルコムからは、「CPに対しても個人情報保護法に従った慎重な取扱いを求めています」という回答を得ていた。

ところが、auのKDDIが、以下のQ&Aを掲載していることに気づいた。

  • EZ番号(固体識別番号)を変更したい。, auお客様サポート よくあるご質問
    画面キャプチャ
    図1: KDDI曰く「EZ番号は、プライバシーに関する情報は含まれておりません」

    「EZ番号」(固体識別番号)はau電話ごとに割り振られており、変更することができません。

    EZ番号はお客さまがURLにアクセスした際にサイト提供元のサーバに通知され、会員のアクセス管理などに利用されますが携帯電話番号やメールアドレス、氏名などのプライバシーに関する情報は含まれておりませんのでご安心ください。

これは新しい。個人情報保護法の「個人情報」には当たらないというのは耳にタコだが、プライバシー情報じゃないという見解は初めて見た。KDDIの法務はいったいどうなっているのか。

もっとも、「個体識別」のことを「固体識別」と書くような頭の弱い人が書いた文章なので、そもそもこれを真に受けるのが間違っているのかもしれないが。*2

ちなみに、総務省の「利用者視点を踏まえたICTサービスに係る諸問題に関する研究会第二次提言(案)」には、契約者固有IDに関する法的検討がなされていて、個人情報保護法に関する検討の部分で、p.41の脚註44に、以下のように書かれている。

契約者固有IDについては、複数のコンテンツプロバイダに対して同一の契約者固有IDが送出されるため、各コンテンツプロバイダが保有するウェブページ上の行動履歴や位置情報を、同一IDに紐付けて集積することが極めて容易との指摘がある。また、各コンテンツプロバイダにとっては、契約者固有IDを、契約者情報等の個人情報と紐付けることが容易に可能であり、同一の契約者固有IDに紐付けて集積されたウェブページ上の行動履歴等が比較的容易に個人識別性を獲得するとの指摘がある。

利用者視点を踏まえたICTサービスに係る諸問題に関する研究会第二次提言(案)

また、プライバシーとの関係について検討されているp.45においても、次のように書かれている。

ウェブページ上の行動履歴や位置情報は、一般にそれ単独では個人識別性を有しないため、特定個人のプライバシーの侵害が成立しないとの指摘がある。(略)しかしながら、個人識別性のない情報であっても、行動履歴等の情報が大量に蓄積されて個人が容易に推定可能になるおそれがあることや、転々流通するうちに個人識別性を獲得してしまうおそれがあることから、現時点で情報に個人識別性がないことをもって、プライバシーとしての保護が完全に失われると考えるのは相当でない。

利用者視点を踏まえたICTサービスに係る諸問題に関する研究会第二次提言(案)

ところで、図1をよく見ると、「このQ&Aを見た方はこんなQ&Aも見ています」のところに、次のQ&Aがある。

それって、EZ番号から電話番号を特定されるってことじゃないの?

KDDI曰く「安易にアクセスしないことが一番です。」
KDDI曰く「URLにアクセスした際にサーバに通知され……ますが……ご安心ください。」

どっちなんだ。

*1 たとえば、「suzukimasatomo先生の最近のつぶやき」、「suzukimasatomo先生の最近のつぶやき その2」など。

*2 だいたい、「個体識別」という言葉も、本来は動物の個体を指す言葉なので、電話機を指して言うのはおかしいし、そもそも、契約者に固有のIDであるなら、それは「個人識別」と呼ぶべきものだろう。最近は年齢も提供するという話なのだから、まさに個人識別番号だ。なぜその言葉を避けるのか。欺瞞じゃないのか。

本日のリンク元 TrackBacks(6)

2010年05月15日

「ライフログ活用サービス」という欺瞞

実は、今年3月、総務省の「利用者視点を踏まえたICTサービスに係る諸問題に関する研究会」からは、有識者ヒアリングとして意見を述べる機会を頂いた。ただし、私に発言の機会が与えられたのは、「ライフログWG」における検討内容のうち、「より信頼されるサービスに向けて(配慮原則の提言)」の部分についてのみで、それ以外の部分については対象外だった。

あまり重大な指摘をする余地のない部分であったが、私としては与えられた使命を全うすべく可能な限り改善点を洗い出して、意見として列挙した。

この「配慮原則の提言」は、報告書案では「ライフログ活用サービス」という表現を使っているが、実質的には、これはすべて「行動ターゲティング広告」を対象としたものになっている。「ライフログ活用サービス」というと、利用者が自ら望んで活用する話に聞こえるが、行動ターゲティング広告では、基本的に利用者に無断で行おうとするものだから、配慮が必要となるというわけである。

配慮原則案は、「(1)広報、普及・啓発活動の促進、(2)透明性の確保、(3)利用者関与の機会の確保、(4)適正な手段による取得の確保、(5)適切な安全管理の確保、(6)苦情・質問への対応体制の確保」から成っており、このうち(3)の「利用者関与の機会の確保」は意味がわかりにくい表現になっているが、ようするに、オプトアウト手続きのことを指している。

(3) 利用者関与の機会の確保
対象事業者は、その事業の特性に応じ、対象情報の取得停止や利用停止等の利用者関与の手段を提供するよう努めるものとする。

このことについて、事業者がプライバシーポリシーで「cookieは拒否できます。削除もできます。」としているケースが散見されるけども「それだけでは配慮が十分とは言えない」というようなことが書かれていたので、その問題に切り込むならもっと根本的なところに切り込むとよいと思い、以下の意見を述べた。

スライド スライド スライド スライド
図1: cookieによるオプトアウトは不完全であるとした意見

残念ながらこの意見は採用されることはなく、パブリックコメントにかけられた報告書案に反映されていない。まあ、これはしかたがないかと思う。現実的にcookieによるオプトアウトがまかり通っている現状において、このような意見は無理筋であることはわかっていたが、せっかくの機会なので一推しで述べてみた意見だった。

それでも、スライドで例として示した、楽天のオプトアウト用cookieが1年の有効期限になっていた件*1については、総務省で意見を述べた甲斐あってか、数日後に再確認した際には、有効期限が20年(実質無期限)に変更されていた。

ただ、ライブドア社のオプトアウト手続きについて調べてみると、現時点でもオプトアウト用cookieの有効期限は1年になっている*2

やはり、少なくともこのような欺瞞行為を是正させる何らかの規定なり、業界の自主ガイドラインなりが必要なのではないだろうか。

しかし、今回の「利用者視点 第二次提言案」はそもそもそのレベルまで問題認識が到達しておらず、私が呼ばれたのは、報告書案公表の1か月前(WG最終回の直前)だったので、そこで何か提案しても通らないようだった。

その後調べて知ったのだが、米国では、インターネット広告事業者の業界団体「Network Advertising Initiative」が自主的に、完全なオプトアウトの仕組みを提供する試みを実施しているようだ。

こういう活動が日本にはない。もしくは、あるのかもしれないが外から見えない。(良心的な広告事業者がそういった策を提言しているかもしれないが、表沙汰にならない。)

ヒアリングでは、次の意見も述べた。

スライド
図2: 行動ターゲティングの結果を識別できるようにせよとする意見

「ライフログ活用サービス」と称すのだから、利用者の望むものを提供しているという建前であるはずだ。であれば、どれが行動ターゲティングの結果なのかを明示することに、何ら臆することはないはずである。

また、配慮原則案は「広報、普及・啓発活動の促進」も謳っているが、残念ながら広報・啓発活動には全く期待できないわけで、そういう状況で、表示された広告自身にそれが行動ターゲティングの結果である旨を示す表示がついていれば、消費者は自然にそれが何なのかを学ぶことができるだろう。

日本で広告業界の自主取組みが活発化しないのは、消費者がものを言わないからだろうが、日本では、ものを言わないというのは、必ずしも不満を抱いていないということではない。もし本当に「ライフログ活用サービス」が消費者の望むものであるなら、ちゃんと事実を説明していけばいいはずで、広告業界と消費者のウィンウィンの関係を築けるはずだろう。

米国では、既にこうしたマーク(アイコン)表示の計画が推進されているようだ。

  • Advertising - A Symbol to Provide Details About Online Privacy, NYTimes.com, 2009年1月26日

    Trying to ward off regulators, the advertising industry has agreed on a standard icon ― a little “i” ― that it will add to most online ads that use demographics and behavioral data to tell consumers what is happening. (略)

    Most major companies running online ads are expected to begin adding the icon to their ads by midsummer, along with phrases like “Why did I get this ad?”

    When consumers click on the icon, a white “i” surrounded by a circle on a blue background, they will be taken to a page explaining how the advertiser uses their Web surfing history and demographic profile to send them certain ads.

    画面キャプチャ 画面キャプチャ

  • UK behavioural targeting industry should adopt US symbol, Marketing, Advertising & Interactive News & Jobs, New Media Age, 2010年2月2日

私のヒアリングでの提案は採用されることはなかったが、報告書案では脚註64に次のように記載された。

64 一部の構成員から、どの広告が対象情報を活用した行動ターゲティング広告等なのか、利用者に容易に認識かつ理解できるようにすべきとの指摘があった。

この提案が受け入れられないとすれば、「利用者の望むものを提供」というのは実は嘘で、本当は皆が嫌がることをやろうとしているのを自覚しているということではないか。

そういう意味で次の意見も述べた。

スライド
図3: 「ライフログ活用サービス」という欺瞞

残念ながらこの意見は採用されなかったが、ヒアリングの席では、事業者の出席者からも「ライフログ」という言葉はおかしいという発言が相次いだ。行動ターゲティング広告を指す言葉として英語圏では通用しないため、ビジネスに支障が出るという。

いったい誰が、行動ターゲティング広告のことを「ライフログ」などと言い出したのだろう? 最初に言ったのは誰? 「マイ・ライフ・アシスト」のようなサービスは「ライフログ」と言ってもよいだろうが、それはオプトイン前提だからだ。

さて、私としては本命の提案は次のものであった。

スライド スライド
図4: 識別IDの時間的・空間的連続性の差異を考慮すべきとする意見

残念ながら、私が呼ばれたのはWG最終回の直前なので、この検討をする余地はなかったと思われる。パブリックコメントにかけられた報告書案では、脚註63で次のように記載されるにとどまった。

63 保存期間には、端末等の識別を継続して行う期間と、蓄積した対象情報を保管する期限の2つがある。

ヒアリングに呼ばれて感じたのは、WGのメンバーは技術的なことをわからずに話しているらしいことだった。メンバーは弁護士や法学研究者、事業者は法務担当者ばかりで、オプトアウトcookieが識別性ゼロであることさえわからない*3まま議論になる一幕もあった。(詳しいことをここに書くのはやめておこうと思う。)

そんなことでは、落とし所を導くことができずに、「消費者優先か事業者優先か」「全否定か全肯定か」の言い合いにしかならないのもしかたないと思った。

*1 ちなみに、Yahoo! JAPANのオプトアウト手続きについて同じ日に確認したところ、2037年までと無期限になっていた。

*2 ちなみに、このライブドアのオプトアウト用cookieの有効期限は、2008年12月の時点では1か月だった。(「livedoorのad4U、拒否できるのは「1ヶ月」だけ」, xenoma日記, 2008年12月13日)

*3 フラグという概念がわからなかったらしい。

本日のリンク元 TrackBacks(6)

2010年05月16日

先週からEZ番号の変更が不可能にされていた

KDDI社員の方からタレコミがあった。

従来、EZ番号は、EZオプションを廃止して再加入すると新たな番号が付与されるようになっていたのだが、5月10日から、同じ個人には同じEZ番号を継続して付与するよう、システム変更があったという。その意図は、「EZ番号変更による問題行為の防止」だという。電話番号を変更してもEZ番号は変わらないようになったという。

エンドユーザのプライバシーにかかわる仕様変更であるにもかかわらず、プレスリリース等を出さずこっそり変更していることから、私から注意喚起をしてほしいとのことだった。

この情報は、とくに隠されているものではなく、聞かれたら答えられるよう各種窓口に周知されているものだそうで、以下のチラシが店頭掲示用として配布されているようだ。

文書画像
図1: 店頭掲示用らしき告知文書
「お客様の利便性向上のため」
「EZ番号: 契約の有無を確認する番号」

KDDIのこの措置が誰の要求に応じたものなのかは知らない。

2ちゃんねるを調べてみたところ、以下のやり取りがあった。

  • 報告人作戦返答処理スレッド★18, あらし報告・規制議論(仮)@2ch掲示板

    205 :reffi@報告人 ★:2010/05/10(月) 20:01:26 ID:???0

    >193
    こちらでも確認しました。
    これでは解除は難しいのでもうちょっと具体的な内容について問い合わせてもらいませんか?
    (安易にEZ番号を変えてくるようなユーザーに対する対策等)
    難しい交渉になると思いますがよろしくお願いします。>葱@報告人 ★さん

    225 :葱@報告人 ★:2010/05/10(月) 22:10:13 ID:???0 ?2BP(2450)

    おつかれさまです。

    >>205
    > 安易にEZ番号を変えてくるようなユーザーに対する対策等
    従来のように個別に焼くだけならそのような対策も必要かと思うのですが、
    \.ezweb.ne.jpとして一括規制するのにそのような対策をお聞きする必要はあるでしょうか……

    それを言い出したら、変動しやすい動的IPアドレスを提供しているすべてのISPに
    「繋ぎかえを繰り返すユーザーに対する対策」
    をお聞きする必要がある気がします。

    「どうしても」とおっしゃるなら、先方に問い合わせいたしますが、
    正直、携帯キャリアに対して厳しすぎるような気がしてなりません。

    大変失礼かとは存じますが、御一考いただけないでしょうか。

    227 :reffi@報告人 ★:2010/05/10(月) 22:22:51 ID:???0

    >225
    単なる繋ぎ替えならユーザーは追いかけられるので再発した場合でも厳しく対応が出来ます。
    携帯の場合、簡単に固有番号そのものを変えられてしまうのでその辺の対策について
    問い合わせてほしいのです。
    前回と同じような回答で解除したのではすぐに再発する可能性が高いのでもう少し
    具体的な回答がほしいのでよろしくお願いします。

    230 :名無しの報告:2010/05/10(月) 22:26:37 ID:+EKWuy6BP

    >>227
    EZ番号は今日から固定化になったようです
    http://ktaimobilegadget.blog88.fc2.com/blog-entry-1211.html

    235 :名無しの報告:2010/05/10(月) 23:02:13 ID:HdaY8zS30

    こんばんは。
    EZ番号の変更についてauホームページより転載です。
    ttp://cs119.kddi.com/faq/1032/app/servlet/qadoc?QID=000021
    >Q:EZ番号(固体識別番号)を変更したい。
    >A:「EZ番号」(固体識別番号)はau電話ごとに割り振られており、変更することができません。
    >>230のブログの通り本日よりEZ番号の変更は出来なくなったようです
    これでもauの対策は不十分なのでしょうか?
    やはり私個人やブログからの情報ではなくauから運営側への正式な返答が必要なんですかね?

    236 :reffi@報告人 ★:2010/05/10(月) 23:04:32 ID:???0

    >235
    そういうことです。
    正式に回答が来てから再度判断しますが対策が講じられていた場合は解除します。

    247 :葱@報告人 ★:2010/05/11(火) 06:48:48 ID:???0 ?2BP(2450)

    >>227
    了解しました。

    少しいろいろ調べた上で後ほど問い合わせいたします。
    あとは何かお聞きしたほうがよい点あるでしょうか?

    248 :名無しの報告:2010/05/11(火) 08:33:07 ID:+SvVvs4eQ

    >>235
    auのホームページには以前からEZweb番号は変えられないと書いてあるのでは。
    これは、EZwebを解約して再加入すればEZweb番号は変わるが、解約および再加入をしないでEZwebを契約してる状態ではEZ番号を変えることはできないという意味だと思います。
    2chはau携帯をEZweb番号でピンポイント規制してるのでEZwebの解約→再加入でピンポイント規制を解除できてしまいます。
    >>230に貼られたサイトには5月10日から EZwebの解約→再加入 をしてもEZweb番号が変わらなくなると書かれていますが、その根拠(ソース)は書かれていません。信用できる情報なのでしょうか?

    295 :葱@報告人 ★:2010/05/12(水) 11:50:45 ID:???0 ?2BP(2450)

    おつかれさまです。

    >>205,225,227,247
    大変遅くなりましたが、送信完了しました。

    なお、今回お聞きした内容は以下の通りです(メールより一部転載、原文ママ)。

    =====
    1.貴社公式webサイトにおいて、「EZ番号は変更できない(*1)」という記載がありますが、
      これは「電話番号の変更(*2)」や「EZ WINコースの解約→再契約(*3)」等を含まないのでしょうか。

    2.外部の非公式webサイト(*4)より、「2010年5月10日よりEZ番号が固定化」「EZwebを解除、再加入しても
      再度同じEZ番号が割り当てられるシステムに変更」というような情報が流れておりますが、これは事実でしょうか。

    3.「電話番号の変更」や「EZ WINコースの解約→再契約」でEZ番号が変わる場合、
      安易にEZ番号の変更を繰り返すユーザーに対して、何か対策などを実施していらっしゃるでしょうか。
      また、その対策内容について具体的に教えていただけないでしょうか。

    4.何らかの事情でEZ番号が変わる場合、新しいEZ番号で変更前のEZ番号迷惑行為歴を追うことは可能でしょうか。

    5.何らかの事情でEZ番号が変わる場合、変更前のEZ番号が他のユーザーに割り当てられることはないでしょうか。

    6.何らかの事情でEZ番号が変わる場合、新しいEZ番号はアトランダムに割り当てられるのでしょうか。
      もし変動範囲がありましたら、それについて教えていただけないでしょうか。
       【例】_△△.ezweb.ne.jpの部分は固定、等

    7.今回ご回答いただく情報について、当掲示板上で公開させていただくことは可能でしょうか。

    【参照URL】
    (*1)http://cs119.kddi.com/faq/1032/app/servlet/qadoc?QID=000021
    (*2)http://cs119.kddi.com/faq/1032/app/servlet/qadoc?QID=000757
    (*3)http://www.naruhodo-au.kddi.com/qa2950935.html(非公式情報)
        http://parame.mwj.jp/blog/0273(非公式情報) など他多数
    (*4)http://ktaimobilegadget.blog88.fc2.com/blog-entry-1211.html(非公式情報)

    =====

    305 :葱@報告人 ★:2010/05/13(木) 09:54:15 ID:???0 ?2BP(2450)

    おつかれさまです。

    KDDI株式会社様より、>>295についてご回答をいただきました。
    残念ながら内容の公開許可はいただけませんでしたので、返答内容の転載は差し控えます。

    ezweb.ne.jp 規制
    http://qb5.2ch.net/test/read.cgi/sec2ch/1262876159/22-23
    http://qb5.2ch.net/test/read.cgi/sec2ch/1262876159/24-25
    http://qb5.2ch.net/test/read.cgi/sec2ch/1262876159/26-27
    http://qb5.2ch.net/test/read.cgi/sec2ch/1262876159/28-29
    \.ezweb.ne.jp (全サーバ規制) ※永久規制

    306 :reffi@報告人 ★:2010/05/13(木) 10:33:32 ID:???0

    >305
    こちらでも確認しました。
    代理人経由で最終判断を仰ぎますがこの内容でしたら解除できると思います。

KDDIから回答があったようだが、内容の公表を拒否されたようだ。なぜ公表を拒否するのだろう。

ちなみに、227は言っていることがおかしい。ケータイだと追いかけられないが一般のISPなら追いかけられるというのは、どういうことなのか?

こんな調子で、ISP丸ごと規制(丸焼き)をチラつかせて、IPアドレスの固定化を各ISPに要求していったら、日本のインターネットはいよいよ終了する。

関連

追記

KDDI社員の方からの情報によれば、正確には以下のとおりであるとのこと。

(1)変更概要
【変更前】EZオプション再加入時に、EZ番号が新たに付与される。
【変更後】回線契約中はEZオプション再加入時も、EZ番号を継続使用する。

(2)変更背景
「EZweb」オプションの廃止⇒再加入等で「EZ番号」を変更し、SNSサイトで迷惑行為を繰り返すといった問題行為も確認されている場合がある事から、迷惑行為対策としてシステム改修します。

(3)変更日
 5月10日(月)受付分以降

(4)変更該当申込種別
1.契約内容変更:EZwebオプションに再加入/EZwebオプションを廃止→取消した場合。
2.機種変更(端末増設):機種変更(端末増設)と同時に上記契約内容変更の処理を行った場合。
3.一次休止再利用:一次休止前にEzwebオプションに加入していた回線を再利用しEZwebオプションに再加入した場合。
4.一次休止・解約:Ezwebオプション加入中の回線を一次休止・解約し、その申込を取消した場合。
5.電話番号変更:電話番号変更をした場合。

※譲渡/承継の場合は現状通りEZ番号は変更されます。

「ユーザより業者最優先で本当にいやになります」とのことだった。

本日のリンク元 TrackBacks(7)

2010年05月20日

クッキー食えないのはドコモだけ

ろくに安全な作り方も確立していないくせになぜかやたら蔓延ってしまった「簡単ログイン」。そもそもUI設計からしておかしい。ボタンを押せば入れるなら、ボタンがある意味がない*1。ログアウト不可能な常時ログインサイトだ。(それなのに「ログアウト」ボタンがあったりする。)

「そんなこと言ったって便利だから必要なんだ」とか、「ケータイでパスワードなんか入れてられない」だとか、「お客さんが付けてくれって言ったら俺たちIT土方には何も助言なんてできないんだ」とか言う人が出てくるわけだが、そんなのは、一般のインターネットのサイトだって、昔から「□ 次回から自動的にログイン 」とか「□ 次回から入力を省略」といったチェックボックスが普通に用意されている。amazon.comなんか大昔からログインしっぱなしだ。

そしてそれはcookieによって実現されてきた。個人識別番号なんぞ使っちゃいない。日本だけこんなことになってしまったのは、docomoの旧型端末「iモード1.0」が永らくcookieをサポートしていなかったからにすぎない。

でも、最近のdocomo端末はcookieをサポートしている。では、現時点でcookieの使える端末は全体の何割くらいだろうか。この点について、モバツイの藤川真一氏が調査してくださった。

この結果を私なりにまとめなおすと次のようになる。

表1: 携帯電話Webブラウザのcookie有効状況(モバツイ調べ)
docomoauSoftBank全体
有効648 (28.0%)1710 (99.9%)606 (98.7%)2964 (63.9%)
無効1667 (72.0%)1 (0.1%)8 (1.3%)1676 (36.1%)
合計2315 (100%)1711 (100%)614 (100%)4640 (100%)

SoftBankにはcookieをオフに設定している人が少しいるということだろうか。そして、auにはcookieをオフにする機能がないのだろうか。おそらくこれらは全ての端末でcookieが使えると思われる。そして、docomoのcookie対応率は28%。cookieが使えないことがあるのはdocomoだけであることが改めて確認された。

全体では64%がcookieに対応していたということになる。今後この割合は、iモード2.0端末の普及とともに増えていくだろう。数年後には、簡単ログインの実現という点からは、個人識別番号は不要になると考えるべきである。

WASForum Conference 2010 にてケータイ認証の話題

今週の土曜日、コクヨホールで「WASForum Conference 2010」が開催されます。この中で、ケータイの認証に関する講演があります。

野村総研の崎村様には、認証基盤連携フォーラム*2でのお取組みをご紹介頂きつつ、OpenIDのモバイル対応についてご講演頂きます。この話題は、日本のWebアプリケーション界における、認証方式の近未来を占う、重要な鍵となるかもしれないと私は考えています。

HASHコンサルティングの徳丸浩様からは、「ケータイ2.0が開けてしまったパンドラの箱」と題して、簡単ログインが危うい綱渡り状態になっていることについてご講演頂きます。

また、私からも、「どうするケータイ認証」として、簡単ログインやめようキャンペーンについて、その背景、趣旨、今後の見通しについてお話しします。

*1 元々は、番号送信時に確認ダイアログがポップアップするdocomoの「UTN」を用いた方法のために設計されたUIだったのだろうが、iモードIDが使われるようになった今となってはナンセンス。なぜそれに気づかないのか。

*2 認証基盤連携フォーラムは、総務省の「通信プラットフォーム研究会 報告書」の結論「認証基盤の相互運用性の確保に向けた検討を行うため、行政当局が関係者で構成する 「認証基盤連携フォーラム(仮称)」を設置」に基づいて設置されたフォーラム。

本日のリンク元 TrackBacks(9)

2010年05月29日

「VeriSignシール」という幻想

オレオレ証明書ではないSSLサーバ証明書は、2つの独立した機能を果たしていると言える。1つ目は、SSLプロトコルによるサーバとクライアント間の暗号化通信のために不可欠な役割であり、2つ目は当該サイト運営者の実在証明の機能である。ただし、今日では、後者を含まない、前者だけのサーバ証明書もある。

後者の実在証明は、かつては認証局サービスを提供する各事業者がそれぞれの独自の基準で、サイト運営者の実在性を確認、認証していたが、それでは利用者にわかりにくいことから、認証の際の実在性確認の方法が標準化され、誕生したのがEV SSLであった。

その結果、VeriSignなど、古くから実在証明に力を入れていた認証局サービスでは、EVのものとEVでない実在証明付きサーバ証明書の2種類が存在することとなった。VeriSignでは、EV証明書の提供開始後も、EVでない実在証明付きサーバ証明書の提供も続けている。

VeriSignは、実在証明のないサーバ証明書を提供するGeoTrustを2006年に買収したことから、今では、3種類のサーバ証明書を提供することになった。その結果、その違いを説明する必要に迫られることとなり、日本ベリサイン社は、実在証明の意義を以下のように説明している。

実在証明を必要とするケースと不要なケースが説明されているが、付け加えて言えば、不特定多数向けのサービスであっても、ドメイン名が広く知られている場合には、実在証明はなくてもよいと思う。また、実在証明を本当に必要とする場面として、マイナーな中小企業が運営するネットショップのケースがあると思う。

基本的に、SSLで安全な通信(偽サイトへの送信を防ぐ意味を含めて)ができるのは、以前訪れたことのあるサイト(ドメイン名や会社名を覚えているサイト)か、元々運営者のことをよく知っている場合のいずれかである。初めて訪れたサイトで、運営会社のことをよく知らない場合、本来は安全な通信は実現しようがない。

しかし、そんなことを言えば、マイナーな中小企業はネットショップを運営できなくなってしまう。そこで、そのような場合に、実在証明付きのSSLサーバ証明書を使うことで、結果的に、そのサイトの運営者について、ある程度の信用性が確認できる……と考えることができる。

VeriSignが古くから「VeriSign Secured Seal(ベリサインセキュアドシール)」を提供しているのは、そうした状況における、運営企業の実在証明のためだったはずだ*1と私は思う。

というように、VeriSignシールは、SSL暗号化通信には何の意味もないとよく言われるけれども、一応、中小企業向けに運営者の実在証明として意義をなしていると思う。

ところが、シールの意味が正しく理解されておらず、不正に貼られている事例があるようだ。以下は、私が作成した入力フォームだが、本物のVeriSignシールが貼られている。(もちろん、ここに入力されたデータは私の手中に入る。)

画面キャプチャ
図1: 個人が作成した入力フォームに本物のVeriSignシールが貼られている様子

シールをクリックすると、「フォームメーラー」という、誰でも無料で入力フォームを設置できるサービスの運営会社の名前が表示される。カード番号を盗むような入力フォームを設置されたとき、この会社は責任を負うつもりなのだろうか。

この「フォームメーラー」は、昨年6月27日の日記「EV SSLを緑色だというだけで信用してはいけない実例」でも取りあげた。その後、このサービスはEV SSLの提供を中止していた。

中止したのはよかったが、なぜ中止しなければならないのか、その意味を理解していなかったようで、その後、2009年9月から、VeriSignシールを貼付ける機能が付け加えられていた。

そもそも「SSLシール」じゃなくて「VeriSignシール」だ。この会社はSSLが何なのかまるで理解していないようで、以下のように宣伝している。

画面キャプチャ 画面キャプチャ
図2: 「日本ベリサイン社のSSL暗号化通信対応」と書かれている様子

「ベリサインのSSL」などというものがあるわけじゃない。SSLは単なるプロトコルの名前であって、VeriSign社が発明したわけじゃないし、どこの証明書を使おうが暗号化の強さに関係ない。

加えて言えば、図2の画面に書かれている「全世界標準の認証ガイドラインに基づいて発行されるSSL証明書なので」というのは、EV SSLの説明であって、このサービスはもうEV SSLの提供をしていないのだから、これは虚偽の商品説明ということになる。

ちょっと自分の頭で考えてみたらどうだろうか。

どのくらいおかしい話かは、このサービスを紹介した以下の個人のブログでわかる。

米国のVerSign社は、こうした不正なシール使用をやめさせる通報窓口を設けているが、日本ベリサインはそうした取り締まりをしないのだろうか。こういう使われ方を放置したり、「ベリサイン社のSSL」といった幻想が広がるのを(これ幸いとばかりに)放置すれば、結局はいずれ、VeriSignブランドの信用低下を招くのではないか。

もっとも、VeriSignの証明書発行事業は、Symantecに買収されることになったそうで、シールもSymantecのロゴに変更されるらしい。この際、わけのわからないシールの幻想から、バッサリおさらばした方がいいのではないか。「シマンテック社のSSL暗号化通信」という表現は胡散臭い。

  • ASCII.jp:シマンテック、ベリサインの事業買収でピースを埋める, ASCII.jp, 2010年5月21日

    シマンテックの買収後はベリサインのブランドを統合した、プレミアムの高いブランドを醸成していくとのこと。そのため、買収後にはロゴの変更も行なわれ、ベリサインロゴのチェックマークがシマンテックロゴに統合される予定となっている。

    引用の画像部分

もし今後、シマンテックがSSLについて少しでも虚偽を含む解説を出してきたら、私は厳しく追求していくつもりだ。

*1 したがって、ドメイン名や会社名が著名で、元々よく知られた企業が、VeriSignシールを貼っている場合があるとすれば、マヌケだと思う。

本日のリンク元 TrackBacks(10)

2010年05月30日

DPI行動ターゲティング広告の実施に対するパブリックコメント提出意見

この記事が今日の朝日新聞朝刊1面に出ている。紙の方の記事では「行動ターゲティング広告」と「米英では頓挫」のキーワード解説が載っている。

これは、総務省の「利用者視点を踏まえたICTサービスに係る諸問題に関する研究会 第二次提言」のことだろう。「ライフログ活用サービスに関する検討について」の中に「ディープ・パケット・インスペクション技術を活用した行動ターゲティング広告について」という節がある。(電気通信事業者の取扱中に係る通信の傍受のことを指して「ライフログ」を呼ぶのには強い違和感があるが。)

この提言は、4月9日から5月10日にかけてパブリックコメントにかけられていたので、私も意見を提出した。提出した意見は以下のとおり。

■意見2: DPI広告事業者の透明性は検証不能であるから第三者による監査を義務付けない限り実施を認めるべきでない
(ライフログ活用サービスに関する検討、DPI技術を活用した行動ターゲティング広告)

理由

提言案は、DPI技術を活用した行動ターゲティング広告(DPI広告)の実施は、通信当事者の同意がない限り、通信の秘密の侵害行為であって違法性も阻却されないとしており、その通信当事者の同意についても、「その意味を正確に理解したうえで真意に基づいて同意したといえなければ有効な同意があるということはできない」としている。この点について、提言案は、最後の段落において、同意にあたっての判断材料として、「利用者に対してサービスの仕組みや運用について透明性が確保されるべき」とし、「各事業者は、透明性の確保に向けて運用にあたっての基準等を策定し、これを適用することが望ましい」と結んでいる。

そのような結論に従う場合、DPI広告を提供する事業者は、おそらく、そのサービスがいかに利用者のプライバシーに配慮したものであるかを説明し、たとえば「Webメールの内容については傍受しない」といった説明をして、利用者の同意を得ようとするであろう。また、利用者も、そのような配慮がなされているからこそ、同意してオプトインできるものと考えられる。

しかし、DPI広告の場合、そのような配慮が本当に実施されているかは、外部からは誰にも検証できない。これは、従来の行動ターゲティング広告にはなかった新しい事態である。従来の行動ターゲティング広告では、専門家がWebブラウザの挙動等を調べることによって大方その影響範囲を推定できるものであった。それに対し、DPI広告のシステムは、実際に何をやっているかは事業者のシステムに侵入して調べるなどしない限り第三者には検証できないものである。

そのような検証不能なシステムについては、事業者の説明があるからといって透明性が確保されたとは言えず、通信の秘密という重大な事項についての同意にあたっては、その程度の透明性で有効な同意があったと見なすべきではない。

したがって、DPI広告実施事業者の説明が真実であることを検証する第三者による監査を義務付けない限り、このようなサービスを合法と認めるべきではない。

つまり、10年前に登場したDoubleClick等の方式や、一昨年の「楽天ad4U」のケースなどでは、Web技術者が解析すればそこで何が行われているか、そして、何は行うことができないものなのかを調べることができたのに対し、電気通信事業者によるDPIでは、基本的に何でも可能なのだから、たとえば「Webメールの内容は見ていない」と言われても、本当にそうなのかは、私たち一般市民からでは調査することが不可能である。だから、法的権限を持った機関による監査が不可欠であるとした。

実際にそんなことが必要なのかといえば、日本のIT事業者は、これまでにも、プライバシーポリシーの記述においてcookieの説明が出鱈目だった前歴があるわけで、cookieが何かもわからないような技術に暗い法務の人々がそれを書いているために、嘘をつくつもりがなくても、利用者を怖がらせたくないという一心で、事実と異なる説明を書いてしまうという展開が、容易に予見されるところである。

欧州なら、もし今後オプトイン方式で実施する事業者が現れたなら、プライバシーコミッショナーが法的権限の下、第三者監査を義務付けるのではないだろうか。

この提出意見に対し、5月26日に公表された「提出された意見及びそれらに対する考え方」は、以下のように答えている。

ご指摘のとおり、DPI技術を活用した行動ターゲティング広告の実施に当たり、例えば有効な同意を得ずにパケットの解析を行う等、事業者が通信の秘密を侵害していたとしても、外部からの観察が容易でない場合があり得ます。しかしながら、通信の秘密の侵害行為には刑事罰が規定(電気通信事業法第179条)されており、一般予防の効果が期待されると考えます。

この意見に対してこの回答ということは、当該電気通信事業者の利用者への説明に1つでも事実でないことが書かれていたなら、刑事告発できるということだろうか。(そうでないとすれば回答の意味がわからない。)

それはそれで新しい展開が訪れるのかもしれない。

関連

本日のリンク元 TrackBacks(3)

最新 追記

最近のタイトル

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|
最新 追記