Another thing: it is important to distinguish default search providers vs. suggestion providers vs. tab-to-search providers. The security requirements and what restrictions are reasonable may well be different for each.

Note: My proposal is that we deprecate support for setting your default search engine to a non-secure engine.

I don't think we should remove support for tab-to-search on HTTP engines unless we get to the point of removing support for HTTP navigations entirely.

My biggest concern is with non-secure Search Suggestion URLs-- these silently leak the user's keystrokes in the omnibox in plaintext and this is unacceptable. I believe we could deprecate HTTP suggestion URLs immediately (e.g. M58) in parallel with outreach, as a first step toward securing our users and deprecating HTTP search engines more broadly.

I agree with Peter that we should continue to support tab-to-search on HTTP providers as long as we support navigation to HTTP. Perhaps we could add a "HTTPBad" treatment to our existing "Search <x>" chip, or the dropdown?

Deleted: HTTPBadForSearch.png 6.1 KB

	HTTPBadForSearch.png 6.1 KB View Download

Does Chrome have any sort of "Search Provider Upgrade" feature? 

(IE had a capability whereby we could remotely "upgrade" search providers in existing clients. E.g. if http://www.yahoo.com changed to https://search.yahoo.com, we could seamlessly rewrite all user providers to point to the new host.)

I agree with both #2 and #3.

#4: I think that would be possible; we've done a similar thing for dangerous filename extensions (see chrome/browser/resources/safe_browsing/download_file_types.asciipb).

From palmer on the other thread:

jschuh said we should get UMAs for All The Things: Protocol for Tab-To-Search, protocol for default search engine, protocol for suggest.

Maybe we already have some of those numbers. ktam or pkasting, are you up to speed on the meaning of all the search-related UMA histograms? I am not. But I don't immediately see any that specifically separate out protocol.

It may be that, for example, Tab-To-Search over HTTP is already very rare, and that we could start requiring HTTPS for it without breaking very much. Or the same for suggest. But we should find out. Does anyone want to be the one to add some UMA counters?

@3: The following prepopulated engines currently use HTTP suggest URLs:
AOL
Ask
Baidu
Daum
Mail.ru
Seznam
Sogou
Yahoo! Japan
We can't deprecate all these in M58 in parallel with outreach, no.  I don't think a situation that we have shipped for 8.5 years is suddenly "unacceptable", but I agree with you that we should try to move away from this and should do outreach, and set a deprecation timeline.  The situation is not "leaking all the user's keystrokes", and we have a wide variety of defenses to try to avoid sending sensitive data over this channel.  These aren't perfect, but if you want to judge the threat accurately here, you should understand in detail what we actually do.  Remember that we designed the system back in a time where we were just as aware of the chance of people listening to HTTP, yet Google itself was doing suggest over HTTP, so we were explicitly trying to build something we thought worked for that case.

@4: It depends what you're asking about.  If it's prepopulate data, we control that and can update it by shipping a new binary.  If it's detected engines, then if the user doesn't edit them, in theory they will get auto-replaced by newer data if the site itself updates.  In practice I think there are bugs in this.

@6: We have no metrics at all to capture protocol for tab-to-search, and the only metrics we have for default search just tell you which prepopulate_id the DSP is set to, from which you can sort of intuit protocol if you correlate with the prepopulate data (this is messy, but we don't change it often, so it can work).

Honestly, I don't think we need any additional metrics for this.  What are they going to tell us that will change any plans in any way?  We all agree we want to move to a world where default search is limited to HTTPS and tab-to-search is not, and we agree that a first step is to reach out to engines that use HTTP regarding switching to HTTPS by default, including actually changing Chrome over to do this if those engines currently support it and don't explicitly tell us not to.  That first step should be taken immediately.

#7: I think most of us believe the goal is secure everything, but that we might tolerate non-secure TTS for longer than we will for default and suggest. But the end-state is secure everything.

And that's the reason for clear UMA metrics: To see how far each of TTS, suggest, and default are from the goal, and when we can move closer to the goal in each of those 3 areas.

Comment #8 is correct. We will get to a state in the not too distant future where all of these are over a secure transport, and we need metrics to plan that timeline.

@8: By "end state" do you mean "the world where the browser itself does not support HTTP"?  Because comments 2 and 3 and (I thought) 5 all suggest that non-default engines not supporting HTTPS is a non-goal until that world.  But comment 9 talks about "in the not too distant future", and in my head, that world is not in the not-too-distant future.

Or are people basically saying "we're going back on the idea that navigation to HTTP sites and using those sites' engines from the omnibox are linked features that should be toggled simultaneously"?  Because if so I can't agree with that course of action.  These are part of the same conceptual action, and regardless of usage, it would be a mistake to remove one before the other.

Yes, unless we have very compelling data to argue otherwise (hence the need for metrics), we should not gate dropping support of HTTP search URLs and registration on generally dropping HTTP.

That's the core design proposition of tab-to-search, though: you can search any site you'd navigate to by just starting to navigate to it.  I don't see how it's different to suggest that users are in so much danger from that that we have to prevent it from working than it is to suggest that users are in danger from actually going to those sites and using the search boxes on them.  All you're proposing is making Chrome work more poorly for no security gain.

I don't think we need to resolve this right now, since the far more important steps to protect people are ones we agree on.