Plugging the CSS History Leak | Hacker News Reader

Plugging the CSS History Leak

blog.mozilla.com

73 pointsrobin_reala31 comments

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/)

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.

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.

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.

I'm having a real hard time believing that. It seems like, at the very worst, a "broken" site will simply make your visited links appear identical as non-visited ones.

Do people really have layouts that rely on visited links changing size or shape? What Javascript uses visited link styling to do something useful?

".. going to break a lot of layouts and a lot of javascript"

I'd love to see an example, because I can't think of any myself.

Any presentation layer change is going to break the look of lots of sites, given the huge quantity of sites.

If you changed the font at all for a visited link, it will display differently across Mozilla browsers versus Chrome ones. Having not read about this, I'd never be able to figure out what was preventing the style from "taking" in normal development.

Sure, but how could it "break" the layout? How could you possibly have a layout that requires links to change size to work?

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.

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.

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.

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.

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.

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.

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.

I guess I'm struggling to think of a case where it's particularly important that visited/unvisited links differ by complex styling. If leaking history is a paranoia thing, that's a useless fluff thing.

The checkmarked visited links thing seems completely wrong to me, to take that example. Something like a checkmark next to a link feels like part of site UI rather than the browser's, and a site's UI shouldn't have access to what I've done on other sites! If they want to keep track of what links I click on the site and maintain checkmarks in their UI accordingly, they can still do that, of course.

All presentation could be described as "useless fluff". If you wanted to change the font for a visited link aside from color, this will eat that.

Note that I take the word "paranoia" from Mozilla's own blog discussing the topic. I do feel that it is a real privacy issue, but it isn't new and I'd much prefer something like what SafeHistory does than this presentation level hack they're planning.

     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.

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?

Most web developers might consider it a non-problem[1]. I, for one, prefer that information that ought to be private stay that way.

[1] Maybe. Or not. I doubt either of us has evidence one way or the other.

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.

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 */ }

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?

| 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.

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

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

Ah, there it is.

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".

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.

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?

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.

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

Reply on news.ycombinator.com