privacy-related changes coming to CSS :visited

For more information about this, have a look at David Baron’s post, the bug and the post on the security blog.

For many years the CSS :visited selector has been a vector for querying a user’s history. It’s not particularly dangerous by itself, but when it’s combined with <a href="https://developer.mozilla.org/en/DOM/window.getComputedStyle">getComputedStyle()</a> in JavaScript it means that someone can walk through your history and figure out where you’ve been. And quickly – some tests show the ability to test 210,000 URLs per minute. At that rate, it’s possible to brute force a lot of your history or at least establish your identity through fingerprinting. Given that browsers often keep history for a long time it can reveal quite a bit about where you’ve been on the web.

At Mozilla we’re serious about protecting people’s privacy, so we’re going to fix this problem for our users. To do so we’re making changes to how :visited works in Firefox. We’re not sure what release this will be part of yet and the fixes are still making their way through code review, but we wanted to give a heads up to people as soon as we understood how we wanted to approach fixing this.

These changes will have some impact on web sites and developers, so you should be aware of them. At a high level here’s what’s changing:

  • getComputedStyle (and similar functions like querySelector) will lie. They will always return values as if a user has never visited a site.
  • You will still be able to visually style visited links, but you’re severely limited in what you can use. We’re limiting the CSS properties that can be used to style visited links to <a href="https://developer.mozilla.org/en/CSS/color">color</a>, <a href="https://developer.mozilla.org/en/CSS/background-color">background-color</a>, <a href="https://developer.mozilla.org/en/CSS/border-top-color">border-*-color</a>, and <a href="https://developer.mozilla.org/en/CSS/outline-color">outline-color</a> and the color parts of the <a href="https://developer.mozilla.org/en/SVG/Tutorial/Fill_Stroke_and_Gradients">fill</a> and <a href="https://developer.mozilla.org/en/SVG/Tutorial/Fill_Stroke_and_Gradients">stroke</a> properties. For any other parts of the style for visited links, the style for unvisited links is used instead. In addition, for the list of properties you can change above, you won’t be able to set rgba() or hsla() colors or <a href="http://www.w3.org/TR/css3-color/#transparent">transparent</a> on them.

These are pretty obvious cases that are used widely. There are a couple of subtle changes to how selectors work as well:

  • If you use a sibling selector (combinator) like :visited + span then the span will be styled as if the link were unvisited.
  • If you’re using nested link elements (rare) and the element being matched is different than the link whose presence in history is being tested, then the element will be drawn as if the link were unvisited as well.

These last two are somewhat confusing, and we’ll have examples of them up in a separate post.

The impact on web developers here should be minimal, and that’s part of our intent. But there are a couple of areas that will likely require changes to sites:

  • If you’re using background images to style links and indicate if they are visited, that will no longer work.
  • We won’t support CSS Transitions that related to visitedness. There isn’t that much CSS Transition content on the web, so this is unlikely to affect very many people, but it’s still worth noting as another vector we won’t support.

We’d like to hear more about how you’re using CSS :visited and what the impact will be on your site. If you see something that’s going to cause something to break, we’d like to at least get it documented. Please leave a comment here with more information so others can see it as well.


176 comments

  1. […] Blizzard has done a nice roundup of David Baron’s post, the bug and the post on the security blog which discusses the :visited […]

    March 31st, 2010 at 22:02

  2. […] Older Article […]

    April 12th, 2010 at 11:41

  3. Daniel

    It’s funny because I just recently read an article describing how this CSS attack worked and I just got into this developer preview so I’m pretty happy to see this (even though I doubt anyone I know would know how to pull this off.)

    April 17th, 2010 at 08:21

  4. Alex

    What about css gradients?

    April 21st, 2010 at 12:03

  5. Nikke

    Personally, I can see why getComputedStyle needs to lie. But why the possibilities for styling needs to be limited escapes me.

    It’s a bit of a bummer, because I’ve often solved the problem of differentiating visited links from unvisited links by reducing visited links’ opacity by a small fraction, instead of replacing the color altogether. That allows for one, global rule for all links, regardless if there are differently colored links in one document.

    Privacy protection is always welcome, but it shouldn’t come at a too high price.

    April 21st, 2010 at 21:23

  6. Shivanand Sharma

    I agree with Nikke. If we are making getComputedStyle to lie then we shouldn’t have to cut down on CSS functionality. Additionally this should only be implemented for the “Private Browsing Mode”.

    If we were to go hunting after these privacy issues we’d end up making a browser with “Private Browsing” as the only mode because there are so many privacy and security issues and growing everyday.

    April 23rd, 2010 at 16:37

    1. Christopher Blizzard

      Shivanand –

      It’s not enough to make getComputedStyle() lie. You also have to prevent any properties being set on an element that would change it’s style such that the change could be detected by measuring another element. That’s why the colors are the only thing you can change – they don’t change the size. Box changes all affect layout in a way you can measure quickly, which is why they aren’t allowed.

      April 23rd, 2010 at 17:20

      1. Matti Schneider-Ghibaudo

        Yes, I had thought about the box size measurements… But why forbid background-image or opacity modification? It would have been a good way to still be able to present users with pretty checkboxes, for example :)

        May 17th, 2010 at 02:18

        1. Shaun Spiller

          I don’t know about opacity, but background image must be blocked. Otherwise you could do:
          a.somedomain.com:visited {
          background: url(/logvisited?somedomain.com);
          }
          That doesn’t even need JavaScript to scrape URLs.

          May 21st, 2010 at 16:57

          1. Matti Schneider-Ghibaudo

            I understand, you’re right.
            Well, what about something nicer: you don’t allow changing the background, but you’d still allow for background positioning. This way, we could still put a padding and a sprite for the background, and change the position of the background for visited links only, therefore showing checkboxes or whatever only there :)

            May 25th, 2010 at 11:49

        2. Mathieu

          Because then the malicious script could know from a server-side script when a specific url is called and each unique url would have it’s own “background-url” property. Don’t know if that was clear.

          May 24th, 2010 at 17:21

  7. Christopher Blizzard

    I will also point out that the changes have been checked into WebKit that work just like the changes we made to Gecko. So this change will be in all the browsers soon enough.

    April 23rd, 2010 at 17:21

  8. Cyrus Omar

    Could canvas/SVG be used somehow to map the element in and then grab the blitted pixels?

    April 26th, 2010 at 19:28

  9. mauro

    But you could still add a 1px padding to all links exept visited, and then getComputedStyle (if it returns a empty string then it is visited)

    Can’t you make that :link styles apply to :visited also? That way you couldn’t make different styles for them

    And it’d be greate if you add the outline to the supported styles for :visited, becouse it wouldn’t affect the others (would it?)…

    :P

    May 23rd, 2010 at 21:37

  10. Luca

    About to preserve user’s privacy:

    setting to false Firefox’s “layout.css.visited_links_enabled” option completely disable visited link styling and I think that it’s a too drastic solution.

    Why not to introduce an option that permit to style visited link ONLY IN THE CURRENT DOMAIN?

    It may substitude “layout.css.visited_links_enabled” option with, for example, an “layout.css.visited_links_scope” option with numeric values: 0 = visited link totally disable, 1 = visted link enabled only for the current domain, 2 = visited link totally enabled

    May 27th, 2010 at 03:19

    1. Shadok

      Very good point and the logs are here anyway.

      But there should have a nother key to restrict that behavior to the nth level of the domain name, otherwise this will be abused through free or ISP-related hosting offers housing malicious scripts.

      P.S. It’s great to see how fast-paced the development is on this blog, great job guys !
      Too bad I can’t help technically, I hope to join one day :)

      June 16th, 2010 at 13:31

  11. Max

    If i change the border-bottom size for visited links it will change the box size, no? So.. guys did you even heard about similar technic based on checking image cache by measuring the speed of image loading?

    June 13th, 2010 at 20:36

  12. J.S.

    Are these restrictions intended to be a long-term solution or merely a temporary patch? It would be regrettable if removing CSS support became the norm for coping with security issues. Perhaps there is a way for the browser to recreate CSS effects internally (e.g., via Javascript).

    June 14th, 2010 at 18:53

  13. […] improvements: Mozilla always puts privacy first, and this latest beta fixes flaws in some Web standards that could expose your browser […]

    July 6th, 2010 at 14:38

  14. Euro

    It’s a good thing that Firefox 4 will use SQLite instead of JSON or XML,

    SQLite is a lot faster.

    July 7th, 2010 at 09:16

  15. Michael Kozakewich

    Ha, that would be an idea. The browser could render everything as if the link was unvisited, store that in getComputedStyle, and then visually present a re-rendered page that allows any CSS on visited links. Basically, showing one rendering to the screen and then opening the other to javascript and PHP. Naturally, background images or any other server call wouldn’t be allowed (but what about data:URIs?)

    But then, would that be worth a bit of visited-link styling?

    July 7th, 2010 at 10:54

  16. Matt Amacker

    Why are we happy with a solution where the API lies?

    Isn’t that a fundamentally wrong way to solve the problem? How many countless hours will be wasted when a clever engineer thinks, “hey! I can help my customer if I do X with the visited color”, only to find after much frustration and no practical assistance that the API is lying. Not cool – how many other API methods will suddenly be re-looked at when there is a legitimate bug because we’re not sure if they are lying too? We can’t assume that everyone is in the “know” about the lie.

    This is NOT the right way to solve it. It should throw an error if you are not allowed to see the value like canvas when you pull pixel data. Then we could provide the validation of same domain at the same time. Making APIs that lie has far further consequences than this single method call.

    Yuck.

    July 7th, 2010 at 13:36

    1. Bastian

      I also prefer a not lying API, the API should send errors or should thwart the grabber. If the grabber only get 10-100 results a second it would be wasted time to grab. How many Links are on a “real” webpage, not 30k+. Imho would a slow down much more good.

      July 8th, 2010 at 21:54

    2. Daniel Dinnyes

      Totally agree! Either a warning or an error should be given.

      November 9th, 2010 at 08:44

  17. Jacob Rask

    How about the :after and :before pseudoclasses with a content property? For instance: a:visited:after { content: 'visited'; }

    July 8th, 2010 at 03:33

  18. ZhouQi

    “:visited” style is a very very … very very very important sign for user to know which url he was visited.
    I don’t think it’s a good idea to limit designer to use css property which will reduce the web usability.

    July 8th, 2010 at 20:33

    1. Jason

      I never understood *why* styling a visited link differently was important. Almost every website I have worked on I have set the same style for links no matter the visited state.

      Shrug. Maybe it is just me…

      August 3rd, 2010 at 09:44

      1. ZhouQi

        Because most visual designers don’t understand the web usability.This is indeed very helpless.

        January 4th, 2011 at 18:59

  19. Stephen

    @Matt Amacker

    Yeah, but if it threw an error than that would indicate the link had been visited, because it’s a different outcome from querying a link that hasn’t been visited.

    I must admit, I don’t like it, but I’m not sure there’s a better solution.

    July 9th, 2010 at 05:38

  20. John

    What about text-decoration? That’s a huge one.

    July 9th, 2010 at 14:04

  21. Matt Amacker

    @Stephen

    Nope. It would throw the error at any attempt to access the value when you shouldn’t. Wouldn’t indicate one way or the other whether is was visited – just that you can’t look.

    July 9th, 2010 at 17:06

    1. Giso Stallenberg

      @ Matt Amacker

      Which would mean you’re no longer able to get ant computed style from any a-element

      August 8th, 2010 at 07:07

      1. Peter da Silva

        Would that be so bad?

        December 2nd, 2010 at 04:23

      2. Damon

        No, it would require getting rid of get computed style on ANY element, because of the box thing. If you make the link have a margin or padding than it’ll push other elements around the screen, making it possible to stick a span after the link and get the information that way, even if the a element itself throws an error instead of allowing getComputedStyle.

        December 13th, 2010 at 15:01

  22. Ant Gray

    I never ever seen someone using :visited, because it overrided by a{color:…}

    July 10th, 2010 at 23:39

  23. ab lafontain

    I can’t install Add-on Fire FTP. Any body else having that problem? It was fine in previous version.

    July 16th, 2010 at 12:41

  24. […] 원본 : privacy-related changes coming to CSS :visited by Christopher […]

    July 20th, 2010 at 06:20

  25. Buddhism For Vampires

    The Panopticlick experiment scares me, a lot, so I’m very glad to see this happening.

    Are the other Panopticlick vulnerabilities/recommendations being addressed in FF 4?

    July 20th, 2010 at 14:31

  26. Sebastian Ferreya

    I think this is ok for now.

    Ideally, the browser should allow full styling for visited links within the domain of the page being displayed, and degrade to the current solution for foreign URLs.

    This will give devs/stylers enough expressive flexibility while keeping privacy within safe technical boundaries.

    July 21st, 2010 at 12:33

  27. […] Amélioration contre les attaques CSS de fingerprinting. […]

    July 26th, 2010 at 05:22

  28. […] Se han implementado diversos cambios para mejorar la privacidad de los usuarios, como que el selector de css :visited en sitios maliciosos no pueda intentar obtener información del histórico de navegación. […]

    July 27th, 2010 at 19:13

  29. White-Tiger

    If Firefox implement this shit, i will just use a other Browser and for then never recommend Firefox to anyone.
    Ok I’m a Guy who don’t care that much about my visited links, but because i have nothing to hide so its wayne to me.

    But a Browser should do what a Browser should. So when i tell the Browser to do something (and it’s a valid standard) it should do it, otherwise the Browser is just crap and i should better use a correct working one.

    The other thing is that such “security” isn’t security. So there are points that makes such exploit unimportant:
    1. a scripts needs long to brute-fore enough “interesting” data.
    2. such script needs much resources and i will detect it / the site that is the shit.
    3. sry but i don’t know the benefits to know users history^^
    4. such damaging to the browser what is called to be working here, does nothing as just damaging the browser, because if I’m not wrong you don’t need getComputedStyle() etc, you just need to read the current link color by using “javascript:node.style.color” and load a special URL to determine the color for visited links. (using an iframe for example).

    So as long you don’t disable :visited etc. in CSS there is no save way to prevent such abuse.
    The only way that should work, is a intelligent browser, so it should work like an AV and detects bad scripts and asking the User what to do. A script is for example dangerous when it uses a big loop and checking some link properties…. this doesn’t damage the browser and should work.

    This is just one short idea and i hope I’m not that wrong ;)
    Sorry for my English as well… hope it’s enough :P

    Kind regards
    White-Tiger

    July 30th, 2010 at 19:15

    1. Matti Schneider-Ghibaudo

      I’ll just answer to the points you give to prove the exploit is unimportant:
      1. How long does http://www.check-history.com/visitedsites.html take to load?
      2. Has loading the previous page made you detect any suspicious activity?
      3. One just needs to test which of the websites of the 10 biggest banks in your country you visited to know which one one should try to phish you with (possibly via tabnagging: http://www.azarask.in/blog/post/a-new-type-of-phishing-attack/ ).
      Or, perhaps less financially threatening, but quite annoying for privacy-related issues: this could also be used to know if you visited porn sites, or sites like meetic, or online games… Basically, it’s a threat for whatever you’d prefer people not to know you’ve been to.
      4. If the API lies, it lies. Period. No way of knowing anything through JavaScript if the browser pretends something that is not true, since JS is only asking the browser to give it the info.

      Your idea of detecting “bad scripts” is not implementable for there are so many ways to circumvent such checks (mainly because JS is extremely dynamic and could not be evaluated on load, for example). Beyond that, with the banks example, even testing only one bank is enough, since there should be statistically enough visitors to test phishing with some.

      I hope you now understand the problematic a bit better :)

      July 31st, 2010 at 15:27

  30. White-Tiger

    ah i see… ok.. phishing is a point^^
    and i see that JS isn’t that good i tough^^ So “.style.color” or “.color” doesn’t work^^ that’s bad^^ So getPropertyValue is of-course the only way
    But there should be a way to detect such by using Flash or Java… just make a Screen shot for example and then parse the text and it’s color^^ It’s more complicated but not impossible.

    August 1st, 2010 at 03:35

  31. Will Entriken

    Here is an attack on which still works against the proposed solution, please see source code and write up at:

    http://privacylog.blogspot.com/2010/08/mozillas-css-visited-solution-is-still.html

    August 2nd, 2010 at 09:17

    1. Peter da Silva

      This is not a vulnerability usable for automated attack. It’s a social engineering attack that could be used to check MAYBE one or two websites per visit, and not too often. The getComputedStyle attack can be used to check thousands of sites per page. It’s like the difference between cracking passwords using rainbow tables against a hashed password file, and cracking passwords by trying to log in to a site using its normal interface.

      December 2nd, 2010 at 04:33

  32. Giso Stallenberg

    When the API would not lie, but instead throw an error, one would also know the link is styled with the pseudo class visited, which is exactly what’s trying to be avoided here.

    August 8th, 2010 at 07:04

    1. Dennis

      It should throw an error on every use of getComputedStyle() and friends.
      Or better, FF should block JS execution and give the warning that privacy unsafe JS is being used, similar to the way it does now when the web site is trying to get the location of the browser.

      December 11th, 2010 at 12:28

  33. […] En rettelse i implementeringen af CSS-standarden, så hjemmesider ikke længere kan se hvilke andre sider du har besøgt. […]

    August 12th, 2010 at 06:22

  34. FrozenKnight

    I was thinking it might be better to create a blacklist of CSS and JavaScript, so that the user could blacklist the properties and such that would not be allowed and the behavior they use when triggered. Maybe this could be set up with a site exclusion, for some games that give rewards for clicking on adds and such. (Or in case you want to enable it on certain sites)
    I personally feel this would be the best solution, some of these could be enabled by default and be user editable.

    August 20th, 2010 at 12:13

  35. Henrik

    Please tell me this won’t in any way affect my personal style sheets (using Stylish and similar).

    August 25th, 2010 at 16:42

    1. Henrik

      Looks like it will. User styles, user agent styles, and author styles will all be handled the same way …

      August 26th, 2010 at 07:13

  36. Sebastian Ferreya

    Blogs need a voting system a la Reddit. Get those good comments floating to the top.

    August 26th, 2010 at 00:56

  37. Hugh

    I use a border-bottom to style my links (looks nicer and stands out better than text-decoration:underline). Unvisited links are solid, visited links are dotted.

    This breaks that styling, and left me very confused for a long time.

    I understand the rational for breaking that part of CSS, and I guess I’m okay with it. I just wish there was a workaround.

    September 4th, 2010 at 12:50

  38. John Farren

    getComputedStyle is not the only part that is lying, the whole document.getElementById(“any_element”).style is not anymore accessible.
    How in the world do you think this is a viable solution ?
    Best Regards

    September 7th, 2010 at 08:36

  39. louis

    hey,this is one of the best posts that I’ve ever seen; you may include some more ideas in the same theme. I’m still waiting for some interesting thoughts from your side in your next post.

    September 25th, 2010 at 20:19

  40. YuriKolovsky

    Just disable javascript for the :visited links… no need to touch the css.
    I mean, provide the non visited links values to javascript when browsing in private mode but keep them looking like they always did.

    September 30th, 2010 at 08:32

  41. James B.

    I rather agree with White-Tiger: I’m going to consider going to another browser. When I get a page full of links, I need a reliable way to be able to hide or otherwise modify the links that I’ve already visited so I’m not repeating myself. This is a daily inefficiency thing that translates to tons of wasted time. While I appreciate the thought of protecting my privacy, there has to be a way to do it while still allowing me to control visited links better.

    October 2nd, 2010 at 12:38

  42. Will Entriken

    James,

    What are you talking about? That can be done with CSS, and maybe some JS that doesn’t care if a link is visited or not.

    October 3rd, 2010 at 08:21

  43. James B.

    According to the original entry, only colors can change, not visibility. Since JavaScript can’t access the browser history, you also can’t do it there either, but that’s also the point of the privacy issue. I can understand breaking the JS methods, but it doesn’t make sense that CSS is also being broken.

    October 3rd, 2010 at 22:21

  44. Spider

    Don’t forget to add an option to disable/enable this feature…
    And other solution will be to fake visibility to the sites other than current domen.

    October 13th, 2010 at 04:14

    1. thinsoldier

      +1 to both suggestions.

      I find visited link styles invaluable on some sites, especially forums, and I’ve written userstyles for a few of my fav sites that involve more than just a change to link color.

      And if we limited visited to work only within the current domain mozilla wouldn’t need to disable any of the styling would they? Or would that somehow still not be safe enough?

      October 15th, 2010 at 08:29

    2. thinsoldier

      And for any kind of large/deep banking/stock market like site where in-domain history would still be valuable then could we have a meta tag or http header to tell the browser to definitely not track history?

      October 15th, 2010 at 08:32

  45. Lay

    This is incredibly good news. The fact that no browser currently protects its users from these attacks has been bothering me since I first heard of them (which was not long ago, but I understand the attacks were observed for nearly 10 years and that the identification via social network’s groups is known for months).

    To be honest, I was checking the features’ list to see if this was going to be implemented, and getting ready to send a request if not.

    This will greatly weight in favor of Firefox in my What browser should I use? dilemma. At the moment, I also use Opera, as there are a few reasons that make it a better choice for some of the things I do. This is the case mostly in browser-based games in which:
    – the speed at which you can validate a form on a tab, switch to the next tab, validate again, switch again etc makes Firefox a bad choice, especially as in some cases when the form runs some javascript when submitted, Ctrl+Tab fails to switch tab),
    – Opera’s userscripts are more powerful than GM scripts thanks to the BeforeScript event handlers that allow the user to prevent or modify a page’s script before it’s run. I gave a fast try at doing the same thing by writing a Firefox addon, but (probably because I didn’t do it well), this greatly slowed down the page’s loading, while in Opera it doesn’t.

    So with Firefox 4, it will be Firefox for general purpose browsing (NoScript, AdBlock, this :visited change and other addons I love), and probably still Opera for browser-based games.

    October 15th, 2010 at 05:03

  46. thinsoldier

    My coworker may have found a bug

    #navigation a, #navigation a:visited {
    color:#fff;
    padding-top:7px;
    text-align:center;
    }

    Despite both regular and visited links being told to have padding, once the link is visited the padding attribute disappears.

    Now I wouldn’t write this rule this way but apparently some people do and they might get confused/annoyed. So, if the visited and normal link styles are defined in one rule the :visited should just be ignored and stick with the normal unvisited link style

    October 15th, 2010 at 08:25

    1. Matti Schneider-Ghibaudo

      :D

      It’s not only confusing, even more importantly, it’s a hole! So, if one writes rules this way, then the padding is ignored after the link is visited… One then just has to measure the size of the enclosing box to get the info! Cool…

      October 15th, 2010 at 08:49

  47. Daniel Dinnyes

    I am not a web developer, still I would like to give my two cents.

    As “Matt Amacker” pointed out above, the lying API without any warning or error message would be a source of lots of frustration.

    Also the functionality changes affect many people as we have seen above. One thing is mentionable though: none of them complained that they miss the functionality of being able to use JavaScript to access the style attributes of an element previously modified based on the :visited property. All of the complaints were from end-user, look-and-feel, and design perspective.

    Even though I don’t know the internal details of page rendering in WebKit, I would suggest introducing a new “layer” of rendering, with limited access rights. Executing CSS and JavaScript code which depend on the :visited flag should only be possible inside this “limited access layer”. This way the style changes introduced by these scripts won’t be visible in the normal, “full access right” layer. Not sure if this is realistic or implementable.

    November 9th, 2010 at 09:05

  48. YuriKolovsky

    Another solution is to just remove cross-domain :visited links.

    November 10th, 2010 at 01:06

  49. Sebastian Ferreyra

    Yuri: I agree completely. I’ve even posted a similar proposal here before (search above), and elsewhere too actually, but it has remained ignored so far.

    Perhaps we should make some noise to get heard.

    November 10th, 2010 at 09:21

  50. Paul

    I almost agree with the cross-domain :visited. But there is one issue:

    You might want to legitimately link to other domains and you’d want users to be consistently informed (via css) that they have already clicked the link. The browser would have to store the origin of the history item to be able to discriminate between users who used your site to access the link or users who used another site or the address bar to do this and that is too much.

    As for user stylesheets, I agree with a per-domain setting, if you trust the site you just disable the “fix”.

    I can’t imagine a legitimate reason for wanting to use JavaScript to find out if a link has or has not been visited (you might say enhancing user experience by providing targeted content). All reasons you might have I’m sure you can live easily without or you can find other ways to achieve a similar effect on your own domain (think local storage and cookies), so maybe no one really cares about the JavaScript part of the fix.

    About the guys saying they’ll use other browsers, just do that if you feel that these changes are harmful to your experience, you live in a free world still you don’t need to threaten you won’t use Firefox, no one cares what YOU use but what the majority does (Firefox has a lot of advantages you will not find in any other browser and I know you care more about those than about underlining links with a border).

    Most users would be happy to know a vulnerability in their software was fixed with very little impact to their user experience (color is the attribute used 90% of the time to signal visited links). Anyway it’s a huge step in the right direction that you don’t use Internet Explorer anymore, thumbs up for that. (Try hiding your visited links using a color similar to the background instead of really hiding it)

    Saying that another browser is a good substitute is like saying “I’m glad visited links work in my other browser even if some other CSS breaks the design horribly because the rendering engine is not really as good as Firefox’s”. You’re probably safest using Chrome as an alternative from this point of view, although wait … they also decided to fix the problem in a similar way, crap, you have to fall back to one of the “80% there” browsers or even worse, Internet Explorer (although IE 9 beta is quite nice).

    As a web developer I really don’t care about how this issue gets resolved, there are so many nice ways of solving the new CSS problems gracefully (or not at all as another web developer above noted) and JavaScript impact really does not matter. I would like the opt-out feature because it would help the ones with user stylesheets a bit, otherwise I really don’t care.

    November 11th, 2010 at 07:11

  51. YuriKolovsky

    @Sebastian
    The problem comes from javascript being able to share a users history using css, now I was appalled with the solution of just disabling :visited all together in the new firefox 4, just having some color changes means nothing.

    Current: Global History->Sitewide CSS->Sitewide Javascript->Site
    Should be: Sitewide History->Sitewide CSS->Sitewide Javascript->Site

    Makes more sense to me, now why would Mozilla not implement this? Either they are stupid, which I doubt is the case, or there is some other reason not to implement it, something that you and I don’t know, I just wish some Mozilla developer would share their insight.

    November 11th, 2010 at 07:57

  52. cw3theophilus

    I am Web Designer and I am appalled at this solution to the privacy problem. I use :visited everyday to set apart links in my site that the user has been to so that the user doesn’t get confused or lost with what they have visited and what not.I also use it with JS to write a new CSS rule to show which page the user is currently on. Especially in my nav bar.
    Many times I need to use opacity, gradient backgrounds, borders, font-weight, text-decoration and background images to set them apart.
    I do not care about getComputedStyle as I practically never use it.

    My suggestion is to either limit :visited to links in the same domain – I mean who cares if a site can see which pages in their site you have visited; they can anyway do the same thing with google analytics – or to disable getComputedStyle completely as only very advanced sites and applications ever use it.

    If this feature is not updated and fixed I will not be upgrading to FireFox 4 but will be sticking with version 3 even if I can’t use all the nice HTML5 features.

    November 12th, 2010 at 07:10

    1. André

      Well you can stick with FF3 if you want, but the users will be moving on to ff4 (or the compatible mozilla seamonkey 2.1), and that is what counts.
      Personally I am very pleased that bandwidth-robbing special effects such as images are being abandoned.
      It you can’t produce decent effects with foreground, background, border, and outline colours you’ll be left behind by others that can.
      And Mozilla (and eventually other) users will appreciate the benefits of better privacy and less wasted bandwidth.
      As well as fewer overly complicated web pages.

      December 15th, 2010 at 01:48

    2. e.r.

      yes.. i hate that new limitation.. now i have to save in a db which link was clicked by a user to hide it afterwards.. change it to domain limitation!!!!!!

      June 7th, 2011 at 13:50

  53. Gary Hvizdak

    Presently I use a:visited { background-color : transparent; }. I just reloaded Google Chrome after having un-installed it many months ago and discovered that some of my links are blacked out after having been visited. All of the affected links have a background color set via the :link pseudo class. Interestingly, links that set the :visited background color to the same :link background color don’t have this issue.

    So Im wondering if this new Chrome bug is related to the proposed Firefox :visited change?

    November 15th, 2010 at 23:07

  54. ARCN

    I hear IE 9 is going to have a “no follow” browser button one can engage. Can FF not have the same thing without having to do all the other stuff you have mentioned?

    December 10th, 2010 at 20:59

  55. Paul

    You guys really don’t get it do you? No one cares if web developers upgrade or not to Firefox 4. Users will and developers will have to cope with these changes so stop boycotting instead try to come up with constructive ideas. Most people saying they won’t upgrade sound like little kids who got their candy stolen.

    You might be affected (a niche of the web developing world will probably feel the impact of this change because most only use color), but users do not care, as they did not care about IE6. You did not use IE 6 yet 65% of your users did, did you stop fixing bugs for it back then? This thing in Firefox will not even be a bug, it will be a well documented security feature described even before the official launch. Most normal users WILL upgrade to FF4 and no one will care how you feel about that. BE F-ING CONSTRUCTIVE OR SHUT UP.

    I have been a web developer for more than 6 years and I really don’t think that having to code to this limitation will actually hurt me.

    December 12th, 2010 at 01:06

    1. ray

      Well said.

      December 25th, 2010 at 05:17

  56. awsdert

    I think that this is a good change, I mean all you should need for indicating a visited element is a change of color and what would a good developer need with the users entire history. Furthermore to get a user’s site-wide history for the session the server can simply be program to create a list for each session, then the list can be used later by scripts that need it (with a user-h.php or something similar to pass the list to JavaScript via AJAX.)

    December 12th, 2010 at 04:06

  57. Joe Honton

    Before taking this step, please consider the Electronic and Information Technology Accessibility Standards (Section 508), published in the United States Federal Register on December 21, 2000, to wit:

    § 1194.21 (g) Applications shall not override user selected contrast and color selections and other individual display attributes.

    § 1194.21 (i) Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

    § 1194.22 (c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.

    December 13th, 2010 at 20:32

  58. awsdert

    While those are important to consider it is also important to consider your target audience, for example a gaming site is unlikely to be visited by the blind and would normally have been designed with colour-blind people in mind.

    December 22nd, 2010 at 13:32

    1. Andrew

      Not to mention that CSS has nothing to do with user selected colors. That is something you set in firefox’s settings, and I’m pretty sure that firefox doesn’t let CSS over ride this anyway.

      December 28th, 2010 at 21:56

  59. YuriKolovsky

    @Paul
    What truly IS important is if firefox is taking the right path here, because in my opinion they will be fixing this so far “small feature” for a long time to come…

    January 4th, 2011 at 13:39

  60. Crystobal Lions

    I am a Fire Fox user and I am appalled that some developers are after so many years still functionally security illiterate. Developers, if you cant fix your golden code or go along with a secure framework or support a secure browser then step out of the way and let those who intelligently error on the side of security.

    Really, If you insist in bow to the pixel whore Babylon java script gods where security is a non thought or after thought at best, do it the privacy of your own local variable.

    January 9th, 2011 at 13:23

    1. Kafpauzo

      I hate this change. I want to use FF4 but because of this change. I’ll have to keep using FF3.

      Why? Well, it’s because the web is a confusing and cluttered space, and it’s hard to keep track of things you visited already. It’s frustrating to click a link, wait, oh noes, I visited this already, and then go back and doing it over again. It’s a guessing game with this change. A lot of developers keep visited links the same color as normal ones to keep the website clean and consistent.

      I use Stylish. Made my own script to add a slight glow around links I’ve visited. It overrides developers styles. It’s made my browsing of the internet way more efficient. I can visually see where I’ve been. It’s less frustrating.

      There are better ways to protect privacy. This seems like a lazy approach. Please change it back to how it was, and find a better way. It affects users as well, not only developers. A better fix would be to set the default history cache to only keep 1 or 2 days of history.

      I really want to use FF4 as my default browser. This change is making me stay on an older version.

      April 20th, 2011 at 02:09

      1. Paul Rouget

        @Kafpauzo You don’t get it. What your describing is not Firefox current behavior. Re-read the article. getComputedStyle is lying, but that doesn’t change anything for the end-user, who will still see the link “purple”.

        April 20th, 2011 at 14:55

        1. nomail

          FWIW, i have a bookmarklet that outlines visited links/images, it no longer works — this new feature should have been optional. I appreciate firefox looking out for my privacy by default, but I don’t appreciate losing the choice — i understand its part of the philosophy to have less configuration options, but dammit, we need to have more :)

          May 5th, 2011 at 02:01

          1. FLskydiver

            Don’t like this isn’t a user option. I use a bookmarklet to hide text and image links I’ve already visited and Firefox 4, which I’ve just updated to, kills it.

            Please allow us to choose not to use this “feature”!

            May 8th, 2011 at 19:37

  61. sdfpokdfsj

    Keeping the old behavior within the current domain like someone else mentioned sounds like a good idea.

    January 15th, 2011 at 06:02

  62. stfuandrtfm

    It’s about time someone has taken the initiative to enforce function (security) over form. I don’t give a rats hind end about the color of the hyperlinks as to whether or not i’ve been on a page, and if the only solution you can come up with is to use a method that can spill my computers guts to the highest bidder, then please, send me your URLs to your pages so I know not to ever visit them again. It’s developers like you who have let the masses of targeted advertising reign the web.

    January 21st, 2011 at 14:25

  63. Peter

    Quick spontaneous post before I forget: If you can only change color, then you lose some accessibility. If for example all unvisisted links are bold and visited are of normal weight then it is much easier to see for someone with a degree of color-blindness.

    And I really don’t get the reason for limiting what will be applied to visited links if it will simply lie when asked. All it seem to do is lessen design and accessibility abilities without a real need to do so. Let functions lie all they want but leave the design part out of it.

    January 23rd, 2011 at 18:36

    1. Matti Schneider-Ghibaudo

      Please read Christopher Blizzard’s comments and mine (first page, search for “April 23rd, 2010 at 5:20 pm”) :)

      January 24th, 2011 at 05:03

  64. MJ.

    Are You KIdding Me? Good Grief ! If Firefox Crashes Once More This Today/Week;. I’ll Try Not To Scream. WTH ?

    Yet I Do Appreciate The So Called “Security” Update Of Firefox. About Time Someone Picked Up Their Brains And Skills And Produced With Them.. Has Been A Long Time Coming.
    Am So Very Untrusting Of Google/Chrome Google Always Have Been. Will Never Use It Ever.
    Absolutely Did Not Appreciate Chrome Google Downloading It’s Self On My Puter. Right Pass McAfee Too !

    February 3rd, 2011 at 20:39

  65. trlkly

    The thing is, you don’t break functionality to fix a bug. If the problem is that certain styling on visited links can give people information. Bold is screwed up because it makes text take up more space, which can be queried. The way to fix that is either to do what Chrome does and keep bold the same size as nonbold.

    Loading a background picture is a problem because it queries the server. So make it where the background is already preloaded upon page load. Heck, that would fix pretty much everything–analyze everything as if all links had been fixed.

    Finally, fingerprinting is a concern, but a lot of people don’t give a crap. Those of us that do aren’t going to run Firefox vanilla in the first place. We’ll use adblock, noscript, and, in risky situations, the built in private browsing mode.

    This is just a step backwards. JavaScript + CSS + HTML5 is supposed to be a fully functional system that will replace many overbearing plugins. Removing features so that people have to go back to relying on Firefox is just stupid.

    I really wish programmers would get off their soapboxes and design what the users want, rather than thinking they know better than the users they are supposed to be serving.

    BTW, I find it funny that they suddenly are okay with breaking standards, when before they didn’t give a crap. Designers are going to design to de facto standards, not what Firefox elitists tell them to do. Stop acting like IE.

    February 9th, 2011 at 04:38

  66. Cycron

    I think these changes should be enabled by default, but there should be a way to disable them.

    February 26th, 2011 at 15:43

  67. Frank Willwright

    I dont know. Dogs are the way to express feelings about CSS I would prefer yellow or brown. Default or not. Fingerprinting is a concern not nearby the wastelands of tomorrow and beyond. We are just little sparks in the immense web of information….Who cares! As time itself will catch up eventually. Regards!, Frank

    March 1st, 2011 at 14:34

  68. Steve

    Visited links are useless IMO. I doubt anyone will really notice if the whole visited concept went away. I for one have my history wiped when I shut down my browser, so I rarely see visited links. If your site is so complicated that someone needs to see where they have been then use cookies to track the user on your site or rethink your site, there might be a design problem.

    That said, there will always be people who like them. So allow them to be enabled please (visited off by default). Let us choose to risk having our history looked at. Then when most websites decide to stop using visited altogether you can finally totally remove visited features..

    March 2nd, 2011 at 02:09

  69. Kafpauzo

    The chosen solution is far more drastic and has far more wide-ranging impact than what’s necessary. A better solution would be this:

    — To thwart the non-JavaScript attack, where a server detects CSS background-image fetches: Regardless of the unvisited/visited state, always fetch both images, the visited and the unvisited, always in the same order. If other CSS properties exist that can have a similar impact, always act as if rendering both the visited and the unvisited versions.

    — To thwart detection by JavaScript: Determine the link’s dimensions and the resulting text flow for both cases, the case with the visited version and the case with the unvisited version of the link. Flow the page in such a way that there’s room for either version. Let the user see the correct version of the link in this space. Let JavaScript see the style settings of the unvisited version.

    — Do the same in cases of siblings and nesting. As above, prepare room enough for either version, display the right version, let JavaScript see the unvisited version.

    — Forbid only those CSS properties whose impact on rendering is so drastic that the above cannot work neatly, i.e. forbid properties like float, clear and display.

    With this solution, the huge number of websites that use various decorations in fully legitimate ways would still work fine. All they’d notice would be minor ugliness in the unusual cases where :visited is indicated with size-changing properties like boldface or border-width. And the only problem on these sites would be that the link size and text flow would become a bit ugly. The style’s signalling functionality would still remain.

    March 3rd, 2011 at 22:54

  70. Kafpauzo

    Just in case my explanation wasn’t clear:

    In the non-JavaScript case, although you fetch both the visited and the unvisited background images from the server, you let the user see only the one that is right according to the link’s visited/unvisited state.

    March 4th, 2011 at 02:12

  71. Joe

    There was a comment above stating “don’t remove functionality to fix a bug”. This assumption about good security is not realistic. There is no way to be secure without some restrictions on both the end user and the developer. Removing small pieces of functionality that prevent developers and users from using some parts of a functional piece is a non-sacrifice here. Data mining and identity theft are a much bigger issue than the ability to use a background image on a visited link. Good for the Mozilla Foundation! They have been brave enough to care for users security more than web developers pain points.

    Also there is a VERY good reason they removed this from a development standpoint. It has to do with separation of concerns. If you want to save state or be aware of previous activity there are mechanisms in place to do that. Using a presentation element to do what cookies or server side persistence should is just bad problem solving. Persistence and application awareness should not be mixed with presentation.

    March 5th, 2011 at 15:39

  72. th

    the new Firefox just rocks.

    March 5th, 2011 at 19:06

  73. Hawk

    I’m not liking these styling limitations.

    Why not limit getComputedStyle to URLs that have the same domain as the site that the JavaScript is running on? If the domains don’t match, then ‘lie’ and return a value as if the link is unvisited. If it’s the same domain, should be no problem.

    Why does CSS have to be crippled like this?

    March 8th, 2011 at 14:46

  74. T.

    Thank you Mozilla. As a user who just learned about this issue from a link in the Firefox 4 RC documentation, it is nice to know my privacy is in good hands even if lazy developers are angry that they can’t use some obscure CSS feature.

    March 9th, 2011 at 16:06

  75. Tar

    This change breaks “hide visited” type bookmarklet functionality, for example the one from:
    https://www.squarefree.com/bookmarklets/pagelinks.html

    If someone has a solution how to make “hide visited” work on FF4/SM2.1 then I’d really appreciate it.

    Bug 147777 – :visited support allows queries into global history – https://bugzilla.mozilla.org/show_bug.cgi?id=147777

    March 11th, 2011 at 07:35

  76. Carl

    Could someone “in the know” – preferably from Mozilla – please comment on all the suggestions that have been made about crippling some JavaScript functions instead of crippling the CSS?

    Most recently, “Hawk” wrote:
    “Why not limit getComputedStyle to URLs that have the same domain as the site that the JavaScript is running on? If the domains don’t match, then ‘lie’ and return a value as if the link is unvisited. If it’s the same domain, should be no problem.

    Why does CSS have to be crippled like this?

    March 11th, 2011 at 17:38

  77. Glenn

    This is about as good an idea as school uniforms are… and continuing to have to wear them once you graduate; but, yeah, sure… lets break accessibility for everyone, too. At the very least you should allow both user and user agent CSS to modify WTH it wants to (pssst: that’s why it’s called “cascading”).

    March 12th, 2011 at 10:05

  78. The Neighbourhood Nerd

    Why not have an alert that warns the user that the site is running this code?

    Warning: This site is attempting to access your history. Allow?

    And an option to block this behaviour permanently.

    March 13th, 2011 at 14:04

  79. YuriKolovsky

    @The Neighbourhood Nerd because that is near impossible, it gets this info from different places where you least expect it.

    March 15th, 2011 at 02:44

  80. Peter

    “Don’t rely on color alone.”
    http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#gl-color

    “Ensure that all information conveyed with color is also available without color, for example from context or markup.”
    http://www.w3.org/TR/WCAG10/#gl-color

    Surely standards are what Firefox is all about? Fooling the javascript is sufficient, you don’t have to compromise standards and accessibility on top of that. If a script can’t detect visited links then that is what counts, so there are no reasons to limit CSS just for the sake of it. Such a simple thing as to “unbold” or having a faded background on a visited link in menu would be impossible even if it would greatly increase scannability.

    I can only echo that once again, surely standards must count for something and certainly people with accessibility issues must be taken into account? And surely, feeding false values into the script is far sufficient? The values are already there, there is no real need to cripple CSS. No real need whatsoever.

    March 16th, 2011 at 17:47

  81. Peter

    @Carl: I concur, external links are what is causing the whole problem, right? Then those links can suffer the consequences if any. There might be a problem with web hosts that share the same domain but that should be easy to work around with regards to URL hierarchy.

    But I still thinks that just fooling the script with false values (color, border, images, layout – everything will “look” like it would if all links would be unvisited) are the best way to go.

    March 16th, 2011 at 18:01

  82. MattG

    The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.
    – 4th amendment of the U.S. Constitution

    My browser history is no doubt one of my effects. Any websites gleaning my browser history without a warrant are violating my 4th amendment rights. Shame on them. :P

    Imperfect security is not an issue, it’s the people who want to use it against you – that’s the real problem. Sometimes you block them, sometimes you allow them through, but either way, you teach them a lesson if you can.

    March 17th, 2011 at 11:09

  83. […] pone su privacidad en primer lugar, se corrigen algunos fallos que permitían a los chicos malos husmear y exponer el historial del […]

    March 19th, 2011 at 11:35

  84. […] Just a FYI, this no longer works. […]

    March 21st, 2011 at 08:00

  85. […] pone a su privacidad en primer lugar, se fijan las fallas en algunos estándares web que permiten a los chicos malos que husmear y exponer el historial del […]

    March 21st, 2011 at 08:09

  86. Duncan

    This really messes up usability for marking visited links!!

    Both my parents have short term memory loss (my Mother has Alzheimer and father has had a few strokes). They do not remember if they used a link or not.

    So they use a “hide visited” links bookmarklet I installed for them. Works like a charm but it breaks on FF4.0.

    This is doubly annoying as it is very hard to train them to use a new browser, which is my only option unless somebody has an alternative solution?

    March 24th, 2011 at 01:00

    1. Hemilton

      If they can’t remember having already visited a site why should they care?

      April 22nd, 2011 at 16:01

  87. One

    The user should be allowed to disable this feature. I used a custom global stylesheet via addon to change visited links opacity, and now I cannot. I’m not a developer, my :visited was usefull for ME.

    March 25th, 2011 at 07:12

    1. Tom

      I agree. I used userContent.rss to force the style of visited links and now this no longer works. I can understand why the change was made but the potential information leak is something I am willing to live with.

      This should be configurable via about:config (and disabled by default, of course).

      March 31st, 2011 at 15:55

  88. marc

    this is a stupid idea to disable the :visited styles.

    it really shows a lack of creativity of the programmers in charge, i’m sure there would be other ways to solve this small security issue.

    sad this came through, even IE9 and Chrome10 followed.

    April 9th, 2011 at 17:05

  89. ranimi

    I want the :visited functionality back too!
    I agree with Tom:
    “This should be configurable via about:config (and disabled by default, of course).”
    Ranimi

    April 12th, 2011 at 01:42

  90. GlitchMr

    And the webmasters will make our cookie to store visited links, you click link, it gets stores into cookie. Making this thing complex.

    April 14th, 2011 at 10:34

    1. ehsan

      salam

      April 29th, 2011 at 22:59

  91. Alan Gresley

    Is this security issue so hard to understand.

    [href*=”http://www.google.com/”]:visited {background: url(images/gallery/im1.jpg);}
    [href*=”http://www.google.co.uk/”]:visited {background: url(images/gallery/im2.jpg);}
    [href*=”http://www.google.com.au/”]:visited {background: url(images/gallery/im3.jpg);}

    If a background shows, then you have visited http://www.google.com/.
    If a background shows, then you have visited http://www.google.co.uk/.
    If a background shows, then you have visited http://www.google.com.au/.

    April 19th, 2011 at 09:36

    1. Alan Gresley

      The HTML was striped from the anchor links.

      April 19th, 2011 at 09:38

  92. Tomcat76

    What I don’t get: if you’re still allowing color settings, then what’s the point in disallowing other basic CSS settings such as font-weight? It makes no sense to me.

    From a personal stand, I’d like to say that my security is my own business. I don’t mind if an application comes with a set of basic security measures, but anything as drastically impacting CSS standards support as this should be configurable.

    I agree that full :visited control via CSS is not an absolute necessity, but the current options are too limited.

    April 23rd, 2011 at 08:18

  93. Henrik

    I run a website that doesn’t do much more than tell people about their browsing history, and – ofcourse – people are fully aware of how this works when they enter the site and run the diagnosis tool, I have no choice but to let this site “go to history” now. :-(

    April 30th, 2011 at 07:08

  94. Henrik

    Tomcat76: The reason as to why font-weight, border-size, height, width etc is disabled is probably because otherwise we would be able to use .offsetHeight, .offsetWidth, .offsetTop and such things to determine whether an url has been visited or not.

    April 30th, 2011 at 07:12

  95. Eric

    I don’t really care about this “feature” nor am I worried that some site knows where I’ve visited. Please give us the option to disable it.

    May 8th, 2011 at 15:23

  96. ben

    Having been a Firefox evangelist since FF1, I’m not going to use FF4 with this “feature” (not that you would care…). However, I feel that many other people think like I do.

    I think you’ve come to a point in development where you start (like many other companies) to take the wrong way; instead of trying to impose “your way” on us (thought, we overcame the totalitarian regimes – or M$ for that matter) you should give us a note and leave it up to us whether we want this option or not (=> implement a switch!).

    Just to make clear why I consider this option useful: Often – when browsing big link lists – the FF 3.x functionality allows me to tell the links I already visited from the ones I haven’t *although they might have different labels*.

    May 14th, 2011 at 04:47

  97. marc

    Hi there. I never used the :visited tag until today because of lazyness. Still the question arises if it wouldn’t have been enough to restrict the usage of :visited to links pointing to the same domain / site, instead of disabling the functionality alltogether. To determine if a user clicked on some link in ones own domain is possible by other means, so there’s no real security problem there.

    June 1st, 2011 at 10:01

  98. Glenn

    You know, given that you’re going lie to any application/site trying to “peek” into your “visited history” by saying “Nope, never been there.”, then why is it you feel the need to also screw the users ability to use CSS to style the links the way he/she wants to? For authors/site styles, go ahead–I don’t care. But for user/user agent styles, leave MY browser/pages alone to let ME style then as I want. The gall of some people…

    June 2nd, 2011 at 13:26

  99. […] CSS :visited selectors have been changed to block websites from being able to check a user’s browsing history […]

    June 9th, 2011 at 21:53

  100. […] this article by Mozilla, who explain what they are doing to help crak down on this, check it out here. Feel free to post up some comments, letting us know what your view on all this is. June 25, 2011 […]

    June 25th, 2011 at 04:53

  101. evrix

    if anyone cares, I addeda bkmklet with this javascript and it seems to work in ff 5.0 on xp
    javascript:(function(){var%20newSS,%20styles=’a:visited%20{color:%20white;%20background-color:%20white;%20display:%20none}’;%20if(document.createStyleSheet)%20{%20document.createStyleSheet(“javascript:'”+styles+”‘”);%20}%20else%20{%20newSS=document.createElement(‘link’);%20newSS.rel=’stylesheet’;%20newSS.href=’data:text/css,’+escape(styles);%20document.documentElement.childNodes[0].appendChild(newSS);%20}%20})();
    I just added “color:%20white;%20background-color:%20white;%20” right before “display:%20none”, which may be safely removed
    links with photos still show, but the related text gets *hidden*

    June 27th, 2011 at 12:20

  102. Jason Featheringham

    This seems innately backwards. Why wouldn’t you just filter getComputedStyle() for visited links instead? Poor judgement from my perspective.

    July 2nd, 2011 at 15:47

    1. evrix

      I just modified a bookmarklet working on previous versions and not made by me, I’m not so into js.

      ps: sorry for looong script line.

      July 3rd, 2011 at 11:45

  103. Julian

    I’m fine with that, but could you please tell me, how do I hide visited links now?

    July 3rd, 2011 at 09:33

    1. evrix

      just let your bookmark bar be shown and add the bookmarklet to it (i.e. add a bookmark with a name like “delete visited” and the code in place of the address), go to any webpage and click on the bookmark: visited links should hide or became white.
      to all: ‘m not a javascript programmer, as a matter of fact I’m not a javascript anything :), so any suggestion will surely do a better work

      July 5th, 2011 at 01:05

    2. evrix

      @louis
      Some css tags seem not to be any longer allowed in conjunction with visited links, did I miss something?

      July 5th, 2011 at 01:07

      1. louisremi

        I mean you can still hide links by using the same color and background-color. As the article states, it isn’t possible “display: none;” for instance.

        July 7th, 2011 at 05:39

  104. Julian

    Evrix
    That bookmarklet doesn’t work for me at all.

    Luisremi
    I would like to hide them, set them to “DO NOT DISPLAY”
    And if I cant do that with CSS like then how do I do it?
    I don’t have the time, nor knowledge necessary to make my own extension (and if the functionality is removed, then is there any other functionality to substitute that?).

    July 7th, 2011 at 07:47

  105. Moon

    Evrix,

    Thank you for trying to help! But that bookmarklet isn’t working for me either. I did exactly as you instructed, but the links do not change at all when I click on the bookmarklet I created.

    Is it working for anyone else?

    (By the way, I just installed Chrome to see if it replaces this lost functionality. Apparently, similar restrictions have been put in place in recent versions of Chrome, so that’s not an option for us.)

    July 11th, 2011 at 21:40

  106. ben

    Suggestions:

    1) Give us a switch to turn the new behavior of.
    2) Allow local “url(‘data:image/png;base64,…)” style changes to “background-image”.
    3) Allow changes to “background-color”.
    4) Provide us with a list of elements which can still be changed (the ones mentioned in “https://developer.mozilla.org/en/CSS/Privacy_and_the_:visited_selector” don’t work – except for “color”).
    5) Give us samples of sites employing the pre 4.0 “security hole”.

    July 13th, 2011 at 01:30

  107. Luis

    Hi,
    I have a page with lots of links marked with images. This is the page:
    http://luis.impa.br/foto/index1.html
    As you can see, I use yellow box-shadows around img links. Since this does not combine with the blue/magenta usual borders for unvisited/visited, I wanted the box-shadow to change colors accordingly to the unvisited/visited status, but this don’t work. I tried everything I could think of using CSS :visited.
    Is my problem related to the issue described in this page? Is it solvable with CSS?
    Thanks!
    L.

    July 24th, 2011 at 12:35

    1. louisremi

      Yes, our problem is likely to be related to the changes described in this page.
      Please read the article carefully.

      July 25th, 2011 at 00:47

  108. Nailgun

    I understand that this is an issue, but the current proposed solution is preposterous.

    This is terrible for colorblind or color-impaired users of Firefox; it completely shuts them out. I would hope that timing attacks would be ineffective if the (simple) text-decorations like line-through, overline, and underline were re-enabled. I understand that this is a security issue, but if the hole is big to the point that it impinges upon accessibility, dev should just bite the bullet and do a bloody retool.
    I’m going to write an e-mail about this and see how far I get with it; there needs to be another way to visually distinguish different kinds of text other than color. It would be a similar hindrance if non-color-styles for regular ‘a’-links were disabled for whatever reason.

    August 4th, 2011 at 05:42

  109. Danny

    This ‘nanny’ approach is simply wrong but if you ‘have’ to do something to ‘protect’ the users then you could, for example, clear FF’s history every 24h by default…

    To f*ck up CSS specs is simply ridiculous… What is next? You won’t allow people to log into Facebook?

    Education is a better approach that don’t let me do my bloody job! Have some ‘Tip of the Day’ or ‘Advisory of the Day’ pop up telling the user to get a clue and clean his 5 years old history.

    August 7th, 2011 at 12:25

    1. chee

      Wat. It seems a little barmy to prefer having your history to be deleted daily than there to be a limit on the styling of a:visited.

      In other notes, this doesn’t “f*ck” up CSS specs. Let’s look at the css2 spec together.
      http://www.w3.org/TR/CSS2/selector.html#link-pseudo-classes

      “Note. It is possible for style sheet authors to abuse the :link and :visited pseudo-classes to determine which sites a user has visited without the user’s consent.
      UAs may therefore treat all links as unvisited links, or implement other measures to preserve the user’s privacy while rendering visited and unvisited links differently. See [P3P] for more information about handling privacy.”

      This is actually in keeping with the spec, and slightly kinder than what the spec allows for.

      October 26th, 2012 at 09:37

  110. Axel

    Gimme a switch!

    I have been warned.

    Axel

    August 8th, 2011 at 01:06

  111. […] pone su privacidad en primer lugar, se corrigen algunos fallos que permitían a los chicos malos husmear y exponer el historial del navegador.Nuevos valores […]

    September 2nd, 2011 at 14:26

  112. ilPestifero

    Great work for our privacy.
    Thanks mozilla!

    September 26th, 2011 at 03:39

  113. Reason A Bubble

    I guess they aren’t reading the comments.

    The consensus seems to be that some sort of opt in toggle would be preferable to us being told “this is what you want, this is what you get”.

    I found the comment regarding the issue this creates for colour blind people to be very relevant.

    The road to hell is paved with good intentions.

    October 5th, 2011 at 15:27

    1. Christopher Blizzard

      Sorry, sometimes we miss comments. We’re not ignoring, just really busy sometimes.

      Let me check with David Baron, who wrote the original patch. (It actually might be a huge amount of work to support this, to be clear.)

      October 7th, 2011 at 07:06

    2. Christopher Blizzard

      Also is there a bug on file about this? It would help a lot.

      cc me and drop me mail – blizzard@mozilla.com

      October 7th, 2011 at 07:09

  114. Moon

    Agreed. I think the folks at Mozilla aren’t bothering because people aren’t jumping ship over this.

    Chrome has some of the same dictatorial policies, you see.

    Come on, Mozilla. At least add the option in about:config. I can’t think of a single excuse for you to remove important Firefox functionality unilaterally and not even allow an advanced user to reinstate it.

    If someone else can, I’m all ears.

    October 6th, 2011 at 20:37

  115. Lila

    There are lots of innocent uses of :visited, none of which are supported by FF 7, it seems. I understand the privacy concern, but why target the problem at the CSS-level? I use :visited to show users which parts of a website they have already been to, by changing the background-color of the link. Looks like now I need to change the text itself to provide this information – i.e. HOME (visited). Not the most elegant way – unless, of course, you use JS. Lots of JS. Which opens up all the JS-related security issues, of course.

    So, for security reasons, you are forcing people away from using just HTML and CSS to using javaScript to achieve the same effect? Please tell me this is a joke.

    October 7th, 2011 at 07:20

    1. chee

      You can still use background-color to style the visited links.
      You cannot use JavaScript to determine which links have been visited.

      The opposite of what you think happened happened.

      October 26th, 2012 at 09:30

  116. LeftEarofCorn

    I used display:none on visited links via bookmarklet for image galleries to know what images I’ve already viewed. When reviewing thousands of rather similar photographs for a job, it is terribly cumbersome to keep track any other way. With no about:config option to toggle this terrible new behavior, I had to roll back to FF3.

    October 7th, 2011 at 14:33

  117. Moon

    P.S. Why are comments posted out of order? I look like a real douchebag having apparently posted *after* that mozilla dev did.

    October 7th, 2011 at 16:35

    1. Peter da Silva

      They aren’t out of order. They’re nested but the nesting is kind of subtle gray boxes. The dev posted as a reply to the message, you posted a reply to the thread.

      October 8th, 2011 at 04:39

      1. Moon

        How odd. I don’t see any gray boxes or nesting (using latest version of FF). Perhaps it’s something unusual about my setup.

        I’ll leave it at that; don’t want to derail this thread.

        October 9th, 2011 at 04:38

  118. Moon

    I filed a bug report here: https://bugzilla.mozilla.org/show_bug.cgi?id=693164

    A Mozilla developer changed the status of the bug to Resolved (Invalid). I don’t know if he bothered to read the comments on this page, but it seems at least one developer does not deem this to be a problem.

    If you disagree, feel free to add to the discussion there.

    October 9th, 2011 at 08:15

  119. David P

    Why are transparent colors and changes to border-styles not allowed? Is there still work being done on this problem?

    I don’t understand why we can’t just have getComputedStyle() lie about everything including display and positioning, behaving as if the link was not visited. Maybe it’s a performance issue, having to keep track of a ‘true’ DOM layout and a ‘fake’ one, or in having to generate the ‘fake’ DOM element hierarchy on demand.

    If nothing else, at least let user styles have the freedom to work with visited links as we like. I totally support the above posted Bugzilla bug. This is still causing REAL users and loyal followers a great deal of pain.

    October 12th, 2011 at 16:33

  120. Bernd Schneider

    Let me start with saying that I’m not a developer but a webmaster who prefers to focus on the content, and not on fixing code bugs. I know relatively little about CSS, but as I’m running a completely hand-made website I won’t get any dedicated support on it either.

    Visited external links look horrible on my site now, because I used the same basic GIF background image that so far changed its color together with the link. Now it is teal vs. yellow besides white on black. The maximum penalty if you ask me.

    I have to explain my visitors
    1) Why it looks so bad.
    2) Why I don’t do anything about it.
    3) And perhaps to those who read something about the privacy subject I may have to justify why I was using “evil code” to sniff out their browser history (which of course I have never done).

    Options for me to fix the issue:
    1) Develop a whole new color/image scheme in which the background images always keep their color and still look good next to the link.
    2) Ditch all tags for external links. I needed a couple of days to work them into the code. It will take just a few clicks to disable the extra usability in the style sheet.
    3) Other options?

    November 8th, 2011 at 11:41

  121. roger21

    THAT SUCKS

    i had a greasmonkey script that allowed me to open all at once the unvisited link from a reddit page using getComputedStyle now it doesn’ work

    i had a stylish bstyle that changed the font weight of link from bold for unvisited to normal for visited (using :visited of course) it was very conveniant to highlight unvisited links and downlight visited ones now it doesn’t work

    THAT SUCKS

    at least ther could be a addons or something to bypass that THAT SUCKS

    November 15th, 2011 at 04:54

  122. […] But then, you shouldn’t rely on :visited. Indeed, it can be used for history sniffing, and browsers will probably end up removing support for most CSS properties that change layout (such as display), just like Firefox already does. […]

    November 15th, 2011 at 10:37

  123. Christos Georgiou

    Please: add an option in about:config that allows the :visited CSS functionality as it was; we have been warned about the security issues.

    November 17th, 2011 at 00:13

  124. armin

    about:config
    CSS functionality:visited

    doesn’t work

    November 24th, 2011 at 06:33

    1. Bernd Schneider

      and doesn’t help because it’s an individual setting.

      November 24th, 2011 at 07:24

  125. heike

    Oh, Klasse! ‘<
    Ich habe jetzt einen ganzen Nachmittag mit dem Versuch vertrödelt besuchte Links im FF unsichtbar zu machen – und eben zu meinem Entsetzen diesen Artikel gefunden.
    Wahnsinnsidee, Mann! Was soll der Mist?! :@

    December 19th, 2011 at 08:39

  126. popitto

    did you find a solution for this problem? i’m using FF 9.0.1 and i found an entry in about:config (layout.css.visited_links_enabled) it was ‘true’ so i changed it to ‘false’ but nothing changed! the color of the visited links are still the same (different from the visited ones)!

    January 23rd, 2012 at 09:02

  127. brenda

    I am taking a college course an this has crashed a lot
    I cant have that and lose all my work I updated the latest firefox there is no bar
    to let you print what am I supposed to do can you give me any suggestions

    March 25th, 2012 at 21:52

    1. Eric

      What does that have to do with CSS security?

      March 26th, 2012 at 10:54

  128. estrella

    no comment

    October 8th, 2012 at 18:29

  129. Serguei

    May be there are any setting in Mozilla browser to switch off CSS privacy for trusted sites?

    November 24th, 2012 at 18:37

  130. Moon

    All you people commenting really should consider posting your comments on the official bug report here:

    https://bugzilla.mozilla.org/show_bug.cgi?id=693164

    Posting here accomplishes nothing. Posting there raises the profile of the problem.

    November 30th, 2012 at 16:03

Comments are closed for this article.