Torbutton Release 1.2.5, Google Captchas, and addons.mozilla.org

Torbutton 1.2.5 has been released. You can download it from the torbutton homepage. It has also been submitted to addons.mozilla.org, though it may take a while for Mozilla to review the addon.

In addition to the numerous bug fixes mentioned in the changelog, one of the new features of this release is to provide the ability to automatically redirect to an alternate search engine when Google presents you with a captcha. The current options are IxQuick, Bing, Yahoo, and Scroogle. Since it supports SSL, and appears to have a progressive stance on user privacy, IxQuick is the current default.

For those unaware, Google's search engine has rate limiting features that cause it to present captchas and sometimes even outright ban IP addresses that issue large numbers of search queries, especially if some of these queries appear to be searching for software vulnerabilities or unprotected comment areas.

The Tor Project has had multiple discussions with Google over the past 2 years about potential workarounds on either Torbutton or Google's side to reduce the number of captchas and ban pages presented to Tor users while issuing normal natural language queries.

Unfortunately, we were unable to come to a solution or any form of compromise that would reduce the number of captchas and outright bans seen by regular Tor users. We hope that this workaround will enhance the experience of Tor users while still allowing them to use Google for queries that don't result in a ban.

In addition, potentially identifying information (such as language, OS version, and Firefox version) will be stripped off of Google Search Box queries by default. This was a major problem for users of Debian and Ubuntu, which have decided to augment their rebranded Firefox implementations to provide an excessive amount of information to Google for some reason.

Furthermore, this release will also only update Torbutton via Tor by default to address concerns with the data retention policies of addons.mozilla.org, as well as to prevent censored users from being revealed as Tor users during the Torbutton update download, which happens over http.

While Mozilla does have a blanket privacy policy covering all of their websites, they currently do not have a clear data retention or sanitization policy on data that is collected and retained during the use of addons.mozilla.org and during the addon update process. Mozilla has informed us that they are working hard to improve their practices and develop a good privacy and data retention policy specific to addons.mozilla.org. However, until such a policy emerges, we have decided that it is best to ensure that Tor users' privacy is protected during the update process via the use of our network.

Data retention concerns aside, the fact that addon update downloads are performed over HTTP can allow censorship regimes to detect the Torbutton download, and to prevent it from happening. For the safety of our censored users, these updates must happen over Tor by default until Mozilla also supports SSL for its addon update downloads. The integrity of the addon is verified by downloading a SHA1 hash over SSL, so this approach should not expose users to exit node tampering.

We have investigated having Torbutton only update via our servers, but this is infeasible for three reasons. First, censored users often cannot reach our servers, so they would be forced to use Tor anyway to safely update. Second, addons hosted on addons.mozilla.org are not permitted to provide a custom update url, so we would have to maintain two versions, or delist Torbutton from that site. Third, future versions of Firefox are expected to ping addons.mozilla.org anyway for statistics gathering purposes.

The unfortunate side effect is that performing these updates via Tor likely also means that the count of Torbutton users on the addons.mozilla.org site will gradually tend downward, and the Torbutton addon will be listed lower in response to searches on the site, since it will appear that we only have a number of users equal to the number of Tor exit nodes once everyone has upgraded.

Not a lot of cheerful news, but as always, we're doing our best to work with what we have.

The complete changelog for this release is as follows:

  • bugfix: bug 1169: Fix blank popup conflict with CoolPreviews
  • bugfix: bug 1246: Fix IST and other HH:30 timezone issues.
  • bugfix: bug 1219: Fix the toggle warning loop issue on settings change.
  • bugfix: bug 1321: Fix a session restore bug when closing the last window
  • bugfix: bug 1302: Update useragent to FF3.6.3 on WinNT6.
  • bugfix: bug 1157: Add logic to handle torbutton crashed state conflicts
  • bugfix: bug 1235: Improve the 'changed-state' refresh warning message
  • bugfix: bug 1337: Bind alert windows to correct browser window
  • bugfix: bug 1055: Make the error console the default log output location
  • bugfix: bug 1032: Fix an exception in the localhost proxy filter
  • misc: Always tell a website our window size is rounded even if it's not
  • misc: Add some suggestions to warning about loading external content
  • new: Add option to always update Torbutton via Tor. On by default
  • new: Redirect Google queries elsewhere on captcha (default ixquick)
  • new: Strip identifying info off of Google searchbox queries

Very good!!!!!!!!!!!!!! I'm going to add it to the next release of factorbee!!! (yeah, maybe it's going to be the one of today!!!!!!). I hope nothing of important has changed in the preferences of TorButton, but i'll change this preference extensions.torbutton.update_torbutton_via_tor!!!!! ... i'll patch it to set it to `false' in my TOR Browser Bundle!!!!!!!!!!!!! I think that all updating systems should be disabled by default, in a TorBB!!!!!!!!! but everything else seems OK!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Yeah, this is super!!!!!!!!!! I very like TorButton!!!!!!----
I also made one Firefox addon: it's BeeFREE!!!!!!!!!!!!!!!!!, I'm including it in factorbee too!!!! but i'm sure you already knew of it, as you copied all the updates ideas from it!!!!!!!!! and i'm happy you copied them!!!!!!!!!!!!!! I very dislike AMO (addons.mozilla.org)!!!!!!!!!! I withdrew BeeFree from AMO, because of their totalitarian, invasive centralization!!!!!!!!!!! and yeah!!! f*** to their statistics!!!!!!!!!!! This is the article i wrote to explain why i added one autonomous updating system to beefree, and why all addons developers have to do the same: http://honeybeenet.altervista.org/beefree/?id=105300 !!!!!!!!!!!!! They also censored some of my posts i sent to their blog in this thread http://tinyurl.com/ydsjdmn !!!!! My suggestion is to avoid to use AMO!! AMO = Googlezilla!!!!!!!!!!!!!!!

~bee!!!!!!!!!!!

If you disable updates of addons in Firefox with extensions.update.enabled, Torbutton won't update via Tor or not. I am still using the Firefox update system. I just wrote an nsIProtocolProxyFilter to set the proxy on Torbutton updates to Tor.

https://www.torproject.org/torbutton/design/#id2937206

Also, I had no idea BeeFree did this. I didn't even know BeeFree existed. Seems like a hard-coded version of AdBlock Plus?

Cancel almost everything of what i said about "update_torbutton_via_tor", because i understood what it does only now, after looking at the source code of TorButton!!!!!!! yeah, you're right, if the updates are disabled that option isn't used!!!!!!!! though I disabled it in the release of factorbee i published today!!!!! Well, nobody will notice any difference!!!!

As for BeeFree, you're almost right!!!!!! It's like an hard-coded version of AdBlock Plus, but beefree doesn't work to remove banners and similar things, but it's useful to remove TRACKING LINKS!!!!!! It's the only addon in the world doing that!!!!!!!!!! it's very unique!!!!! and it's the second of the current three projects at the HONEY BEE NET!!!!!! Actually, beefree is three/four addons into one!!!!! It gives you a very honey homepage, so that you don't need to connect yourself with a server every-time you start firefox!!!(it's the page factorbee uses as homepage too!!!!this feature is disabled by default!!) It gives you protection with hard-coded filters against tracking links, and against all javascript tracking links on all websites!!! And, last but not least, beefree can also edit the HTTP headers to remove those information you don't want to leak!!!! For example, it has a very smart way to remove the HTTP referrers!!! HTTP referrers get automatically removed every time you move from a domain to another!!! In this way it doesn't break anything!!!!! and different websites won't know where you were surfing before!!!!!! but within the same domain the referrer is sent to avoid to break something!!!!

If you install beefree, and you try to go on Google, Dogpile or YouTUBE, you'll see what it does!!!!! For example, YouTUBE has plenty of javascript-based tracking links (read my article http://honeybeenet.phpbb3now.com/viewtopic.php?f=14&t=227 !!!!!!!!) and if you want to watch the videos (i'm talking about a normal usage of Firefox, even without using TOR), you need to keep javascripts enabled!!!!!!! I think that even NoSCRIPT cannot protect you against tracking links in javascript, but beefree does!!!!!!!!! So, i always suggest to use BeeFree and AdBlock Plus together, because they're two very needed addons!!!!!!!!!!!!!! This is the website for BeeFree: http://honeybeenet.altervista.org/beefree/ !!!!! There is everything you may want to know about it!!!! Plenty of webpages to read!!!!!!! The list of hard-coded filters is here: http://honeybeenet.altervista.org/beefree/?id=109000 !!!! Filters are hard-coded, because beefree does a lot of string manipulations, and those stuffs aren't possible to do with regexps alone!!!!!!!!!!!

~bee!!!!!!!!!!!!!!

"Always tell a website our window size is rounded even if it's not"

What is the purpose of this setting?

To provide further protection against mechanisms like panopticlick. If you disable the window resizing code because it either causes problems or you find it annoying, there's no reason why this means we should stop protecting you altogether.

See http://panopticlick.eff.org/ and https://blog.torproject.org/blog/effs-panopticlick-and-torbutton

Please stop allowing that thing called "bee" from posting on the Tor blog. I am so tired of her/his posting style and insane use of exclimation points. How old can it be? Maybe 15 years old? (there is no way it is an adult who has skill in creating anonymity and security software) Not to mention all he is doing (seemingly) is trying to spam the Tor blog for his own bundle...and insanity.

Please stop letting his posts through.

Thank you.

I too find bee's posts hard to read. I wish he wouldn't obfuscate his ideas behind such awful writing. It looks like he might have had a good idea or two in that most recent comment, but it's really hard to parse all of it. It might be nice if it was possible to collaborate with him.

I can understand the bee obsession (maybe), but there's a big difference between the breeze of humor and the winds of insanity.

Re: stopping the madness of the thing called "bee":

Can Tor project limit the amount of exclimation points allowed? Maybe mark as spam like the AMO blog had to due with bee?

Please stop bee. Thanks.

Bee-haters calm down, please!

While his posting style may be slightly irritating, some of his remarks and the pointers to his work are relevant IMHO.

Peace.

bee's posting style aside, bee doesn't understand security nor firefox. bee is simply adding in various plugins/extensions and calling it good.

case in point, look at download.sh from the source bundle:

# https://www.torproject.org/vidalia/
wget "https://www.torproject.org/vidalia/dist/vidalia-0.2.7.tar.gz"
let counter++

The script doesn't download the pgp signature, nor check it. This is true for every download link in that file. And then to make the user feel better:

md5sum * > ../sources.md5sum
sha1sum * > ../sources.sha1sum

Rather than bother checking the md5 or sha1 hashes from the source website, just create them all AFTER the download and compare against that. If you have a corrupt/malicious download, you have no way to know that using bee's method.

Also, "wget" is called from the environment PATH variable, not specifically hardcoded to a path. While easier to code, anything can be called wget and download.sh will run it.

Also, all of the scripts use "/tmp/factorbee", which as a known path, is exploitable. mkstemp would be preferable.

The tor config file has this rampant problem too,

DataDirectory /tmp/factorbee/app/tor-cache
GeoIPFile /tmp/factorbee/app/tor/share/tor/geoip

HI!!!!!!!!!

> bee doesn't understand security nor firefox.
And definitely, you don't understand honey bees!!!!!!!!!

> The script doesn't download the pgp signature, nor check it. This is true for every download link in that file
You should check them manually, if you mind to!!!
I made the download.sh file for your convenience!!! You aren't forced to use it!!!!
You're of course free to download all the files in the way you like more, or even to take them from somewhere else (CDs)!!!!!!
That script is mostly useful to let you see which source packages you need to build factorbee!!!!!!!(and where you need to save the tarballs!)

> "wget" is called from the environment PATH variable, not specifically hardcoded to a path
If your computer is infected with a rootkit, even having a full PATH won't help!!!!!
I presume the computer where you'll build, and also use, factorbee to be already "safe"!!!!!!!!!!

What if you're using a poisoned version of the GNU C Compiler (GCC)?!!! The build scripts of factorbee have no ways to know that!!!!!!
It's the same for the PATHs!!!! It's not a fault of factorbee if your environment PATH variable points to nowhere, or to a folder with a false wget!!!!!!!

Good luck in using an unsafe computer infected with virii, rootkits, hardware keyloggers etc!!!! Factorbee isn't made to protect you against those kinds of stuffs!!!!!!

> all of the scripts use "/tmp/factorbee", which as a known path, is exploitable
It's not a bug, but a well-known limitation!!!!!!!!!!

> mkstemp would be preferable.
> The tor config file has this rampant problem too,
> DataDirectory /tmp/factorbee/app/tor-cache
That's an encrypted directory, if you've got EncFS installed, or it gets mounted into the RAM memory if you run factorbee as root!! (and then factorbee will drop the root privileges!!!) Factorbee will refuse to start if the "/tmp/factorbee" directory isn't enough safe!!!!!!
Having a fixed path (/tmp/factorbee) gives disadvantages but also plenty of advantages!!!!!
The disadvantages mostly exist if your computer is infected with some trojans, but then even after `mktemp' also one remote "ls /tmp" could print where factorbee is located!!!!!! A forensic analysis of your disk won't give a lot of information about what was stored into /tmp/factorbee (the folder gets renamed before getting deleted), because that's only a mountpoint!!!!! The files are (usually) either encrypted or saved into the memory (RAM, with the swap files disabled!!!!!!) and firefox profiles could be stored into a ram disk (files in the ram disk get also wiped!!)
If you run factorbee, with both: encfs and the root privileges, all the files (like the "tor-cache") are encrypted and the encrypted files are stored into the volatile memory!!!!!!!!!!!!!!!!!! I don't think that it'll be so easy for anybody to recover the files!!!!!!!!!!!!!!!!
There isn't any "rampant problem", except for your absolute misconceptions in understanding how factorbee works!!!!!!!!!!!

THERE IS NOT COMPARISON!!!!!
The official Tor Browser Bundle, is very much more UNSAFE than factorbee!!!!
It stores everything (yeah, including the "DataDirectory" "tor-cache", firefox profiles, everything!!!) in plain-text on your disk!!!!!!!

Well, ok, whatever!!! THANK YOU for getting interested in factorbee!!!!!!!!!!!!!

bye!!!!!!!!!!
~bee!!!!!

I dunno why, but I kept this for last, and then i forgot to reply to the most funny part of his post!!!!!!!!!!!!
Ah yeah, i'm also presuming a gender for you!!!!!!!!!!

> then to make the user feel better:
> md5sum * > ../sources.md5sum
> sha1sum * > ../sources.sha1sum
> Rather than bother checking the md5 or sha1 hashes from the source website, just create them all AFTER the download and compare against that

That's of course untrue!!!!!

But that's very funny too!!!! So, you believe that the download.sh script generates the MD5/SHA1 hash values of all downloaded files, and then it checks if those hash values are OK against the same files it used to generate the hash values!!!!!!!!!!! lol!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

You should really read the "README" file, you've got along with the source package!!!!!!! it's written there, that it's your duty to check the downloaded files fingerprints!!!!!!!!! (they're not even the same thing of the checksums...)!!!

These two files, sources.md5sum and sources.sha1sum, are generated using the downloaded files, but after that, they are not checked against anything!!!!!!!!!!!!!!!!!!!!!!! it's well written in the files you didn't read!!!!!!!!!
Those two files, are useful because they're saved inside the auto-generated source-tarball of factorbee!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
For example, you could share the source and binary tarballs of factorbee, and when your friends will get the source and binary tarballs, and both are "ok" (i.e.: they aren't hijacked/poisoned/fakes -- you could sing your own tarballs with your own GPG key) then the sources.md5sum and sources.sha1sum files, will inform ur friends about what files were used to build the binaries!!!!! You could also add the original source files into the "source tarball of factorbee", but then the size of that file will increase from 1MB to 220MB!!! (the size of the QT package alone is ~120MB!!!!) So, keeping only the hash values of all files, has the same results and reduces the size of the source-tarball of factorbee!!!!!! because it's still possible to know which sources were used to build the binaries, without including the real tarballs...!!!!!!!!!!!! this is why those two files are generated and included into the source-tarball!!!!!!!!!!! they aren't made as a way to check whenever the downloads went ok!!!!!!!!
Please, at least read the README!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Sometimes i've to think that I'm surrounded by .........!!
http://www.youtube.com/watch?v=ymzh7YAlZng ...hahahah im kidding, but GOTCHA!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

bye!!!!!!!!!!!!
~bee!!!!!!!!

Sorry about offtopic, but WTF is going on with Tor network??? Someone is heavvy DoSSing public nodes. I tested by seting my own pc ar public realy. After some time, huge traffic frow from, nigeria, egypt and so on. This crap started yesterday, when some 40% of relays just dissapered. :(

It does show a big drop though, so apparently something is/was happening. I suspect those graphs are also heavily averaged, so gather you're not going to notice any larger short-term spikes. I experienced first hand the effects of this on Tor performance as a client at the time, and your own Time-to-complete graphs back both those things up given the sharp increase in delay. Things are running better again now, but there was a point where Tor became almost unusable here around the start of this event.

>tested by seting my own pc ar public realy. After some time, huge traffic frow from, nigeria, egypt and so on.

Being you a relay server, it's quite normal for your machine to receive/resend a lot of traffic from all over the world, and in particular from repressive or intolerant countries : serving as a relay to help users from those countries is the reason why you would run a Tor relay after all :=)

Of course w/o seing your machine's detailed traffic stats nobody can affirm there isn't something wrong with it, but a priori if you have no other problems than are seing a lot of connections/traffic going thru your Tor's machine, then I would say it's working as designed... and yes I believe every tor user should be configured as a relay when and wherever possible.

Thank you for helping freedom of communication at home and abroad!

--
Noino

Syndicate content Syndicate content