Side note.

  https://twitter.com/account/use_phx?setting=false&format=text

Recognised that URL immediately, and (after first changing to newtwitter which I hate), reloading the page did indeed switch me back to oldtwitter.

Edit: Because of the change in URLs between the old and new versions of Twitter, I can only find one alternative to the us_phx option (a fairly obvious one):

  http://twitter.com/settings/account

Returns 302 if not logged in, and if logged in then 200 regardless of if your account is set to use new or old twitter.

302 wont work. It simply redirects to the destination page, and then the onload would be triggered. What you need to find is something which generates an error code, ie 4xx/500. When logged in, this generates a 406, because I set "format" to something invalid:

https://twitter.com/account/use_phx?setting=false&format...

But when logged out, it redirects to the login form which ultimately provides a 200 status code.

There are probably several other ways of making twitter generate a HTTP error code.

This is why I use "Request Policy" on Firefox. It prevents by default all kinds of cross-domain requests like these.

It's a bit painful to set up at first for all sites that you visit frequently (similar to setting up NoScript), but then you can enjoy a much more lightweight browsing experience - and a more secure one as well.

I almost wish attacks like this could be used to trim down all the options provided by uber-social sites that offer me the option to twitter/like/stumbleupon/reddit/digg/etc... every single page.

by using browser history leaking...you can! http://www.azarask.in/blog/post/socialhistoryjs/

This will be plugged in future browsers though...its already blocked in chrome

This could actually be useful to a UI designer in a non-evil way. Normally we have a list of services that you could authenticate with. If we knew that someone was logged into a less-common social network we could show that button instead of a more-common one they weren't logged into.

Perfect. I needed a replacement for the visited link technique that's being squashed by Firefox.

Twitter provides an undocumented endpoint that returns true/false depending on your session state.

  <script>
    function twitterSessionsPresent(state) {
      console.log(state);
    }
  </script>
  <script src='https://api.twitter.com/sessions/present.js?callback=twitterSessionsPresent'></script>

Doesn't expose any "real" private info( eg: passwords ). If the intent of the piece was to get users to turn off Javascript and secure themselves, the possibilities laid out are not forceful enough to achieve that objective, imo.

The intent of the piece was to tell people about a neat trick I'd discovered. Nothing more.

Which sites you log into, is private information.

The Firefox addon "Request Policy" does protect from this attack, but it's not the most user friendly way to browse the web. I've been trying it out myself the past couple of days. Fine for geeks, but not fine for the average user.

You said "Which sites you log into" but mean "Which sites you maintain a persistent log in on" which are two very different things.

The post you responded to is correct in that the title is somewhat incendiary compared to the reality, unless there is some possible hijacking or scraping vector from this, but that seems massively unrealistic.

For the average user "Which sites you log into" and "Which sites you maintain a persistent log in on" are equivalent.

Are you logged into RedTube? If you were, would that be 'private' information?

That's what 'private browsing' is for, then you switch back, it is fantasti.cc

That's what 'private browsing' is for.

That's what 'Noscript' is for.

That's what just using Lynx is for.

Yeah, lots of people go to this amount of trouble. Hell, why feel bad for people injured in car crashes? That's what five-point restraints and helmets are for.

I was referring to the grandparent's specific anecdote about surfing for 'porn', not browsing in general.

Chill out, mon.

I wonder why doesn't it work in Opera?

Iit's only the Facebook, Twitter and Digg attacks that don't work in MSIE and Opera. The GMail attacks works in all of them. The reason the "script" based attacks don't work in Opera and IE is because they don't fire the onload/onerror events if the returned content isn't valid JS.

Checking the color of <a> gives similar information. It's all client-side so you can do 40k+ URIs per second.

Here's code I wrote to display the "digg this" button only to digg users: http://int2e.com/blog/improved-digg-integration-script/

Unfortunately, the next version Firefox will block this hole, and I imagine other browsers will follow suit.

http://hacks.mozilla.org/2010/03/privacy-related-changes-com...

Why is that unfortunate?

I use visited links to personalize my site.

There are definitely privacy implications when doing it on a large scale, but I wish there was a middle ground.

Hm. It reported I'm on Twitter although I wasn't. Both on Chrome and FF. JavaScript was enabled. A bug perhaps?

Strange. It's still working fine for me. Said I wasn't logged in, so I logged in and checked and work, and I logged out again and checked and it worked. I wonder if you're using a proxy that is interfering somehow? I'm assuming it's not an addon as you said it's the same in both Chrome and Firefox?

I'm sure this isn't what you're thinking, but just to double check... You don't think that you're logged out of twitter just because it's not open anymore do you? If you log in, and then close the tab without logging out, then you're still logged in...

I know I wasn't logged in because I don't even have a twitter account :). But, your assumption that this may be a proxy issue is almost certainly right, since I accessed the page from my work computer. I tried it now from my home computer and everything checks out - it doesn't show that I'm logged in anywhere except where I actually am.

For the Twitter test, the HTTP response code is an error code if you're logged in. So if your work place blocks Twitter and returns an error code like 403 or something, then you will appear to be logged in.

The test could easily be modified so it checks some other url first to make sure twitter isn't generally blocked.

The intention of the article was to describe a general technique, rather than to provide some complete fully functional tests. Although they do work for the vast majority of people.

Can you get usernames this way?

Not in any of the examples provided. The article describes a general technique for attacking sites. There are lots of variations of the attacks that work against lots of different sites. Two variations are provided as examples which cover 4 particularly well known sites.

iOS 4.2, mobile safari: Facebook mobile failed, but switching to full site works.