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 getComputedStyle() 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 color, background-color, border-*-color, and outline-color and the color parts of the fill and stroke 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 transparent 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.

171 comments

Post a comment
  1. Pingback from Ajaxian » Stop sniffing my breadcrumbs! on March 31st, 2010 at 10:02 pm:

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

    Reply

  2. Pingback from Mozilla Developer Preview 4 Ready for Testing ✩ Mozilla Hacks – the Web developer blog on April 12th, 2010 at 11:41 am:

    [...] Older Article [...]

    Reply

  3. Daniel wrote on April 17th, 2010 at 8:21 am:

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

    Reply

  4. Alex wrote on April 21st, 2010 at 12:03 pm:

    What about css gradients?

    Reply

  5. Nikke wrote on April 21st, 2010 at 9:23 pm:

    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.

    Reply

  6. Shivanand Sharma wrote on April 23rd, 2010 at 4:37 pm:

    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.

    Reply

    1. Christopher Blizzard wrote on April 23rd, 2010 at 5:20 pm:

      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.

      Reply

      1. Matti Schneider-Ghibaudo wrote on May 17th, 2010 at 2:18 am:

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

        Reply

        1. Shaun Spiller wrote on May 21st, 2010 at 4:57 pm:

          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.

          Reply

          1. Matti Schneider-Ghibaudo wrote on May 25th, 2010 at 11:49 am:

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

        2. Mathieu wrote on May 24th, 2010 at 5:21 pm:

          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.

          Reply

  7. Christopher Blizzard wrote on April 23rd, 2010 at 5:21 pm:

    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.

    Reply

  8. Cyrus Omar wrote on April 26th, 2010 at 7:28 pm:

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

    Reply

  9. mauro wrote on May 23rd, 2010 at 9:37 pm:

    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

    Reply

  10. Luca wrote on May 27th, 2010 at 3:19 am:

    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

    Reply

    1. Shadok wrote on June 16th, 2010 at 1:31 pm:

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

      Reply

  11. Max wrote on June 13th, 2010 at 8:36 pm:

    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?

    Reply

  12. J.S. wrote on June 14th, 2010 at 6:53 pm:

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

    Reply

  13. Pingback from Firefox 4 Beta 1: Tell us what you think! :: The Mozilla Blog on July 6th, 2010 at 2:38 pm:

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

    Reply

  14. Euro wrote on July 7th, 2010 at 9:16 am:

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

    SQLite is a lot faster.

    Reply

  15. Michael Kozakewich wrote on July 7th, 2010 at 10:54 am:

    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?

    Reply

  16. Matt Amacker wrote on July 7th, 2010 at 1:36 pm:

    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.

    Reply

    1. Bastian wrote on July 8th, 2010 at 9:54 pm:

      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.

      Reply

    2. Daniel Dinnyes wrote on November 9th, 2010 at 8:44 am:

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

      Reply

  17. Jacob Rask wrote on July 8th, 2010 at 3:33 am:

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

    Reply

  18. ZhouQi wrote on July 8th, 2010 at 8:33 pm:

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

    Reply

    1. Jason wrote on August 3rd, 2010 at 9:44 am:

      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…

      Reply

      1. ZhouQi wrote on January 4th, 2011 at 6:59 pm:

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

        Reply

  19. Stephen wrote on July 9th, 2010 at 5:38 am:

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

    Reply

  20. John wrote on July 9th, 2010 at 2:04 pm:

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

    Reply

  21. Matt Amacker wrote on July 9th, 2010 at 5:06 pm:

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

    Reply

    1. Giso Stallenberg wrote on August 8th, 2010 at 7:07 am:

      @ Matt Amacker

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

      Reply

      1. Peter da Silva wrote on December 2nd, 2010 at 4:23 am:

        Would that be so bad?

        Reply

      2. Damon wrote on December 13th, 2010 at 3:01 pm:

        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.

        Reply

  22. Ant Gray wrote on July 10th, 2010 at 11:39 pm:

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

    Reply

  23. ab lafontain wrote on July 16th, 2010 at 12:41 pm:

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

    Reply

  24. Pingback from CSS :visited에 대한 프라이버시 정책변화 ✩ Mozilla 웹 기술 블로그 on July 20th, 2010 at 6:20 am:

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

    Reply

  25. Buddhism For Vampires wrote on July 20th, 2010 at 2:31 pm:

    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?

    Reply

  26. Sebastian Ferreya wrote on July 21st, 2010 at 12:33 pm:

    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.

    Reply

  27. Pingback from Mozilla Firefox 4.0 bêta 1 disponible ! | BabyGeek on July 26th, 2010 at 5:22 am:

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

    Reply

  28. Pingback from Firefox 4 beta 2 – Firefox Chile on July 27th, 2010 at 7:13 pm:

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

    Reply

  29. White-Tiger wrote on July 30th, 2010 at 7:15 pm:

    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

    Reply

    1. Matti Schneider-Ghibaudo wrote on July 31st, 2010 at 3:27 pm:

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

      Reply

  30. White-Tiger wrote on August 1st, 2010 at 3:35 am:

    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.

    Reply

  31. Will Entriken wrote on August 2nd, 2010 at 9:17 am:

    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

    Reply

    1. Peter da Silva wrote on December 2nd, 2010 at 4:33 am:

      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.

      Reply

  32. Giso Stallenberg wrote on August 8th, 2010 at 7:04 am:

    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.

    Reply

    1. Dennis wrote on December 11th, 2010 at 12:28 pm:

      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.

      Reply

  33. Pingback from Prøv Firefox 4 Beta! « MozillaDanmarks blog on August 12th, 2010 at 6:22 am:

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

    Reply

  34. FrozenKnight wrote on August 20th, 2010 at 12:13 pm:

    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.

    Reply

  35. Henrik wrote on August 25th, 2010 at 4:42 pm:

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

    Reply

    1. Henrik wrote on August 26th, 2010 at 7:13 am:

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

      Reply

  36. Sebastian Ferreya wrote on August 26th, 2010 at 12:56 am:

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

    Reply

  37. Hugh wrote on September 4th, 2010 at 12:50 pm:

    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.

    Reply

  38. John Farren wrote on September 7th, 2010 at 8:36 am:

    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

    Reply

  39. louis wrote on September 25th, 2010 at 8:19 pm:

    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.

    Reply

  40. YuriKolovsky wrote on September 30th, 2010 at 8:32 am:

    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.

    Reply

  41. James B. wrote on October 2nd, 2010 at 12:38 pm:

    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.

    Reply

  42. Will Entriken wrote on October 3rd, 2010 at 8:21 am:

    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.

    Reply

  43. James B. wrote on October 3rd, 2010 at 10:21 pm:

    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.

    Reply

  44. Spider wrote on October 13th, 2010 at 4:14 am:

    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.

    Reply

    1. thinsoldier wrote on October 15th, 2010 at 8:29 am:

      +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?

      Reply

    2. thinsoldier wrote on October 15th, 2010 at 8:32 am:

      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?

      Reply

  45. Lay wrote on October 15th, 2010 at 5:03 am:

    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.

    Reply

  46. thinsoldier wrote on October 15th, 2010 at 8:25 am:

    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

    Reply

    1. Matti Schneider-Ghibaudo wrote on October 15th, 2010 at 8:49 am:

      :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…

      Reply

  47. Daniel Dinnyes wrote on November 9th, 2010 at 9:05 am:

    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.

    Reply

  48. YuriKolovsky wrote on November 10th, 2010 at 1:06 am:

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

    Reply

  49. Sebastian Ferreyra wrote on November 10th, 2010 at 9:21 am:

    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.

    Reply

  50. Paul wrote on November 11th, 2010 at 7:11 am:

    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.

    Reply

1 2 3

Add your comment

  1.