1858894 - HTTPS-First/Only: HTTP entries are added to Global History when upgrading schemeless strings typed in Address Bar

Status: RESOLVED FIXED

(Toolkit :: Places, defect, P3)

Description

[Marco Bonardo [:mak]]

When we upgrade a schemeless typed url, we still add the http version to global history, then the https versions.
I suspect that visit addition to Global History happens quite before we try to upgrade the protocol, and the resolution to the upgrade happens even later (in case we fail to upgrade).

STR:

• set dom.security.https_first_schemeless
• type "amazon.de" in the urlbar and confirm

There's a few problems with that:

1. User expectation is likely to NOT find the http url in history. Finding it will make them think we didn't effectively upgrade. The privacy perception is then lost.
2. the http version, because it's typed, will generate a large frecency (we have plans to change frecency, but it's not ready for release yet). That means many things like autofill or UrlbarProviderHistoryUrlHeuristic.sys.mjs will prefer http when building a result (we use the most frecent protocol), We will upgrade those results later, but still showing http in the panel may break user perception of safety.

We could replace the default fixup protocol when schemeless upgrade is enabled, but then local addresses would be treated as https first too. Should we detect local addresses earlier? Or should we just downgrade https schemeless if https fails?

Comment 1

[Malte Jürgens [:maltejur]]

This seems to affect HTTPS-First and HTTPS-Only in general as well, I could reproduce the same issue with both. Navigations which are upgraded also seem to suffer from the same issue. For example with HTTPS-Only or HTTPS-First enabled (these aren't real urls):

1. Visit https://one.example.com
2. Click on link to http://two.example.com (while two.example.com supports HTTPS)
3. Land on https://two.example.com as the site gets upgraded

In this case we would add both http://two.example.com and https://two.example.com to the history.

Comment 2

[Masatoshi Kimura [:emk]]

If we do not add http versions to global history, when we click a http link, the link color will not turn to the visited color. It will also affect extensions such as Link Status Redux. I do not want such behavior change. Can we add the http version as a hidden entry?

Comment 3

[Marco Bonardo [:mak]]

(In reply to Malte Jürgens [:mjurgens] from comment #1)

This seems to affect HTTPS-First and HTTPS-Only in general as well, I could reproduce the same issue with both. Navigations which are upgraded also seem to suffer from the same issue.

True, but I think from a privacy/security perception point of view there's a difference between clicking on a link and seeing in history it was http, VS typing a schemeless origin in the address bar and find Firefox has apparently tried the http version.
As a user I would think Firefox is visiting http first, and then the page redirected.

(In reply to Masatoshi Kimura [:emk] from comment #2)

If we do not add http versions to global history, when we click a http link, the link color will not turn to the visited color.

That should indeed not change. Most upgrades are fine as-is, because the user has actually clicked on an http link, it's ok to show that in history (I'd be ok with hiding these visits visually, if we'd have the info at hand).
The perception problem here is specific to the address bar use-case.

The frecency problem should be solved absolutely, a simple workaround could be to not mark as "typed" these schemeless visits, so the http version doesn't generate a large score... it's not a perfect solution though because any "upgraded" visit should ideally always generate a low score, but that requires the Docshell to pass AddURIVisit some flag that tells "this has been upgraded", and afaik we know only later if the upgrade was successful. We need a timeline of the upgrade and the docshell calls to visit addition to tell what can be done.

The perception problem is maybe not super critical, but I think it's worth checking how we can make it less confusing.

Comment 4

[Malte Jürgens [:maltejur]]

Attachment: Bug 1858894 - Hide http history entries that were upgraded to https r?freddyb,#places-reviewers

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/278f6c572c8f
Hide http history entries that were upgraded to https r=places-reviewers,freddyb,mak

Comment 6

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/278f6c572c8f