Slashdot Mirror

check this link its an ftp link
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

The link still says beta 7 because they aren't ready for people to download beta 8 yet. That's why the beta 8 page on the wiki says "Hi! We're glad you're interested in Firefox 4 Beta 8 - it's not quite ready yet."

The download link on the original page is old. It reads http://download.mozilla.org/?product=firefox-4.0b7&os=win&lang=en-US, so just change the "7" to an "8" and voi-la! A download link like so http://download.mozilla.org/?product=firefox-4.0b8&os=win&lang=en-US . Those from other locales may choose a diff lang or OS.

The download link on the original page is old. It reads http://download.mozilla.org/?product=firefox-4.0b7&os=win&lang=en-US, so just change the "7" to an "8" and voi-la! A download link like so http://download.mozilla.org/?product=firefox-4.0b8&os=win&lang=en-US . Those from other locales may choose a diff lang or OS.

Firefox 4 fixes the CSS history bug without having to kill visited links altogether. Essentially it lies to JavaScript so everything looks like it's not been visited.

Are we fast yet.com shows the measurements used by the Mozilla Javascript development team, comparing performance of ff4 to chrome/v8 and safari/nitro using both the sunspider (Mozilla) and v8bench (Google) test suites. LOTS of movement in Firefox over the past few months, including the apparent surpassing of Safari's Nitro engine in both tests and even beating Chrome's V8 in the Mozilla test suite.

This boost is likely due in part to the recently added hardware acceleration. This is listed as supported on all major operating systems (see the Firefox 4 Beta Technology page).

You may wish to re-try this on FF 4. There has been significant work put in to reducing disk access in Firefox:

• Use sqlite's WAL to reduce fsyncs and disk writes
• Write cookie data to disk less frequently
• Fewer files opened on startup
• Fixed the SQLite page size to increase performance on Windows

There is also a tracking bug for bad I/O patterns available, so you can see what they're up to.

You may wish to re-try this on FF 4. There has been significant work put in to reducing disk access in Firefox:

• Use sqlite's WAL to reduce fsyncs and disk writes
• Write cookie data to disk less frequently
• Fewer files opened on startup
• Fixed the SQLite page size to increase performance on Windows

There is also a tracking bug for bad I/O patterns available, so you can see what they're up to.

You may wish to re-try this on FF 4. There has been significant work put in to reducing disk access in Firefox:

• Use sqlite's WAL to reduce fsyncs and disk writes
• Write cookie data to disk less frequently
• Fewer files opened on startup
• Fixed the SQLite page size to increase performance on Windows

There is also a tracking bug for bad I/O patterns available, so you can see what they're up to.

You may wish to re-try this on FF 4. There has been significant work put in to reducing disk access in Firefox:

• Use sqlite's WAL to reduce fsyncs and disk writes
• Write cookie data to disk less frequently
• Fewer files opened on startup
• Fixed the SQLite page size to increase performance on Windows

There is also a tracking bug for bad I/O patterns available, so you can see what they're up to.

If you do get the beta, go and run this add-on, https://addons.mozilla.org/en-US/firefox/addon/200733/

It will help the Firefox developers learn how best to use hardware acceleration.

The problem is that people [buy a copy of Microsoft Office just for Outlook] instead of using an e-mail client instead.

Does the e-mail client have an appointment calendar? For example, are Thunderbird users aware of Lightning, a version of Sunbird packaged as a T-bird extension? There's a reason that Outlook's icon is a clock, and not just because the rim and hands spell "OL". And can it connect to Exchange at work, where IT has disabled standards-based connection protocols for nebulous "security reasons"?

I work in a small office (My own!!). My partner is a thumbfisted computer user, take Excel off his computer and he usually would use it as a lamp. BUT, after I installed Thunderbird+ lightning + shared gmail calendar, he was hooked.

Training time: 0

His happy face when he clicked his way to setting up a shared event: priceless

The problem is that people [buy a copy of Microsoft Office just for Outlook] instead of using an e-mail client instead.

Does the e-mail client have an appointment calendar? For example, are Thunderbird users aware of Lightning, a version of Sunbird packaged as a T-bird extension? There's a reason that Outlook's icon is a clock, and not just because the rim and hands spell "OL". And can it connect to Exchange at work, where IT has disabled standards-based connection protocols for nebulous "security reasons"?

One of the applications that can directly show the user if the website he/she is visiting uses DNSSEC is Firefox. There is a plugin for it here

I haven't used Opera's tab stacking yet, but it sounds a lot like one of the features the Tree Style Tab add-on adds to Firefox. It's quite a flexible add-on, and if you constantly have a lot of tabs open or would prefer to have a hierarchical tab list on the side to save vertical real estate (especially if you have a 16:9 monitor), it can revolutionize your world almost as much as tabs did originally. I can't recommend it enough.

I need a plugin that blocks comments on slashdot and other forums where people mention how great it is that they use Ad Block.

Ah, yes, you need FoxFilter 7.6.1 which includes keyword blocking (e.g., "ad block" "adblock"). You're welcome!

Password Hasher for Opera
Password Hasher Plus for Chrome
PasswordMaker for Firefox

Curious as to how this affects plugins like FireFox's SearchWP that has been around since Feb 2004

https://addons.mozilla.org/en-US/firefox/addon/376/versions/

And how did Google get it back dated to 1999? That was before Chrome even existed and we were in the Internet Explorer 4.0 days and Netscape.

Oh, I know that noooooow... :-)

Unfortunately, what I didn't know was that in the minor version upgrade that moved this particular parameter, they silently turned Java back on even if you'd explicitly disabled it before, so instead of enabling it only when work required, I was running with it enabled by default. By the way, if anyone is interested in a tragi-comic demonstration of people on the Firefox team completely missing the point when it comes to security issues, here you go. Please try not to throw rocks at your screen while reading...

https://addons.mozilla.org/en-US/firefox/addon/3282/

Think up a new password. Just one.
Pass = "PcbEn!"
The mnemonic for that password is "Passwords Can Be Easy Now!"

Now use that one simple password to create stupidly complex passwords for the sites you visit by using Password Hasher.

Every site you go to will have it's own unique mix of 26 upper, lower, numbers, symbols (if it supports it) that can be easily recreated in seconds without ever being written down or stored electronically.

All you have to remember is that passwords can be easy now.

Example password for Slashdot using this example is "nRP2zGk56sYN8IMUyFR/XpIx45" which is out of the brute force range this year and probably next year too.

For the very few oblivious people (esp on /.), here's your solution: Adblock

It's really just one more reason for me to not feel guilty about blocking ads. Sometimes I click on ads from sites which I trust and wish to support, but other than that, the hell with them.

For example, here's how you can opt out of the DoubleClick cookie for AdSense partner sites, DoubleClick ad serving, and certain Google services that use the DoubleClick cookie

Here's another way. One that doesn't rely on me trusting someone else to do something.

But yes, legislation to enforce this would be better, because it's one thing to have cookies that track you on a single site (useful for providing persistent site customization, shopping carts, etc), and quite another to share this across web sites, especially with "behavioral tracking".

As in Ghostery? Or do you mean a data-spoofer, not just a blocker?

(Two trackers on this page: Google Analytics, Doubleclick. Status: Blocked. (But then I'm logged in, so...))

( [Laughs] Google sent me to the French Mozilla add-on page. "So, you do not like our tracking, eh?")

Out of curiosity, why? It would seem to me that this (C#):

(x, y) => x + y

is much preferable to this (JS):

function(x, y) { return x + y; }

and is syntactically sugarlicious in JS 1.8 (MDC link) :

function(x, y) x + y

In the SSJS space, some frameworks support more recent JS specifications which include some more interesting language capabilities than lambda syntax. One of my favorites is destructuring assignment which is used often with the require() function in a way similar to Java's import statement.

New in JavaScript 1.7

New in JavaScript 1.8

Out of curiosity, why? It would seem to me that this (C#):

(x, y) => x + y

is much preferable to this (JS):

function(x, y) { return x + y; }

and is syntactically sugarlicious in JS 1.8 (MDC link) :

function(x, y) x + y

In the SSJS space, some frameworks support more recent JS specifications which include some more interesting language capabilities than lambda syntax. One of my favorites is destructuring assignment which is used often with the require() function in a way similar to Java's import statement.

New in JavaScript 1.7

New in JavaScript 1.8

From Jesse Ruderman:

The WSJ contains some factual inaccuracies, and the headlines on Slashdot and The Register are based entirely on those inaccuracies.

The article refers to a cookie-related experiment (bug 565475) that we ended in bug 570630. (I'm pretty sure this is what it refers to, since it mentions a May 28 landing, corresponding to bug 565475 comment 12.)

We ended that particular experiment because we decided the idea in bug 565965 would be strictly better than the idea in bug 565475 (see bug 570630 comment 0).

The idea in bug 565965 failed to make it into Firefox 4 because we didn't want to break desirable cooperation across websites, such as single sign-on, and haven't come up with a good UI (see bug 565965 comment 16).

Some of us were also concerned that the effect on advertisers would not be the effect privacy advocates want. Rather than abandoning targeted advertising, advertisers might increase their use of first-party redirects or switch to heuristic fingerprinting. These outcomes would be bad for privacy (users concerned about tracking could no longer simply disable third-party cookies) and bad for web performance.

The WSJ claims that we ended the experiment immediately after a conversation with an ad executive, but based on the history in bug 565475, it's clear that we did so before that conversation. The WSJ may have been confused because of the date of bug 565475 comment 18, which was made two days after the change it describes.

For more background, see https://wiki.mozilla.org/Thirdparty

From Jesse Ruderman:

The WSJ contains some factual inaccuracies, and the headlines on Slashdot and The Register are based entirely on those inaccuracies.

The article refers to a cookie-related experiment (bug 565475) that we ended in bug 570630. (I'm pretty sure this is what it refers to, since it mentions a May 28 landing, corresponding to bug 565475 comment 12.)

We ended that particular experiment because we decided the idea in bug 565965 would be strictly better than the idea in bug 565475 (see bug 570630 comment 0).

The idea in bug 565965 failed to make it into Firefox 4 because we didn't want to break desirable cooperation across websites, such as single sign-on, and haven't come up with a good UI (see bug 565965 comment 16).

Some of us were also concerned that the effect on advertisers would not be the effect privacy advocates want. Rather than abandoning targeted advertising, advertisers might increase their use of first-party redirects or switch to heuristic fingerprinting. These outcomes would be bad for privacy (users concerned about tracking could no longer simply disable third-party cookies) and bad for web performance.

The WSJ claims that we ended the experiment immediately after a conversation with an ad executive, but based on the history in bug 565475, it's clear that we did so before that conversation. The WSJ may have been confused because of the date of bug 565475 comment 18, which was made two days after the change it describes.

For more background, see https://wiki.mozilla.org/Thirdparty

From Jesse Ruderman:

The WSJ contains some factual inaccuracies, and the headlines on Slashdot and The Register are based entirely on those inaccuracies.

The article refers to a cookie-related experiment (bug 565475) that we ended in bug 570630. (I'm pretty sure this is what it refers to, since it mentions a May 28 landing, corresponding to bug 565475 comment 12.)

We ended that particular experiment because we decided the idea in bug 565965 would be strictly better than the idea in bug 565475 (see bug 570630 comment 0).

The idea in bug 565965 failed to make it into Firefox 4 because we didn't want to break desirable cooperation across websites, such as single sign-on, and haven't come up with a good UI (see bug 565965 comment 16).

Some of us were also concerned that the effect on advertisers would not be the effect privacy advocates want. Rather than abandoning targeted advertising, advertisers might increase their use of first-party redirects or switch to heuristic fingerprinting. These outcomes would be bad for privacy (users concerned about tracking could no longer simply disable third-party cookies) and bad for web performance.

The WSJ claims that we ended the experiment immediately after a conversation with an ad executive, but based on the history in bug 565475, it's clear that we did so before that conversation. The WSJ may have been confused because of the date of bug 565475 comment 18, which was made two days after the change it describes.

For more background, see https://wiki.mozilla.org/Thirdparty

From Jesse Ruderman:

The WSJ contains some factual inaccuracies, and the headlines on Slashdot and The Register are based entirely on those inaccuracies.

The article refers to a cookie-related experiment (bug 565475) that we ended in bug 570630. (I'm pretty sure this is what it refers to, since it mentions a May 28 landing, corresponding to bug 565475 comment 12.)

We ended that particular experiment because we decided the idea in bug 565965 would be strictly better than the idea in bug 565475 (see bug 570630 comment 0).

The idea in bug 565965 failed to make it into Firefox 4 because we didn't want to break desirable cooperation across websites, such as single sign-on, and haven't come up with a good UI (see bug 565965 comment 16).

Some of us were also concerned that the effect on advertisers would not be the effect privacy advocates want. Rather than abandoning targeted advertising, advertisers might increase their use of first-party redirects or switch to heuristic fingerprinting. These outcomes would be bad for privacy (users concerned about tracking could no longer simply disable third-party cookies) and bad for web performance.

The WSJ claims that we ended the experiment immediately after a conversation with an ad executive, but based on the history in bug 565475, it's clear that we did so before that conversation. The WSJ may have been confused because of the date of bug 565475 comment 18, which was made two days after the change it describes.

For more background, see https://wiki.mozilla.org/Thirdparty

From Jesse Ruderman:

The WSJ contains some factual inaccuracies, and the headlines on Slashdot and The Register are based entirely on those inaccuracies.

The article refers to a cookie-related experiment (bug 565475) that we ended in bug 570630. (I'm pretty sure this is what it refers to, since it mentions a May 28 landing, corresponding to bug 565475 comment 12.)

We ended that particular experiment because we decided the idea in bug 565965 would be strictly better than the idea in bug 565475 (see bug 570630 comment 0).

The idea in bug 565965 failed to make it into Firefox 4 because we didn't want to break desirable cooperation across websites, such as single sign-on, and haven't come up with a good UI (see bug 565965 comment 16).

Some of us were also concerned that the effect on advertisers would not be the effect privacy advocates want. Rather than abandoning targeted advertising, advertisers might increase their use of first-party redirects or switch to heuristic fingerprinting. These outcomes would be bad for privacy (users concerned about tracking could no longer simply disable third-party cookies) and bad for web performance.

The WSJ claims that we ended the experiment immediately after a conversation with an ad executive, but based on the history in bug 565475, it's clear that we did so before that conversation. The WSJ may have been confused because of the date of bug 565475 comment 18, which was made two days after the change it describes.

For more background, see https://wiki.mozilla.org/Thirdparty

From Jesse Ruderman:

The WSJ contains some factual inaccuracies, and the headlines on Slashdot and The Register are based entirely on those inaccuracies.

The article refers to a cookie-related experiment (bug 565475) that we ended in bug 570630. (I'm pretty sure this is what it refers to, since it mentions a May 28 landing, corresponding to bug 565475 comment 12.)

We ended that particular experiment because we decided the idea in bug 565965 would be strictly better than the idea in bug 565475 (see bug 570630 comment 0).

The idea in bug 565965 failed to make it into Firefox 4 because we didn't want to break desirable cooperation across websites, such as single sign-on, and haven't come up with a good UI (see bug 565965 comment 16).

Some of us were also concerned that the effect on advertisers would not be the effect privacy advocates want. Rather than abandoning targeted advertising, advertisers might increase their use of first-party redirects or switch to heuristic fingerprinting. These outcomes would be bad for privacy (users concerned about tracking could no longer simply disable third-party cookies) and bad for web performance.

The WSJ claims that we ended the experiment immediately after a conversation with an ad executive, but based on the history in bug 565475, it's clear that we did so before that conversation. The WSJ may have been confused because of the date of bug 565475 comment 18, which was made two days after the change it describes.

For more background, see https://wiki.mozilla.org/Thirdparty

From Jesse Ruderman:

The WSJ contains some factual inaccuracies, and the headlines on Slashdot and The Register are based entirely on those inaccuracies.

The article refers to a cookie-related experiment (bug 565475) that we ended in bug 570630. (I'm pretty sure this is what it refers to, since it mentions a May 28 landing, corresponding to bug 565475 comment 12.)

We ended that particular experiment because we decided the idea in bug 565965 would be strictly better than the idea in bug 565475 (see bug 570630 comment 0).

The idea in bug 565965 failed to make it into Firefox 4 because we didn't want to break desirable cooperation across websites, such as single sign-on, and haven't come up with a good UI (see bug 565965 comment 16).

Some of us were also concerned that the effect on advertisers would not be the effect privacy advocates want. Rather than abandoning targeted advertising, advertisers might increase their use of first-party redirects or switch to heuristic fingerprinting. These outcomes would be bad for privacy (users concerned about tracking could no longer simply disable third-party cookies) and bad for web performance.

The WSJ claims that we ended the experiment immediately after a conversation with an ad executive, but based on the history in bug 565475, it's clear that we did so before that conversation. The WSJ may have been confused because of the date of bug 565475 comment 18, which was made two days after the change it describes.

For more background, see https://wiki.mozilla.org/Thirdparty

From Jesse Ruderman:

The WSJ contains some factual inaccuracies, and the headlines on Slashdot and The Register are based entirely on those inaccuracies.

The article refers to a cookie-related experiment (bug 565475) that we ended in bug 570630. (I'm pretty sure this is what it refers to, since it mentions a May 28 landing, corresponding to bug 565475 comment 12.)

We ended that particular experiment because we decided the idea in bug 565965 would be strictly better than the idea in bug 565475 (see bug 570630 comment 0).

The idea in bug 565965 failed to make it into Firefox 4 because we didn't want to break desirable cooperation across websites, such as single sign-on, and haven't come up with a good UI (see bug 565965 comment 16).

Some of us were also concerned that the effect on advertisers would not be the effect privacy advocates want. Rather than abandoning targeted advertising, advertisers might increase their use of first-party redirects or switch to heuristic fingerprinting. These outcomes would be bad for privacy (users concerned about tracking could no longer simply disable third-party cookies) and bad for web performance.

The WSJ claims that we ended the experiment immediately after a conversation with an ad executive, but based on the history in bug 565475, it's clear that we did so before that conversation. The WSJ may have been confused because of the date of bug 565475 comment 18, which was made two days after the change it describes.

For more background, see https://wiki.mozilla.org/Thirdparty

From Jesse Ruderman:

The WSJ contains some factual inaccuracies, and the headlines on Slashdot and The Register are based entirely on those inaccuracies.

The article refers to a cookie-related experiment (bug 565475) that we ended in bug 570630. (I'm pretty sure this is what it refers to, since it mentions a May 28 landing, corresponding to bug 565475 comment 12.)

We ended that particular experiment because we decided the idea in bug 565965 would be strictly better than the idea in bug 565475 (see bug 570630 comment 0).

The idea in bug 565965 failed to make it into Firefox 4 because we didn't want to break desirable cooperation across websites, such as single sign-on, and haven't come up with a good UI (see bug 565965 comment 16).

Some of us were also concerned that the effect on advertisers would not be the effect privacy advocates want. Rather than abandoning targeted advertising, advertisers might increase their use of first-party redirects or switch to heuristic fingerprinting. These outcomes would be bad for privacy (users concerned about tracking could no longer simply disable third-party cookies) and bad for web performance.

The WSJ claims that we ended the experiment immediately after a conversation with an ad executive, but based on the history in bug 565475, it's clear that we did so before that conversation. The WSJ may have been confused because of the date of bug 565475 comment 18, which was made two days after the change it describes.

For more background, see https://wiki.mozilla.org/Thirdparty

From Jesse Ruderman:

The WSJ contains some factual inaccuracies, and the headlines on Slashdot and The Register are based entirely on those inaccuracies.

The article refers to a cookie-related experiment (bug 565475) that we ended in bug 570630. (I'm pretty sure this is what it refers to, since it mentions a May 28 landing, corresponding to bug 565475 comment 12.)

We ended that particular experiment because we decided the idea in bug 565965 would be strictly better than the idea in bug 565475 (see bug 570630 comment 0).

The idea in bug 565965 failed to make it into Firefox 4 because we didn't want to break desirable cooperation across websites, such as single sign-on, and haven't come up with a good UI (see bug 565965 comment 16).

Some of us were also concerned that the effect on advertisers would not be the effect privacy advocates want. Rather than abandoning targeted advertising, advertisers might increase their use of first-party redirects or switch to heuristic fingerprinting. These outcomes would be bad for privacy (users concerned about tracking could no longer simply disable third-party cookies) and bad for web performance.

The WSJ claims that we ended the experiment immediately after a conversation with an ad executive, but based on the history in bug 565475, it's clear that we did so before that conversation. The WSJ may have been confused because of the date of bug 565475 comment 18, which was made two days after the change it describes.

For more background, see https://wiki.mozilla.org/Thirdparty

From Jesse Ruderman:

The WSJ contains some factual inaccuracies, and the headlines on Slashdot and The Register are based entirely on those inaccuracies.

The article refers to a cookie-related experiment (bug 565475) that we ended in bug 570630. (I'm pretty sure this is what it refers to, since it mentions a May 28 landing, corresponding to bug 565475 comment 12.)

We ended that particular experiment because we decided the idea in bug 565965 would be strictly better than the idea in bug 565475 (see bug 570630 comment 0).

The idea in bug 565965 failed to make it into Firefox 4 because we didn't want to break desirable cooperation across websites, such as single sign-on, and haven't come up with a good UI (see bug 565965 comment 16).

Some of us were also concerned that the effect on advertisers would not be the effect privacy advocates want. Rather than abandoning targeted advertising, advertisers might increase their use of first-party redirects or switch to heuristic fingerprinting. These outcomes would be bad for privacy (users concerned about tracking could no longer simply disable third-party cookies) and bad for web performance.

The WSJ claims that we ended the experiment immediately after a conversation with an ad executive, but based on the history in bug 565475, it's clear that we did so before that conversation. The WSJ may have been confused because of the date of bug 565475 comment 18, which was made two days after the change it describes.

For more background, see https://wiki.mozilla.org/Thirdparty

The "pressure from advertisers" came after the feature was turned off because it didn't work right: https://bugzilla.mozilla.org/show_bug.cgi?id=570630#c15

We're also investigating a different approach of double-keying cookies with the primary and 3rd-party domains, which has the advantage of preventing advertisers from correlating your visits across sites within a session. This breaks even more legitimate things (as Opera also found when they experimented with this) so we're still brainstorming.

Thanks for the tip on Ghostery! I'll add that the Anonymizer Nevercookie addon is now in the Mozilla addon directory, version 0.1 mind you.

https://addons.mozilla.org/en-US/firefox/addon/260205/

Do not want; ads. I can find a product just fine. Make more noise, and I avoid your product. Pretty simple. Advertising is a waste of time and money, but not people. The people in advertising are just a waste of air and should be sewn together to make a protective CME shield for the Earth. Thank you.

I use Ghostery and Adblock Plus to stop all my tracking and doesnt slow me down one bit, in fact not having to load all those ads speeds up your browsing.
If websites wanted to make money from advertising DO IT FROM YOUR OWN SITE and dont take the cheap way out, and people relying on generic advertising for an income better get some business sense and stop complaining your not making any money.

I use Ghostery and Adblock Plus to stop all my tracking and doesnt slow me down one bit, in fact not having to load all those ads speeds up your browsing.
If websites wanted to make money from advertising DO IT FROM YOUR OWN SITE and dont take the cheap way out, and people relying on generic advertising for an income better get some business sense and stop complaining your not making any money.

As far as history sniffing is concerned, just recently we heard about history sniffing by “mainstream ad networks” and YouPorn (...accompanied by a great disturbance in the Force, as if millions of anon suddenly cried out in terror and were suddenly silenced). Also, [PDF] “documents hundreds of commercial sites exploiting it”.

To learn whether you’re vulnerable (and how exactly this works), http://startpanic.com/.

There are a few ways to immunize Firefox against this sort of attack:

Clearing your history is obviously effective, whether that means clearing it entirely or just deleting particular sites from the history. If a site isn’t in the history, it can’t be detected. You could also use an addon to clean up your history, e.g.
History Deleter – Deletes browsing history by keywords and/or date (on browser close)
HistoryBlock – Blocks specified sites from history, recently closed tabs, and the download manager

Also, disabling the visited link styling will also prevent history sniffing, but you won’t be able to tell if links have been visited by their visual style any more. To disable it, go to about:config, paste layout.css.visited_links_enabled into the search bar, and change its value to false.

As far as history sniffing is concerned, just recently we heard about history sniffing by “mainstream ad networks” and YouPorn (...accompanied by a great disturbance in the Force, as if millions of anon suddenly cried out in terror and were suddenly silenced). Also, [PDF] “documents hundreds of commercial sites exploiting it”.

To learn whether you’re vulnerable (and how exactly this works), http://startpanic.com/.

There are a few ways to immunize Firefox against this sort of attack:

Clearing your history is obviously effective, whether that means clearing it entirely or just deleting particular sites from the history. If a site isn’t in the history, it can’t be detected. You could also use an addon to clean up your history, e.g.
History Deleter – Deletes browsing history by keywords and/or date (on browser close)
HistoryBlock – Blocks specified sites from history, recently closed tabs, and the download manager

Also, disabling the visited link styling will also prevent history sniffing, but you won’t be able to tell if links have been visited by their visual style any more. To disable it, go to about:config, paste layout.css.visited_links_enabled into the search bar, and change its value to false.

https://addons.mozilla.org/en-US/firefox/addon/6623/

BetterPrivacy has worked for me over a year. Can be set to remove all of these LSOs ("supercookies") on browser exit. Can be set to delete by timer or manually when erasing other history information. Can be set to notify when a new LSO is stored.

The only caveat is that to not lose any Flash game saves, you need to add the cookies or the domains hosting them to the exception list.

...being relatively happy with my Firefox/Adblock/Noscript bubble of sanity...

You might want to look at the BetterPrivacy Add-on as well as the above. It is a whitelist based manager of Flash cookies. Which are used by a surprising number of sites that don't use Flash in any obvious way, including Gmail.com (whose Flash cookie I allow).

BetterPrivacy for Firefox. The developer's site, with links to reviews of BetterPrivacy in half a dozen big name magazines.

Netflix streaming said Chrome was incompatible last time I tried to use it. I've also had a lot of warnings on various sites that "all features may not be supported". As Mozilla knows, evangelism with major sites is as important as rendering bugs to the end user (me!). Usually everything just works or would work if they would unblock it.

Firefox plugin BetterPrivacy - https://addons.mozilla.org/en-US/firefox/addon/6623/ - will delete LSOs

It can be set up to automatically delete LSO on browser exit; on a timer (every x minutes/hours/days) or manually

It allows you to set a whitelist (protection list).

It doesn't 'solve' the problem; but in the mean time it at least breaks part of the cycle.

Also: Ghostery - https://addons.mozilla.org/en-US/firefox/addon/9609/ - helps to stop the problem in the fire place.

Used with Ad Block Plus - https://addons.mozilla.org/en-US/firefox/addon/1865/ - it makes surfing the web much better.

The Wild West era ended when there was no one left to conflict with.. right?

Firefox plugin BetterPrivacy - https://addons.mozilla.org/en-US/firefox/addon/6623/ - will delete LSOs

It can be set up to automatically delete LSO on browser exit; on a timer (every x minutes/hours/days) or manually

It allows you to set a whitelist (protection list).

It doesn't 'solve' the problem; but in the mean time it at least breaks part of the cycle.

Also: Ghostery - https://addons.mozilla.org/en-US/firefox/addon/9609/ - helps to stop the problem in the fire place.

Used with Ad Block Plus - https://addons.mozilla.org/en-US/firefox/addon/1865/ - it makes surfing the web much better.

The Wild West era ended when there was no one left to conflict with.. right?

Firefox plugin BetterPrivacy - https://addons.mozilla.org/en-US/firefox/addon/6623/ - will delete LSOs

It can be set up to automatically delete LSO on browser exit; on a timer (every x minutes/hours/days) or manually

It allows you to set a whitelist (protection list).

It doesn't 'solve' the problem; but in the mean time it at least breaks part of the cycle.

Also: Ghostery - https://addons.mozilla.org/en-US/firefox/addon/9609/ - helps to stop the problem in the fire place.

Used with Ad Block Plus - https://addons.mozilla.org/en-US/firefox/addon/1865/ - it makes surfing the web much better.

The Wild West era ended when there was no one left to conflict with.. right?