パスワードを忘れた? アカウント作成
1483 story

欧州議会がcookie禁止法案を来週採決 58

ストーリー by koyhoge
ほんとにそんなことして大丈夫なんか 部門より

IDGのレポートによると、欧州議会はHTTPで使用されるcookieを違法とするかどうかについて、11月13日に採決する模様。サイトを開いている企業が、cookieを使用することによって、本人に知られることなく個人情報を収集できるのが、プライバシーの侵害であるというのがその根拠だ。

確かにクロスサイトスクリプティング問題などによって、cookieの危険性が指摘され始めている。しかし、状態を持たないHTTPではcookie等のサポート手段がないと、Eコマースで使われるような複数ページにまたがる処理が行えないのも事実。

どうなるか成り行きが注目される。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by naka64 (4590) on 2001年11月07日 6時41分 (#36156) 日記
    自分ちの事情もご存じないらしい。

    ここがCookie送りつけてんです…。
  • http自体が (スコア:2, 参考になる)

    by raspy (3714) on 2001年11月07日 9時20分 (#36186) ホームページ

    http自体がセッションを意識してないのに、 cookieやらなんやらで無理矢理やってるってのが、問題ですよね。これで、80番以外のポートを利用していこう、という流れになればいいのになぁ。

    けど、法で禁止まではしなくていいと思うけど。。

    --
    raspy
    • Re:http自体が (スコア:2, 興味深い)

      by G7 (3009) on 2001年11月07日 12時01分 (#36264)
      >http自体がセッションを意識してないのに、 cookieやらなんやらで無理矢理やってるってのが、問題ですよね。

      #何番ポート使っても同じですよねよね?

      てゆーか、Object指向的(笑)に言えば、
      メソッド呼び出しのチェーンだけでなんでもやろうとすると場合によっては無茶なんで、
      Commandオブジェクトをキューに覚えておいてもらって後でCommandをリプレイする、という構図は
      よく使うわけですよね。ここでいうキューの役割はwwwブラウザが果たすわけです。勘合符。

      プライバシだかなんだかを考慮した次世代Cookie仕様を作る、くらいが
      落とし所じゃないんでしょうか?
      それが原理的に無理だとすると、逆にいえば
      疎結合(チェーンを使わず勘合符Objectを使う)の不特定多数ユーザー向けリモートアプリは
      全部無理ってことになる、だけっすかね。

      ーーーー
      ところで更にOOP的に考える(ぉぃ)と、
      なんでユーザー側にはブラウザという「唯一の」Objectしか与えられていないの?
      という疑問も、生じます。
      これが複数有れば、そのうちの1つが「汚染」されても、それを捨てるなり
      他の新鮮な奴に交換するなり、すれば良いだけ。
      複数のブラウザをPCにInstallしといて、Cookie「を」使い分けるためにブラウザを使い分ける、
      ってこと、しませんか?
      俺も時折スラドをアクセスするために(笑)やります。AC書き込みは(何故か)してないけど。
      #てゆーかスラドのためにw3mをCookieつきでmakeし直した(笑)

      MSIE風に喩えて言うならば、InternetShortcut「に」Cookieが記録される、という形で、
      ユーザーがワンタッチで「サイトへのアクセス」の単位という「Object」を使えるように
      すりゃいいのかなーと。
      素でIEのアプリアイコンを叩いて起動したら何もCookieを覚えていない状態で起動する。
      URLとCookieを塊にして覚えているアイコンをIEにDropしたら、そのURLにアクセスし、
      そのURLに関連づいたCookieが更新されたらそのアイコンのObjectに書き戻す。
      #「サイト」の単位をどう決定するか?が問題だろけど。

      親コメント
      • by G7 (3009) on 2001年11月07日 15時10分 (#36326)
        >素でIEのアプリアイコンを叩いて起動したら何もCookieを覚えていない状態で起動する。
        >URLとCookieを塊にして覚えているアイコンをIEにDropしたら、そのURLにアクセスし、
        >そのURLに関連づいたCookieが更新されたらそのアイコンのObjectに書き戻す。

        あ。一言(?)忘れてた。上記は以下の仕組みを持ちあわせる必要があると思います。

        アイコンをユーザーは自由にコピーできる必要がある。
        従来のwindowsのShortCutやファイルと同様の扱いですね。
        これによって、あるURLに関連づけられた「Cookieの記憶セット」を
        バージョン分岐(?)させたりすることがユーザーが自由に(楽に)出来るようになる。

        ブラウザのどっかに、リロードとか戻るとかのボタンと同じノリで、
        「今使ってるShortCutの」Cookieを編集(忘却とか)させる、というボタンが要る。

        つまりサーバーは、「1台のPCないしは1つのログイン単位」と付き合うのじゃなくて、
        「1つのShortCut」と付き合うことになります。
        ある長期記憶の連続性を期待したければ、その記憶を持っているShortCutを
        ユーザーが明示的に手元に置いておいてそれをDblClickすればいい。

        親コメント
    • by hidetosi (3049) on 2001年11月07日 23時45分 (#36421)
      関数型言語や論理型言語で
      状態を表現する方法を参考にすることは
      できないんでしょうか。

      第5世代コンピュータで何かうまい方法
      出てなかったのかな。
      親コメント
    • by jbeef (1278) on 2001年11月07日 9時34分 (#36189) 日記
      でも、どういうプロトコルがありえますか?
      • セッションは何十分か継続させる必要がある
      • 同時に何百~何千ものセッションを維持する必要がある
      HTTP相当のプロトコル階層でスケーラブルにこれを維持せよというのは無理があるのでは?
      親コメント
      • でも、どういうプロトコルがありえますか?

        チップIDなんてありましたね.(いつの話やねん)
        親コメント
      • by tomatsu (2545) on 2001年11月07日 12時19分 (#36271)

        プロクシサーバを考慮しだしたら、地獄にはまりそう……。>プロトコル

        Javaとか、他のポート使ってたら、ほぼ確実に、グローバルIP持ってないと動かないだろうし、それじゃ使い物にならないと思うし。

        国際的にも似たような要求はあるはずだと思うけど、それを満たせる物が現実の物として浮かび上がってこないのは、技術的or社会的に困難だからなんだろうか。

        親コメント
      • by raspy (3714) on 2001年11月07日 15時22分 (#36327) ホームページ

        えーっと、cookieって仕組みに甘えてきたから 今みたいな問題があるわけで。

        プロトコルレベルでセッションを意識すれば、TCP の上でもうまくいくんじゃないでしょうか。

        --
        raspy
        親コメント
  • by atrib (5512) on 2001年11月07日 9時26分 (#36188)
    Webアプリケーションを業務で開発している者なのですが、セッションを維持するのにCookieを使ってはいけない、と言われると非常に困りますね。Cookie禁止が設定されている場合を想定してURL Rewritingも使用できるようにはしてあるんですけど、REFERERで漏れる可能性があるし。

    クロスサイトスクリプティングって設計をきちんとすれば防げるという認識をしているのですが、間違っているでしょうか?Cookieの問題点はクロスサイト~だけじゃないとは思いますが、無いと困るんですよね。

    セッションを使用するサイトを使っていると、Cookieを使っているのか、クロスサイト~の検証はされているのか等々確かに気になります。禁止する前に(商用サイト。特に金融系に)そういう情報の表示を義務付けた方がよいのでは?

    #ただ、Cookieどーのこーのを読んでどれだけのヒトが
    #理解できるかは疑問ですが。

    皆さんはセッションの維持ってどうされているのですか?? > 開発者の方々
    •  あまり良い方法ではないかもしれませんが、FORMのINPUTタグにセッションIDとセッションの状態を持たせています。(もちろんhiddenで)

       トップページのユーザーログインに成功した次のページからは、ログアウトまで全てFORMです。(^ ^;

       LANならまだ良いのですが、インターネットに出す場合はhttpsでないと怖いなあ、とは思います。

      --
        --- Melloques Les Covdrasey ---
      親コメント
      • >FORMのINPUTタグにセッションIDとセッションの状態を持た
        >せています。(もちろんhiddenで)

        ええと。それって、

          * 全てがSubmitボタンになっちゃって、文字列をClickしたりすることは無くなる。
          * MethodはPOSTにしとかないとSessionIDが見えちゃう(=ユーザーにURLを記録され得る)と困るんで
              GETとかは使わない。
          * Inputタグは必ず「どれか1つの」FORMに従属するから、
              1つの入力欄を複数のSubmit先URLに関連付けることが出来ない。
              場合によっては"同じ"入力項目を複数個所で表示(入力を期待)しないとならない。

        って感じになるんでしたっけ?

        なんか色々と面倒な雰囲気(^^;;;

        余談:
        IEが表示するSubmitボタンは、WindowsでいうWindowなのかな?
        だとしたら、多数出したらWin9x系では動かない、とか(笑)
        親コメント
        • >* 全てがSubmitボタンになっちゃって、文字列をClickしたりすることは無くなる。

           これは、「Aタグでリンクすると、GETになっちゃうのでPOSTできない」って意味ですよね。

           J(ava)Scriptを使わないという条件ですと、そうなります。(たぶん)

           で、私はそうしてます。(;_;)

          >* MethodはPOSTにしとかないとSessionIDが見えちゃう(=ユーザーにURLを記録され得る)と困るんでGETとかは使わない。

           はい。使いません。

           サーバーサイドで、GETかPOSTかをチェックして、GETの場合はエラーページを表示してます。

          >* Inputタグは必ず「どれか1つの」FORMに従属するから、1つの入力欄を複数のSubmit先URLに関連付けることが出来ない。
          場合によっては"同じ"入力項目を複数個所で表示(入力を期待)しないとならない。

           これも、J(ava)Scriptを使わないという条件ですと、(たぶん)そうなります。なるべく、デザイン段階で工夫する必要があります。

           ...この方法ですと、

          • GETで表示する(静的な)ページは別ウィンドウ(かフレーム)で開く必要がある
          • そもそも、セッション管理を自分で作りこむ必要がある

          など、他にもヤなことが色々ありますよね。 ですから、ここまでするニーズがない限り、あまりお勧めはできません。(^^;;

           他に、何か良い方法はないもんですかね。

          --
            --- Melloques Les Covdrasey ---
          親コメント
          • >>* Inputタグは必ず「どれか1つの」FORMに従属するから、1つの入力欄を複数のSubmit先URLに関連
            >>付けることが出来ない。
            >これも、J(ava)Scriptを使わないという条件ですと、(たぶん)そうなります。なるべく、デザイン段階
            >で工夫する必要があります。

            ふと思い出したんですが(つーか最初から思い出せよ俺)、
            URLのアドレスの部分は変えられないけど、ボタンごとのパラメータ(正式名称覚えていません御免)を使って
            次に表示すべき頁の内容を差し替える、って手は有りますね。

            JavaServletだと、 引数に応じて RequestDispatcher.html#forward や同#includeあたりで
            別頁(と呼ぶのが妥当かどうか疑問だが)に飛ばす/別頁を含める、っていう制御をやればいいのかな。
            あるいは飛ばすまでもなくいちいち全然違う表示をレンダリングする手も有るでしょうけど。

            1つのwwwアプリ(厳密な言い方じゃないが)を、
            同一アドレス+SUBMITボタンのパラメータ+forward/include、で全部まかなってしまう、
            ってのは変なんでしょうか?

            #あ。だんだんオフトピになってきたかも…

            >・ そもそも、セッション管理を自分で作りこむ必要がある

            まだ説明そこまで読んでないんですが、JavaServletって、
            「セッション管理の仕掛」を自作(つまりPlugIn)できるんだったかなあ?
            出来るといいなあ。

            どうやると奇麗なのかなあ。うーみゅ。
            親コメント
            • >1つのwwwアプリ(厳密な言い方じゃないが)を、
              >同一アドレス+SUBMITボタンのパラメータ+forward/include、
              >で全部まかなってしまう、
              >ってのは変なんでしょうか?

               “全部”まかなうかどうかは別にして、そういうのもアリではないかと思います。

               Java/Servletに限らず、サーバー・サイド・スクリプトの類なら、forward(Location:ヘッダで実現できる)機能やinclude(レスポンス用streamに当該ファイルをwriteすればできる)機能で、同様のwwwアプリが作れると思います。
               (手間は メチャメチャ かかりますけど・・・)

               自作セッション管理のメリットといえば、セッションの状態管理をサーバー側で自由に行える点でしょうか。

               もっとも、そのためには同一URLで、少なくとも
                ・同一セッションID(を示すINPUTタグ)
                ・セッション中の状態を表す値(を示す 以下略)
                ・指定されたイベントを識別する値(を示す 以下略)
              くらいはリクエストヘッダとして受け取り、その後の状態管理を自力で書いたスクリプト(の先頭の方)で行う必要が有ります。

               この方法ですと、「戻る」ボタンや「次へ」ボタンに振り回されることも少なくなり、便利といえば便利ですが・・・。

               セッション切れ時のトランザクションの後始末等を自力で書いてると、こっちの血管が先に切れそうになります。いや、ほんと。
              --
                --- Melloques Les Covdrasey ---
              親コメント
        • >IEが表示するSubmitボタンは、WindowsでいうWindowなのかな?
          >だとしたら、多数出したらWin9x系では動かない、とか(笑)

           Windowかどうかは解りませんがWin9X系でHTML FORMのプルダウン(SELECT)を
           いっぱい出すと途中からリソース不足で表示できなくなった事はありますね。

           カレンダーを表示して日毎にプルダウンを表示して数ヶ月分の更新を
           一度に行う様な仕様だったのを1ヶ月毎に変更した覚えがあります。
           変更後の方が使いやすくなったのは怪我の功名(?笑)

           重蔵。
          親コメント
    • CookieなしでPOSTメソッド使ってる。
      というのはダメ?

      だってCookieオフにしてる人から、クレームきそうじゃ
      ないですか?使うと。危険と言われてるから、というの
      もあるけど。

      使い捨てCookieなら良いような気がするけど。。。

      つか、本当にCookieってやばいんですか?
      親コメント
    • basic認証後環境変数で取れるLOGINを
      使ったことがあります。
      これってブラウザが覚えてるのかな?
      親コメント
    • SSL Session ID とか使えそうなんだけど、
      IE5 が駄目なんだよなぁ。
      30秒~2分間隔で Session ID をリセットしてしまうので。

      IE6 でもこの辺は一緒なのかな。
      親コメント
  • by shadowfire (6584) on 2001年11月07日 10時50分 (#36214) ホームページ
    Servlet/JSPで仕事してますけど、禁止されると セッション保持の面でサイト作るのが面倒ですよね。 でもi-modeでもCookie使えないので、i-mode対応 のサーバアプリケーション作ってる私としては これでCookie以外の手段が出てくればいいなあ、 と思ってます。 けどstatelessなhttpではどうしてもクライアントの 側で何らかの情報持ってくれないと識別できない のが鬱。
    --
    --------------------
    /* SHADOWFIRE */
  • by Anonymous Coward on 2001年11月07日 4時10分 (#36145)
    昨今のECサイトでCookieなしのWebアプリなんて、ほとんど考えられないと思うんだけど、たとえば、セッション用の一時的なCookieなども含まれるのでしょうか?
    CookieなしだとURL Rewriting...?
    そんなんで、Webアプリを書けっていわれるとぞっとするね。
  • たとえば (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2001年11月07日 7時08分 (#36160)

    cookieそのものを禁止されたとして、ますますJavaとかの利用に拍車がかかるかも知れませんね。

    それはそれでまた、面白い話かもしれないし、ビジネスチャンスとも見える。

    • それを見越してのWinXPアクティベーションだったのかもしれませんね。

      親コメント
  • ちゃんとユーザーに情報を提供し、自発的な同意が得られれば使う事も出来るとなってますね。

    どういう文面であれば十分な情報提供になるのか、またどういう形であれば自発的な同意と見なされるかという件については専門外なのでわかりませんが、普通のサイトであれば技術的に問題に問題になる事はあまりないような気もします。

    • デフォルトだと「クッキーはなんでも無条件に受け入れる」になっていますが、これをデフォルト「受け付けない」にし、サイト毎に肌理細かく制御するように仕様を変えればいいのではないでしょうか。現状でもある程度制限できますけど、デフォルトがスカスカなので被害が発生しやすいのではないかと。

      クッキーの存在が悪いのではなく、一般ユーザはデフォルト値しかつかわんのだから、そこがセキュリティホールにならないようにしてほしいのです。クッキーだけじゃなく、JAVAスクリプト等も同様。

      機能制限に関するブラウザの対応状況

      • MSIE5.5=「インターネット(デフォルト)」「信頼済み」「制限付き」に分類することでそれぞれの分類の中では細かい制御が可能。
      • Mozilla系=クッキーの受け入れ可否をサーバごとに設定できる。クッキー以外については可否を制御できない。JAVAスクの可否制御がないのは特に悲しい。
      親コメント
      • Mozilla は GUI が用意されていないだけで、JavaScript はかなり細かく制御可能です。複雑すぎて、現段階ではいい UI を設計できていないから実装できない、という状態かと思います。1.0 までに UI ができるといいですね。

        Mozilla では、サーバレベルでポリシーを任意の数だけ定義し、ポリシーレベルで JavaScript の利用可否を選択できます。制御可能なレベルはメソッド/プロパティ単位。window.open() だけ禁止、なんてのも可能です。そもそも Window オブジェクトへのアクセスを全部止める、というのも簡単にできます。

        標準では JavaScript を off にし、信頼できるサイトに使っても良いメソッドやプロパティへの参照を許可する、という形にするのが一番でしょう。

        うざい機能だけ殺す辺りだけが説明してありますが、この辺りは特に詳しい文書が無いので良くわかりませんが、(あまり試していませんが) 実装されているもの全てが制御可能と思われます。

        親コメント
    • 出す、出さないとサイト毎に制御できると良いよね。
      プライバシーの侵害度ではクッキーに負けず大きい。
      親コメント
      • 自分はcookieよりrefererの方がプライバシー気になります。
        本当に必要なんでしょうか?

        クッキーは便利なところもいっぱいあるから仕方ないか、
        と妥協してるけどrefererはユーザにとって便利なこと
        あんまりないしなぁ。
        親コメント
        • う、ごめんなさい。
          Mozillaだとrefererを送らない設定があるんですね。
          きちんと調べてから書くんだった。
          user_pref("network.http.sendRefererHeader", 0);
          で全く送らないそうです。

          しかしmozillaはゾーンによりポリシーの規定とか細かくできる
          みたいだし、もしやサイト毎によるrefererの制限も
          できちゃったりするんでしょうか。

          ちなみにrefererの設定は
          http://www.alib.jp/mozilla/maniac.html
          を参考にさせていただきました。
          親コメント
        • by jbeef (1278) on 2001年11月07日 17時13分 (#36346) 日記
          サイト側がREFERERを活用して、自サイトからのリンクを辿ってきたアクセスしか許可しないように作りこまれている場合、クロスサイトスクリプティング攻撃を防げる。

          というメリットはいちおうあるにはあります。(もっとも、REFERERを送ってこないブラウザの可能性を想定すると使い物になりませんが。)

          親コメント
  • by masashi (569) on 2001年11月07日 10時52分 (#36216) 日記
    クライアント側も Java使えとゆー事では?
    確かに現在は cookie に頼らざるを得ないが、ソレは Web上でのサービス開発者にとって、とてつもない苦痛でもある。
    トランザクションとかも必要なこのご時世に、いまだ前時代の手法で、クライアント側の処理にブラウザのHTMLな機能のみを使ってる事が問題なのでは無いだろうか。
    (今ちょっと無駄に思える)ギガヘルツプロセッサとかブローバンドとを活かして、クライアント側が平然とJavaアプリケーションを使うようになれば cookieに頼らなくてもいいし、開発側ももっと楽に(自由に?)なるはずだ。

    (と思うのだが、私はアンマシ Javaの世界に詳しく無いのよ。どーなの?)
    --
    masashi
    • by G7 (3009) on 2001年11月07日 13時18分 (#36290)
      >トランザクションとかも必要なこのご時世に、いまだ前時代の手法で、クライアント側の処理にブラウザ
      >のHTMLな機能のみを使ってる事が問題なのでは無いだろうか。

      逆に、いちいち毎回wwwサイトごとの独自クライアントソフトを与えてあげないと
      満足に動くwwwアプリも構築できないという、低機能なブラウザ(つーかhtml&http)しか無い、
      ってのを寒いと捉えることも出来るかと。
      親コメント
  • と記事では言っているので、IE 5.5 以前で言うところの

    「セッションごとのCookie(保存なし)」

    はいいんじゃないんですかねえ。

    IE 6 ではそういう概念は消滅した模様ですが。
    • [インターネット・オプション]の[セキュリティ]タブにある
      [詳細設定]で設定できませんか?

      もっとも、そうしなければ触れない設定であることとか、
      ほかの変えたくない設定まで細かく指定しなければいけない、
      とかを指摘されているのかもしれませんが...
      --
      Treason, like beauty, is in the eye of the beholder.
      親コメント
  • なにかあると禁止! (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2001年11月07日 15時35分 (#36331)
    禁止にすることよりも、まず、 Cockieに変わるものを考えてから、 禁止にすべきですね。 難しい問題ですが、禁止にすることで、 困る人の方が多いように感じます。
    • Re:なにかあると禁止! (スコア:2, すばらしい洞察)

      by lovely_kitayama (5922) on 2001年11月07日 17時34分 (#36352) ホームページ 日記
      う~ん…一概には言えませんが、禁止にすることで困る人もいますが、禁止になっていないので困る人たちもいる、と。このような動きがあるということはその一端と言えますよね。

      現在以上に cookie という技術が普及するとなおのこと
      禁止にしにくくなると思うのでこの動き自体は(私が思うに)望ましいことといえるなぁ…と。

      Windows が普及しすぎたので、なにか問題があってもあまり知識の無い一般ユーザが乗り換える器が無いという現状
      に重ねて考えてしまいます…。

      結局 Cookie がアレゲだという事実は否めないですし。
      親コメント
  • by tanji (6368) on 2001年11月07日 18時34分 (#36371) ホームページ
    欧州議会で採決されてもなぁ。技術的なことを知らない人に採決されるってのがまた。
    それに、これって適用範囲は欧州内のみなのでは?
    # それによって他にも広がりを見せるかどうかは見所かもしれないですが

    ところで
    企業によるクッキーの利用は個人のプライバシーの侵害であり、ヨーロッパ人権/基本的自由条約の下での人権侵害に当たるとされている
    とは書かれてますが、個人もやっぱ対象になるんですかね。
typodupeerror

※ただしPHPを除く -- あるAdmin

読み込み中...