On Apr 16, 2008, at 2:58 PM, Travis Leithead wrote:
Travis, last time I asked about this you declined how to say how
this
could be solved but said you thought it was possible. Would you be
willing to explain further now?
Sorry Maciej, I'm still going to decline to say how, but insist that
it is possible. With Software, anything's possible :)
No, not anything. No amount of brilliant engineering will solve the
halting problem.
But I agree that in this case the question is more what the
consequences are of a solution, rather than whether it is possible at
all. For making technical decisions as a group, "trust me" is not very
high quality input.
David's described solution sounds almost feasible, other than possibly
compatibility impact (I'm not sure how common it is to set properties
other than color or background-color in :visited rules, or how
often :link rules set a non-color property that is not set
for :visited). It also seems to still leave holes for timing attacks.
Cheers,
Maciej
-----Original Message-----
From: Maciej Stachowiak [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 16, 2008 2:40 PM
To: Arve Bersvendsen
Cc: Travis Leithead; Lachlan Hunt; public-webapi
Subject: Re: [selectors-api] Handling :link and :visited Pseudo
Classes
On Apr 16, 2008, at 2:26 PM, Arve Bersvendsen wrote:
On Wed, 16 Apr 2008 22:49:30 +0200, Travis Leithead <[EMAIL PROTECTED]
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.
Agreed. Besides what Arve posted, there are all sorts of ways
for :link vs :visited to affect the layout of other elements. Besides
normal flow siblings it could affect the size and/or position of other
floats in the same containing block (if floated), its children, its
parent, and so forth. So I don't see how you could hide visited link
information for attackers short of doing an extra style resolution and
layout solely to handle queries for style or layout information.
Furthermore, giving answers from these queries that don't match the
true layout could break scripts doing animations or script-driven
layout.
In addition, CSS inheritence could alter non-size properties of
children like color, so restricting :link and :visited to properties
that don't affect size or position wouldn't work either.
I'd like us to understand how it is feasible to every fully solve this
problem before catering to partial solutions in the Selectors API
spec.
Travis, last time I asked about this you declined how to say how this
could be solved but said you thought it was possible. Would you be
willing to explain further now?
Regards,
Maciej
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/
