1379247 - hide https:// but show http:// when browser.urlbar.trimURLs=true

Status: RESOLVED DUPLICATE of bug 1067293

(Firefox :: Address Bar, enhancement)

Description

[Darkspirit]

Please hide https:// but show http:// as it was planned for Photon a while ago:
https://www.soeren-hentzschel.at/wp-content/uploads/2017/04/firefox-57-photon-hauptmenue.png

What to change:
https://dxr.mozilla.org/mozilla-central/source/browser/base/content/utilityOverlay.js#958
>  // remove http://
>  if (!url.startsWith("http://")) {
>    return url;
>  }
should get changed to
>  // remove https://
>  if (!url.startsWith("https://")) {
>    return url;
>  }

Comment 1

[Darkspirit]

I couldn't find any bug about this topic, so I created this one. This may be a candidate to block bug 1352366.

Comment 2

[Darkspirit]

(In reply to Darkspirit from comment #0)
> should get changed to
> >  // remove https://
> >  if (!url.startsWith("https://")) {
> >    return url;
> >  }
plus
> let urlWithoutProtocol = url.substring(8);
and one or two tests below

Comment 3

[Sören Hentzschel]

(In reply to Darkspirit from comment #0)
> Please hide https:// but show http:// as it was planned for Photon a while
> ago:
> https://www.soeren-hentzschel.at/wp-content/uploads/2017/04/firefox-57-
> photon-hauptmenue.png

This was an early mockup, it doesn't mean that it was really planned for Photon. Current mockups shows the "https://" in the url bar for https pages, so it's not part of the Photon redesign.

Comment 4

[Darkspirit]

(In reply to Sören Hentzschel from comment #3)
I've noticed this and saw that there was no bug in general about this, so I created this one.

The clear green padlock shows us that we are secured.

Release Date | Version | HTTP_PAGELOAD_IS_SSL
2016-11-15 	Firefox 50 	49,82 %
2017-01-24 	Firefox 51 	52,02 %
2017-03-07 	Firefox 52 	54,30 %
2017-04-19 	Firefox 53 	57,74 %
2017-06-13 	Firefox 54 	58,93 % <- current

Average increase: 2,28 percentage points

Future:
2017-08-08 	Firefox 55 	~61,21 %
2017-09-26 	Firefox 56 	~63,49 %
2017-11-14 	Firefox 57 <3 	~65,76 % <- expected
2018-01-16 	Firefox 58 	~68,04 %, but https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html may be a push

Comment 5

[Johann Hofmann [:johannh]]

I don't think this is part of Photon, this change needs a discussion of its own. You're right in that the case for hiding https by default is getting stronger and stronger over time, but there are many implications from doing this, so we have to tread carefully here.

I'm leaving this in Photon triage for the rest of the team to confirm.

Comment 6

[Darkspirit]

(In reply to Johann Hofmann [:johannh] from comment #5)
> I don't think this is part of Photon, this change needs a discussion of its own. You're right in that the case for hiding https by default is getting stronger and stronger over time, but there are many implications from doing this, so we have to tread carefully here.
> 
> I'm leaving this in Photon triage for the rest of the team to confirm.

Thank you for your comment and I very appreciate your caution.

Some further thoughts on this:
Possible cases:
One types in "example.com" and expects to see "example.com".
a) Plaintext: The webserver doesn't respond a 301 to https and so we see "http://example.com".
b) Redirection: The webserver responds a 301/307 to https, so we see "[green padlock] example.com".
c) HSTS/Preloading: We only try to connect to https, so we see "[green padlock] example.com".

Current behaviour:
* We try to connect to http:// (then we might get a redirection) or respect HSTS.
* URLs of Awesomebar results (https:// or just www.) are determnined by browser.urlbar.trimURLs.

For evaluation:
* Awesomebar: For consistency it could be evaluated to show a blue padlock (like the URL color) before those trimmed https urls.
* A bonus: Try to connect to https:// if we get "connection refused" or a timeout over X seconds on port 80: bug 1002724

What users currently might perceive:
I type in example.com, so I see example.com. This is fine and clear.
I type in banking.example.com, but then I suddently see a "[green padlock] https://banking.example.com". It appears complex because it's like "[icon] blabl://blabl.this-interests-me.com".

What users then might perceive:
I type in example.com and then I see http://example.com. I know this is an URL and it looks a bit longer. Fortunately, I see this more rarely.
I type in banking.example.com, then I see a green padlock and banking.example.com. This looks tidy and secure. I feel comfortable.

So this would be then for a very long transition period until http:// should be shown in red in the far future.

Comment 7

[Darkspirit]

Attachment: hide-https-but-show-http.png

Comment 8

[Darkspirit]

Attachment: hide-https-but-show-http.png

Added bug 1310447, bug 665859 and bug 1335970 for a better overview, to sketch a possible roadmap. B1 would be great if we think of mobile devices. This bug was initially about option B2.

Comment 9

[Madis]

(In reply to Darkspirit from comment #7)

As a user, I'm all in to hiding "https", showing "http" and marking those sites as insecure. However, I'm feeling a bit dubious about ever showing "http" in red per se (you said far future, but still).

Nowadays, people mostly see the "http" when reading plaintext links, whether it is in a webpage, forum, game, instant messaging and so on. Users perceive it as a hyperlink, some software only parses it when there is a protocol and it is just easier to type/memorize "http" than "https", too.

So, when "http" is written in red, I expect people to
* get confused - what's wrong with the website? Clicking the insecure icon explains the problems, but the word itself doesn't.
* get discouraged at clicking any links - the browser taught me http is bad, so I should not click an URL that contains one (even if it just redirects to https anyway)
* learn to ignore warnings, as a result of previous points

I do hope you consider this, and would like to hear any counter-arguments if you have them.

Comment 10

[Darkspirit]

Attachment: hide-https.png

(In reply to Madis from comment #9)
If I understand you correctly it would be better to improve the positive incentives and to less frighten the user, even http is bad.

Maybe just hide both https and http like it is done in Microsoft Edge or Firefox on Android to simplify the locationbar and to make https look less complex.

Comment 11

[Sören Hentzschel]

In my opinion it's a terrible idea to hide the protocol for http AND https. For me it doesn't matter if Firefox shows http:// but not https:// or https:// but not http://. But it's not obvious enough if the only difference is a small icon. Also the tooltip has to be changed with the new proposal - "verified by …" does not explicitly tell that this a https connection, this would require more knowledge from the user. It's already difficult enough to know the difference between http and https for the average user. And on the desktop we have more space than on a smartphone so maybe it's a benefit on the smartphone to always hide the protocol (I am not sure…) but not on the desktop…

Your original proposal was much better in my opinion.

Comment 12

[Madis]

(In reply to Darkspirit from comment #10)
> Created attachment 8895198 [details]

Unfortunately you misunderstood me, and I agree with Sören to revert your proposal. 

My point was that it is perfectly okay to display gray http with red warning, smarter users can make the connection "http = bad" (like now "https = good"). 

However, marking "http" red by itself is bad for various reasons: 

* Color doesn't provide information - user doesn't understand why it's red 
* It is okay to use http as a starting point (so it redirects to https), but users are discouraged to do that too 
* Users see and have "http" so much in the web, they know it signifies a link and they don't know why it's bad 

I hope you understand my point now that I have tried to reclarify it.

Comment 13

[Darkspirit]

I am currently trying to make my "first patch" in form of variant B2 (just hide https://, but show http://) in attachment 8886186 [details] behind a pref. If it works well and I don't see further problems (like wrong Awesomebar results) I would try to set up MozReview, upload it there and would ask someone to make a try build to run all tests over it.

Comment 14

[Darkspirit]

Attachment: trim-https.png

So far it's a good UX for me and a friend. Now I'm looking into all expectations, whether everything is correct and if this could have negative security implications.

Comment 15

[Darkspirit]

Attachment: photon-ui-porn.png

Regarding
> [...] as it was planned for Photon a while ago:
> https://www.soeren-hentzschel.at/wp-content/uploads/2017/04/firefox-57-photon-hauptmenue.png
I want to provide this better preview of what a user might perceive then.

Comment 16

[Darkspirit]

Attachment: overview.png

(Johann Hofmann [:johannh] from comment #5)
> [...] but there are many implications from doing this, so we have to tread carefully here.

I've made an overview of the different security indicator states with some banking websites and badssl.com. So far, this is uniform, clean and comprehensible.
At the bottom you can see Awesomebar results with http and https mixed. I noticed that autocompleted domains still have the old behavior and that should get fixed, too.

Comment 17

[Darkspirit]

Attachment: bug1379247_v1_experimental.patch

* This experimental patch does not create a new pref: I feared performance regressions and wanted something to test easily.
* Protocol + subdomain + path are now greyed out as they should be.
* I'm not satisfied that Awesomebar shows an "https://" if I press Ctrl when it says "Switch to Tab". I'll fix it when I find it.

* This patch (now) passes the urlbar test
./mach test base/content/test/urlbar
> Browser Chrome Test Summary
> 	Passed: 134
> 	Failed: 0
> 	Todo: 0
> 	Mode: e10s
> *** End BrowserChrome Test Results ***

* (But) I can't successfully run
./mach test mochitest-1
(up to 5) because of gtk errors.


:johannh
Could you or someone else please start a linux64 try build on treeherder with all required tests, if you wouldn't mind and had a minute? Thank you.

Comment 18

[Darkspirit]

Sorry for the noise.
I found out now how to use reviewboard without having to ask someone for a review and if I could change the commit message later.

It's looking nice, but:
* If you edit a trimmed https url and hit enter you will connect via http because Awesomebar suggested you
"http://<your-edited-https-url> -- Visit". Awesomebar should suggest to connect via https as long only the path was changed.
* If I type in (the already visited) "golem.de" and press "End" Awesomebar suggests to connect via https the whole time, but when I type one character after the autocompleted "/" it now suggests to connect via http -- it should keep suggesting https.

In the next patch version I'll create a browser.urlbar.trimURLs.trim-https pref and duplicate the related tests to work for "false" (trim http) and "true" (trim https).

An exact behavior inversion would also mean you see an "example.com" tooltip when hovering an https url (but with procotol in the insecure cases) like it is done in the urlbar.

Comment 19

[Mark Banner (:standard8)]

Jan, I'd suggest that you start working with our UX team before going much further to work out the specific designs. It is apparent that this has been dropped from the Photon work - though I don't know the reasons why.

From my perspective, we recently added indications of https:// in a lot of places in the autocomplete pop-up to give users a clearer indication that they'll end up at a secure site. Although switching the indications seems reasonable to me, I'm concerned that we need to do something that's slightly more apparent (e.g. if we suddenly switched would "eye memory" make me think the http was an https) - working through this with UX first would likely save time for writing/adjusting the patch.

Comment 22

[Anne (:annevk)]

Duplicate of bug 1067293?

(FWIW, I think we should go toward the Safari solution (except for their EV UI) and not display path by default either. When the field is focused we can show more of course.)

Comment 23

[Johann Hofmann [:johannh]]

Let's dupe it!

Comment 24

[Darkspirit]

(In reply to Johann Hofmann [:johannh] from comment #23)
> Let's dupe it!

I am a bit unhappy that this got duped to bug 1067293 because it's about a different and confusing idea:
If both protocols would be hidden in the locationbar, how should one learn which type of link is normal and which strange/dangerous?

An always invisible https:// without padlock (also invisible in the link preview on the bottom left), 
but visible (light-)red[1] http:// and ftp:// after a crossed padlock with Not Secure text (and also visible in the link preview on the bottom left) would be still my long-term suggestion.

Please consider going the path of bug 1310842 (which is the way Chromium probably wants to go).

If this would come, then after attachment 8945035 [details] (bug 1335970), but before removing the padlock.

[1] against eye memory problems, comment 19.

Comment 25

[Darkspirit]

Oops. It's just your last comment there ("We should just hide both.") that has irritated me so much. Sorry. This one is like bug 1310842; please pretend that I haven't said anything:

(Tanvi Vyas[:tanvi] from bug 1067293 comment 9)
> People don't notice the absence of security indicators.  So ideally we would:
> * add a negative indicator for http.
> * leave http:// in the url bar, and possibly make it a color that stands out
> * have no indicator for https (remove the lock)
> * remove https:// from the url bar.  If the site doesn't have a scheme
> listed, the user can assume its secure.