- From: Jonathan Rimmer <jon.rimmer@gmail.com>
- Date: Wed, 04 Feb 2015 10:42:55 +0000
- 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