Block META redirect within NOSCRIPT element at Google search

[1]

Apparently Google wants to use javascript.
So I sent this feedback :

OK so now Google wants to use javascript.
Trust me, there are many who would rather not.
If Google is still really not EVIL, then, is there a Google search page,
which does not require javascript, like the older ones years ago?
I use Google because it was so very friendly to non-javascript browsers.
Now I am searching for another search site, unless Google still provides this.
Can you list a link to this somewhere that anyone can easily find on your page?
Much appreciated if a link like this exists, or if Google simply goes back to not having META REDIRECTS and other modern extravaganza, etc.
Thank You, for all you did.

Maybe they will help us.
Thanks Giorgio

[Tom T.]

Apparently Google wants to use javascript.
So I sent this feedback :

OK so now Google wants to use javascript.
Trust me, there are many who would rather not.
If Google is still really not EVIL, then, is there a Google search page,
which does not require javascript, like the older ones years ago?
I use Google because it was so very friendly to non-javascript browsers.
Now I am searching for another search site, unless Google still provides this.
Can you list a link to this somewhere that anyone can easily find on your page?
Much appreciated if a link like this exists, or if Google simply goes back to not having META REDIRECTS and other modern extravaganza, etc.
Thank You, for all you did.

Maybe they will help us.
Thanks Giorgio

https://ssl.scroogle.org
No META warnings, blocks, or "click here".
No scripting required; resultant links also don't require scripting for an effective click. (Of course, the destination site itself may.)
No cookies required.
No ads.
No record kept of your search queries, or so they say.**
Logs deleted within 48 hours vs. 2 years or more for Google. **

You still get Google results. What they do is substitute their own IP for yours, send your query to Google, retrieve the results, remove the cookies, the ads, the "sponsored links" and the "shopping results" -- I searched "e-book reader" at Scroogle and at Google. What a difference! -- and send the sanitized page back to you.

** I have no connection to this site, personally or financially. I can't control what they do, or verify that their claims are always adhered to. So this information is posted in the hope that it might be useful, but with no liability or warranties, express or implied. ... Having said that, just the above list of stuff stripped out of the results, and the freedom from script and cookies, is still, IMHO, a huge improvement over Google. YMMV.

[Dirk]

https://ssl.scroogle.org

A lot of personalized scroogle-plugins are available. How should I decide, which would be te best for me. Normally I use the standard google search field of FF8, but at the moment I get a couple of advertizings despite of the use of AB+ and NoScript.

Should I use scroogle.de or a plugin, that was modified by a user? I do not search only in my own country, but often use english search items and I have to be sure to get all the relevant hits without filtering.

[Tom T.]

A lot of personalized scroogle-plugins are available. How should I decide, which would be te best for me. Normally I use the standard google search field of FF8, but at the moment I get a couple of advertizings despite of the use of AB+ and NoScript.

Should I use scroogle.de or a plugin, that was modified by a user? I do not search only in my own country, but often use english search items and I have to be sure to get all the relevant hits without filtering.

The Scroogle site itself will tell you that they can't, and don't, test every possible Scroogle plug-in, of course.
Nor can I.

Searching (via Scroogle, of course for "scroogle firefox plug-in" brings many results.
At least this developer delivers his products through addons.mozilla.org , who seem to be trying harder to vet plug-ins and to revoke those found to be unsafe or ineffective.

Also, he offers three different versions there: a universal one, one that returns only results in German, and one that returns only results in English.

I just did a quick test, and it seems the universal one will meet your needs. From the home page listed above, ssl.scroogle.org, I entered
Berliner Mauer
and the first link on the list was to "Berlin Wall' at en.wikipedia.org
The second link was to "Berliner Mauer" at de.wikipedia.org.

Many other links appeared, in both German and English. So unless you want to install separate plug-ins for .de and .en, using the dropdown bar to choose, it seems like the basic plugin,
https://addons.mozilla.org/en-US/firefo ... ssl-search
should meet all your needs.

Please note that I haven't personally tested this add-on thoroughly. I'm only passing on a Mozilla-registered add-on that looks like what you want.
*Personally*: I just have Scroogle as the very first entry in Bookmarks. You could bookmark both the En and the De Scroogle pages. But I know a lot of people like to have a search bar available always. I like having more screen space (laptop) and fewer toolbars. So it's just personal taste.

If you do try it, please post a review there to let others know. And also, perhaps you could post back here whether this plug-in was satisfactory?
We get so many issues with Google that it would be good to have user feedback on these alternatives, including search plug-in alternatives. Thanks.

[Mc]

Seems whatever Google did to fix this for us has regressed. I'll ask Giorgio to revisit this. Thanks for the report.

Will there finally be a NoScript solution or must we modify the google using (keyword) searches by adding &gbv=1?

[Tom T.]

Seems whatever Google did to fix this for us has regressed. I'll ask Giorgio to revisit this. Thanks for the report.

Will there finally be a NoScript solution or must we modify the google using (keyword) searches by adding &gbv=1?

I had asked Giorgio a while ago. Probably the previous work-around, to add to
noscript.forbidMetaRefresh.exceptions

Code: Select all

^https?://(?:www|encrypted)\.google\.(?:[a-z]{2,3}|[a-z]2\.[a-z]{2,3})/ t.co

would work. I''ll ask him again. He just apologized to another user at another thread for a delay, as three new Web threats had emerged that needed to be dealt with. IMHO, I like his priorities.

[Mc]

I had asked Giorgio a while ago. Probably the previous work-around, to add to
noscript.forbidMetaRefresh.exceptions

Code: Select all

^https?://(?:www|encrypted)\.google\.(?:[a-z]{2,3}|[a-z]2\.[a-z]{2,3})/ t.co

would work.

Doesn't work here.

IMHO, I like his priorities.

Me too
So let's just wait.

[Giorgio Maone]

Sorry, this thread got very long and convoluted.
What should I test at this point, exactly?

[Guest]

Sorry, this thread got very long and convoluted.
What should I test at this point, exactly?

See from here: http://forums.informaction.com/viewtopi ... 713#p32713
to here: http://forums.informaction.com/viewtopi ... 869#p32869

That's a regression made by Google...

[Giorgio Maone]

I had asked Giorgio a while ago. Probably the previous work-around, to add to
noscript.forbidMetaRefresh.exceptions

Code: Select all

^https?://(?:www|encrypted)\.google\.(?:[a-z]{2,3}|[a-z]2\.[a-z]{2,3})/ t.co

would work.

Doesn't work here.

It still works just fine for me (it's the default value in current NoScript versions).

Did you double check your value is exactly that?
If you did, could you please provide me with the exact URL where the refresh blocking happens?

[Tom T.]

In both Fx 3.6.24 and Fx 8.01, NS 2.2.2rc4 on both, adding back the above exception,

Code: Select all

^https?://(?:www|encrypted)\.google\.(?:[a-z]{2,3}|[a-z]2\.[a-z]{2,3})/ t.co 

solves the problem, mostly. There may be a brief flash of the white "click here" page, but then the results page loads with no further action, and the resultant links work, too.

Perhaps many users who, like myself, removed the exception when Google "fixed" it the first time, did not realize that they needed to add it back, and that a NS Update would not do that for them. (only on rc builds?) I admit that before this issue came up, I didn't realize that an update wouldn't change a user-set about:config pref, even if that was the purpose of the update (to add an exception to fix an issue).

Is there any possibility that NS itself can be modified to suit Google's code without the exception, Giorgio? .. Or if you still have good relations with your contacts there (per some Hackademix articles), could you persuade them to re-fix it on their end?

[Mc]

I had asked Giorgio a while ago. Probably the previous work-around, to add to
noscript.forbidMetaRefresh.exceptions

Code: Select all

^https?://(?:www|encrypted)\.google\.(?:[a-z]{2,3}|[a-z]2\.[a-z]{2,3})/ t.co

would work.

Doesn't work here.

It still works just fine for me (it's the default value in current NoScript versions).

Did you double check your value is exactly that?
If you did, could you please provide me with the exact URL where the refresh blocking happens?

Haha, I tried this code not recognizing it's the default one. And about:config shows it as user set.
So I always used the default code , and I'm not redirected, if I do keyword searches.
Just add a bookmark with Location
http://www.google.com/search?q=%s
and a keyword.
I use it modified for several (forum) searches like Mozdev and MozillaZine.
I'm not redirected, if I do a keyword search from url bar.
Redirection is finished by google, though, if I use the same search from SmartSearch.