RE: [selectors-api] Handling :link and :visited Pseudo Classes

>> 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 :)

-----Original Message-----
From: Maciej Stachowiak [mailto:mjs@apple.com]
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 <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.

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/
>

Received on Wednesday, 16 April 2008 22:00:34 UTC