Skip to Main Content

www link pointer imageA long-standing privacy vulnerability that exists in every major Web browser is about to finally get fixed, thanks to Mozilla engineer David Baron.

On March 31, the Mozilla security blog announced that they are testing a solution to the issue, which currently allows Web pages to sniff through your browser history to identify which Web sites you've recently visited. That history information could then be used to create more convincing phishing attacks, or it could be sold to advertising companies without your knowledge.

Ever since the earliest graphical Web browsers, it has been a common practice for Web pages to display links using a different color depending on whether you've visited the link recently. By default, Web browsers typically use blue for non-visited links and purple or red for visited links. This provides the user with a useful visual clue about where they have been, but it has also created an opportunity for the Web site to figure out where you have been. With a little bit of JavaScript code, a Web page could create a link, check the link's "computed style" to determine whether it's the "visited" color or the "non-visited" color, and use that information to determine whether you've been to that URL before. A Web page could run this process on a giant list of URLs, then report the results back to the server, and you may never know anything happened.

While this issue has been known for many years, there never seemed to be a good solution. One possibility was forcing visited and non-visited links to always look the same, but that would break the visual clue that users have come to expect. Another possibility was to prevent JavaScript from checking how a link is styled, but a malicious Web site could get around that by indirectly checking its style, by crafting a set of style rules so that visited links affect the appearance of other elements on the page, and then checking the appearance of those elements.

David Baron proposed some changes that would effectively eliminate this vulnerability, while still allowing visited and non-visited links to display differently and minimizing the impact on today's Web. The solution consists of three major parts:

  • Reduce the types of styles that may be applied on the basis of whether a link has been visited. Basically, visited and non-visited links may only differ in color.
  • When JavaScript checks the computed style of an element, the browser will respond as if all links were non-visited.
  • Make sure the browser displays visited and non-visited links at the exact same speed.

The first change will likely have the biggest impact on existing Web sites. Currently, it's possible for visited and non-visited links to visually differ in size, font, underlining, spacing, images and any other styles available in modern stylesheets. Once this change is implemented, they will only be able to differ in font color, border color and other non-image color aspects. For example, on many sites, it's a common convention to suffix external links with a little arrow image, often using different images to match the font color on the link. After this change, they will always be displayed using the non-visited link image.

abstract technology imageThis change will also remove a Web page's ability to style elements around links on the basis of whether the link has been visited. For example, it's currently possible to use the CSS rule "a:visited + div {color: red;}" which means, "When there is a 'div' element after a visited link, give the div a red font color." After the change, this will no longer work; the div element will always be styled as if the link is non-visited. This prevents JavaScript from determining the visited status of a link based on the appearance of other elements.

Due to this first change, the only elements that may appear differently depending on whether a link has been visited are the link itself and any elements within the link. And even then, they may only differ in colors. This paves the way for the second change: the browser will lie to JavaScript and pretend that all links look non-visited. Since the only differences are in color, the browser doesn't have to do the extra work of recalculating sizes and positions to determine how the non-visited version would look; it just remembers the colors for both the visited and non-visited states, and it always reports the non-visited ones.

While those two changes should fix the vulnerability, there's still one loophole that remains: It is possible to construct style rules such that a visited link and a non-visited link would take significantly different lengths of time for the styles to be applied. A Web page could make use of this fact and use JavaScript to time how quickly the style is applied to the link in order to determine whether the link has been visited. The third proposed change would be to make sure the browser calculates both possible states (visited and non-visited) before applying any styles. This would ensure that the amount of processing time is consistent and that there is no detectable difference.

These changes have not yet been finalized, and there is still discussion about what additional types of styling might be safe enough to allow. Firefox is the first major browser to begin implementing these changes, but other browsers are likely to follow suit if this approach proves effective.<>