Changes to :visited in Firefox/Gecko

Thanks for the article.

I do not use a:visited on my website, so this is probably good for me but I am shocked at the different scripts out there that would actually track over 2000+ pages of history. That is just amazingly crazy.

An interesting use of the history exploit is http://www.haveyourfriendsbeenthere.com, which you can use to figure out which sites (out of a few dozen) your friends have visited.

Warning: Quick way to destroy a friendship.

+1

This reminds me of the changes that were introduced to the way text measured in px’s is treated in browsers these days on resizing. Browsers used to follow the specs. for that, but the last one to do so was IE6 I believe.

If there is a problem with the specification, then change the specification, don’t just ignore it.

O darn, it’s depressing to see browser makers consciously interfering with the specs.

when it’s combined with getComputedStyle() in JavaScript it means that someone can walk through your history…

I’m ignorant of JS, but couldn’t they just set a rule that getComputedStyle() can’t be combined with :visited?

But ralph, it’s for our own protection! Like when our government banned paddo’s (magic mushrooms) because some foreign tourists came over, drank a lot of alcohol, did a bunch of crack and PCP and other Major Drugs, and then also some mushrooms, and then jumped out of windows and killed themselves… well, we can’t have a government that lets people do that sort of stuff to themselves, so let’s ban the drug that was least likely to cause the problem and tell people it’s for their own good.

Those who care will move to another country. I expect FF 3.6 will probably force me over to Opera as my main surfing browser, which is a shame because there’s no NoScript for Opera. Maybe I should jump on them for that. But at least Opera correctly shows PNGs with a colour profile of sRGB (which according to the Gimp guys, that’s Gimp’s version of “no colour profile” because it’s the only thing you can choose anyway, so I guess changing my profile is out unless I want to download some Gimp colour profile plugins… or I could just tell people using the inferiour browser that it’s the cause of the page they see, and switching to ANY other browser (even the One Who Must Not Be Named) will miraculously fix the problem).

Someone can set a padding on visited links, and then you can just figure out the position of some other element below the visited link. If it moved, then you know the link was visited. There are also other clever ways of going around the mere blocking of getComputedStyle().

I don’t know why Stomme poes continues to rant. He’s now throwing dirt onto Safari and Firefox for choosing the right decision of supporting the optional bits in PNG images that specifically tell how the displaying program should manage the colors in the image. What, crazy to actually follow the PNG specification?!

And on whether one should violate a spec, consider this: Say a spec exhibits a major security hole – is it unreasonable to fix this security hole immediately, rather than letting your users run the risk of getting exploited as your proposal is considered? Regardless, even if Mozilla proposes this to the standards community (assuming that they haven’t), and the community decides to fix the problem, you still end up at square one: unable to use a large number of CSS properties. Vying for a proposal to come before action is just playing with dice, hoping that others don’t see the need to fix this exploit.

I don’t know why Stomme poes continues to rant. She’s now throwing dirt onto Safari and Firefox for choosing the right decision of supporting the optional bits in PNG images that specifically tell how the displaying program should manage the colors in the image.

I’d be happy enough if it simply wasn’t on by default. Webmasters shouldn’t have to go back and change thousands of images for a browser because it happens to have this stuff on by defualt (who wants to talk a client through about:config?)

http://hsivonen.iki.fi/png-gamma/

A few lines of code easily changes thousands of images, and then it’s merely a matter of uploading the new files. Safari 2, the last major foothold on problematic color correction, has also been out for more nearly five years now, so it is fully a web developer’s fault if s/he embedded color correction information in his/her PNG images, somehow expecting the images to look right with CSS color values. This leads us back to what I have been suggesting: don’t put color correction in your images if you don’t want them color corrected, and the problem is that CSS doesn’t support color profiles.

It’s also not reasonable to talk the clients of photographers through about:config so that their photographs don’t look flat and dull. At least with color correction on though, webmasters can do something to disable it on their own, whereas photographers cannot do anything to turn on color correction in the other situation. We also end up with a very problematic situation where there will be people who have it on and others who don’t.

I apparently do not have the option of removing profiles in my editor:

Yup, that’s what I have when I make PNG’s. In fact, because I have not downloaded any profiles, that’s my only option, and it’s supposed to mean “none”. I should not have to excessively play with images or editors to make them work in browsers where previously they worked just fine. Nor do I want browsers trying to guess what profile my personal monitor is using if they can’t get it right (FF 3.5+ on two Windows machines do not show a problem, but Macs and Linux do). People should have to turn “correction” on, not off.

No profile attached = shouldn’t have the problem. However, if it’s not way, then your PNG images are indeed tagged. Check your images with TweakPNG to see if there are any color management related chunks.

Either way, it’s not a browser vendor’s fault if the program you use isn’t capable of doing something.

Also, Firefox and presumably Safari get the color profile information from the system, so they don’t guess any more than your system does.

Also, Firefox and presumably Safari get the color profile information from the system, so they don’t guess any more than your system does.

I’ve wondered if that had something to do with why some OSes have mismatched colours and others don’t. What I don’t know is if an OS running on an OS (Windows running on a Virtual Box running on Linux) has a separate system profile or not, seeings how they are using the same monitor.


(I’ve been dragging this way off topic)

In any case, the question seems to be, will other vendors jump onto the :visited protection scheme? And how will this actually work once it gets implemented.

Occam’s razor suggestion - but if this is really a problem why not have the browser load all images linked in the CSS file immediately whether it needs to display them or not? That would foil the privacy issue while retaining legitimate use. There’s a cost in bandwidth, but I think it’s a fair cost for the flexibility requested.

BTW, as long as css background positioning isn’t affected I don’t care. When I do use a visited state to a link button it’s going to be part of a larger CSS sprite.

Presumably that would still leave the door open for timing attacks, since images bog down the rendering process.

Explain.