Given the kind of privacy concerns being expressed around this thread, I thought this article might be in order. This article puts everything in the correct perspective. And I think we need to deal with the privacy issue within this perspective.
http://www.schneier.com/blog/archives/2009/12/the_politics_of.html <http://www.schneier.com/blog/archives/2009/12/the_politics_of.html>Thanks Santosh On Wed, Dec 16, 2009 at 6:34 AM, John Panzer <[email protected]> wrote: > On Tue, Dec 15, 2009 at 4:40 PM, SitG Admin < > [email protected]> wrote: > >> 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/ > > > Note that all of these except the last are about how to use this for useful > purposes or just playing around; the last one is a theoretical note that > says "this may be useful for phishing" but doesn't give a specific attack > (that I can find -- the referenced paper may have something but it's very > long). > > Of course this is just absence of evidence. But so far no one has > documented this vulnerability actually helping phishers, though it's been > around for years and well documented for >1year. Since it depends on > Javascript running on an open website, I'd think that it would be detected > if the phishers were caught. Unless they are so clever that they have > managed to do this without detection, of course. > > Not saying this isn't an issue, just saying it should be weighted > appropriately when considering things like default settings for OPs. > > > >> >> 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 >> > > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > > -- http://hi.im/santosh
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
