Jeremiah Grossman

People have been using this technique in this way since at least 2006:
http://int2e.com/blog/improved-digg-integration-script/
http://jeremiahgrossman.blogspot.com/2006/08/i-know-where-youve-been.html

Since changing browsers to prevent this will not happen tomorrow, this can be partially worked around both server and client-side.

Server-side: If you have any sensitive URIs you don't want leaked or brute-forced, add an extra parameter containing a random value. URIs you might want to protect are those with XSRF tokens or session IDs. URIs can be brute-forced locally on the victim at a speed of approximately 40,000 URIs per second.

Client-side: Use incognito mode for sensitive surfing. Plugins such as noscript can partially defend against this, however it's possible to do history detection using pure CSS which I believe will work even if you're using noscript.
Update: Fixnum posted another client-side solution "in Firefox, go to about:config and turn off layout.css.visited_links_enabled"

The Top-10 is just a start. As a penetration tester and sometimes-trainer, I find it's when developers start to see practical demonstrations of what these vulnerabilities can actually allow a malicious party to achieve that the eyes really get opened. Particularly when those demonstrations are within their own applications.

Check out the rest of the OWASP site, and play with WebGoat (http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project).

Take a look at the 'Web Security' section here: http://code.google.com/edu/courses.html

Start following some of the many webappsec blogs floating around the interwebs, subscribe to mailing lists, read tweets:
http://www.gnucitizen.org/
http://ha.ckers.org/
http://jeremiahgrossman.blogspot.com/
http://www.webappsec.org/lists/websecurity/
http://twitter.com/#search?q=%23WebAppSec

There is a huge amount of information out there.

It depends on a number of things. If you've documented your communications with them and have repeatedly tried to get in touch you may feel like disclosing publicly. A year is more than enough time to fix a XSS issue, and nobody would really judge you for going public with it.

However, this might depend on where you live. Some countries (like the UK, where I'm typing this from) make testing website for vulnerabilities illegal, no matter how serious the issue or good the intentions[1]. Very few people are actually caught by these laws, but there is always a risk that you piss off a litigious company, who then go after you.

[1]:http://jeremiahgrossman.blogspot.co.uk/2006/09/is-testing-for-xss-illegal.html

This issue is nine years old at this point and has been published, republished, and blogged countless times. I yearn for the day it stops wasting space on the front page of news aggregators.

A partial bibliography:

2000:

http://bugzilla.mozilla.org/show_bug.cgi?id=57351

2002:

http://seclists.org/bugtraq/2002/Feb/0271.html

http://bugzilla.mozilla.org/show_bug.cgi?id=147777

2006:

http://portal.acm.org/citation.cfm?id=1135777.1135884

http://portal.acm.org/citation.cfm?id=1135777.1135854

http://jeremiahgrossman.blogspot.com/2006/08/i-know-where-youve-been.html

2008:

http://azarask.in/blog/post/socialhistoryjs/

http://www.mikeonads.com/2008/07/13/using-your-browser-url-history-estimate-gender/

Two major problems come to mind.

1) Breaks password managers and broswers' save password function. Many users are helpless without these.

2) You know how your browser helpfully remembers and fills in your name and address across different websites? Yeah, now it'll fill in your username and password too, making it accessible via javascript to any site that wants it. Since the password isn't in a password field, the browser doesn't know to restrict it to the original site.

For an example of using javascript to get this kind of information, see Jeremiah Grossman's blog: http://jeremiahgrossman.blogspot.com/2010/07/i-know-who-your-name-where-you-work-and.html

No. Or rather, there isn't supposed to be. About 8 years ago (see http://jeremiahgrossman.blogspot.com/2006/08/i-know-where-youve-been.html for an early demonstration) it was possible. This was considered bad, because it could help malicious sites gain information about the browser history which might help with an attack.

The browser developers responded by minimizing what a ":visited" can do, so Javascript shouldn't be able to get direct, or indirect through CSS, access to that information.