W3C home > Mailing lists > Public > public-houdini@w3.org > February 2015

Re: Proposal for adding @extend to CSS

From: Jonathan Rimmer <jon.rimmer@gmail.com>
Date: Wed, 04 Feb 2015 10:42:55 +0000
Message-ID: <54D1F7AF.9070709@gmail.com>
To: public-houdini@w3.org

On 2015-02-04 03:06, Tab Atkins Jr. wrote:
> On Mon, Feb 2, 2015 at 3:15 AM, Michiel Bijl <michiel@agosto.nl> wrote:
>> What exactly is the (security) issue with a:visited?
> You can style links differently with :visited, produce a bunch of
> links, and check their styles, which lets you tell which sites the
> user has visited recently.  This is a privacy violation, and makes it
> easier to, for example, phish effectively, since you can tell which
> bank the user visits, etc.
>
> To limit this, browsers limit rules containing a :visited pseudoclass
> to only be able to apply a handful of styles (nothing that causes
> network requests, or that changes layout in an observable way; you can
> pretty much only do color and text-decoration), and whenever you do
> getComputedStyle(), they lie and claim all links are unvisited while
> computing the style, so you can't even tell when directly querying the
> style.
>

Perhaps getting a bit off-topic here, but given the security 
complications of :visited, and the difficult of implementing it at all 
without leaking info via side-channels[1] mightn't it be better to 
redefine it to work only on destination URLs which are the same as the 
origin or where the user agent has a previously recorded navigation from 
the origin to the destination? That would seem to cover two important 
:visited use cases -- internal links within a site or document, and 
links on content aggregators like Reddit -- and let the current styling 
restrictions be relaxed.

It would be a shame to lose the ability to see, for example, that a link 
you followed on Twitter is the same as one you see on Reddit, but maybe 
it would be worth it for the simpler security situation with respect to 
how :visited interacts with new features and can be protected from 
side-channel attacks? This use case could always be handled via 3rd 
party browser extensions.

[1] http://www.ieee-security.org/TC/SP2011/PAPERS/2011/paper010.pdf

Jon
Received on Wednesday, 4 February 2015 10:43:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 15:47:05 UTC