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

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: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 Thursday, 17 April 2008 01:26:09 UTC