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

欧州議会がcookie禁止法案を来週採決」記事へのコメント

  • たとえば (スコア:1, すばらしい洞察)

    by Anonymous Coward

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

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

    • by Anonymous Coward on 2001年11月07日 9時12分 (#36183)
      JavaらないといけないならJavaに乗り換えないといけないプログラマは死ぬかもなぁ。 ていうかオイラが死にかけてんだけど。
      って、JavaはクッキーもURLも使わずに同一ユーザからの接続って認識できちゃうんですか?

      親コメント
      • Re:たとえば (スコア:2, 興味深い)

        by white (2295) <{white} {at} {niu.ne.jp}> on 2001年11月07日 10時48分 (#36212) ホームページ
        Javaだと、単にクライアント側でアプリケーションが走らせることができますから、あとは独自プロトコル over HTTPをすればOK。ユーザー識別はログイン&パスワード、セッション管理はログイン後にユニークIDを貰うようにすればいいと思います。
        親コメント
        • by G7 (3009) on 2001年11月07日 11時15分 (#36240)
          webアプリとかJavaServletの世界は勉強し始めたばかりです。間違ってたら突っ込んでくださいm(__)m>諸兄

          >Javaだと、単にクライアント側でアプリケーションが走らせることができますから、あとは独自プロト
          >コル over HTTPをすればOK。

          それでは問題解決にならないのでは?
          Cookieだけでも不安なのに更に鯖が提供する中身不明のクライアントアプリまで
          動かすことを許すんでは、却って悪いのではないかと。

          クライアントのJavaをSandboxに入れることで安全が得られる(=Applet)、というなら、
          なんてゆーかよくわかんないけど、CookieのようなものもSandboxに入れれば
          いいんじゃないのかな。
          StatefulなSessionをそれ自体が持つProtocolはそれこそ辛いだろうから、
          Stateless protocol+クライアント(=ブラウザ)に勘合符Objectを持たせる、
          っていう構図は変えなくていいかなと。
          親コメント
          • 中身不明ってことでは、ソース非公開の商用アプリだって同じですよね?

            問題なのは、ユーザーがそれと意図しないうちに、Cookieを設定し情報収集されること。要するに、disclosureが足りないってこと。
            明示的なログインを要求すれば、ユーザーへの意志確認になる。技術的にどうこう、がわからなくても、自分の意志でログインしたって点だけは明らかになる。
            だからと言ってログイン後は好き勝手していいわけじゃないけど、そういうプロセスは必要、ってことだと思います。
            親コメント
          • by Anonymous Coward
            >それでは問題解決にならないのでは?
            >Cookieだけでも不安なのに更に鯖が提供する中身不明のクライアントアプリまで
            >動かすことを許すんでは、却って悪いのではないかと。

            それこそ、オープンソースで開発すればいいのでは?
            自分では自身がないので Anonymous Coward なんですが。
            • by G7 (3009) on 2001年11月07日 13時23分 (#36291)
              >>動かすことを許すんでは、却って悪いのではないかと。
              >それこそ、オープンソースで開発すればいいのでは?

              「なにを」作れって言うんですか?
              要件を満たすものを作ることが「技術的に」可能かどうか?が問題だと思うのですが。

              まぁHTTPやTCPに替わる全然違うものを(Openで)作って解決する、という手は
              きっとまだ残されているんでしょうけど。

              >自分では自身がないので Anonymous Coward なんですが。

              関係ないだろうに…
              この世がすべて「言い出しっぺの法則」で動くのが是だとしたら、
              それはそれで窮屈で困る世の中っすよ。
              親コメント
      • by kamira (6480) on 2001年11月07日 14時00分 (#36307) ホームページ
        非常にめんどくさい方法ならありますね。
        platformはasp? cgi? php?
        aspならsessionでイケませんか?
        cgiなら、最初に環境変数を極限まで取り込んでマージしてサーバーに保存。
        後はユーザーからリクエストがあった際に比較する。
        で、商品購入等の処理が一通り終わったら情報を消去。
        ユーザー環境(OS)等を見れば、短期間で変化する事はまずありませんから
        大丈夫だと思います。
        getで送る方法もありますが、万一refferが漏れますと危険ですから
        推奨はしません。
        親コメント
        • by G7 (3009) on 2001年11月07日 15時02分 (#36325)
          >aspならsessionでイケませんか?

          そのsessionという上位概念を実現するために必要な下位概念つーか道具は何か?
          という話だったんじゃないでしょうか?
          sessionを実現するために、Cookieを使ったり、他の技術を使ったり…と。

          >cgiなら、最初に環境変数を極限まで取り込んでマージしてサーバーに保存。
          >後はユーザーからリクエストがあった際に比較する。

          クライアント側からは幾らでも捏造可能だったり、
          逆にサーバー側から見たらWinのActivation並の邪悪さだと見なされるものだったり、
          しませんかそれって?
          親コメント
          • by kamira (6480) on 2001年11月07日 17時29分 (#36351) ホームページ
            > そのsessionという上位概念を実現するために必要な下位概念つーか道具は何か?
            > という話だったんじゃないでしょうか?

            aspについてはすいませんでした。
            その通りです(^^;

            > >cgiなら、最初に環境変数を極限まで取り込んでマージしてサーバーに保存。
            > >後はユーザーからリクエストがあった際に比較する。
            > クライアント側からは幾らでも捏造可能だったり、
            > 逆にサーバー側から見たらWinのActivation並の邪悪さだと見なされるものだったり、
            > しませんかそれって?

            ええ、します。
            あくまで技術的には可能というだけのモノですね。
            特にサーバーから見ればかなりの悪です。

            ただ、現実的に考えますと環境変数から
            REMOTE_ADDR,REMOTE_HOST,HTTP_USER_AGENT,HTTP_REFERER,
            これらを適当にマージしcrypt比較したものでセッションの確認をすると仮定しますと、
            他のクライアントからリアルタイムに捏造するのは、かなり困難では?
            (パケット通信は省きます)

            勿論この方法は、サーバー上で認証をかけてDBにアクセスするようなモノでは
            危険ですので利用する事はできません。
            ただ、DBを利用しない簡易ショッピングカート(一回限りで注文内容をメールで送信)や
            ツーショットチャット等ならそれなりに利用できると思います。
            個人的には他の方の書かれていましたJava利用するなり、独自プロトコルover httpが
            良いと思います。

            というわけで、Cookieが無くなるだけでこれだけの不便と苦痛ができるワケです(笑
            利用者の側に立って、物事を考える必要がありますね。
            親コメント
      • by Anonymous Coward
        もうはるか昔の話なので嘘800かも

        アプリケーションサーバでは、
        SessionBeenを端末と結びつける機構があって、
        ある端末からのメッセージは、その端末の
        SessionBeenオブジェクトを持って通知される。

        で、その機構とは、、、、、
        • by youkan (3208) on 2001年11月07日 11時27分 (#36250) 日記
           出口のProxyは、AOLが有名ですが、たとえば、NEC、Sony、Fujitsu、Melco...
           などなど電気会社の大手は、8台前後のProxyを設置しておられます。一定時間、IPアドレスでクライアントを特定しておくというのは、無理があります。
          親コメント
        • by G7 (3009) on 2001年11月07日 11時59分 (#36262)
          >で、その機構とは、、、、、端末のIPアドレスを見る

          クライアントがDHCPな世界だと、もうアウトじゃないっすかソレ。
          いわゆるプロバイダ経由で接続することを考えると、
          そのwebアプリの対象ユーザー層次第で
          DHCPユーザーのほうが多数派になっちゃったりしますよね。

          え?その機構ってまさかJavaServlet(つーかJ2EEでEJB)な世界「一般」の話じゃ
          ないですよね?ね?ね?
          Servlet初心者なんで不安になってしまう俺。

          Servletの HttpSessionクラスの説明はここ
          あう。あのクラスが勝手に全部やってくれるんで意識してなかったなあ。
          初心者(=成果物が「まだ」無い段階)で良かったのかも。

          親コメント

アレゲは一日にしてならず -- アレゲ研究家

処理中...