Investigate whether going directly to search suggestion URL violates search provider TOS

NEW
Unassigned

Status

()

defect
P5
major
5 years ago
3 months ago

People

(Reporter: rrayborn, Unassigned)

Tracking

(Blocks 1 bug)

31 Branch
ARM
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(fennec+)

Details

Reporter

Description

5 years ago
Not sure if this is a known issue but clicking on some Google search results is taking me to the local domain http://<search-term>

Steps to reproduce:
1) Type in a search term to the URL bar something. eg: "fac"
2) Click a single word Google result that ISN'T the first result. eg: "facebook"
  (For some reason it works fine for the first result, but only the first result)
3) Fennec will take you to the local server address of the search result.  eg:
"http://facebook/"

This was reproduced dozens of times with terms like
 * type:"dog"  click:"dogecoin"  resolves to "http://dogecoin/"
 * type:"cat"  click:"catfish"   resolves to "http://catfish/"
 * type:"toro" click:"toronto"   resolves to "http://toronto/"
 * type:"fac"  click:"facebook"  resolves to "http://facebook/"
 * type:"bar"  click:"bart"      resolves to "http://bart/"
 * etc

Thanks
This is not related to the new search activity.
Component: Search Activity → General
Rob, can you confirm whether this happens in the latest Nightly (https://nightly.mozilla.org)?
Reporter

Comment 3

5 years ago
Brian - This does not effect Nightly, but it does effect Beta.
(In reply to Rob from comment #3)
> Brian - This does not effect Nightly, but it does effect Beta.

Looking at [1], isSearchQuery does a URL load rather than a search if isSearchQuery() returns false. We pass false to use as the default if we can't determine whether the query is a URL or a search, which seems like a bug to me -- I always thought we defaulted to true (i.e., a search) there.

So what's happening is basically the same as typing a single word and hitting enter, which is fixed by bug 693808 (Fx33+).

[1] http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/home/SearchEngineRow.java#82
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 693808
Is this fixed bug bug 693808? I think it is actually fixed by bug 1047607.
Flags: needinfo?(bnicholson)
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #5)
> Is this fixed bug bug 693808? I think it is actually fixed by bug 1047607.

The candidates were bug 693808, bug 854305, bug 993705, and bug 1047607. Bug 693808 seemed like the logical choice since it's the real fix, and the other bugs are more about the workaround.
Flags: needinfo?(bnicholson)
Reporter

Comment 7

5 years ago
I'm glad to see that this has been fixed for the majority of use-cases, but this being fixed as a side-effect of previous bugs can still lead to questionable behaviours:

1) We are still treating the 1st "suggestion" different from Google's other suggestions. If I type in "amazon.co" and click the 1st "suggestion" ("amazon.co") then it resolves to a Google search for "amazon.co".  Whereas if I click any other suggestion that would resolve isSearchQuery() to false I get the webpage (2nd result "amazon.com" goes to http://amazon.com).  At the very least we need to fix this inconsistent behaviour
2) If we are implying that auto-suggest is a search query, then IMO we should treat it as such.  If I type "amazon.co" and click "amazon.com" under a Google search branded element I expect to be taken to a search rather than being taken to the URL.  As a former AWS TAM (few years ago), ***I'm also guessing that using Google's auto-suggest and then going directly to a URL is a violation of there TOS unless we got a contractual exception.***

Reopening for now, LMK if you'd like me to file separate bugs or if my assumptions are not correct.

Thanks
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Reporter

Updated

5 years ago
Group: mozilla-employee-confidential, core-security
Reporter

Comment 8

5 years ago
I was asked to change this to a "private" bug due to possible TOS concerns until we get resolution.

Thanks
tracking-fennec: --- → ?
(In reply to Rob from comment #7)
> I'm glad to see that this has been fixed for the majority of use-cases, but
> this being fixed as a side-effect of previous bugs can still lead to
> questionable behaviours:
> 
> 1) We are still treating the 1st "suggestion" different from Google's other
> suggestions. If I type in "amazon.co" and click the 1st "suggestion"
> ("amazon.co") then it resolves to a Google search for "amazon.co".  Whereas
> if I click any other suggestion that would resolve isSearchQuery() to false
> I get the webpage (2nd result "amazon.com" goes to http://amazon.com).  At
> the very least we need to fix this inconsistent behaviour

The first suggestion corresponds to the user-entered query, so it's assumed that the user always wants to do a search when clicking this suggestion (otherwise, they would just hit enter/Go from the URL bar). In other words, if I've fully typed "gmail.com", the only reason I would tap the first suggestion would be if I wanted to search for it. If we were to use the same URL-following behavior for the first suggestion as we used for the remaining suggestions, that means it would be impossible for user to actually do a search for "gmail.com".

However, if I type "gmail." and see "gmail.com" as one of the suggestions, I most likely want to go to http://gmail.com. I agree this might seem inconsistent, but at the same time, the first suggestion has the search magnifier icon that differentiates from the rest, so I don't think it's unreasonable for them to have different behaviors.

> 2) If we are implying that auto-suggest is a search query, then IMO we
> should treat it as such.  If I type "amazon.co" and click "amazon.com" under
> a Google search branded element I expect to be taken to a search rather than
> being taken to the URL.  As a former AWS TAM (few years ago), ***I'm also
> guessing that using Google's auto-suggest and then going directly to a URL
> is a violation of there TOS unless we got a contractual exception.***

The vast majority of the time, the user will want to go to the suggested URL rather than do a search for that URL. We actually implemented this in the first place because people were entering "amazon.", clicking "amazon.com", then were getting annoyed at the indirection. Note that if you really wanted to do a Google search for "amazon.com", you could type "amazon.com" and click the user-entered suggestion as described above.

The point about violating Google's TOS is interesting, and I'm not sure whom to ask. CC'ing some people that may know.

Given the private change, I'm going to morph this bug to the second issue. Feel free to file a follow-up about the first issue, and UX can have a look.
Status: REOPENED → NEW
Summary: Google searches resolving to local domain http://<search-term>/ → Investigate whether going directly to search suggestion URL violates search provider TOS
Reporter

Comment 10

5 years ago
@Brian - I appreciate the thorough response.  Thanks for bringing me up to speed on the thought process.  It's clear that this behaviour has had adequate discussion so I won't file a bug for it.
This shouldn't need to be core-security
Flags: needinfo?(dveditz)
Group: mozilla-employee-confidential, core-security
Flags: needinfo?(dveditz)
Reporter

Updated

5 years ago
Blocks: 1052172
mconnor, can you weigh in here?
Assignee: nobody → mconnor
tracking-fennec: ? → +
filter on [mass-p5]
Priority: -- → P5
Assignee: mconnor → nobody
You need to log in before you can comment on or make changes to this bug.