欧州議会がcookie禁止法案を来週採決 58
ストーリー by koyhoge
ほんとにそんなことして大丈夫なんか 部門より
ほんとにそんなことして大丈夫なんか 部門より
IDGのレポートによると、欧州議会はHTTPで使用されるcookieを違法とするかどうかについて、11月13日に採決する模様。サイトを開いている企業が、cookieを使用することによって、本人に知られることなく個人情報を収集できるのが、プライバシーの侵害であるというのがその根拠だ。
確かにクロスサイトスクリプティング問題などによって、cookieの危険性が指摘され始めている。しかし、状態を持たないHTTPではcookie等のサポート手段がないと、Eコマースで使われるような複数ページにまたがる処理が行えないのも事実。
どうなるか成り行きが注目される。
プッツンしているだけな気も (スコア:2, 興味深い)
↑
ここがCookie送りつけてんです…。
http自体が (スコア:2, 参考になる)
http自体がセッションを意識してないのに、 cookieやらなんやらで無理矢理やってるってのが、問題ですよね。これで、80番以外のポートを利用していこう、という流れになればいいのになぁ。
けど、法で禁止まではしなくていいと思うけど。。
raspy
Re:http自体が (スコア:2, 興味深い)
#何番ポート使っても同じですよねよね？
てゆーか、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に書き戻す。
#「サイト」の単位をどう決定するか？が問題だろけど。
Re:http自体が (スコア:1)
>URLとCookieを塊にして覚えているアイコンをIEにDropしたら、そのURLにアクセスし、
>そのURLに関連づいたCookieが更新されたらそのアイコンのObjectに書き戻す。
あ。一言(?)忘れてた。上記は以下の仕組みを持ちあわせる必要があると思います。
アイコンをユーザーは自由にコピーできる必要がある。
従来のwindowsのShortCutやファイルと同様の扱いですね。
これによって、あるURLに関連づけられた「Cookieの記憶セット」を
バージョン分岐(?)させたりすることがユーザーが自由に(楽に)出来るようになる。
ブラウザのどっかに、リロードとか戻るとかのボタンと同じノリで、
「今使ってるShortCutの」Cookieを編集(忘却とか)させる、というボタンが要る。
つまりサーバーは、「1台のPCないしは1つのログイン単位」と付き合うのじゃなくて、
「1つのShortCut」と付き合うことになります。
ある長期記憶の連続性を期待したければ、その記憶を持っているShortCutを
ユーザーが明示的に手元に置いておいてそれをDblClickすればいい。
Re:http自体が (スコア:2)
状態を表現する方法を参考にすることは
できないんでしょうか。
第5世代コンピュータで何かうまい方法
出てなかったのかな。
Re:http自体が (スコア:1)
- セッションは何十分か継続させる必要がある
- 同時に何百～何千ものセッションを維持する必要がある
HTTP相当のプロトコル階層でスケーラブルにこれを維持せよというのは無理があるのでは？Re:http自体が (スコア:1)
チップIDなんてありましたね.(いつの話やねん)
Re:http自体が (スコア:1)
プロクシサーバを考慮しだしたら、地獄にはまりそう……。＞プロトコル
Javaとか、他のポート使ってたら、ほぼ確実に、グローバルIP持ってないと動かないだろうし、それじゃ使い物にならないと思うし。
国際的にも似たような要求はあるはずだと思うけど、それを満たせる物が現実の物として浮かび上がってこないのは、技術的or社会的に困難だからなんだろうか。
Re:http自体が (スコア:1)
えーっと、cookieって仕組みに甘えてきたから 今みたいな問題があるわけで。
プロトコルレベルでセッションを意識すれば、TCP の上でもうまくいくんじゃないでしょうか。
raspy
Cookieなしでセッションの維持は・・・ (スコア:2, 興味深い)
クロスサイトスクリプティングって設計をきちんとすれば防げるという認識をしているのですが、間違っているでしょうか？Cookieの問題点はクロスサイト～だけじゃないとは思いますが、無いと困るんですよね。
セッションを使用するサイトを使っていると、Cookieを使っているのか、クロスサイト～の検証はされているのか等々確かに気になります。禁止する前に(商用サイト。特に金融系に)そういう情報の表示を義務付けた方がよいのでは？
＃ただ、Cookieどーのこーのを読んでどれだけのヒトが
＃理解できるかは疑問ですが。
皆さんはセッションの維持ってどうされているのですか？？ > 開発者の方々
Re:Cookieなしでセッションの維持は・・・ (スコア:1)
あまり良い方法ではないかもしれませんが、FORMのINPUTタグにセッションIDとセッションの状態を持たせています。(もちろんhiddenで)
トップページのユーザーログインに成功した次のページからは、ログアウトまで全てFORMです。(^ ^;
LANならまだ良いのですが、インターネットに出す場合はhttpsでないと怖いなあ、とは思います。
--- Melloques Les Covdrasey ---
Re:Cookieなしでセッションの維持は・・・ (スコア:1)
>せています。(もちろんhiddenで)
ええと。それって、
* 全てがSubmitボタンになっちゃって、文字列をClickしたりすることは無くなる。
* MethodはPOSTにしとかないとSessionIDが見えちゃう(=ユーザーにURLを記録され得る)と困るんで
GETとかは使わない。
* Inputタグは必ず「どれか1つの」FORMに従属するから、
1つの入力欄を複数のSubmit先URLに関連付けることが出来ない。
場合によっては"同じ"入力項目を複数個所で表示(入力を期待)しないとならない。
って感じになるんでしたっけ？
なんか色々と面倒な雰囲気(^^;;;
余談：
IEが表示するSubmitボタンは、WindowsでいうWindowなのかな？
だとしたら、多数出したらWin9x系では動かない、とか(笑)
Re:Cookieなしでセッションの維持は・・・ (スコア:2, 興味深い)
これは、「Aタグでリンクすると、GETになっちゃうのでPOSTできない」って意味ですよね。
J(ava)Scriptを使わないという条件ですと、そうなります。(たぶん)
で、私はそうしてます。(;_;)
はい。使いません。
サーバーサイドで、GETかPOSTかをチェックして、GETの場合はエラーページを表示してます。
これも、J(ava)Scriptを使わないという条件ですと、(たぶん)そうなります。なるべく、デザイン段階で工夫する必要があります。
...この方法ですと、
など、他にもヤなことが色々ありますよね。 ですから、ここまでするニーズがない限り、あまりお勧めはできません。(^^;;
他に、何か良い方法はないもんですかね。
--- Melloques Les Covdrasey ---
Re:Cookieなしでセッションの維持は・・・ (スコア:1)
>＞付けることが出来ない。
>これも、J(ava)Scriptを使わないという条件ですと、(たぶん)そうなります。なるべく、デザイン段階
>で工夫する必要があります。
ふと思い出したんですが(つーか最初から思い出せよ俺)、
URLのアドレスの部分は変えられないけど、ボタンごとのパラメータ(正式名称覚えていません御免)を使って
次に表示すべき頁の内容を差し替える、って手は有りますね。
JavaServletだと、 引数に応じて RequestDispatcher.html#forward や同#includeあたりで
別頁(と呼ぶのが妥当かどうか疑問だが)に飛ばす/別頁を含める、っていう制御をやればいいのかな。
あるいは飛ばすまでもなくいちいち全然違う表示をレンダリングする手も有るでしょうけど。
1つのwwwアプリ(厳密な言い方じゃないが)を、
同一アドレス+SUBMITボタンのパラメータ＋forward/include、で全部まかなってしまう、
ってのは変なんでしょうか？
#あ。だんだんオフトピになってきたかも…
>・ そもそも、セッション管理を自分で作りこむ必要がある
まだ説明そこまで読んでないんですが、JavaServletって、
「セッション管理の仕掛」を自作(つまりPlugIn)できるんだったかなあ？
出来るといいなあ。
どうやると奇麗なのかなあ。うーみゅ。
Re:Cookieなしでセッションの維持は・・・ (スコア:1)
＞同一アドレス+SUBMITボタンのパラメータ＋forward/include、
＞で全部まかなってしまう、
＞ってのは変なんでしょうか？
“全部”まかなうかどうかは別にして、そういうのもアリではないかと思います。
Java/Servletに限らず、サーバー・サイド・スクリプトの類なら、forward(Location:ヘッダで実現できる)機能やinclude(レスポンス用streamに当該ファイルをwriteすればできる)機能で、同様のwwwアプリが作れると思います。
(手間は メチャメチャ かかりますけど・・・)
自作セッション管理のメリットといえば、セッションの状態管理をサーバー側で自由に行える点でしょうか。
もっとも、そのためには同一URLで、少なくとも
・同一セッションID(を示すINPUTタグ)
・セッション中の状態を表す値(を示す 以下略)
・指定されたイベントを識別する値(を示す 以下略)
くらいはリクエストヘッダとして受け取り、その後の状態管理を自力で書いたスクリプト(の先頭の方)で行う必要が有ります。
この方法ですと、「戻る」ボタンや「次へ」ボタンに振り回されることも少なくなり、便利といえば便利ですが・・・。
セッション切れ時のトランザクションの後始末等を自力で書いてると、こっちの血管が先に切れそうになります。いや、ほんと。
--- Melloques Les Covdrasey ---
Re:Cookieなしでセッションの維持は・・・ (スコア:1)
＞だとしたら、多数出したらWin9x系では動かない、とか(笑)
Windowかどうかは解りませんがWin9X系でHTML FORMのプルダウン(SELECT)を
いっぱい出すと途中からリソース不足で表示できなくなった事はありますね。
カレンダーを表示して日毎にプルダウンを表示して数ヶ月分の更新を
一度に行う様な仕様だったのを１ヶ月毎に変更した覚えがあります。
変更後の方が使いやすくなったのは怪我の功名(?笑）
重蔵。
Re:Cookieなしでセッションの維持は・・・ (スコア:1)
というのはダメ？
だってCookieオフにしてる人から、クレームきそうじゃ
ないですか？使うと。危険と言われてるから、というの
もあるけど。
使い捨てCookieなら良いような気がするけど。。。
つか、本当にCookieってやばいんですか？
Re:Cookieなしでセッションの維持は・・・ (スコア:1)
使ったことがあります。
これってブラウザが覚えてるのかな？
Re:Cookieなしでセッションの維持は・・・ (スコア:1)
IE5 が駄目なんだよなぁ。
30秒～2分間隔で Session ID をリセットしてしまうので。
IE6 でもこの辺は一緒なのかな。
i-modeでもそうなんだけど (スコア:2, 参考になる)
--------------------
/* SHADOWFIRE */
Re:i-modeでもそうなんだけど (スコア:1)
Re:i-modeでもそうなんだけど (スコア:1)
しかしどうしてiモード端末はcookieをサポートしてくれないのかなあ。メモリが限られているにせよ、限られたcookie機能（セッション限りだけとか）なら実現可能だと思うのだが。
他方、JavaScriptは、必要でなくかつ危ないので、実装しないで欲しいのだが。
CookieなしのWebアプリケーション？ (スコア:1, 興味深い)
CookieなしだとURL Rewriting...？
そんなんで、Webアプリを書けっていわれるとぞっとするね。
Re:CookieなしのWebアプリケーション？ (スコア:3, 参考になる)
参照： INTERNET Watch: 電子技術総合研究所がフリーメールサイト7社のセキュリティホールを指摘
たとえば (スコア:1, すばらしい洞察)
cookieそのものを禁止されたとして、ますますJavaとかの利用に拍車がかかるかも知れませんね。
それはそれでまた、面白い話かもしれないし、ビジネスチャンスとも見える。
Re:たとえば (スコア:2)
それを見越してのWinXPアクティベーションだったのかもしれませんね。
Re:たとえば (スコア:2, 興味深い)
Re:たとえば (スコア:1)
>Javaだと、単にクライアント側でアプリケーションが走らせることができますから、あとは独自プロト
>コル over HTTPをすればOK。
それでは問題解決にならないのでは？
Cookieだけでも不安なのに更に鯖が提供する中身不明のクライアントアプリまで
動かすことを許すんでは、却って悪いのではないかと。
クライアントのJavaをSandboxに入れることで安全が得られる(=Applet)、というなら、
なんてゆーかよくわかんないけど、CookieのようなものもSandboxに入れれば
いいんじゃないのかな。
StatefulなSessionをそれ自体が持つProtocolはそれこそ辛いだろうから、
Stateless protocol＋クライアント(=ブラウザ)に勘合符Objectを持たせる、
っていう構図は変えなくていいかなと。
確認の必要性 (スコア:1)
問題なのは、ユーザーがそれと意図しないうちに、Cookieを設定し情報収集されること。要するに、disclosureが足りないってこと。
明示的なログインを要求すれば、ユーザーへの意志確認になる。技術的にどうこう、がわからなくても、自分の意志でログインしたって点だけは明らかになる。
だからと言ってログイン後は好き勝手していいわけじゃないけど、そういうプロセスは必要、ってことだと思います。
Re:たとえば (スコア:1)
>それこそ、オープンソースで開発すればいいのでは？
「なにを」作れって言うんですか？
要件を満たすものを作ることが「技術的に」可能かどうか？が問題だと思うのですが。
まぁHTTPやTCPに替わる全然違うものを(Openで)作って解決する、という手は
きっとまだ残されているんでしょうけど。
>自分では自身がないので Anonymous Coward なんですが。
関係ないだろうに…
この世がすべて「言い出しっぺの法則」で動くのが是だとしたら、
それはそれで窮屈で困る世の中っすよ。
Re:たとえば (スコア:1)
platformはasp? cgi? php?
aspならsessionでイケませんか？
cgiなら、最初に環境変数を極限まで取り込んでマージしてサーバーに保存。
後はユーザーからリクエストがあった際に比較する。
で、商品購入等の処理が一通り終わったら情報を消去。
ユーザー環境(OS)等を見れば、短期間で変化する事はまずありませんから
大丈夫だと思います。
getで送る方法もありますが、万一refferが漏れますと危険ですから
推奨はしません。
Re:たとえば (スコア:1)
そのsessionという上位概念を実現するために必要な下位概念つーか道具は何か？
という話だったんじゃないでしょうか？
sessionを実現するために、Cookieを使ったり、他の技術を使ったり…と。
>cgiなら、最初に環境変数を極限まで取り込んでマージしてサーバーに保存。
>後はユーザーからリクエストがあった際に比較する。
クライアント側からは幾らでも捏造可能だったり、
逆にサーバー側から見たらWinのActivation並の邪悪さだと見なされるものだったり、
しませんかそれって？
Re:たとえば (スコア:1)
> という話だったんじゃないでしょうか？
aspについてはすいませんでした。
その通りです(^^;
> >cgiなら、最初に環境変数を極限まで取り込んでマージしてサーバーに保存。
> >後はユーザーからリクエストがあった際に比較する。
> クライアント側からは幾らでも捏造可能だったり、
> 逆にサーバー側から見たらWinのActivation並の邪悪さだと見なされるものだったり、
> しませんかそれって？
ええ、します。
あくまで技術的には可能というだけのモノですね。
特にサーバーから見ればかなりの悪です。
ただ、現実的に考えますと環境変数から
REMOTE_ADDR,REMOTE_HOST,HTTP_USER_AGENT,HTTP_REFERER,
これらを適当にマージしcrypt比較したものでセッションの確認をすると仮定しますと、
他のクライアントからリアルタイムに捏造するのは、かなり困難では？
(パケット通信は省きます)
勿論この方法は、サーバー上で認証をかけてDBにアクセスするようなモノでは
危険ですので利用する事はできません。
ただ、DBを利用しない簡易ショッピングカート(一回限りで注文内容をメールで送信)や
ツーショットチャット等ならそれなりに利用できると思います。
個人的には他の方の書かれていましたJava利用するなり、独自プロトコルover httpが
良いと思います。
というわけで、Cookieが無くなるだけでこれだけの不便と苦痛ができるワケです(笑
利用者の側に立って、物事を考える必要がありますね。
Re:たとえば (スコア:2)
などなど電気会社の大手は、8台前後のProxyを設置しておられます。一定時間、IPアドレスでクライアントを特定しておくというのは、無理があります。
Re:たとえば (スコア:1)
クライアントがDHCPな世界だと、もうアウトじゃないっすかソレ。
いわゆるプロバイダ経由で接続することを考えると、
そのwebアプリの対象ユーザー層次第で
DHCPユーザーのほうが多数派になっちゃったりしますよね。
え？その機構ってまさかJavaServlet(つーかJ2EEでEJB)な世界「一般」の話じゃ
ないですよね？ね？ね？
Servlet初心者なんで不安になってしまう俺。
Servletの HttpSessionクラスの説明はここ。
あう。あのクラスが勝手に全部やってくれるんで意識してなかったなあ。
初心者(=成果物が「まだ」無い段階)で良かったのかも。
IDGのレポートを読む限り (スコア:1)
ちゃんとユーザーに情報を提供し、自発的な同意が得られれば使う事も出来るとなってますね。
どういう文面であれば十分な情報提供になるのか、またどういう形であれば自発的な同意と見なされるかという件については専門外なのでわかりませんが、普通のサイトであれば技術的に問題に問題になる事はあまりないような気もします。
ブラウザのデフォルトを変えればいいのでは (スコア:2)
クッキーの存在が悪いのではなく、一般ユーザはデフォルト値しかつかわんのだから、そこがセキュリティホールにならないようにしてほしいのです。クッキーだけじゃなく、JAVAスクリプト等も同様。
機能制限に関するブラウザの対応状況
Re:ブラウザのデフォルトを変えればいいのでは (スコア:4, 参考になる)
Mozilla は GUI が用意されていないだけで、JavaScript はかなり細かく制御可能です。複雑すぎて、現段階ではいい UI を設計できていないから実装できない、という状態かと思います。1.0 までに UI ができるといいですね。
Mozilla では、サーバレベルでポリシーを任意の数だけ定義し、ポリシーレベルで JavaScript の利用可否を選択できます。制御可能なレベルはメソッド/プロパティ単位。window.open() だけ禁止、なんてのも可能です。そもそも Window オブジェクトへのアクセスを全部止める、というのも簡単にできます。
標準では JavaScript を off にし、信頼できるサイトに使っても良いメソッドやプロパティへの参照を許可する、という形にするのが一番でしょう。
うざい機能だけ殺す辺りだけが説明してありますが、この辺りは特に詳しい文書が無いので良くわかりませんが、(あまり試していませんが) 実装されているもの全てが制御可能と思われます。
REFERERもさあ (スコア:2)
プライバシーの侵害度ではクッキーに負けず大きい。
Re:REFERERもさあ (スコア:1)
本当に必要なんでしょうか？
クッキーは便利なところもいっぱいあるから仕方ないか、
と妥協してるけどrefererはユーザにとって便利なこと
あんまりないしなぁ。
Re:REFERERもさあ (スコア:1)
Mozillaだとrefererを送らない設定があるんですね。
きちんと調べてから書くんだった。
user_pref("network.http.sendRefererHeader", 0);
で全く送らないそうです。
しかしmozillaはゾーンによりポリシーの規定とか細かくできる
みたいだし、もしやサイト毎によるrefererの制限も
できちゃったりするんでしょうか。
ちなみにrefererの設定は
http://www.alib.jp/mozilla/maniac.html
を参考にさせていただきました。
Re:REFERERもさあ (スコア:1)
というメリットはいちおうあるにはあります。（もっとも、REFERERを送ってこないブラウザの可能性を想定すると使い物になりませんが。）
新しい時代を迎えよう (スコア:1)
確かに現在は cookie に頼らざるを得ないが、ソレは Web上でのサービス開発者にとって、とてつもない苦痛でもある。
トランザクションとかも必要なこのご時世に、いまだ前時代の手法で、クライアント側の処理にブラウザのHTMLな機能のみを使ってる事が問題なのでは無いだろうか。
(今ちょっと無駄に思える)ギガヘルツプロセッサとかブローバンドとを活かして、クライアント側が平然とJavaアプリケーションを使うようになれば cookieに頼らなくてもいいし、開発側ももっと楽に(自由に?)なるはずだ。
(と思うのだが、私はアンマシ Javaの世界に詳しく無いのよ。どーなの?)
masashi
Re:新しい時代を迎えよう (スコア:1)
>のHTMLな機能のみを使ってる事が問題なのでは無いだろうか。
逆に、いちいち毎回wwwサイトごとの独自クライアントソフトを与えてあげないと
満足に動くwwwアプリも構築できないという、低機能なブラウザ(つーかhtml&http)しか無い、
ってのを寒いと捉えることも出来るかと。
クッキー・ファイルを禁止 (スコア:1)
「セッションごとのCookie(保存なし)」
はいいんじゃないんですかねえ。
IE 6 ではそういう概念は消滅した模様ですが。
Re:クッキー・ファイルを禁止 (スコア:1)
[詳細設定]で設定できませんか？
もっとも、そうしなければ触れない設定であることとか、
ほかの変えたくない設定まで細かく指定しなければいけない、
とかを指摘されているのかもしれませんが．．．
Treason, like beauty, is in the eye of the beholder.
なにかあると禁止！ (スコア:1, すばらしい洞察)
Re:なにかあると禁止！ (スコア:2, すばらしい洞察)
現在以上に cookie という技術が普及するとなおのこと
禁止にしにくくなると思うのでこの動き自体は（私が思うに）望ましいことといえるなぁ…と。
Windows が普及しすぎたので、なにか問題があってもあまり知識の無い一般ユーザが乗り換える器が無いという現状
に重ねて考えてしまいます…。
結局 Cookie がアレゲだという事実は否めないですし。
そんなことを (スコア:1)
それに、これって適用範囲は欧州内のみなのでは?
# それによって他にも広がりを見せるかどうかは見所かもしれないですが
ところでとは書かれてますが、個人もやっぱ対象になるんですかね。
Re:so long http (スコア:2)
トランザクションが必要だといっているのに、SOAPみたいな、どうするんだというような約束事をつくり出したりするし。
#もう、誰も読んでいないか。。。