Confirming it's not an issue on Chrome for Windows, version 67 on both platforms.

Searches from omnibox should follow the scheme of the search engine - they are sent over HTTPs if the search engine supports it, and over HTTP otherwise.

If you actually added a custom search engine "http://www.google.com", the traffic will be in plain text. However, note that the pre-defined search engine shipped with Chrome is "https://www.google.com", which is on HTTPs.

Can you double-check the scheme of your search engine?

I haven't changed this value. This is a fresh install on Ubuntu 18.04 from Google's repo. The search engine is set to the default, google, which appears to use the http address. Maybe this got picked up in local settings, but I haven't logged into my Google account for this browser instance yet (it hasn't loaded my extensions &c).

I've attached a screenshot of the "out of the box" choices.

Deleted: Screenshot from 2018-07-16 17-28-32.png 41.8 KB

	Screenshot from 2018-07-16 17-28-32.png 41.8 KB View Download

Connections to google.com should be forced to HTTPS only due to HSTS preloading, including for search requests (since the network stack should enforce this). Strange that the query URL is http:// though, as it looks like the default defined here should be https://:

https://cs.chromium.org/chromium/src/components/search_engines/prepopulated_engines.json?l=122

Gathering a network log (https://www.chromium.org/for-testers/providing-network-details) would allow us to verify if e.g. HSTS is at least working as expected here.

Here's the network log. This is after entering testing123 on the address bar. Entering ?testing123 has a similar result.

Deleted: chrome-net-export-log.json 1.0 MB

chrome-net-export-log.json 1.0 MB View Download

It does look like HSTS is working as expected for the actual request, so nothing should be being sent in plaintext over the network (prettified JSON for readability):

{  
   "params":{  
      "load_flags":18432, "method":"GET",
      "url":"http://www.google.com/search?hl=en&source=hp&q=testing123"
   },
   "phase":1,
   "source":{  
      "id":1751168,
      "type":1
   },
   "time":"347964166", "type":96
},
{  
   "params":{  
      "headers":[  
         "HTTP/1.1 307 Internal Redirect",
         "Location: http://www.google.com/search?hl=en&source=hp&q=testing123&tbs=li:1",
         "Non-Authoritative-Reason: Delegate"
      ]
   },
   "phase":0,
   "source":{  
      "id":1751168,
      "type":1
   },
   "time":"347964166", "type":104
}

I'm not sure why a plain HTTP entry for the search engine would have gotten added though. Someone more familiar with the search engine feature may have a better idea.

Whoops, sorry, left off the important bit of the log that actually shows the connected HSTS internal redirect:

{  
   "params":{  
      "load_flags":18432,
      "method":"GET",
      "url":"http://www.google.com/search?hl=en&source=hp&q=testing123&tbs=li:1"
   },
   "phase":1,
   "source":{  
      "id":1751168,
      "type":1
   },
   "time":"347964173",
   "type":96
},
{  
   "params":{  
      "reason":"HSTS"
   },
   "phase":0,
   "source":{  
      "id":1751168,
      "type":1
   },
   "time":"347964173",
   "type":103
},
{  
   "params":{  
      "headers":[  
         "HTTP/1.1 307 Internal Redirect",
         "Location: https://www.google.com/search?hl=en&source=hp&q=testing123&tbs=li:1",
         "Non-Authoritative-Reason: HSTS"
      ]
   },
   "phase":0,
   "source":{  
      "id":1751168,
      "type":1
   },
   "time":"347964173",
   "type":104
}

I don't know enough about HSTS to comment further, but as someone trying to keep track of what's happening through the network view it would sure be less confusing, at least, to have it not show an http GET with a user-entered term when using the built in address bar search.

To clarify: were you monitoring requests at the network level (say, with a tool like Wireshark) and seeing plain HTTP requests for this? If so, then HSTS was not working as intended.

(The complexity here is entirely internal implementation details -- HSTS happens to be implemented in Chrome as an "internal redirect" and uses some of the same logic that a server-side 301/302 redirect would. This could also be exposed to developers or power-users via extensions or the Dev Tools Network panel.)

The network logs here are primarily for us to be able to diagnose what's actually going on in reports like this, rather than being interpretable for end-users.

It's still weird/undesirable that a plain HTTP search engine (for Google which should only show up in the list as HTTPS) is in your list and the default, so hopefully we can figure out why that's happening and what the problem is.

I'm seeing that result in the developer tools Network panel. I understand the 'internal redirect' is happening within Chrome, but that's confusing and should be highlighted somehow, imo, since everything starts to make less straightforward sense to end users (like me); it's more a local software decision than a network event. Definitely agree the default shouldn't be http.

For some reason the `Needs-Feedback` label didn't clear and trigger, so adding msramek@ back to cc. Also, adding some Components that may help triage the search engine issue.

I'll see if we have a bug filed for the display of the HSTS internal redirect in Dev Tools, and if not I can make a new one to track that separately (I can cc you if you'd like).

[omnibox triage, plus kicking over to Search component, not omnibox.]
I find it hard to believe this is an out-of-the-box install.

Is this a Chromium build or a Google Chrome build?  Do you have enterprise policies applied on this machine?

It certainly looks like a mis-specified search engines.  If you didn't say it was out of the box, I'd think either two things are going on here:

- the user is syncing and originally started using Chrome a long time ago.  I think in the days of your we had search engines specified differently, and that could've had a http:// for google.com.  Or, as in my case, I felt the need years ago to add a google.com keyboard because something was strange with the default that shipped with Chrome, as I added an http:// one.  Only recently did I delete it.

- something is funny with sync.  The fact that the google.com entry's keyword is google.com__ indicates to me that something is happening with sync.  Underscores are how sync resolves conflicts.

I find it hard to believe that this is truly a new install without logging in to sync.

Can you run again with --user-data-dir=blah/ and see if it shows the same two Google search engines?

I think you're right, I recall having to manually entire the search address some years ago. It does use https with a new data directory. I've since signed into my browser-level profile, but I guess something was lost in the fog. I'll just change it, but I hope that HSTS is made more clear and I'd be interested to follow that ticket.

masondavid@, thanks for your reply!

cthomp@,

I will leave it to you to further triage or close this issue.

I'll close this bug since I think we cleared out that it was a mis-entered search engine entry (potentially getting replicated with sync).

The DevTools HSTS confusion is being tracked in Issue 864690.