Closed Bug 1067293 Opened 10 years ago Closed 1 year ago

Add pref to omit "https://" from address bar (pref'd off by default)

Categories

(Firefox :: Address Bar, task, P3)

Product:
Firefox
Component:
Address Bar
Type:
task

Tracking

()

Status:
RESOLVED FIXED
Milestone:
118 Branch
Tracking Flags:
Tracking Status
firefox118 --- fixed

People

(Reporter: annevk, Assigned: mseibert)

References

(Blocks 2 open bugs, Regressed 1 open bug)

Details

(Whiteboard: [fxprivacy] )

Attachments

(2 files, 1 obsolete file)

Bug 1067293 - Omit "https://".r=dao
(deleted), text/x-phabricator-request
Details
WIP: Bug 1067293 - Enable https trimming and insecure connection label.
(deleted), text/x-phabricator-request
Details
It seems TLS-enabled domains have a UI disadvantage compared to domains without TLS. Namely, they show the string "https://" which normal uses come rarely in contact with outside the browser. We should follow the precedent from mobile Safari and stop showing this string. (We should probably also start thinking of ways of making non-TLS look less attractive. E.g. replace the globe with an icon that indicates surveillance.)
I think Opera 11's solution was brilliantly simple and elegant: the protocol part of the address bar was covered with a button/label with the actual level of trust. This reduced amount of technical jargon in the address bar. It solved problem of showing "https:" on pages with poor security/mixed content. When the addressbar was focused the label slided away, soothly uncovering the full URL. This avoided the annoying magic around copy&pasting http: from the addressbar. http://pureinfotech.com/2010/12/18/opera-11-is-out-with-great-new-features-tab-stacking-extensions-and-more-take-the-tour/ http://techdows.com/2010/11/opera-11-adds-safe-address-field-visual-mouse-gestures-and-updated-extensions-options.html
OS: Mac OS X → All
Hardware: x86 → All
The https:// prefix should not be removed. Besides the padlock (which can be spoofed through a favicon) and green bar, the 'https://' prefix clearly shows that the current page is accessed over a secure channel. The documentation of two Dutch banks use this for example: https://www.ing.nl/de-ing/veilig-bankieren/veilig-internetbankieren/veilige-verbinding-met-mijn-ing/index.aspx ("First check whether the web address begins with 'https'. The 's' refers to 'secure'") https://bankieren.rabobank.nl/klanten/ ("Only continue when the location bar starts with https://bankieren.rabobank.nl/...") You can imagine that this is used elsewhere too. Chrome also does not hide https, probably for the same reason...
(In reply to Peter Wu from comment #2) > The https:// prefix should not be removed. Besides the padlock (which can be > spoofed through a favicon) and green bar, the 'https://' prefix clearly > shows that the current page is accessed over a secure channel. > > The documentation of two Dutch banks use this for example: > https://www.ing.nl/de-ing/veilig-bankieren/veilig-internetbankieren/veilige- > verbinding-met-mijn-ing/index.aspx ("First check whether the web address > begins with 'https'. The 's' refers to 'secure'") By that logic, http://https.example.com/evil would be considered secure as well, since it would be displayed as `https.example.com/evil` in the address bar.
(In reply to Mathias Bynens from comment #3) > (In reply to Peter Wu from comment #2) [..] > > The documentation of two Dutch banks use this for example: > > https://www.ing.nl/de-ing/veilig-bankieren/veilig-internetbankieren/veilige- > > verbinding-met-mijn-ing/index.aspx ("First check whether the web address > > begins with 'https'. The 's' refers to 'secure'") > > By that logic, http://https.example.com/evil would be considered secure as > well, since it would be displayed as `https.example.com/evil` in the address > bar. This a bug introduced by hiding the scheme. Anyway, that page lists the valid URLs so it is less of an issue. The full text: "First check whether the web address begins with 'https'. The 's' refers to 'secure'. The correct addresses are: * Mijn ING: https://mijn.ing.nl/internetbankieren/SesamLoginServlet ..." My point stands, removal of https:// breaks expectations.
An Opera-like solution addresses all of these concerns: 1) it isn't possible to spoof 2) It expresses the security state plainly without expecting people to decode icons or jargon like "https" 3) It reverts to the current format when the address bar has focus so that documentation written assuming a particular UI still makes some sense, and the way that copy and paste work isn't mysterious
Please do not omit "https://"! There are many banks that educate their customers that the URL of the genuine site starts with "https://". I also think omitting "http://" is a bad idea too. I like the IE's design: do not omit any part of the URL, and highlight "https" if the page is fully encrypted (without mixed content). Also I really hope all major browsers can have same UI of the address bar, which can make educating users much easier.
Sites recommending to look at "https://" are giving the wrong advice and ought to be fixed. That advice is already wrong for a number of clients (and could not be followed anyway for small screens).
Whiteboard: [fxprivacy]
Whiteboard: [fxprivacy] → [fxprivacy] [triage]
We talked about it today in our meeting, but we couldn't reach consensus and our UX person is on leave at the moment. We will keep tracking this bug, but we need to schedule a Vidyo meeting around April or in person in London to move forward with this in any direction.
Whiteboard: [fxprivacy] [triage] → [fxprivacy]
Note that we currently omit "http://" from the url bar (unless you go to about:config and flip the browser.urlbar.trimURLs pref). Safari's UI is considerably different than ours. They only have the domain name in the url bar. If you click on the url bar, you will see the full url. The url will include the scheme if it is https, and omit the scheme if it is http. Chrome also shows the scheme if it is https but omits it if it is http. Some users may be trained to look for the lock, some are trained to look for https, and some are trained to look for both. The visual effect of removing the https seems minimal, so I am in favor of keeping it in for those users who look for it. We have a bug open to make the https text green (https://bugzilla.mozilla.org/show_bug.cgi?id=1184925), so perhaps we can do that to unify its appearance with the site identity icons. 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. But we are a long way from here. So for now, I think we are better off leaving https:// in the url bar than removing it. Note that if we did omit "https://", the UI for the following two cases would look identical in Firefox Nightly and DevEdition: * http://people.mozilla.org/~tvyas/password/password_test2.html * https://people.mozilla.org/~tvyas/mixedcontent.html with disabled protection In both cases, the user would see no scheme in the url bar and a grey lock with a red strikethrough.
For the record, Edge will omit both https:// and http://.
(In reply to Tanvi Vyas [:tanvi] from comment #9) > Note that if we did omit "https://", the UI for the following two cases > would look identical in Firefox Nightly and DevEdition: > * http://people.mozilla.org/~tvyas/password/password_test2.html > * https://people.mozilla.org/~tvyas/mixedcontent.html with disabled > protection > In both cases, the user would see no scheme in the url bar and a grey lock > with a red strikethrough. Why does that have to be the case? The URL bar could keep showing the green lock with the grey warning even if we stripped the scheme.
(In reply to Tanvi Vyas [:tanvi] from comment #9) > People don't notice the absence of security indicators. For example, Brave is leaning towards not showing extra UI for EV certs: https://twitter.com/bcrypt/status/694648403326664705
(In reply to Panos Astithas [:past] from comment #11) > (In reply to Tanvi Vyas [:tanvi] from comment #9) > > Note that if we did omit "https://", the UI for the following two cases > > would look identical in Firefox Nightly and DevEdition: > > * http://people.mozilla.org/~tvyas/password/password_test2.html > > * https://people.mozilla.org/~tvyas/mixedcontent.html with disabled > > protection > > In both cases, the user would see no scheme in the url bar and a grey lock > > with a red strikethrough. > > Why does that have to be the case? The URL bar could keep showing the green > lock with the grey warning even if we stripped the scheme. When the user disables mixed active content protection, the url bar will show a grey lock wiht a red strikethrough. So in both cases we show a grey lock with a red strikethrough. There is no green lock, or green lock with a grey warning triangle. If we don't have a scheme, then both would look like: [image of grey lock with red strikethrough] people.mozilla.org/~tvyas/password/password_test2.html [image of grey lock with red strikethrough] people.mozilla.org/~tvyas/mixedcontent.html
Why is it a problem that they would look identical? They have identical security according to us, otherwise we'd have used a different indicator. That "https" is still there in one scenario might in fact give users the wrong idea. Precisely those users that would only look for "https" are being protected by this, by steering them towards relying on the lock instead. I think in fact that we should go much further and only show the domain, as trust can be determined by the lock icon and the domain. Everything else is a distraction. And hopefully in the future just by the domain, if we manage to get rid of HTTP. But removing "https://" seems like a good first step.
Here's an example of Tesco having an insecure page, and saying it's OK, despite browser warnings saying otherwise, because "https://" is visible in the address bar: https://twitter.com/Tesco/status/703113077483438080
(In reply to porneL from comment #15) > Here's an example of Tesco having an insecure page, and saying it's OK, > despite browser warnings saying otherwise, because "https://" is visible in > the address bar: > > https://twitter.com/Tesco/status/703113077483438080 This may help a little with that specific problem (which is separate from what this bug is about): https://bugzilla.mozilla.org/show_bug.cgi?id=1201437 Starting in Firefox 47, we will degrade the security UI for https connections that required a certificate override. It will be a lock with a warning triangle. Note that we decided to go with the lock with the warning triangle instead of the crossed out lock + crossed out https because we felt the crossed out lock was a bit harsh for web developers creating their sites with self signed certs. Chrome uses the crossed out lock + crossed out https. The reason this is separate from this bug is because this bug is about omitting https when the site is fully secure.
(In reply to Anne (:annevk) from comment #14) > Why is it a problem that they would look identical? They have identical > security according to us, otherwise we'd have used a different indicator. They aren't identical security. But trying to create a unique indicator for each unique security issue would result in too many icons. That is too confusing for users. I too would get confused. (ex issues: weak crypto, mixed display content loaded, overriden ssl certificate warning, mixed active content loaded, mixed active content attempting to load, password field on http page). > That "https" is still there in one scenario might in fact give users the > wrong idea. The "https" that is present in the scenario where mixed active content is loaded on the page is an "https" with a strikethrough. > Precisely those users that would only look for "https" are being > protected by this, by steering them towards relying on the lock instead. > > I think in fact that we should go much further and only show the domain, as > trust can be determined by the lock icon and the domain. Everything else is > a distraction. And hopefully in the future just by the domain, if we manage > to get rid of HTTP. But removing "https://" seems like a good first step. Safari's location bar UI is quite different from ours. The lock + domain is shown in the location bar; clicking on the location bar shows the full URL including "https" if the domain is secure ("http" is omitted if the domain is not secure). If the UX team thinks we should move to the lock + domain only in the location bar, and require a click to see the full url with path, then we can discuss that redesign. But as far as I know, such proposals aren't in place. Before removing "https", we need user research that tells us that users don't look for the "https". That they just look for the lock by itself.
Whiteboard: [fxprivacy] → [fxprivacy] [triage]
This is related to discussions in: https://bugzilla.mozilla.org/show_bug.cgi?id=1335970 and also might be part of the changes of the https://bugzilla.mozilla.org/show_bug.cgi?id=https-everything also.
Whiteboard: [fxprivacy] [triage] → [fxprivacy]
Chrome is showing some movement here (again): https://bugs.chromium.org/p/chromium/issues/detail?id=797354. (FWIW, I strongly suspect most users end up ignoring the address bar as there's just too much to read there. Apart from EV (which I wish we could just drop altogether), Safari's UX seems much better at conveying the authority of the site to users.)
Note that there's been a lot of helpful input (and a WIP patch!) in bug 1379247, I just duped it because this one is older and also had quite some activity.
So, IMHO, if we want to do this, it goes hand in hand with flipping the pref from bug 1310447 to true by default (which means showing degraded UI for all HTTP sites). Why? I don't think "flipping" the scheme indicators, i.e. showing http and not showing https is a wise course of action. We should just hide both. Showing "http://" will not say "insecure" to a majority of users, and in the worst case they might even mistake it for "https://" without additional security signals (such as the broken lock). This means we'd effectively declare any HTTP site (even just static text) as insecure. That could be fine, who knows.
Blocks: https-everything
Type: defect → task
Type: task → enhancement

This could be implemented for the new dom.security.https_only_mode (bug 1613063) and for a browser.urlbar.default-to-https pref.

Depends on: https-only-mode

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #24)

This could be implemented for the new dom.security.https_only_mode (bug 1613063) and for a browser.urlbar.default-to-https pref.

This bug is about hiding https://. When I read browser.urlbar.default-to-https, I thought that it referred to autocompleting to https by default. I didn't find the pref in mozilla-central nor in Bugzilla, so I filed a new bug with that idea at bug 1628831 .

If this feature were to be implemented, I think that the feature would be more easily discoverable if it were to be called browser.urlbar.trimURLs.https (false = current behavior, true = omit https as requested in this bug).

Depends on: 1628831

browser.urlbar.trimURLs should hide https instead of http if browser.urlbar.default-to-https is true.
dom.security.https_only_mode could imply browser.urlbar.default-to-https.

browser.urlbar.default-to-https doesn't exist anymore, and the URL trimming feature is hard coded to remove a single string, http://

Oh, to be clear though, simply changing the trimURL method to remove both protocols should cause some problems. I think it needs a more careful look. I tested it like 7 or 8 months ago so maybe that's not the case anymore. But at that time it had some side effects with respect to urlbar copy behavior. I think maybe it also affects uriFixup service

(In reply to aminomancer from comment #31)

browser.urlbar.default-to-https doesn't exist anymore, and the URL trimming feature is hard coded to remove a single string, http://

It never existed. I suggested it.
https:// should be hidden instead of http.
http:// should be visible and possibly red.
security.insecure_connection_text.enabled should be set to true.

Oh, I thought you were trying to give advice. Yes I agree 100% with all of that. The idea of hiding the rare dangerous protocol while showing the ubiquitous safe protocol is perfectly backwards. I don't need to know the page is https, I just need to know when it's not https, especially given that like 99.99% of the pages the average user visits are gonna have valid certs nowadays.

:adw, I'm happy to take this on if we think this is the right strategy. Personally, I feel like this makes sense especially now that other browsers are essentially doing the exact same thing. It's probably less controversial now than eight years ago, especially given the adoption of https.

It seems pretty actionable:

  • Turn on the "Not Secure" text in the URL bar on http:// sites by default
  • Trim https://, don't trim http://

It has the potential of making the URL bar a tad cleaner for the vast majority of use cases.

I was thinking we could go further and omit www. from the value of the urlbar input for https:// addresses, as we'll still have the ability to recover the full real URL via focusing on the urlbar.

Flags: needinfo?(adw)

A major highly visible change like this needs to go through Product review. This isn't something we as engineers can decide to implement by ourselves. Marco wrote an engineering proposal for it, but it didn't make the 2022H2 plan. So if you'd like to push this forward, the next step would be to bring it up at a team meeting or raise it separately with Chris.

Flags: needinfo?(adw)
Attachment #9286120 - Attachment is obsolete: true
Severity: normal → S3

Any updates on this?

Attached file Bug 1067293 - Omit "https://".r=dao (deleted) —
Assignee: nobody → mseibert
Status: NEW → ASSIGNED

Backed out for causing bc failures in browser_preferences_usage.js

  • Backout link
  • Push with failures
  • Failure Log
  • Failure line: TEST-UNEXPECTED-FAIL | browser/base/content/test/performance/browser_preferences_usage.js | browser.urlbar.trimHttps should not be accessed more than 32 times. - 100 <= 32 - {"filename":"chrome://mochitests/content/browser/browser/base/content/test/performance/browser_preferences_usage.js","name":"checkPrefGetters","sourceId":598,"lineNumber":42,"columnNumber":14,"sourceLine":"","asyncCause":null,"asyncCaller":null,"caller":{"filename":"chrome:
Flags: needinfo?(mseibert)

https://hg.mozilla.org/mozilla-central/rev/6aa8174d4b57

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
status-firefox118: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 118 Branch

:mseibert could you please consider nominating this for a relnote? https://wiki.mozilla.org/Release_Management/Release_Notes_Nomination

(In reply to Donal Meehan [:dmeehan] from comment #44)

:mseibert could you please consider nominating this for a relnote? https://wiki.mozilla.org/Release_Management/Release_Notes_Nomination

This is still disabled by default, we'll target 119 at the earliest for shipping this. In any case, let's work on the relnote when we enable this in nightly.

status-firefox118: fixed → disabled
Flags: needinfo?(mseibert)
Summary: Omit "https://" → Omit "https://" (pref'd off by default)
Regressions: 1848715
Blocks: 1850491
Type: enhancement → task
status-firefox118: disabled → fixed
No longer depends on: https-only-mode
See Also: https://bugzilla.mozilla.org/show_bug.cgi?id=1060546, https://bugzilla.mozilla.org/show_bug.cgi?id=1462556 → https://bugzilla.mozilla.org/show_bug.cgi?id=1658924, https://bugzilla.mozilla.org/show_bug.cgi?id=1562881
Summary: Omit "https://" (pref'd off by default) → Add pref to omit "https://" from address bar (pref'd off by default)
No longer depends on: 1628831
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: