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

On Apr 16, 2008, at 3:28 PM, L. David Baron wrote:

> On Wednesday 2008-04-16 23:26 +0200, Arve Bersvendsen wrote:
>> 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.
>
> It's not impossible; it just requires deviations from current
> standards and probably a lot of work.
>
> On Wednesday 2008-04-16 14:39 -0700, Maciej Stachowiak wrote:
>> 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.
>
> My current thinking (from
> https://bugzilla.mozilla.org/show_bug.cgi?id=147777#c65 ) is that
> what we'd need to do to fix this is:
>
> 1. change CSS selector matching so that :visited rules are used
>    *only* for the non-alpha components of the 'color' and
>    'background-color' properties (and everything else is computed
>    based on the :link rules)
>
>
> 2. make getComputedStyle and any other APIs lie about those two
>    properties

I guess you would have to extend this to rules that use :visited  
or :link anywhere in the selector (for example before a sibling or  
descendant combinator) and make sure the getComputedStyle lies extend  
to descendants that inherit the color as well.

Also, I think setting background-color may be subject to a timing- 
based attack if the default is transparent, since it will require  
extra rect fills, and setting color may be subject to a timing based  
attack if the anti-aliasing mode changes based on the color of text,  
resulting in different cost of drawing the text. I believe this is  
true on Mac OS X.

Regards,
Maciej

Received on Thursday, 17 April 2008 01:25:19 UTC