- From: Arve Bersvendsen <arveb@opera.com>
- Date: Wed, 16 Apr 2008 23:26:26 +0200
- To: "Travis Leithead" <travil@windows.microsoft.com>, "Lachlan Hunt" <lachlan.hunt@lachy.id.au>, public-webapi <public-webapi@w3.org>
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. 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:27:07 UTC