Adblock Plus and (a little) more
Why you do not want to use the LOAD_ANONYMOUS flag · 2011-01-30 15:49 by Wladimir Palant
When you are creating a Firefox extension you don’t need to use browser’s default settings when downloading something, you can choose from a number of load flags defined on the nsIRequest interface instead. Some of them are really useful, e.g. the flags controlling caching. And then there is LOAD_ANONYMOUS flag that sounds like a good idea for downloads of public files — after all, why should you allow cookies and such? Making user tracking possible isn’t the point here.
Adblock Plus 1.3.2 added this flag for downloads of filter subscriptions, development build users didn’t notice any issues. Shortly after the release I had to revert this change and release Adblock Plus 1.3.3 however. Turned out that “no authorization tokens” included proxy authentication as well. So for users accessing the web through a proxy that requires authorization (e.g. NTLM authorization in some companies) the download would always fail with channel status NS_ERROR_PROXY_CONNECTION_REFUSED and HTTP response “407 Proxy Authentication Required”. Fewer than 0.1% of the users were affected, I must consider myself lucky to have found the problem so soon after the release. Other people might not be so lucky, hence this warning: LOAD_ANONYMOUS flag might be useful in some very special scenario, you probably don’t want to use it in your extension however.
Comment [8]
Commenting is closed for this article.
Kaonashi · 2011-01-30 16:52 · #
You’d think that there would be a set of more fine grained options in general to deal with authentication tokens vs everything else. That applies to both how addons are forced to handle cookies and how the browser handles them.
tom · 2011-01-30 18:13 · #
what about trying with LOAD_ANON first, and if that fails, try without..
and maybe even learn if you should use it after first dozen or so tries..
Reply from Wladimir Palant:
What’s the point then? A website that wants to infringe your privacy will simply provoke a failure when requested in anon mode and do its thing in the subsequent unrestricted request.
Danny Moules · 2011-01-30 19:22 · #
Any feasible way to detect if a proxy has been set up and then revert, otherwise use LOAD_ANON?
Moomoo · 2011-01-30 20:25 · #
What about websites that only let you download when you have cookies as a measure against direct linking?
Reply from Wladimir Palant:
In my case there could be no such websites.
Florian Quèze · 2011-01-30 20:43 · #
Shouldn’t a NO_COOKIES flag be added to nsIRequest to avoid cookies but still be able to authenticate with proxy servers?
YoureSelfish · 2011-02-01 03:57 · #
Mook · 2011-02-01 06:18 · #
Hmm, I don’t suppose you happen to know how to convince a channel to not use cookies, then? HttpBaseChannel::AddCookiesToRequest seems to pretty much always want to add the cookies from the cookie service, if I’m reading things right (which I might not be)… Since that’s called from nsHttpChannel::AsyncOpen, I don’t think I can find a good spot to avoid it being triggered.
At least, I’m assuming overriding the cookie service contract id would be too evil ;) Oh, and with the XPCOM 2.0 registration, we can’t look up the old contract id before clobbering it with our own anyway…
Reply from Wladimir Palant:
No, unfortunately not. That was actually the idea when I added LOAD_ANONYMOUS flag but this one has way too many side-effects. You might be able to remove Set-Cookie headers from an http-on-examine-response observer however.
Mook · 2011-02-01 10:57 · #
Yeah, sadly, in my case the server sends a different response (redirect versus not) due to those cookies, and just tacking on extra cookies doesn’t work either because they don’t get clobbered.