+rolfe also made sample discussion mocks for this.

Today we discussed that we should annotate in this SE chooser UI which SEs are not HTTPS. This could be just a simple icon (warning triangle / lock instead of page icon?)

Max, is this something you would help look at?

Alternative idea: should this be a HTTPS-only feature? We are granting access to trusted Chrome UI (the blue search chip replacing security indicators) so it seems reasonable to have minimum security requirements as we have for some permissions.

We should also make sure that sites from the Safe Browsing list are blocked from adding search engines.

maxwalker - I felt exactly the same way! I'll forward you a thread for reference. pkasting@ weighed in on the difficulty of making it https-only (although I think in the long run that would be a nice place to take things.)

My quick mock attached, but hat tip for palmer@ for mock-making. The more the merrier!

Deleted: VerboseStateSearchEngine.png 159 KB

	VerboseStateSearchEngine.png 159 KB View Download

Issue 689745 tracks the proposal to limit Search Providers to HTTPS. That issue is considerably more contentious for a number of reasons, so we should limit this issue to the "HTTPBad" UX proposals.

Our long-term goal is to not show "Secure" for HTTPS sites and given the space constraints here, I think it makes sense not to. I think we should instead explicitly show "Not secure" only for HTTP sites. 

I'm a little nervous about the (i) icon as it invites "click for more info" and I don't think the proposal here includes supporting that as a feature.

Are we limited to keeping the "single-line of text" design we have today? Or could we do something more like the attached?

Deleted: NonsecureProvider.png 22.2 KB

	NonsecureProvider.png 22.2 KB View Download

Alternatively, perhaps we could just show the /!\ on not-secure providers and add an explanation to the footer, next to the "Done" button?

Deleted: FooterWarning.png 42.5 KB

	FooterWarning.png 42.5 KB View Download

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?

Re c#2 and c#3 -- totally, I think we should try to get there in the medium term too. We'll need to do a lot of UMA collecting, outreach, and maybe getting ecosystem players to move in the mean time, so wanted to talk about UX options for the short-term.

I think we should talk *just* about the UI on this bug, and talk about things like UMA and breaking changes on Issue 689745. @palmer I'm going to add your comments there :)

If the (i) can be clickable, we could direct to the help center, and give more info there.

We should make a judgement call on whether we want to try to get in an annotation quickly for the existing UI, or redesign this known-to-work-poorly chooser UX more broadly, and have the indication be part of that design consideration.

Re #9 can you give a brief overview of what else about this is poor, and how often this surface is accessed?

See bug 144389, especially comment 2, and bug 8395 to start with.

I don't know how often the surface is accessed.

The search engines view is already very information dense. So I'm a bit concerned that adding too many warning indicators could cause visual clutter and warning fatigue. Limiting warning indicators to the default search engines list (highest security risk) could alleviate this.

Some additional ideas - until non-secure search engines are unsupported:

1) We could reuse the existing Settings pattern of showing an icon and tooltip next to the control on the right. The red icons would still be quite noticeable but not break the column layout too much (left-aligned text). See attachment 1 (wording WIP).

2) Another idea to prevent users from adding a non-secure default search engines: show a confirmation dialog with a warning. It would be possible to set non-secure engines, but we would warn users. If a search-engine is still added, it would show an inline warning as described above. See attachment 2 (wording WIP).

I agree with Peter that the current UX should be improved in general.

Deleted: 1) Icon & Tooltip.png 245 KB

	1) Icon & Tooltip.png 245 KB View Download

Deleted: 2) Dialog.png 249 KB

	2) Dialog.png 249 KB View Download

Ah, both of those look nice, Max, thanks! I think since we are moving towards removal, we should pick a simple implementation -- @Peter, can you comment on complexity of implementation?

I can't -- this is WebUI, you'd want someone like dbeam@ to comment on that.

Adding +dbeam@ to comment on WebUI complexity

i think this would be fairly simple to do, but we'd likely not want to add it until after md-settings ships (for prioritization purposes we're only getting on par with the old options page until shipping)

Removing myself - maxwalker's got this one