アカウント名:
パスワード:
:visited疑似クラスに対して適用可能なプロパティを制限するのは、意味ないですよね？ getComputedStyleした後に適用可能なプロパティ（colorとか）が違うか見れば良いだけですし。
かといって、getComputedStyleを制限するのは悪影響が大きすぎませんか？ 普通のページならともかく、ウェブアプリだと挙動がおかしいものが出てくる気がします。
というか、:visitedをブラウザのグローバルな履歴に対して判定しているから履歴が漏れるのであって、 JavaScriptのドメイン制限のように、ドメインごとに分けられた履歴で:visitedを判定するとか、 ブラウザ開発者なら一番最初に思いつきそうな対策をあえて避けるのはなぜ・・・？
# iframeとJava
> :visited疑似クラスに対して適用可能なプロパティを制限するのは、意味ないですよね？いいえ。> getComputedStyleした後に適用可能なプロパティ（colorとか）が違うか見れば良いだけですし。それはできないように対策されています。> かといって、getComputedStyleを制限するのは悪影響が大きすぎませんか？取得ができなくなるわけではありません。違うかどうかが判定できないだけです。具体的には訪問済みリンクのスタイルを見ても、未訪問の場合と同じスタイルが返されるようになっています。ですから初めて訪問したときにちゃんと動作するサイトなら、ちゃんと動作します。ではなぜ適用可能なプロパティの制限が必要なのかというと、たとえば訪問済みリンクのボックスのサイズを変えて、親要素のサイズ変更を検出するという攻撃が考えられるからです。この場合リンクが未訪問だと仮定したレイアウトを内部的に計算して保持するのはコストが高すぎて現実的ではありませんし、実際に画面に表示されているものとズレが生じたら傍目にはバグにしか見えないでしょう。またたとえば背景画像の有無によってスタイルの適用速度にはっきりとした差が現れれば、時間計測によってスタイルの推測が可能です。ですから訪問済みの場合と未訪問の場合で、レンダリング時間がほぼ同じになるようなスタイルの変更しかできないように制限されています。
> ドメインごとに分けられた履歴で:visitedを判定するとか、RequestPolicyを使ってるとわかりますが、今どきのサイトは静的コンテンツのみ別サーバに分けてるとか実体はamazon AWS上にあるとか当然のように行われていて、あまり現実的ではありません。リンク集を見てもどの外部サイトが訪問済みなのかわからないというのは大きく利便性を損ないます。それをサイトに知られたくないだけであって。それでもいいという人向けのアドオン [mozilla.org]はありましたが、デフォルトで採用できるような代物ではありません。
このバグは修正までに8年近くも検討が重ねられてきたわけですが、みなさんよほど「ぼくのかんがえたさいきょうの」攻撃/対策に自信がおありのようで。
説明の仕方が悪く「ドメイン内のリンクだけ:visitedを判定する」と伝わってしまったようで申し訳ない限りです。
私が意図したのは「サイト毎に履歴をとって、それを元に:visitedを適用する」ということです。 （ユーザーのナビゲーション用とは別個にCSSの計算専用の履歴として、privateな履歴を記録する）
ここで問題になるのが、どこからどこまでが1つの「サイト」なのかという判定条件ですが、 元コメでは安易に「ドメイン」と書いてしまい誤解を招いてしまいましたが（発想が古い）、 XMLHttpRequestのアクセス制限と同じ判定方法で判定する、が具体的かつ正確だと気づきました。 ドメイン単位ではありません。
なので動作的には、
となって、レスにかかれたようなデメリットやクラッカーとのいたちごっこを考える必要がないという訳です。
サイト毎の「内」と「外」を分けるという方法はCrossなんちゃらの対策としてはまっとうな方法だと思うんですが 「サイト固有CSSの:visitedをグローバルな履歴に基づいて適用したブラウザの実装」がバグでなくて、 「:visitedが指定できるCSSの仕様そのものがセキュリティホール」となってしまった経緯が知りたいのです・・・
私が意図したのは「サイト毎に履歴をとって、それを元に:visitedを適用する」ということです。
#1744154 [srad.jp] の人が紹介してくれている SafeHistory [mozilla.org] はその方法です。 SafeHistory ではドメインごとに「そのドメインにあるリンクを辿ることによってページを訪れたことがあるかどうか」で visited スタイルを適用するかどうかを決めます。
この方法の問題点は、もちろん訪問済みページへのリンクが visited スタイルで描画されないことがある (そういう変更何だから当たり前) ことと、「サイト」と「ドメイン」は違うということでしょう。後者については、一つのドメインを複数のサイトで共有していたり、一つのサイトが複数のドメインにまたがっていたりすると、期待通り動かないことは理屈上はあり得ます。実際どれだけ問題かは僕は検証したことがありません。
#1744154 [srad.jp] の人が
と言っている通り、まあ素人がぱっと思いつくことは誰かが既に試していると思って間違いないでしょう。べつに 8 年かかったからといって 8 年間ずっと考えていた結果というわけではないので、誇張が入っている気がしますが。
それだと :visited の意味が変わりすぎ。削る方がマシ。自分の使い方を一般化しないでくれ。
> 説明の仕方が悪く「ドメイン内のリンクだけ:visitedを判定する」と伝わってしまったようで申し訳ない限りです。いいえ。理解もしてますしちゃんと伝わってます。自分で> ブラウザ開発者なら一番最初に思いつきそうなと言ってるくせに、目の前の愚かなACはわざわざ太字で二回も強調しないとこんな簡単なことすら理解できないとでも思ってるんですか? 自惚れが過ぎるんじゃないですか?> XMLHttpRequestのアクセス制限と同じ判定方法で判定する、XMLHttpRequestは基本的にドメインをまたげませんけど? ドメインがなんだかわけのわからな
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
JavaScriptの制限をCSSにも適用すれば良いだけでは？ (スコア:1)
:visited疑似クラスに対して適用可能なプロパティを制限するのは、意味ないですよね？
getComputedStyleした後に適用可能なプロパティ（colorとか）が違うか見れば良いだけですし。
かといって、getComputedStyleを制限するのは悪影響が大きすぎませんか？
普通のページならともかく、ウェブアプリだと挙動がおかしいものが出てくる気がします。
というか、:visitedをブラウザのグローバルな履歴に対して判定しているから履歴が漏れるのであって、
JavaScriptのドメイン制限のように、ドメインごとに分けられた履歴で:visitedを判定するとか、
ブラウザ開発者なら一番最初に思いつきそうな対策をあえて避けるのはなぜ・・・？
# iframeとJava
Re:JavaScriptの制限をCSSにも適用すれば良いだけでは？ (スコア:1, 参考になる)
> :visited疑似クラスに対して適用可能なプロパティを制限するのは、意味ないですよね？
いいえ。
> getComputedStyleした後に適用可能なプロパティ（colorとか）が違うか見れば良いだけですし。
それはできないように対策されています。
> かといって、getComputedStyleを制限するのは悪影響が大きすぎませんか？
取得ができなくなるわけではありません。違うかどうかが判定できないだけです。具体的には訪問済みリンクのスタイルを見ても、未訪問の場合と同じスタイルが返されるようになっています。ですから初めて訪問したときにちゃんと動作するサイトなら、ちゃんと動作します。
ではなぜ適用可能なプロパティの制限が必要なのかというと、たとえば訪問済みリンクのボックスのサイズを変えて、親要素のサイズ変更を検出するという攻撃が考えられるからです。この場合リンクが未訪問だと仮定したレイアウトを内部的に計算して保持するのはコストが高すぎて現実的ではありませんし、実際に画面に表示されているものとズレが生じたら傍目にはバグにしか見えないでしょう。
またたとえば背景画像の有無によってスタイルの適用速度にはっきりとした差が現れれば、時間計測によってスタイルの推測が可能です。ですから訪問済みの場合と未訪問の場合で、レンダリング時間がほぼ同じになるようなスタイルの変更しかできないように制限されています。
> ドメインごとに分けられた履歴で:visitedを判定するとか、
RequestPolicyを使ってるとわかりますが、今どきのサイトは静的コンテンツのみ別サーバに分けてるとか実体はamazon AWS上にあるとか当然のように行われていて、あまり現実的ではありません。
リンク集を見てもどの外部サイトが訪問済みなのかわからないというのは大きく利便性を損ないます。それをサイトに知られたくないだけであって。それでもいいという人向けのアドオン [mozilla.org]はありましたが、デフォルトで採用できるような代物ではありません。
このバグは修正までに8年近くも検討が重ねられてきたわけですが、みなさんよほど「ぼくのかんがえたさいきょうの」攻撃/対策に自信がおありのようで。
Re:JavaScriptの制限をCSSにも適用すれば良いだけでは？ (スコア:1)
説明の仕方が悪く「ドメイン内のリンクだけ:visitedを判定する」と伝わってしまったようで申し訳ない限りです。
私が意図したのは「サイト毎に履歴をとって、それを元に:visitedを適用する」ということです。
（ユーザーのナビゲーション用とは別個にCSSの計算専用の履歴として、privateな履歴を記録する）
ここで問題になるのが、どこからどこまでが1つの「サイト」なのかという判定条件ですが、
元コメでは安易に「ドメイン」と書いてしまい誤解を招いてしまいましたが（発想が古い）、
XMLHttpRequestのアクセス制限と同じ判定方法で判定する、が具体的かつ正確だと気づきました。
ドメイン単位ではありません。
なので動作的には、
となって、レスにかかれたようなデメリットやクラッカーとのいたちごっこを考える必要がないという訳です。
サイト毎の「内」と「外」を分けるという方法はCrossなんちゃらの対策としてはまっとうな方法だと思うんですが
「サイト固有CSSの:visitedをグローバルな履歴に基づいて適用したブラウザの実装」がバグでなくて、
「:visitedが指定できるCSSの仕様そのものがセキュリティホール」となってしまった経緯が知りたいのです・・・
Re:JavaScriptの制限をCSSにも適用すれば良いだけでは？ (スコア:2)
#1744154 [srad.jp] の人が紹介してくれている SafeHistory [mozilla.org] はその方法です。 SafeHistory ではドメインごとに「そのドメインにあるリンクを辿ることによってページを訪れたことがあるかどうか」で visited スタイルを適用するかどうかを決めます。
この方法の問題点は、もちろん訪問済みページへのリンクが visited スタイルで描画されないことがある (そういう変更何だから当たり前) ことと、「サイト」と「ドメイン」は違うということでしょう。後者については、一つのドメインを複数のサイトで共有していたり、一つのサイトが複数のドメインにまたがっていたりすると、期待通り動かないことは理屈上はあり得ます。実際どれだけ問題かは僕は検証したことがありません。
#1744154 [srad.jp] の人が
と言っている通り、まあ素人がぱっと思いつくことは誰かが既に試していると思って間違いないでしょう。べつに 8 年かかったからといって 8 年間ずっと考えていた結果というわけではないので、誇張が入っている気がしますが。
Re: (スコア:0)
それだと :visited の意味が変わりすぎ。削る方がマシ。
自分の使い方を一般化しないでくれ。
Re: (スコア:0)
> 説明の仕方が悪く「ドメイン内のリンクだけ:visitedを判定する」と伝わってしまったようで申し訳ない限りです。
いいえ。理解もしてますしちゃんと伝わってます。自分で
> ブラウザ開発者なら一番最初に思いつきそうな
と言ってるくせに、目の前の愚かなACはわざわざ太字で二回も強調しないとこんな簡単なことすら理解できないとでも思ってるんですか? 自惚れが過ぎるんじゃないですか?
> XMLHttpRequestのアクセス制限と同じ判定方法で判定する、
XMLHttpRequestは基本的にドメインをまたげませんけど? ドメインがなんだかわけのわからな