Closed Bug 1618896 Opened 5 years ago Closed 3 years ago

Consider gathering telemetry like HTTP_PAGELOAD_IS_SSL separately only for the address bar

Categories

(Firefox :: Address Bar, task, P4)

task

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jan, Unassigned)

References

Details

(Keywords: nightly-community, privacy)

HTTP_PAGELOAD_IS_SSL captures all first-party page loads. Nightly looks much better than beta.
But for the decision to default to https some day (next year?) I think it would be helpful to have separate telemetry on manually typed in addresses:
e.g.
a) Manually typed in an https:// url (it does not matter if we got redirected to http://)
b) Opened https:// because we remembered a redirect
c) Opened https:// because of HSTS (btw, urlbar results offer http://*.dev/ although the whole TLD is preloaded)
d) Opened http://localhost, 127.*, [::1]
e) Opened http://<other-private-IP> like http://192., http://10., http://[fd00:*]/
f) Opened http://<public-ip>
g) Opened http://domain with success
h) Opened http://domain and got an error
i) Opened http://domain and got redirected to https://domain
j) Opened http://domain and got redirected to https on almost the same domain (http://www. -> https://, http:// -> https://www.)
k) Opened http://domain and got redirected to http on almost the same domain (http://www -> http://, http:// -> http://www.)
l) Opened http://domain and got redirected to https://otherdomain
m) Opened http://domain and got redirected to http://otherdomain

With more precise telemetry it could be evaluated if https:// connection errors on localhost or private IPs should be automatically retried via http:// or if the error page should contain a simple "Try to connect insecurely via http://" button.

This could be extended by a background test (study) to try to connect to https:// on the same domain, e.g. http://sparkasse-hannover.de/ works, but https://sparkasse-hannover.de/ not. It could be evaluated to retry via https://www. (or vice versa) in such cases.

Type: enhancement → task

Doing this in the Address Bar may not be trivial, because some of the measurements involve knowing what happens when the load starts. The Address Bar in the end is just a picker UI, once the user made a pick it passes a string to the docshell, and it's done. The docshell is the one that may know better what it is asked to load and where it ends up.
Thus I suspect this telemetry should be implemented in the docshell based on its definition.

Component: Address Bar → DOM: Navigation
Product: Firefox → Core

The Address Bar in the end is just a picker UI, once the user made a pick it passes a string to the docshell, and it's done. The docshell is the one that may know better what it is asked to load and where it ends up.

DocShell doesn't know whether a load came from the address bar or not. If we want to collect this telemetry, could the address bar code just record the URL schemes for URLs it attempts to load? Moving back to Address Bar component for now.

That said, do we actually need this telemetry to make this product decision? See HTTPS-first bug 1158191 and HTTPS-only mode bug 1613063.

Severity: normal → --
Component: DOM: Navigation → Address Bar
Product: Core → Firefox

(In reply to Chris Peterson [:cpeterson] from comment #2)

DocShell doesn't know whether a load came from the address bar or not. If we want to collect this telemetry, could the address bar code just record the URL schemes for URLs it attempts to load?

Yes, that should be doable.

That said, do we actually need this telemetry to make this product decision? See HTTPS-first bug 1158191 and HTTPS-only mode bug 1613063.

Who makes this decision? It looks like the OP isn't around anymore. I'll give this a low priority pending more info.

Severity: -- → N/A
Priority: -- → P4
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.