Discovery of an OpenID session at an OP

[SitG Admin]

At 9:40 AM -0800 12/15/09, John Panzer wrote:
>long-standing hole in browsers that gives ~equivalent information to
>phishers, and this is not one I've heard of them using (perhaps you
>have).  It's a good opportunity to look at what attack vectors this
>has enabled in the real world

http://www.azarask.in/blog/post/socialhistoryjs/
http://www.schillmania.com/random/humour/web20awareness/
http://www.niallkennedy.com/blog/2006/03/automatic-favor.html
http://www.niallkennedy.com/blog/2008/02/browser-history-sniff.html

This may be a less-than-thorough list, I'm just copying across from a 
bookmarks folder I retained about this particular exploit.

http://jeremiahgrossman.blogspot.com/2006/08/i-know-where-youve-been.html
https://www.indiana.edu/~phishing/browser-recon/

At 10:11 AM -0800 12/15/09, Breno de Medeiros wrote:
>I don't buy the CSS history stealing argument, that's all. CSS history
>stealing is essentially a cross-domain cookie API without user opt-out
>option.  So I wonder how long before browsers turn off this 'feature'.

Stanford released a fix (Firefox addon) for it a few years ago; I 
don't expect browsers to integrate anything similar until we've 
shifted into full isolation mode (thread isolation for each tab is 
moving toward this, and single-site browsers have the right idea; 
give each site its own virtual environment and retrieve final data 
from *those* to interact with, allowing an extra layer of 
interpretation so the user can see colored links (and other data 
overlaid) that the remote site doesn't have any way to be aware of, 
unless the top/privileged layer specifically *opts in* to sending 
that data back down the chain), because we're currently at a fairly 
stable pattern as far as the convenience/security balance goes.

-Shade