To first be launched in the 'Firefox Confidential' add-on. The idea here is to provide a visual notification to a user if they are entering a search query or use a search suggestion that doesn't go over https. Of course, most users don't understand what that actually means. Therefore we need to have a link and landing page that provides this information to allow users to make an informed decision based on unbiased facts. Requires the copy, mechanism to provide the visual notification and ability to detect when this should show up.

This bug will track the feature in the product, not in the add-on.

Robin and I briefly talked about this and we would like to know a few things before making some design suggestions. Questions: 1. Among the default set of search engines on Fennec, do we know which ones are doing HTTPS by default, which ones are not? Or is that dependent on the search terms? 2. At which stage of the search interactions, does a browser know a search query/search suggestion is not going HTTPS? Is it before the user press on the search term/suggestion? Or after a search is performed? 3. Can Fennec switch a search query from HTTP to HTTPS? If the browser can detect the search engines that are not HTTPS, when the users attempt to add them to the list, Fennec can notify the users that this is not secure, and confirm if they still would like to add it. If Fennec can only detect HTTPS after a search has been performed, a visual notification could be helpful. Even more, if the browser can automatically/with permissions switch a search query from HTTP to HTTPS, then we should offer that option and ask the users if they want to keep it that way for all search queries.

Strictly speaking as a feature in the product, I think a good starting point would be a simple label to the provider icons/suggestions in our current UI. But I wonder about the usefulness of this if there isn't even a recognition of the differences in our users' mind ATM. I.e. I'm concerned it might confuse them especially if their isn't really a pain point here...

(In reply to Yuan Wang(:Yuan) – Mobile Firefox Design Lead from comment #2) > Questions: > 1. Among the default set of search engines on Fennec, do we know which ones > are doing HTTPS by default, which ones are not? Or is that dependent on the > search terms? The list of engines is here: http://mxr.mozilla.org/mozilla-central/source/mobile/locales/en-US/searchplugins/ Looking at the files, I see HTTP for Amazon, Bing (will change soon) and Wikipedia. Also note that the user can add new search engines themselves. > 2. At which stage of the search interactions, does a browser know a search > query/search suggestion is not going HTTPS? Is it before the user press on > the search term/suggestion? Or after a search is performed? We know the list of search engines before the attempts the search. We may not currently know the HTTP//HTTPS state but we could add it. Search suggestions are queried before the search, but we should know that state before it's executed as well. > 3. Can Fennec switch a search query from HTTP to HTTPS? We could switch the URL, but if the search engine does not support HTTPS, then the query will just fail. > If the browser can detect the search engines that are not HTTPS, when the > users attempt to add them to the list, Fennec can notify the users that this > is not secure, and confirm if they still would like to add it. Yes, we can do that for user-added engines.

Is this something we're still trying to do as part of the Firefox Confidential add-on? Or just a feature built into Fennec? If this is just something we want in the product, I'm going to remove the dependency from the meta bug. If this is something we want in the add-on, we should file a separate bug, and start discussing what kinds of things we could do with an add-on here.

My preference is that we start implementation with the add-on to ensure we have the flexibility to tweak it before including it in our main codeline. I'm concerned there will be a lot of messaging to our mass of users who will feel it is clutter and unnecessary. Therefore I'd like to use the add-on as our test bed to get it right, instead of evolving it in our codeline (which will take longer to do). Let's get the experience started on the add-on first and once we feel it's of a good caliber, then we can integrate it.

I filed bug 1069633 about adding something to the product. So, let's shift gears here and think about what we could do in an add-on. Unfortunately, an add-on doesn't have the ability to add visual indicators to the awesomescreen, but maybe we can do something else to educate users about non-https searches. Perhaps we could just block non-https search suggestions, and then maybe prompt users when they try to do a search over http? A prompt sounds annoying, but I'm not sure of a better way to warn them before they actually start the search. We could also disable all non-http search engines, but that could confuse users if their custom search engines disappear. Or, given that we can't actually use an add-on to experiment on what we would want to do in the product, maybe we should just drop this from the add-on.

If we can provide any visual indication, the only other option would be to provide a prompt letting the user know the search they are about to perform isn't secure. Annoying? Sure. They could either 1) Tap OK and proceed with the search 2) Tap Cancel and go back to choose another search provider D) Go to their Add-on Manager and disable the add-on because they really like using that unsecure search provider.

Agree with Robin and Margaret's suggestions. I guess there are 3 things this addon could do: 1. Block the search engines that are not https by default 2. When there is a HTTP search query, show a prompt like Robin suggested to warn the users it's not going to be secure 3. When the user attempts to add a non-https search engine to the list on Customize/Search, tell the user the search engine is not secure and the addon is blocking it.

I started playing around with this, and I was able to add some logic to prompt a user before performing a non-https search: https://dl.dropboxusercontent.com/u/3358452/2014-10-08%2020.57.20.png However, this only works if the user taps on a search row, not if they just submit a free-text search. To address this, I think we should do something to warn the user that their default search engine doesn't use https when the add-on is installed. Robin, do you have ideas about a good way to do this? Hopefully this would be pretty edge-casey, since the default engines we ship all use https. I am also going to work on adding a warning when the user tries to add a non-https search engine. And I could also display a prompt if the user tries to make a non-https engine their default in settings. Anything I'm missing?

I've been talking with Robin on IRC, and here are the features I've added: 1) Prompt user if they tap on a non-https search engine in the awesomescreen: https://dl.dropboxusercontent.com/u/3358452/2014-10-08%2021.56.09.png 2) Show a toast if the user sets a non-https engine as their default: https://dl.dropboxusercontent.com/u/3358452/2014-10-08%2022.18.13.png 3) Prompt user if they try to add a non-https engine from the Page menu: https://dl.dropboxusercontent.com/u/3358452/2014-10-08%2022.50.31.png 4) Prompt user if they try to add a non-https engine from the text selection action bar: https://dl.dropboxusercontent.com/u/3358452/2014-10-08%2023.02.09.png The code is all in my github repo, maybe mfinkle or rnewman would like to do a sanity check code review: https://github.com/leibovic/privacy-coach/blob/master/bootstrap.js Also I updated the build here: http://people.mozilla.org/~mleibovic/coach.xpi

This all looks great, Margaret. The only one I question is the toast that says "you may want to change your default back". Back to what? Let's drop the word 'back'.

(In reply to Robin Andersen [:tecgirl] from comment #12) > This all looks great, Margaret. The only one I question is the toast that > says "you may want to change your default back". Back to what? Let's drop > the word 'back'. Done! https://github.com/leibovic/privacy-coach/commit/342932ab394fc8d1c04cee8c9190535b3ca73e02 I'm going to close this bug out. We can open new bugs (or just add things to the add-on) as we have more ideas.