アカウント名:
パスワード:
悪用を防止できるのが最善なのでしょうが、visited疑似クラスのビーコンを拾うサービスが登場 [bakera.jp]を読んでも、悪用を防止するという観点での対応は困難であるように思います。
であれば、むしろ、History の制御機能を増やすべきように思います。cookie の制御機能に倣うと、たとえば
といった機能を用意し、あとはユーザの判断に委ねるのが次善策のように思います。上記が実現すれば、少なくとも、エロサイトへの訪問履歴が洩れて……といった事態は防止できる (ような設定が可能になる) ように思います。ぐぐってみたら、HistoryBlock [mozilla.org] というものもあるそうで。
なお、個人的には、さきほど History の保存期間を 0 に設定しました。
Bugzillaでvulnerabilityとして扱われているんだからバグそのもの。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
どうにも (スコア:4, すばらしい洞察)
無効化手順も準備していたようだ (スコア:4, 参考になる)
行動ターゲティング広告の説明とその無効化について [rakuten.co.jp]というページへの
リンクがありました。
> 本サービスの無効化をご希望される方は、
> お手数ですが以下の手順に従い無効化してください。
> なお、本サービスはクッキーの設定が「オフ」になっている
> お客様には提供されておりませんのでご注意下さい。
だそうですので「無効化をする」というフラグを Cookie に書いておいて、
広告表示の際にそのフラグを見に行く、という仕組みらしい。
とりあえず無効化の手段も用意しましたよ、問題ある？ といったところでしょうか。
こんなものに気付く人はほとんどいないわけで、ややせこい感じは否めません。
正直 (スコア:3, 興味深い)
関係ない広告よりは興味ある広告の方がマシだし。
職場でエロ広告さえ表示されなければな。
Re:正直 (スコア:1)
それにプライバシーの範囲にしても、精神的や社会的な被害を受けるレベルでなければ侵害されてもいいよ。スパムメールが送られてくるとかは嫌だけど、どこどこでどんなエロ動画を落とした、くらいのレベルまでなら
気になるあの子知人に知られても平気さ。俯瞰しよう。何事も俯瞰しなくちゃ駄目だ。
Re:正直 (スコア:1)
でも他サイトの閲覧履歴を握られるのは嫌だなー。
#Amazonがユーザの閲覧履歴を他に提供する、のも嫌。
やってみました (スコア:3, 参考になる)
で、そこそこ程度の性能のデスクトップマシンで1時間ほど総当たりをぶん回すと、最近見たニコ動リストが完成しました。 その間CPUコアの内1個が使用率100%で振り切ったままでしたから、ここままだと目立ちすぎてこっそり使うのは無理そうですが。 ある程度探索するターゲットを絞った上で、 滞留時間の長いミニゲームやらの裏あたりでこそっと回せば、楽しいマーケティング情報が集められそうです。 ミニゲームの動作でCPU負荷をごまかせますし。
ユーザ側でガードするのは、最初に試しやすいと書いたのと同じ理由で外から挙動を観察する方法では難しそうです。 やるとしたら、ウィルスチェッカ辺りが割り込んで、極端にリンク数が多い、もしくは、リンク先が頻繁に書き換わるのを検出するぐらいでしょうか?
Re:御約束 (スコア:1)
例えば、amazonさんはクエリに余分な物が付いてても無視してくれるようなので、
http://amazon/hogehoge?foo=bar
が見たいときに、
http://amazon/hogehoge?foo=bar&SCRAMBLE=[ランダムな文字列]
としてやればよろしい。 ヒストリ覗き見スクリプトは正当なURLであるところのhttp://amazon/hogehoge?foo=barへのアクセス履歴を 検査するかも知れませんが、そこへのアクセスはスクランブルにより無かったことになってますので空振りします。
要するに「特定ドメインだけヒストリが残らない」と似たような結果になりますが。http://amazon/hogehoge?foo=barがページ内に出てきてもvisitedとして表示されないので。
ただ、この手法なら、ブラウザの対応を待たずに実現可能です。多分。 プロクシを一段噛ませて、amazonへのリクエストがあった場合には スクランブル付きのURLへリダイレクトしてやる、という実装で。
# 踏んだことのあるリンクかどうか、は結構生活の役に立ってるので全部offにはしたくない。
# amazonだけなら、サイト側に履歴が嫌と言うほど残ってるのでoffにしても問題なし。
# URL末尾に#hogehogeを付ける、とかあれこれ考えてみたけど原理的な問題で今ひとつ良い方法がない。
編集者はいい加減にしろ (スコア:2, 参考になる)
> 「ブラウザ側の欠陥を突くことによって閲覧履歴を取得するもの」で、「Flashオブジェクトの中に数千個の隠しリンクが埋め込まれており、
と正確に書かれているのに、なんでタイトルが
> Flash Playerのバグを突いて
になるんですか? Flashを使わなければならない理由は(難読化以外に)何もありません。JavaScriptさえ不要です [bakera.jp]。
Re:編集者はいい加減にしろ (スコア:1)
ご指摘ありがとうございました。
Re:編集者はいい加減にしろ (スコア:1, 興味深い)
タレコミ時のタイトルでは「Flashの脆弱性を突いて」だったはず。
上のACの指摘はおかしいだろ。
一般論と、ドリコムの事例を混同してる。
このストーリーはドリコムの広告という具体的特定事例の話なんだから、
「Flashの脆弱性を突いて」で正しい。
by タレコミ人
Re:編集者はいい加減にしろ (スコア:2, すばらしい洞察)
も少し配慮した方がいいよ。
編集者が間違ったからと言って、罵詈雑言を浴びせる権利は誰にも無い。
君らの発言を「指摘だ」と主張するのなら、あまりにも悲しすぎるね。
Re:編集者はいい加減にしろ (スコア:1, すばらしい洞察)
> 上のACの指摘はおかしいだろ。
> 一般論と、ドリコムの事例を混同してる。
> このストーリーはドリコムの広告という具体的特定事例の話なんだから、
> 「Flashの脆弱性を突いて」で正しい。
いや、そもそもドリコムが突いたのは「Flashの脆弱性」じゃなくね？
一般論と具体的特定事例の違いじゃなくて、
Flashのどの様な動作が今回言われている脆弱性なのか挙げてみて下さい。
リンクが隠せる事？ visitedが取得出来る事？ それとも、この二つを合わせて？
Flashが従う、より上位の仕様とは無関係にFlashが独自に持つ脆弱性ですか？
これが新聞記者相手なら、そんな細かな事を言っても意味不明だろうけど...
Re:編集者はいい加減にしろ (スコア:1, 参考になる)
技術的な意味合いでは仕様通りの動きであり、
得られるべくして得られる情報、
脆弱性では無いって事になると思うんだよね。
UserAgentやHostは公開情報じゃん。
もちろんユーザ感覚的にはそれらとは全然違う、公開してない情報なんだけど、
技術的には特に隠されずに取得可能な状態に置かれているというのは、
公開情報と大差無いと言うか...
結局、それを拾うか否かってのは現時点では倫理的な問題な気がする。
で、
> FlashのJavaScript (ActionScript)が visitedを取得できること
これ、情報を渡してしまうブラウザ側の脆弱性と見るべきなんじゃないの？
Flashが「ブラウザが正規に提供する情報」を取得するのはFlashの脆弱性じゃなくね？
情報漏洩報道の構図と似ている様な...
本来は「契約外に社外・部署外に持ち出された時点」が漏洩なのに、
持ち出した社員が更に第三者へ流した時点を漏洩と看做してるみたいな違和感。
Re:編集者はいい加減にしろ (スコア:1, 興味深い)
ブラウザのエンジンに問題があるわけで
Flash自体にはまったく関係ない話しですよね。
Re:編集者はいい加減にしろ (スコア:2, すばらしい洞察)
Re:編集者はいい加減にしろ (スコア:1, 興味深い)
むしろ History の制御機能を増やすべきなのでは (スコア:2, 参考になる)
悪用を防止できるのが最善なのでしょうが、visited疑似クラスのビーコンを拾うサービスが登場 [bakera.jp]を読んでも、悪用を防止するという観点での対応は困難であるように思います。
であれば、むしろ、History の制御機能を増やすべきように思います。cookie の制御機能に倣うと、たとえば
といった機能を用意し、あとはユーザの判断に委ねるのが次善策のように思います。上記が実現すれば、少なくとも、エロサイトへの訪問履歴が洩れて……といった事態は防止できる (ような設定が可能になる) ように思います。ぐぐってみたら、HistoryBlock [mozilla.org] というものもあるそうで。
なお、個人的には、さきほど History の保存期間を 0 に設定しました。
Re:むしろ History の制御機能を増やすべきなのでは (スコア:1)
- a要素の描画時にvisitedが影響するのは色だけにする(a要素のサイズは変えない)
- a要素のデザイン関連の属性をスクリプトから取得すると、visitedに関わらず標準(:link相当?)の値が取得される(a要素の色変化の検出禁止。サイズを取得できない要素が存在するのはスクリプトベースでレイアウトを行うページに対する影響が大きくなりすぎるので。前項と合わせて標準の値で固定することで変化を検出できなくする)
これだと「visitedなリンクだけは巨大な文字で表示」が不可能になりますが、これは禁止せざるを得ないようです。 例え「a要素の大きさはスクリプトから取得できない」にしたところで、 「a要素の大きさが変わる」→「周りのレイアウトが変わる」を検出できてしまうので。この手の機能をon/off出来るぐらいでどうでしょう。
# 外部リンクの場合は・・・とか条件を詰めればもっと詰められそうではありますが。
うーん (スコア:1, 参考になる)
洩れるもんだと思って行動するしかないかなー。
Re:うーん (スコア:1, 興味深い)
# まあ、そうゆう所は最初から避けとくのが無難な時代なのかも
Re:うーん (スコア:1)
cookieを有効にしてフィルタを解除する必要があります
自分がやられたら不愉快なことはしない (スコア:1, すばらしい洞察)
合法非合法の前に、やっていいことと悪い事の区別ができない大人が増えたってことかしら
Re:自分がやられたら不愉快なことはしない (スコア:3, すばらしい洞察)
「だって法律で禁止されて無いもん。OKでしょ？」
です。
Re:自分がやられたら不愉快なことはしない (スコア:2, 参考になる)
Re:自分がやられたら不愉快なことはしない (スコア:2, すばらしい洞察)
こういうのは有権者が声を上げて法律の整備を促していかないと、向こうは図に乗るばかり。
Re:自分がやられたら不愉快なことはしない (スコア:1, すばらしい洞察)
> という、商売の根本が欠落してる身勝手な企業が多すぎ。
不愉快じゃない、からやってるのでは。
Firefoxのアドオン (スコア:1)
Re:Firefoxのアドオン (スコア:1)
ポイズニングできないのかな (スコア:1, 興味深い)
全部にtrueでも返しておけばトラッキングするという目的を果たさなくなるのでは？
ついでに全部の広告自動クリックするextentionでもあればいいのに。
クリックトラッキング全滅で楽しいことになりそう。
Re:行政は何してるの？ (スコア:2, すばらしい洞察)
いいかげん御上がきちんとやらないから以下略ってのは止めようよ。
気にくわないことをしている企業のサービスを受けないという選択肢もあるんだが
そういうのはナシでいきなり取り締まれというのはなぁ。
自分の行動の判断をいつも御上にゆだねてるのか??
Re:行政は何してるの？ (スコア:2, すばらしい洞察)
消費者サイドからの突き上げも無しに行政が動くのは異常だと思うのですが。
Re:行政は何してるの？ (スコア:1, すばらしい洞察)
Re:行政は何してるの？ (スコア:2, 参考になる)
バグを利用して公開されていない情報にアクセスするような不正なプログラムを配布して利用することに対して取り締まれ、ということですよね。
で、記事では現状でそのようなプログラムを作成する法律は、準備中だが未成立だから合法であると読めます。
企業も行政も所詮は法にのっとってできるだけのことをするので、
法ができるまでは仕方がないところでしょうか。
安全性を保ってかつ行き過ぎない法律を作ってもらいたいところです。
指摘、指導はありでしょう。 (スコア:1)
刑法なりで取り締まるのはやり過ぎでしょうが、好ましくないと
指摘、指導するのはありでしょう。
資本主義とか倫理観にだけ頼っていると、間に合わない場合も
あるでしょうから。個人のプライバシーや企業の秘密、防衛上の秘密などが
漏えいする可能性もあるのですから。
Re:気になるなら履歴を消せば良いじゃない (スコア:3, 参考になる)
パスワードも含めて
プライバシー情報は全部消すようにしてます。
よく使うマシンでは
パスワードのみ残してます。
Re:気になるなら履歴を消せば良いじゃない (スコア:1, 参考になる)
IEは終了するまで残ってるけど、Firefoxの場合は一切残ってないはず。（戻る進むの部分は残ってますが、CSSなどには反応しません）
Re:気になるなら履歴を消せば良いじゃない (スコア:2, すばらしい洞察)
「世の中の全てのページにアクセスすれば良いじゃない」
が正解かと。
#履歴に残るページ数とかは無視…
Re:ええー (スコア:2, すばらしい洞察)
Re:ええー (スコア:1)
OSの事なら、楽天はOSのログインを作動させたり迂回してないから関係ないよ。
それに「起動時に」でしょ、このFlashが動作する時じゃないでしょ。
ブラウザにログイン機能がついてて、URLが訪問済みかどうかのチェックをする度にログインが必要ってんなら別だけど。
Re:ええーいや、微妙 (スコア:2, 興味深い)
アクセス制御のかかった機器であるかどうかだそうです。
ACCS事件の例 [cnet.com]では、FTP下でアクセス制御されていることを前提としたデータであれば、
別のプロトコル(Http)下でアクセス制御されていないアクセスで取得した場合でも要件を満たしていて、
アクセス制御は動作時でもプロトコルレベルでもなく、ハードウエアつまりＰＣにかかっていればよいという判決。
基本的にアクセスされないことが前提。基本的にはクロスドメインアクセスはできないようになっている。
すると、今回話題に上っている他サイトへのアクセス履歴取得は
- ログインの必要な特定電子計算機に対して
- 仕様の不備を悪用して、
- 非公開のデータを
- ユーザー＝管理者が意図していない方法で取得して利用可能にしている
のでアクセス制御云々っていう部分に関しては判例的には要件を満たしているように思います。ただ、取得したデータを直接送信させて収集しているわけではなく、計算された結果
としての広告用コードのみを送信して広告を取得するプログラムを配置している
だけなので、不正アクセスには当たらないというのが楽天さんの主張では？
結局ぜい弱性をつこうが何しようが、操作してるのはユーザー自身なので。
Re:ええーいや、微妙 (スコア:1)
#1440699を見る限り、「アクセス制御を作動させる事」や「アクセス制御の制限を免れる事」が、どの条件にも含まれていると思います。
URLのヒストリーの参照の為に、ログインをしてませんし、ログインを回避もしてません。
だから不正アクセスではありません。
以下、アクセス制御機能を、OSのログインとして説明します。
まず、第三条の２の一では、他人のパスワードを使ってログインする事を禁止していますから、当てはまりません。
ニでは、ログインしなければアクセスできない情報に、ログインせずにアクセスする事を禁止しています。
三では、正規のパスワードを使わずに、別の方法でログインする事を禁止しています。
URLのヒストリーにアクセスする事は、この三つのどれにも当てはまりません。
>ACCS事件の例では、FTP下でアクセス制御されていることを前提としたデータであれば、
>別のプロトコル(Http)下でアクセス制御されていないアクセスで取得した場合でも要件を満たしていて、
>アクセス制御は動作時でもプロトコルレベルでもなく、ハードウエアつまりＰＣにかかっていればよいという判決。
これは、第三条の２のニにあてはまる事です。
ログインしなければ見れない情報に、ログインせずにアクセスしたので違法アクセスと判断されました。
>ログインの必要な特定電子計算機に対して
>仕様の不備を悪用して、
>非公開のデータを
>ユーザー＝管理者が意図していない方法で取得して利用可能にしている
>のでアクセス制御云々っていう部分に関しては判例的には要件を満たしているように思います。
それは要件として間違っています。
仕様の不備は関係ありません。
アクセス制御を作動させたり回避したりしている事も必要です。
Re:ええーいや、微妙 (スコア:2, 興味深い)
今回のケースは私も違法だとは思っていないですよ。
ただ、
情報にアクセス制御がかかっていないから合法なんではなく、
楽天やドリコムはアクセスしていないから合法なんです。
ログインしなければ見れない情報に、ログインせずにアクセスしたので違法アクセスと判断されました。
ACCSで問題になった個人情報は、
HTTPのCGI経由ならログインしなくても見ることができる状態になっていた（アクセス制御がかかっていない）。
FTPやSSH、コンソール経由でのアクセスの場合はログインして権限がないと見られない情報です（管理者だけはアクセス制御下にあると思いこんでいた）。
ACCS判決では、そこをプロトコルレベル（OS、コンソール、SSH、FTPを問わず）で判定するのではなく、
機械装置としてアクセス制御がかかった機器であるからという判決になっています。
その機器の中の情報を正常以外の方法でアクセスして取得したので違法という判断です。
通常は、PC上のデータはOSにログインしてかつ許可がない情報は見られないような特定電子計算機ですし、
ブラウザーを開かないと他のサイトへのアクセス履歴は『識別符号が「特定電子計算機に入力されるもの」』なので、
他サイトへのアクセス履歴は「アクセス制御がかかっていない情報」ではないですよ。
で、『同法3条2項2号も、アクセス制御機能による特定利用の制限を免れることができる情報または指令を入力』に相当するのはFlash内のコードにあたるわけです。
ただ今回のケースは、不正利用するプログラムの配布・配置に過ぎず、
不正アクセス法でいうところの、文頭に共通する「電子計算機にアクセスし」というアクセス行為は一切行っていないので、
『現在国会で継続審議となっている刑法改正案の「不正指令電磁的記録作成等の罪」（いわゆる「ウイルス作成罪」）』
の範疇になるわけです。
>仕様の不備を悪用して、
>非公開のデータを
>ユーザー＝管理者が意図していない方法で取得して利用可能にしている
>のでアクセス制御云々っていう部分に関しては判例的には要件を満たしているように思います。
それは要件として間違っています。
仕様の不備は関係ありません。
アクセス制御を作動させたり回避したりしている事も必要です。
この要件で違法になると書いているわけではありません。
後続して「結局ぜい弱性をつこうが何しようが、操作してるのはユーザー自身なので。」と書いたのはその意味なんですが、わかりにくかったですかね。すみません。。
Re:ええーいや、微妙 (スコア:1)
何を持って通常アクセス制限されているかはどう判断するのか知りませんが
ACCS事件ではFTPアクセスでしか見れないものをwebで取得したからNGという判断だったかな。
このあたり高木氏が的確な指摘をしていたはず。
Re:ええーいや、微妙 (スコア:1)
「その計算機にログインしているユーザにとあるプログラムを実行させる」ことでアクセス制御機能を回避している、という解釈はアクロバティック過ぎますか?
この件自体は割とどうでも良いと思っているんですが、どうもこの件、 ハイパースレッディングに深刻な脆弱性が報告される [srad.jp]とか、 CPUの高速化技術を悪用したRSA鍵盗聴が可能か [srad.jp]とかと似ているように思えてちょっと引っかかります。
リンク先は大まかに言って、「あるスレッドの実行が他のスレッドに与える環境的な影響を測定することでパスワードを盗み出す手法」のような技で、これがそのまま実現できたわけではないんですが。 今回の件が合法なら、もし万が一、そんな感じの、より深刻な手法が実現しちゃったときにも合法と判断されちゃいそうに思います。「盗むとこまでは合法だけど、その盗んだパスワードを使った瞬間に違法」では何となく気色悪いですし。塞いでおくべき法の穴なんじゃないかな、と。
ところで、そういや、今更気付いたんですが、HTMLに埋め込まれたスクリプトってプログラムの一種なのに、お決まりの「このプログラムを実行させることで起こったいかなる不利益も以下略」の儀式が無いですね。 何か起こったとき、誰が責任取るんでしょう? ブラウザは一応変なことが起こらないように設計されてるはずですが、責任取ってくれそうには見えませんし。
と言うか、「ブラウザを使うことで起こったいかなる不利益も以下略」を承認したような気がします。 と言うことは、いざ何か起こった時ってユーザが勝手に責任取れ、なんでしょうね。 最初に一発、「その上でどんなスクリプトが動くか分かりませんが認めますか?」「はい」をやっちゃってるわけですね。考えてみると怖いなぁ・・・。
Re:ええーいや、微妙 (スコア:1)
ユーザーのマシンにアクセス制御がかかっていれば、
不正アクセス禁止法で言われている、アクセス制御がかかった対象物として十分というのがACCSの判例ですということなんです。
今回の件が不正アクセスにならないのは、楽天・ドリコム側は配置しただけで何も実行していないというところがキモなんですよ。
Re:ええーいや、微妙 (スコア:1)
暗号の解読や鍵の解析が、「アクセス制御機能」を回避する為のものなら、不正アクセスになると思います。
暗号の解読は、それ自体がアクセス制御機能の回避に当たり、違法行為になると思います。
鍵の解析や盗聴の場合、それによって得た鍵を使って情報にアクセスする事が不正アクセスとなり違法行為と見なされるでしょう。
URLヒストリーの参照との違いは、アクセス制御機能を回避したり、不正にアクセス制御機能を作動させている事です。
Re:ええーいや、微妙 (スコア:1)
ftpの場合、ftpでアクセスできる情報を、ftpのログインという機能で保護しているという考え方だと思います。
そのftpでアクセスすべき情報を、ftpのログインをせずにアクセスしたから不正アクセスです。
今回の件の場合、OSのログインで保護されてる情報を、OSにログインされてる状態でアクセスしてます。
ACCSの件で、「管理者が意図していない方法かどうか」が問題になったのは、アクセスした情報が「ftpのログイン」というアクセス制御で保護されたものかどうかで争ったからです。
意図された方法だったなら、アクセス管理で保護されているとはいえないので、合法。
意図されていない方法なら、アクセス管理で保護されているので、それを回避したら違法。
URLのヒストリーは、OSのログインで保護されてる事に疑いは無いので「管理者が意図していない方法かどうか」は争点となりません。
ただし、保護されてはいるが、それを回避してないから問題は無いという事です。
Re:ええーいや、微妙 (スコア:1)
> 他サイトへのアクセス履歴は「アクセス制御がかかっていない情報」ではないですよ。
ひどい。。
他のサイトへのアクセス履歴は『識別符号が「特定電子計算機に入力されるもの」』で、
自由に情報を提供する状態にはなっていないので「アクセス制御がかかっていない情報」ではないですよ。
Re:スパイウェアベンダーの常套句 (スコア:1)
単純な話です、SPAMの広告を見て、それを買う人が実際に居るからです。
大部分の人は、SPAMで宣伝されてる物に興味が無い人ので、悪印象を持ちますが、そういう人はそものも客としては見込みが低いので問題ありません。
逆に、ほんの僅かですが、SPAM広告に興味を引かれて客になる人が確実に居ます。
その人からの儲けがSPAM費用を上回るのなら、SPAMを止める事は無いでしょう。
Re:「その場しのぎ」と「時間稼ぎ」は違う (スコア:1)
IEでは仕様かも。
It's not who is right, it's who is left.