Opened 8 years ago

Closed 5 years ago

#4302 closed defect (worksforme)

Enabling GoogleServices but not Google Search sometimes breaks results links

Reported by: pde Owned by: pde
Priority: High Milestone: HTTPS-E 4 stable
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Keywords: httpse-ruleset-bug
Cc: simon80@…, swrobel Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When Google Search and GoogleServices are both disabled or both
enabled, things work fine. However, if the Google Search redirect rule is disabled and the GoogleServices rule is enabled, then left clicking on search result links in the non-SSL search results page will result in a redirect to the Google home page instead of the link destination.

Child Tickets

Change History (13)

comment:1 Changed 8 years ago by pde

Status: newaccepted

This was a mailing list report from August. I haven't been able to reproduce this bug yet, but we just received another report.

comment:2 Changed 8 years ago by swrobel

Cc: swrobel added

I can confirm that turning off GoogleServices gets rid of the problem with search. To clarify, the problem for me is that the links don't go anywhere (it shows some loading activity but never leaves the search results page). I can right click and open in a new tab and they go to the right place.

Details on my system: Windows 7 x64 with Firefox 7.0.1 and HTTPS Everywhere 1.1

comment:3 Changed 7 years ago by pde

A possibly related issue I observed today: if I turn HTTPS Everywhere off, the results links one gets from http://www.google.com/webhp are broken. Restarting the browser fixes this.

Possibly some caching issue?

comment:4 Changed 7 years ago by pde

Priority: normalmajor

comment:5 Changed 7 years ago by dw

This has been driving me mad for months. Can't a change be pushed to merge GoogleServices+Google rules until a better fix is found? There are a lot of very confused people out there right now.. :)

comment:6 Changed 7 years ago by pde

I agree this is a bad bug; we need someone to sit down and spend an hour or so working out why this is happening.  Motivated?  Live HTTP Headers is probably the debugging tool to try first.

comment:7 Changed 7 years ago by pde

A possibly-related bugfix:

https://gitweb.torproject.org/https-everywhere.git/commitdiff/50ca41a1e189ef8383781f803e51ec7a06688a3b

(but that was only in effect when the user had the optional "Search www.google.com" ruelset enabled, and Google was doing outgoing click tracking)

comment:8 Changed 6 years ago by mikeperry

Keywords: httpse-ruleset-bug added

comment:9 Changed 6 years ago by schoen

I reproduced this bug in the case where they're doing outbound search tracking (http://www.google.com/url links). Interestingly, the outbound search tracking links work properly (!) if copied and pasted into a new table and loaded manually, which was not what I would have expected.

comment:10 Changed 6 years ago by mikkoharhanen

Schoen's findings are peculiar... Maybe we could work around the problem and not enforce google.com/url in GoogleServices.xml. Unfortunately there is a drawback. If you do not use encrypted.google.com to search, then the resulted links are not using HTTPS. This is a problem if you use https://google.com/ and expect that your search is wholly encrypted. Therefore I would redirect google.com/url in the file GoogleSearch.xml.

Here is an illustration of what I mean:
https://github.com/mikkoharhanen/https-everywhere/commit/9779bbb110db2846bb60eb6754090caedf564fd4

comment:11 Changed 6 years ago by micahlee

Milestone: HTTPS-E 4 stable

comment:12 Changed 5 years ago by jsha

schoen: Can you still reproduce this issue?

comment:13 Changed 5 years ago by jsha

Resolution: worksforme
Status: acceptedclosed

This no longer reproduces because Google always redirects web search to HTTPS, even on a fresh Firefox profile with no HTTPS Everywhere installed. Closing.

Note: See TracTickets for help on using tickets.