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
