"The Tor Browser Bundle uses startpage.com as the default search engine, but startpage.com has a so-called "family filter" enabled by default, which filters out many webpages"
This is pretty funny for a browser that people use to evade censorship and filters.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items ...
Show closed items
Linked items 0
Link issues together to show that they're related.
Learn more.
You can manufature startpage URLs that have arbitrary combinations of preferences. Go to the settings page, click the settings you want, and click "Get URL." Use that as the search URL rather than the. Alternatively, I believe there's a cookie you can set. So the technical possibility exists.
Mike, I think this one is a good idea. I'm hearing reports that the "porn blocker" is not just blocking porn, but is being assholish about LGBT stuff, which is of course serious. I did a little investigation, and it also seems that their filter blocks many searches for nonmainstream sexual practices, regardless of the pornographic content of the webpage. This has some tremendously negative effects. For example, one can search for "lesbians" and get some okay-looking webpages, and for "kink" and get some webpages about hairstyling and bent ropes, but when one searches for "lesbians and kink", you get no results with the "safe" filter on. There are probably bunches of other examples, but that one is seriously problematic in my book.
Furthermore, when I search for that term, it gives me advertisements for at least one thing that it presumably would have filtered otherwise, which kind of implies to me that the whole filtering mechanism just sucks.
Can we try it with the filter off in the next alpha and see if it is finally the straw on the camel's back that sets off the promised pornopocalypse that has yet failed to destroy western civilization?
Trac: Cc: N/Ato mikeperry Priority: normal to major
And here's a less serious-business example. With the filter on, when you search for "tom lerher smut", you get a lot of generic Tom Lehrer results. If you want Mr. Lehrer's delightful anticensorship anthem, "Smut", you need to turn the filter off.
And here's another one. If you search for "The Owl and the Pussy-Cat" , hoping for the Edward Lear poem and punctuating its title properly, you get a bunch of cat and owl articles because that word for a cat is a naughty one. (Sometimes you get the right poem way down on the page.) The advertisers present you with the right poem, though. If you turn off filtering, you get the nice nonsense poem you wanted.
You cannot search for "pussy riot" either, because of the same forbidden word. WTH.
I remark in passing that "Moby-Dick" appears to be unfiltered, as "Dick's Sporting Goods", as is "Dick Cheney".
I could do this all night, but I shouldn't have to. The pussy riot one should clinch this. Let's kill this filter hard.
What we're seeing here is actually a change in Google's Safesearch. It used to be on by default and quite a bit smarter about differentiating porn from non-porn. Now it seems to be keyword based and off by default. I will email the Startpage people and tell them that Google's filters have changed, and see what they say.
If they still want to keep this new junky version enabled, I guess we'll have to experiment with encoding Startpage preference URL in the omnibox.
I wonder if their video/image filters also got dumber.
Trac: Summary: startpage.com filters search results to startpage.com filters search results by keyword now (due to Google change)
So, if their reaction is "I guess we won't filter by default any more", great, let's use their default. But if it's anything else (including "we'll ask google nicely" or "we will have better, smarter filters" or no prompt answer), I think we should try to use the preference URL.
nickm: Agreed. I just sent them a mail to see if they will change their default. I also asked if the preference URL was stable (so we can rely on it not to change format/names for prefs).
If keyword.URL is gone, it should be a different ticket to remove it. We should probably file a new ticket for pref cleanup, or just do it when we rebase for ff31esr.
Trac: Status: reopened to closed Resolution: N/Ato fixed