

Plugging the CSS History Leak - robin_reala
http://blog.mozilla.com/security/2010/03/31/plugging-the-css-history-leak/

======
storborg
This is a horrible solution to the CSS history problem that's going to break a
lot of layouts and a lot of javascript.

A far better solution, IMHO, is to simply track both the origin page and
destination page of clicked links, and only apply a:visited styles to links
when the origin page is one that has been previously been used to visited the
destination page. This is the solution employed by the SafeHistory plugin.
(<http://www.safehistory.com/>)

~~~
raganwald
So... Let's say that both proggit and hacker news have articles about plugging
the CSS history leak. If I visit the link through proggit, the a:visited style
is appled and I can see I've visited it.

Now I go to HN to see what's new and I see a link to the same article. Will my
browser make it look like I haven't visited it because I haven't visited it
through HN?

That would not please me as a user.

~~~
snprbob86
I'd agree with you, but then I realized that I already switch browsers and
computers so many times in a given day that I have this problem within a site,
never mind spanning two.

So I asked myself: When do I use the visited link colors for? And I think the
answer is: only when I press the browser's Back button. I want to see where I
left off clicking. If I have to click an extra link and say "Whoops, already
saw that", then oh well. As long as I know where to start reading when I
return.

~~~
Periodic
I use four different computers in a day, I'm often taking breaks to read HN or
Reddit, visited styling isn't helping me much there.

The place I use it most is for Google search results, particularly when I
refine my search and I want to know what are the links I visited in my
previous search so I can click only on the new ones.

It's always a trade-off. I think this is a fairly reasonable one.

------
btipling
Maybe allow for a same-domain policy so that you can still use the fancy
styling for visited links for your own site, since more than likely the
website will have that information in their logs already or be able to track
it other ways.

------
imp
Would it be enough to allow the browser to arbitrarily style visited links
that occur within the same domain of the current page and force these
restricted rules on links outside the domain? Although I don't typically do
much with visited links, it seems pretty extreme to limit them so much.

Edit: Nevermind, I forgot that the URL destination can be changed. I guess the
browser could force style changes to the links if href is changed, but that
might be too complicated. It just seems like there should be a more elegant
way to fix the problem than restricting what styles can be set for visited
links.

~~~
wvenable
It's really just limiting the difference in styles between the visited and
non-visited. Which, if you think about it, is unlikely to affect too many
layouts.

------
thorax
I'm sure they do feel they're working hard to compromise on this issue, but
their decisions for this will break sites with very careful styling/designs
(e.g. checkmarks, font styling, etc). It just doesn't sit well with me that
Mozilla feels so strongly (or caves to pressure) on issues like this that
they're willing to break so much backwards compatibility.

I would love to see them make this optional and turn it off by default. It's a
paranoia thing that people have lived with forever, and the most concerned
people could turn on this mode if they ever need to do so.

~~~
tptacek
It only seems like paranoia because widespread, highly-publicized abuse of
history sniffing hasn't started yet. I'm happy they've jumped onto this
grenade before it exploded.

The most valuable thing Mozilla just did was to send a signal to the market
that history sniffing is going to be unreliable, and that ad networks
shouldn't invest time and money into exploiting it. The scariest thing about
history sniffing was the idea that some large company would adopt it and
create pressure to keep the vulnerability there forever, as part of how the
Internet works.

~~~
thorax
Yeah, I know it's valuable to put out some solution to this, but I would have
preferred more options discussed on how to prevent this rather than choosing
an option that breaks presentation backwards compatibility.

I know I have the minority opinion on this, so I have to speak up or that
opinion will go unheard. I prefer to avoid breaking backwards compatibility
for presentation as much as possible. I'd much rather some approach be
tried/found that isn't quite so inelegant as this one.

~~~
briansmith
Many, many options were proposed. Look in the Bugzilla entry (#147777) for it.
There were over 241 comments in that bug report alone, not counting dupes.
Many of those comments were proposing alternatives.

------
cryptnoob

         Firefox already allow you to disable all visited
         styling   (immediately stops this attack) by setting the
         layout.css.visited_links_enabled option in about:config 
         to false. 
    

I would rather they stop here. Don't break things for everybody for something
that most people consider to be a non-problem.

~~~
jeroen
Most people consider password security a non-problem (see
<http://news.bbc.co.uk/2/hi/technology/3639679.stm> ). Should we stop caring
about XSS? Or passwords being stored as plain text?

------
IgorPartola
How about something like this:

    
    
        <a href="some-visited-url">
          <span class="test"></span>
        </a>
    

Does the CSS for span.test change if the link is visited or not?

Also, this will be very awkward when the style you see with your eyes is not
the style that is given to JavaScript.

~~~
JeffJenkins
That should be fine. If they make selectors that have an a:visited (and
whatever else) take the special code paths it should work fine. The style test
in your example is going to be uniform across visited and unvisited unless
it's something like:

a:visited .test { /* sneaky style */ }

~~~
IgorPartola
That's exactly my point. If I define:

    
    
      a .test {
        color: red;
      }
      
      a:visited .test {
        color: green;
      }
    

Then I could for example using jQuery do:

    
    
      $('a .test').each(function() {
        if ( $(this).css('color') == 'green' ) {
          console.log( $(this).parent().attr('href') );
        }
      });
    

Is that incorrect?

~~~
onedognight
| When a web page tries to get the computed style of a link (or any of its
_sub_ -elements), Firefox will give it unvisited style values.

~~~
arantius
They've probably thought about this, but what about siblings?

a:visited + .sneakydiv { /* ... */ }

------
tjic
First, let me say that I entirely follow the technical description of the
potential attack they're talking about, and I can imagine ways to exploit it.

My question: is it really worth worrying about?

What's the threat scenario where this leaks appreciable amounts of my privacy
? Note: I'm NOT arguing "my privacy is worthless".

~~~
Periodic
I think it's a problem when you may have beliefs that some others don't agree
with but which you don't think they they have a right to know.

Here's a simple case: What if your employer was very stuck-up and controlling
and the CEO is a crazy {insert religion or lack of here}. They make you log in
from home to check your email on their website. Now what if their website
sniffed your computer to check if you'd been looking at {insert other
religious belief here} and forwarded that information on.

In this case your expectation of privacy does not match the actual privacy
case. Most people wouldn't think that looking at a hard-core christian website
from home might get them looked at funny by their atheist bosses. This is a
case of technology not behaving properly, which is a bug.

You can think of all sorts of cases where there might be negative consequences
for you if everyone could view your at-home browsing history.

------
arantius
For all the naysayers ("this will break so many sites!") a challenge: Can you
find even one site that applies a non-color style to visited links? Two? Ten?
How long do you have to look to find it/them?

Are any of these 'broken' besides not being quite as pretty? Is any content or
feature invisible, unreadable, or unavailable?

------
blasdel
Their solution to "Layout-Based Attacks" is trivial to get around, _any_
visual style change can be detected, even if it doesn't trigger reflow -- the
<canvas> API has pixel accessors.

~~~
kinetik
That's incorrect. Web content needs additional privileges to paint web content
into a canvas for exactly this reason.

