Firefox plans fix for decade-old browsing history leak Firefox developers say they're close to plugging an information leakage hole that has plagued every major browser for more than a decade. The cascading style sheets history attack makes it easy for web masters to compile vast lists of links visitors have previously viewed. It exploits technology in virtually every browser that …
" That means users of the NoScript add-on for Firefox will in many cases be protected against the attack. Then again, it's getting harder and harder to do anything online without Javascript."
Or you can just run Opera. Disable Javascript globally, and re-enable it for the sites you trust, and or need it...
No need for stupid bloaty add-ons...
What you describe is basically how NoScript works, Forbid globally, then whitelist either temporarily or permanently as needed. No bloat, and works really well in combination with AdBlock Plus and FlashBlock.
Why is it that no matter what the issue, some commentard invariably pops up with the admonishment that we "just use Opera"? I've tried it once or twice, and was disappointed with its ability to extinguish the crust of wiggling, flashing, bouncing advertising -- or, if you insist, the "enhanced browsing experience".
Shill much?
Most Open-Source supporters don't automatically assume everything M$ does is shit. We very carefully and throughout examined the issue before coming to the conclusion that everything M$ does is shit :)
Seriously though, not everything M$ does is bad. I for one am a fan of C# and Direct3D.
And Office is good to, although I'm not really willing to pay all that money for it when there are perfectly good alternatives available for free. I won't argue they are better, but they do all that I, and probably something like 99% of Office users, really need.
And I won't even start on Windows. That is a subject you can debate (or rather; yell nonsensical insults at each other) for years... And we have. - I will say this though; Windows 7 is extremely good compared to it's predecessors. In my experience, at least. (I won't pretend to be an expert on the inner workings of any version of Windows.)
However, IE is extremely bad; a horrid scar on Microsoft's name. Any professional web-developer, who has had the misfortune of having to develop cross-browser compatible websites (or worse; JavaScript), will tell you as much. -- This is why many of us dislike Microsoft so much, because they stubbornly keep IE around, and seem determined to avoid proper standards, forcing us to slowly go mad trying to deal with it's many shortcomings. It has little to do with their other products.
Is to be less clever for once. For god sake, put a bloody switch on the configuration named: "disable colored history markings on links" plus a note underneath saying:
"this does blah blah blah, while we fix the problem with a much more clever solution (not recommended)"
That way I could have been browsing for 9 years without being tracked.
But what can I say, software development nowadays (open source or not) is like modern Hollywood flicks, an excuse to make something shiny, not good.
Thanks Mozilla.
"Many proposed fixes threatened to bring browsers to a crawl or prevent users from knowing whether they had previously visited a website, trade-offs Mozilla, Microsoft and other browser makers have largely considered unacceptable."
Yes, I know...The security threat is real. CSS Styles can be made to resize text based on whether a link has been visited or not, and javascript is capable of measuring the size/properties of an element to detect whether the user has visited a link.
However the "visited" history feature is not that crucial a feature in the first place. It could easily be reset across browsing sessions without impacting general user experience, or it could be disabled across domains, or it could be disabled entirely.
Many of us configure to browser to clear history automatically anyways, so nothing lost.
Since they're determined to retain the feature, then I guess changing the color only is an acceptable compromise.
… does, as you seem to be saying, need to be more fine-grained. There are certain sites for which I *want* to keep history across browsing sessions, then there's everywhere else where either I would prefer to throw away the history (or not record it in the first place) or it doesn't matter.
Manual selective clearing is possible, but people are lazy.
There is no need for you to be insulting over something so trivial. For a start:
(1) I don't want my bookmarks autosorted. I want them where *I put* them. I.e. I am in control, not someone else *dictating* over me what I should do. (The one thing I would really like is being able to set a colour for each bookmark and folder, to allow me to quickly visually scan long lists, as I like to sort by subject rather than by name). My point is, there are smarter ways to sort a list than simply by name, and often its a personal preference how best to sort the list, something hard to code for every possible way, so freedom for users is important to let the users choose how best to do something. (We are controlled enough in our lives as it is, (and its getting worse all the time), so the last thing we need is yet more rules imposed on us all).
(2) If you absolutely cannot live without sorted bookmarks, you open the Organise Bookmarks menu item, then right click on a folder, and select "Sort By Name". Then hey presto, just like magic, its sorted.
So JavaScript has to be injected in a page and then a list of predefined URLs used to establish the colouring assigned by the browser based on page history. That excludes capturing anything useful from the querystring and implies that there's already a script injection vulnerability, something of far greater significant in any case.
"So JavaScript has to be injected in a page and then a list of predefined URLs used to establish the colouring assigned by the browser based on page history."
Almost... One merely needs to visit a website containing the javascript to be affected.
For example, theregister.com web developers could test whether cnet.com was in your browser history.
...to implement a proper set of permissions for JavaScript, such as one that disables access to "private" information? The closest I want scripting to access my history is the "history.back" command. Anything else, it would be nice to switch off. As well as "can scripting access http:// or ftp:// or predefined ports (SMTP for instance)?" or "can scripting access my favourites in any way OTHER than 'add to favourites'?".
These are not so much bugs, but inherent weaknesses in the script design itself, and perhaps better than messing with the visited link functionality would be to simply look at these weaknesses, then implement a proper set of options where the user can slam the door on them. I view my history with Ctrl-Sh-H, I don't need script to do it.
Mozilla, fix the real problem please...
I guess you didn't actually understand what the issue is. Scripts can't actually access the history.
Previously visited links are displayed in a different format. CSS can used to set a style for previously visited links. So a Javascript script can test a long list of links, and based on the current style, figure out if you went to the site or not.
But this is such a trivial disclosure. You'd have to go to a page with this script, and this big list of links. I'm pretty sure the big list of links would have actually displayed, though they could be white-on-white, and nearly invisible. And my entire browsing history is only known, if you could guess which sites I might have went too. There are tens of millions of websites in the world.
Of course, the scope of this tracking is limited to specifically looking for individual URLs and checking "have you visited paypal.com" rather than trawling ALL your history. So no need to worry that someone will discover you were looking at fatgranniesonline.com or whatever.
Ok, so that doesn't mean it's safe, it just means it can only be used for very specifically targetted attacks. So how to fix it?
The "simple" answer might be to only return CSS properties (such as element width) for the link based on their standard properties and NOT what is defined for A:visited. Sounds great, but it won't work. You could put that link element in a fixed-width container with another variable-sized element, and then measure the change in that second element to deduce the width of the first (and therefore whether it's being shown as :visited or not).
So, the true solution (other than disabling :visited CSS highlighting altogether, which is going way to far in my mind) is to restrict CSS formatting of :visited so that only styles that cannot affect the rest of the page layout are implemented (such as foreground colour, background colour, opacity), meaning css properties such as font-weight, font-famiily, font-size, width, margin, padding etc, etc would be silently ignored. AND then once you've done that, make reading the properties of the link in javascript only return the default element properties, not the values defined in :visited - so you have no programmatic way of determining whether a link is visited or not. Or at least I can't think of any. I don't know if canvas or any other new fangled thing can be distorted into getting the actual pixel colour of a link and returning it - I'd hope not.
What we need is a Seal of Good Web Design, like the W3C ones for HTML 4.01 etc, but sites are ONLY allowed to claim compliance with the standard if they degrade gracefully but remain fully (or nearly or 80% or whatever) usable without any Flash, Javascript or any other extension. Sites need to be shamed into working properly without Javascript. Its amazing how simple web security becomes then.
I always love when I hit a white page with one setence that basically says "click here to navigate without ..." and I am able to very quickly and easily do what I want without a bunch of expanding and collapsing context menus or waiting for a series of cascading combo menus to load up lists of 75K different OS and product options.
KISS!
There's quite a lot that can be done on the server these days, via PHP, that would make JavaScript somewhat less relevant, but it does have its uses.
On my site are some movie reviews. Some of the reviews contain items that could be considered spoilers, so it is useful to put them in a separate "layer" when can be toggled visible and invisible as required. JavaScript does this.
In another part, I use scripting to determine whether to display romaji using circumflex accents (like "ô") or proper caron accents (like "ō" (if you can see that)). At the moment, I make many assumptions based upon the type of browser. It would be a hell of a lot simpler to ask "does this machine support Unicode?" but I have not figured out how (suggestions welcome!). Anyway, what you get shown depends upon what the script determines your capabilities to be. Oh, and there is <noscript> to, that reverts to circumflex behaviour to be more compatible with old systems that don't have script (or Unicode) rather than newer systems with script blocking...
Having updated to Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2) Gecko/20100307 Mandriva Linux/1.9.2-0.1mdv2010.0 (2010.0) Firefox/3.6, visited links on the Register will not show up in a different way at all.
On an other PC with a slightly older version of Firefox there is no problem.
I hope this "problem" will be fixed, eventually.
All proposed solutions including NoScript fail to block the simplest of CSS-history leaks; That of specifying a unique background URL for :visited links. Then simply check which of the URLs have been requested. It also escapes attention by not sending the results back by XmlHttpRequest.
Even by rendering first with links in the unvisited state then rendering a second time does nothing to stop the leak and nearly halves browsing speed.
A more reasonable compromise was to restrict the visited status by a same-origin policy. It was downloadable from safehistory.com but sadly it's unmaintained and incompatible with modern browser versions. Also there still remained the chance of history sniffing as part of an XSS attack - albeit slightly reduced.
The only way to plug the leak is to turn off layout.css.visited_links_enabled for good.
"It's high time that it was made a legal requirement for ALL web pages to retain basic functionality with javascript, flash, animations of all types and externally hosted code disabled."
That is BS. It is basically impossible these days to make a decent site without Javascript. You can be a Javascript luddite if you want, but Javascript is the future of all consumer computing. Google Docs? Gmail? There are going to be Javascript editions of basically everything you use a computer for, and then all of the non-Javascript editions will be discontinued.
Also, Javascript is not "externally hosted".
Limited Scope?
Once the prefered search engine has been identified, the URL to be tested can be generated dynamically to include a list of rubrics ... eg car loans, jobs, Pr0N, Paris Hilton etc Then when a 'hit' is detected backtracking to that particular URLs sitemap gives another set of specific links to check. Make no mistake, mature versions of this exploit do not stumble blindly, they are hunting.
We know of at least one car dealership and several office supplies outlets that use this exploit to 'provide a more personal user experience' which invarialbly means hiking the price up if the visitor has not seen the cheaper one on a competitors web site and offering a free cuddly toy if they have.
Pretty much every site I am aware of, and almost every commercial site I've worked on over the last 14 years uses the :visited selectors for specifying colours, background-images, underlines, etc. as part of the site design and to improve usability. As a developer, I wouldn't consider using something that does not conform to the standards. Web developers have used this for years because it's part of the CSS spec and thus considered safe.
And now Mozilla are seriously considering breaking widely used functionality and moving away from the standard, because they want to pander to a few paranoid beardies in sandals who wouldn't know usability and design if it bit them in the arse. Why, thank you very much.
I consider myself to be reasonably security conscious, but I find it hard to see what exactly the security issue is.
From what I understand, the only way this "bug" (and I use the term in the loosest possible sense) can be exploited is when the "attacking site" has a link to *exactly* the URL in its HTML / JS that the visitor has been to before. This means that the "attacking" site can't ask the browser to give up the history, but it has to ask whether it has been to URL xyz.
I would suggest that anybody worried about this has more pressing issues than keeping their browser history private.
BTW, @grumpy: "Site developers have done stuff according to the CSS specification, and now Mozilla is thinking about ignoring web standards so that everybody has to fix their style sheets in order to placate a handful of paranoids." There, fixed that for you.
you use a car. it turns out that the manufacturers - or the petrol station or, indeed, anyone in the car biz - can now discover whether you've been to any particular place, and whether you were going a certain speed. (Not Plod: anyone who sees you.)
you use an oven. it turns out that the manufacturers (and anyone else involved in the world of cooking) can now discover whether you've been cooking chicken, or hash cakes, or anything else they ask about...
you use a browser. it turns out that any website that cares to ask can find out whether you've been to www.revolutioninchina.com, or to any other site they want to ask about...
how lovely that a few of you clueless techies think that because you personally can find a way round this, then it isn't a problem.
you worthless, clueless people.
you are the problem.
Fule,
People knowing where you've been driving is only a problem if you weren't driving on the public highway in full view of everyone else at the time.
Anyone who matters who's watching you browse Chinese revolutionary websites won't be using Javascript tricks on websites, they'll be monitoring your connection directly and blocking you accessing them with their big firewall. Derr.
You worthless, clueless tin-foil hatters.
Next they'll be inventing a mode that hides all the pr0n you browse by leaving no trace of it in your history. Oh hang on a minute...
Well, there's your answer then, innit. Make Pr0n mode disable the 'visited link' functionality of the browser and the history list in the Javascript location object. Then you can browse in that all day if you're bothered about your history being acquired by spies. If this causes a website to 'break', then it's the user's fault, not the websites nor Mozilla Corp's. You chose to enable it, you dirty dog.
Anyone in favour of the Pr0n modes of all the browsers dropping support for a:visited etc, please give a thumbs up on this message. I rate it as two thumbs fresh, myself.
The Caja project addresses this problem for websites that want to include third-party HTML without allowing JS in it to sniff history or do other nasty things. It uses a similar method -- limit how fancy styles can get for :visited (nothing that changes layout), and then present the unvisited styles whenever JS tries to observe computed CSS.
http://code.google.com/p/google-caja/
Sits over there in the corner mumbling to itself.
At Netscape 4.72 they could store your browsing history.
Stuck with 4.6 because of that.
Endured websites that broke W3 just because they could (Would have been fired where I worked but then a f**k lot of programmers should be eating at soup lines.)
History.
Is no longer repeating itself.
It is back.
and it is mad.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
