W3C home > Mailing lists > Public > public-webapi@w3.org > April 2008

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 16 Apr 2008 14:39:31 -0700
Cc: Travis Leithead <travil@windows.microsoft.com>, Lachlan Hunt <lachlan.hunt@lachy.id.au>, public-webapi <public-webapi@w3.org>
Message-Id: <38873197-A54C-488E-B061-81DB09B698CF@apple.com>
To: Arve Bersvendsen <arveb@opera.com>


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 21:40:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 16 April 2008 21:40:17 GMT