But today I wanted to praise two widgets which IMHO get it right. I’m talking about Feedjit which shows the (approximate) physical location of your last N visitors and the Weather Sticker from Weather Underground. The things I like in them:

• Minimal fuss (no signup) required to get them.
• They are just an image! (Feedjit offers also a javascript version, but it is optional)
• Given that it is just an image, the browser can download it in parallel and doesn’t need to suspend the processing of the page.

Even though it is just an image, the provider gets a link back. Also, it can

Finally, it works when Javascript is not available and it eliminates a very obvious way to attack your users!

I wish that all gadget providers would offer a lo-fi version of their gadgets. A+ to both of these services (and you can find them in my sidebar).

Mozilla Firefox does not protect you against this attack by default. However, Google Chrome supposedly does because they implement each tab in it’s own virtual sandbox.

I tried to search around, but didn’t find any results which seemed relevant, so I went ahead and did some experimentation on my own. The results are:

• No, Google Chrome doesn’t introduce further sandboxing to passing cookies between requests coming from different sites (this is the main reason for CSRF). I tested this in all the process modes available for Chrome (and it is logical that they all behave the same, since the passing or not of cookies is a “higher level” policiy”)
• I also tried it with IE 8, the other browser at the moment which uses processes to separate out tasks. Besides being much slower (adding an other entry to my Windows 7 annoyances list), it didn’t show different results. (BTW, I did the comparison with the “process-per-tab” mode for Chrome to compare oranges to oranges, and it still was considerably slower!)

The conclusion? The initial comment was made probably because of a misunderstanding. Still, a solution of this sort might be useful. What I’m pondering here:

• each tab has a “zone”. The zone is determined by the FQDN of the address entered in the address bar (ie. clicking on links doesn’t change the zone).
• cookies are sent with the request only if the site which set the cookie and site which is sending the cookie are in the same “zone” as specified by the same origin policy

What does this brake? Probably some Web 2.0 widgety type things (in the sense that they have to revert back to the “copy this snippet over there” more or require an extra login – both of which are tolerable). However it may also break situations where people navigate using search engines (ie. they don’t enter the address but rather search for it).

Image taken from nellee100’s photostream with permission.

Update: a somewhat related post – Bug in Internet Explorer security model when embedding Flash. Very cool!

This is rather old, but still good (originally found it via the Pat’s Daily Grind blog): a security company did some tests with the password manager included in different browsers. And of course they slapped not one but two sensationalistic titles on it (“Google Chrome Receives Lowest Password Security Score” and “Safari Ties for Last Place”). You can’t blame them, because sex Paris Hilton sells

However, there are some discrepancies between their test results and the ones reported by users. Also, the developers of Chrome responded in a very detailed and well reasoned post which pointed out that some of the assumptions would actually break websites like Facebook and still not add more than a small security barrier which can be overcome.

It is exactly because situations like this why testers should contact the vendors before they publish the results. However that seems to have become a kind of a lost art, nowadays everybody seems to want to rush out the door with “news”.

Image taken from Max (Tj)’s photostream with permission.

A few words about the methodology: I took the top 1 000 000 sites list from Alexa (love them or hate them for their toolbars, but it is very nice of them to provide this list freely and without any registration or stuff – I admit that I went to their site with the intent to scrape it and was very pleasantly surprised). I feed the list to a simple multi-threaded Perl script which tried to download the https://$site/ URL (with cURL – BTW you can hear an interview with the creator of curl on FLOSS weekly) and recorded the error code. It managed to go over 358947 entries before the power went out, so here are the partial results

Even if I ignore the errors associated with my network connection (the two largest categories “Couldn’t resolve host”, “Failed to connect to the host” and “Operation timeout”), and the one which seems to be a statistical fluke (“The server didn’t reply anything”), the sites which have their SSL certificates in order come in dead last (!) with 5%. How can we instruct people to look for proper SSL encryption when the sites themselves fail to provide such?

The biggest percent is made out of the “The remote SSL certificate wasn’t ok” case which seems to caused mostly by sites that reuse SSL certificates issued for other domains (for example google.it use the certificate for www.google.com).

The second biggest problem in case of SSL sites was “SSL connect error” (including on yahoo.com). These servers seems to keep port 443 server open, but don’t respond with anything. Are they tarpiting the connection? Why would they do that?

The last error (which still outnumbers the no-error cases by a factor of 5!) was “Problem with CA cert”. A cursory check seems to indicate that these are mostly self-signed certificates. While such certificates do provide some guarantees, it would be much better for them to use proper ones (they are not that expensive).

My (sad) conclusion: SSL == fail.

PS. The terminal23 blog contains further bad news. I thought that at least EV certificates (although way too expensive), at least they provide some guarantee that proper checks have been done. It seems not…

Also, quite obvious: the biggest problem were “Flash cookies” – again, duh!, since they are stored outside of the browser, so there is not very much the browser can do about them. There are many ways users can be “tracked”, and the given the obsession of security companies focusing on cookies, advertising (and other companies interested in profiling users) will surely (if they haven’t done so already) diversify their options. A few other options I didn’t mention until now for tracking users:

• Using Silverlight / signed Java applets to create markers
• Using interactions with other plugins (like asking the Windows Media Player to download a plugin for example)
• Using other tricks in the HTTP protocol. From the Google Browser Security Handbook:
  

  Trivia: as hinted earlier, ETag / If-None-Match, as well as Last-Modified / If-Modified-Since header pairs, particularly in conjunction with Cache-Control: private, max-age=… directives, may be all abused to store persistent tokens on client side even when HTTP cookies are disabled or restricted. These headers generally work the same as the Set-Cookie / Cookie pair, despite a different intent.

The last option can be detected / defended against by the browsers, however the rest are beyond the browsers control normally.

Conclusion: true anonymous browsing involves such high sacrifices and reduction in functionality (demonstrated by the decloak Metasploit project for example) that very few users would be willing to use it, and it is certainly far from a “one-click solution”.

<html>
    <frameset rows="20,*" border="0" frameborder="no">
        <frame name="menu" src="menu_frame.html" scrolling="no" noresize="1">
        <frame name="work_frame" src="">
    </frameset>
</html>

First of all you would say: but frames are so 1998! And you would be right. Frames are outmoded, deprecated and a usability nightmare (because you can’t bookmark the exact state of the frameset), you have to use them in certain situations. Like, for example when providing a "unified menu" in an intranet where you can’t (or don’t want to) touch all the sub-sites referenced. "The right tool for the right job".

Back to our problem: the page from the upper frame contained a bunch of links targeted at the lower frame in the form of:

<a href="http://www.example.com" target="work_frame">Example</a>

The problem was that while on all "sane" browsers the link opened in the lower frame, Internet Explorer (both version 6 and 7) insisted on opening a new window for the link. Finally I got the idea to create a blank page and set the lower pane to it:

<html>
    <frameset rows="20,*" border="0" frameborder="no">
        <frame name="menu" src="menu_frame.html" scrolling="no" noresize="1">
        <frame name="work_frame" src="blank.html">
    </frameset>
</html>

Magically everything worked. So there you go: IE + Frames = Headache (from banging your head against the desk), or at least Magic.

PS. I never tried using "about:blank" instead of an explicit blank page, which seems to be standard (I don’t know if official or unofficial) between the major browsers. Possibly it would also work (and has the advantage that you don’t have to explicitly code an "empty" html file).

Some random dude in Taiwan couldn’t browse the web (because an undersea cable broke due to a recent earthquake) and he decided that using a webserver (probably configured by him) which ran arbitrary executables mailed to it (hint: the from e-mail field is not a reliable authentication mechanism) is a sane thing to to because I need Slashdot!. Of course he made the front page on Slashdot.

Please, don’t reinvent the wheel! I’m too young to have used any of the following services, but at least I know that they’re out there:

• Accessing th Internet – offline (Google Cache because the site loads very slow). The mail address mentioned works (I just tested it) and has a response time of ~10 minutes.
• www4mail.org

Tracking Users Via the Browser Cache. Original story: meantime: non-consensual http user tracking using caches. Also covered here: Clearing cookies is not enough to save your privacy. And it was already posted on slashdot (so please don’t post it again :)).

As you might know I personally believe that to gain 100% privacy and anonymity on the ‘net is almost impossible and if you take all possible steps to achieve it, you get a web which lacks many of the functionality which make it so attractive. In the end everybody must decide for themselves, but probably most of the people have better things to do than running around in a thin-foil hat. Now that I’ve got this off my chest, lets see the technical details for this new method:

Whenever an object (web page, image, etc) is downloaded from the web server, additional headers are returned which signal to the browser (and any proxy which may be in between) how long the given object should be cached (caching is essential and it improves page loading speed substantially, so no, turning it off is not the solution). The idea is to give the browser an object (and again, this can be even an html page, so turning off scripts, images & stuff won’t make you bullet proof) with a header that tells the browser that the object must be revalidated on every request (revalidation is the process where the browser asks the webserver: I got the version of this object which was produced on date X, do you have a newer one? And the webserver responds either with no or with the new version). Based on this the server can tell exactly when this particular client last loaded a page from it.

This is just an other possibility to track users on web pages (you can read about others on my blog). Possible defenses would be: (a) turn off caching (and live with very low performance) (b) some finer grained caching control (which to my knowledge doesn’t exists in any browser) or (c) embrace the truth: as long as they have something that you want, they can demand the price.

On the upside: it seems that currently this is not suitable for cross-domain user tracking without some additional stuff (like javascript – then again if you have javascript enabled, all kind of other technologies can be used).