Why can’t I set the font size of the visited link?
Hello, Habr! I present to you the translation of the article “Why can't I set the font size of a visited link?” by Jim Fisher.
Visited links are displayed in purple; not visited - in blue. This difference has come to us since the advent of the web. But CSS allows us to reconfigure these properties with the pseudo-selector: visited! Let's say you want to make the visited links gray and reduce their size in order to show the user that this link has already been visited.
This style is applied to the current page:
Coloring the link in gray, as expected, notifies us that it has already been visited, but the font size remains the same! This happens because changing the font size can be the cause of the vulnerability! If CSS can change the font size, I (Jim) can tell if you visited pornhub.com. But how?
Web pages are available to inspect the displayed items on the page. The most obvious way is to use window.getComputedStyle (). He talks about the properties applied to the aforementioned visited link; as reported by the browser: font-size: 18px; color: rgb (0, 0, 238).
If getComputedStyle reports a change in font size from 18px to 6px for the visited links, I (Jim) will understand that the page has created a link to pornhub.com, then I will check the font size in order to determine the browsing history of your browser. I can use this data for targeted advertising, I can sell your data or blackmail you, and so on ... The security hole was closed by prohibiting the font-size change for a: visited.
But the information obtained using getComputedStyle about the color of the visited link will be: rgb (0, 0, 238) - that is, blue. This is a lie - the link is gray! For the color property, browsers close the hole in the vulnerability in another way: instead of prohibiting changes, they force getComputedStyle to lie about the real value.
Why are two approaches used? Why can't we get getComputedStyle to lie about the font-size parameter too? The reason is that you can examine the displayed elements of the web page and other methods besides getComputedStyle. You can also check the position of an element on a page using .pageXOffset or .pageYOffset. Changing the font-size of the visited link will affect the offset of other elements, because of which you can indirectly check which links were visited. Disabling font-size for a: visited is a tough but reliable solution.
This link provides a short list of allowed properties, such as color, which should not affect the page layout and cannot be detected. All of them are different forms of color change. All other CSS properties are blocked.
In theory, there is no way by which it could be determined that the color of the visited link has been changed. The only possibility is a temporary attack: for example, if changing the color to pink took longer than blue, the page can measure how long it took to display the element and compare it with the expected duration.
PS:
Special thanks for helping me correct the translation for Olga Pereverzeva .
Thanks to Oleg Yatsenko ( Samber ), in the comments he drew attention to the fact that the solution to the problem with such a data leak was first implemented in Mozilla - the author of the solution is David Baron .
Visited links are displayed in purple; not visited - in blue. This difference has come to us since the advent of the web. But CSS allows us to reconfigure these properties with the pseudo-selector: visited! Let's say you want to make the visited links gray and reduce their size in order to show the user that this link has already been visited.
a:visited {
color: gray;
font-size: 6px;
}
This style is applied to the current page:
Coloring the link in gray, as expected, notifies us that it has already been visited, but the font size remains the same! This happens because changing the font size can be the cause of the vulnerability! If CSS can change the font size, I (Jim) can tell if you visited pornhub.com. But how?
Web pages are available to inspect the displayed items on the page. The most obvious way is to use window.getComputedStyle (). He talks about the properties applied to the aforementioned visited link; as reported by the browser: font-size: 18px; color: rgb (0, 0, 238).
If getComputedStyle reports a change in font size from 18px to 6px for the visited links, I (Jim) will understand that the page has created a link to pornhub.com, then I will check the font size in order to determine the browsing history of your browser. I can use this data for targeted advertising, I can sell your data or blackmail you, and so on ... The security hole was closed by prohibiting the font-size change for a: visited.
But the information obtained using getComputedStyle about the color of the visited link will be: rgb (0, 0, 238) - that is, blue. This is a lie - the link is gray! For the color property, browsers close the hole in the vulnerability in another way: instead of prohibiting changes, they force getComputedStyle to lie about the real value.
Why are two approaches used? Why can't we get getComputedStyle to lie about the font-size parameter too? The reason is that you can examine the displayed elements of the web page and other methods besides getComputedStyle. You can also check the position of an element on a page using .pageXOffset or .pageYOffset. Changing the font-size of the visited link will affect the offset of other elements, because of which you can indirectly check which links were visited. Disabling font-size for a: visited is a tough but reliable solution.
This link provides a short list of allowed properties, such as color, which should not affect the page layout and cannot be detected. All of them are different forms of color change. All other CSS properties are blocked.
In theory, there is no way by which it could be determined that the color of the visited link has been changed. The only possibility is a temporary attack: for example, if changing the color to pink took longer than blue, the page can measure how long it took to display the element and compare it with the expected duration.
PS:
Special thanks for helping me correct the translation for Olga Pereverzeva .
Thanks to Oleg Yatsenko ( Samber ), in the comments he drew attention to the fact that the solution to the problem with such a data leak was first implemented in Mozilla - the author of the solution is David Baron .