658707 - If I type an address without a protocol, assume I want https if I usually visit with https

Status: RESOLVED WONTFIX

(Firefox :: Address Bar, enhancement)

Description

[Jesse Ruderman]

Steps to reproduce:
1. Launch Firefox with a profile that has visited https://www.bankofamerica.com/ in the past.
2. Type www.bankofamerica.com.
3. Press Enter.

Result: Firefox guesses that I want http.

Expected: Firefox should guess that I want https.

You can think of this idea as HSTS-lite. It doesn't prevent me from visiting with http, so it's safe to infer. I want Firefox to guess the faster and more secure option when I don't specify a protocol.

Trickier cases:
* Typing 'bankofamerica.com', without the 'www'.
* Sites that are frequently visited both with and without https.

Comment 1

[Sid Stamm [:geekboy or :sstamm]]

Related: UI for HSTS is bug 572803.

I like the idea of HSTS-lite.  It's HNSSTS (HTTP-Not-So-Strict-Transport-Security).

Perhaps we could implement a first phase of this by catching redirects from HTTP->HTTPS and marking that host name as "Default to HTTPS"?

Comment 2

[Alex Faaborg [:faaborg] (Firefox UX)]

>HSTS-lite

If we base this on adaptive learning over time I think the normal naming convention would be awesome-HSTS :)  This is a really fantastic idea.

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

We talked about this with bsterne just a few days ago.

Experiment:
https://www.amazon.com -> http://www.amazon.com
http://amazon.com -> http://www.amazon.com
https://amazon.com -> SSL error page: ssl_error_bad_cert_domain, because the cert is for https://www.amazon.com

I believe there are many sites where https://<site>/<path> is an error page and/or different content than same http://<site>/<path> works fine.

Accordingly, I think that we will still need an explicit indication for web sites to say that we can/should rewrite http:// links to https://. bsterne, dveditz, and I were talking about doing this as a way of bootstrapping mixed stronger content warnings. YouTube, for example, could explicitly tell us to rewrite http://youtube.com links to https://youtube.com links in the addressbar and/or only when the YouTube-hosted resource would result in a mixed content warning. We have not fully explored the idea though.

See http://tools.ietf.org/html/draft-hoffman-server-has-tls-04
and http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2#TOC-Server-Advertisement-of-SPDY-throug

Comment 4

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

See also bug 635803, about improving the "https://<domain> uses cert for https://www.<domain>" experience.

Comment 5

[Jesse Ruderman]

Brian, you'd only get this if you've successfully visited the https site before, so bug 635803 is not closely related.

Comment 6

[Johnathan Nightingale [:johnath]]

I like this idea if we can do it in ways that sidestep comment 3, but I wonder what proportion of our users are getting this for free through the awesomebar. I suspect many users don't type "www.bankofamerica.com<enter>" they type "www.banko<down><enter>" which should select the https entry, if that's the thing they typically connect with (the assumption in comment 0).

Again, no problem with this idea, just wish I knew what proportion of users we already help, albeit accidentally.

Comment 7

[Jesse Ruderman]

> I wonder what proportion of our users are getting this for free through the 
> awesomebar

Probably fewer once we ship inline autocomplete! (Bug 566489)

Comment 8

[Jesse Ruderman]

Bug 720081 has been filed for fixing this for inline autocomplete.

Comment 9

[Lukas Blakk [:lsblakk] use ?needinfo]

fwiw I requested this in bug 577788

Comment 10

[Marco Bonardo [:mak]]

currently inline always tries to suggest https, if any page in a certain root is secure.
Unfortunately, as you can imagine, some domains have secure pages but an unsecure root, though we don't have this information.
I have filed bug 840027 to try figuring out a way to ask the user intentions when this happens, though if you have any insight that would be useful.

Comment 11

[Mike Conley (:mconley) (:⚙️)]

Not sure why this was given the perf keyword, as this sounds like a cool security feature and not performance related.

Comment 12

[Jesse Ruderman]

I gave it the perf keyword because it saves a redirect in the most common case (site redirects to https but does not use STS).

Comment 13

[:Gavin Sharp [email: [e-mail]]]

Auto-fill (inline autocomplete) now covers most of the cases (including the STR from comment 0) - it favors https: if there are such visits. When auto-fill is disabled, doing an extra round-trip to the places database may actually take longer than just going through the redirect, and would be complicated to implement, so I think this is otherwise WONTFIX.