mozilla
/
gecko-dev
зеркало из https://github.com/mozilla/gecko-dev.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
gecko-dev/dom/security/metrics.yaml

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

153 строки
4.9 KiB
YAML
Исходник Обычный вид История

Bug 1868380 - Add glean telemetry for HTTPS-First r=freddyb,simonf - Add new glean metrics.yaml for dom/security - Add 8 new metrics for (schemeless) HTTPS-First, see metrics.yaml for explanation - Add getter for timing on document load listener - Provide `nsHTTPSOnlyUtils::PotentiallyDowngradeHttpsFirstRequest` with complete document load listener so that it is able to access the timing - Adapt browser_httpsfirst.js and browser_schemeless.js tests to also check for correct telemetry values Differential Revision: https://phabricator.services.mozilla.com/D196072
2024-03-06 20:19:35 +03:00
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
# Adding a new metric? We have docs for that!
# https://firefox-source-docs.mozilla.org/toolkit/components/glean/user/new_definitions_file.html
---
$schema: moz://mozilla.org/schemas/glean/metrics/2-0-0
$tags:
- 'Core :: DOM: Security'
httpsfirst:
upgraded:
type: counter
description: >
Bug 1885893 - Only collect HTTPS-First telemetry on successful request r=freddyb This patch addresses the problem that we currently collect HTTPS-First telemetry for sites that are not reachable at all, be it through always causing a error or through always timing out. - On a downgrade, do not collect telemetry instantly, but instead save the telemetry data in the load state for the downgraded request - That telemetry data will then be copied over into the document load listener of the new request - On a successful request, if we have downgrade data in the load listener, we collect the downgrade telemetry, as the downgrade seems to have been successful - Similar to the downgrade case, we only count the upgrade metric once we encounter a successful request annotated with the information that it was upgraded by HTTPS-First, instead of counting it instantly on the decision to upgrade. This also means the upgrade metric will not include loads that are downgraded again anymore - Add a testcase for a site which is neither reachable via HTTP nor HTTPS, and ensure no telemetry is collected Differential Revision: https://phabricator.services.mozilla.com/D210792
2024-05-27 17:20:11 +03:00
Counts how often a load is successfully upgraded to HTTPS because of
HTTPS-First (`dom.security.https_first` enabled). This does not include
loads that get downgraded again.
Bug 1868380 - Add glean telemetry for HTTPS-First r=freddyb,simonf - Add new glean metrics.yaml for dom/security - Add 8 new metrics for (schemeless) HTTPS-First, see metrics.yaml for explanation - Add getter for timing on document load listener - Provide `nsHTTPSOnlyUtils::PotentiallyDowngradeHttpsFirstRequest` with complete document load listener so that it is able to access the timing - Adapt browser_httpsfirst.js and browser_schemeless.js tests to also check for correct telemetry values Differential Revision: https://phabricator.services.mozilla.com/D196072
2024-03-06 20:19:35 +03:00
bugs:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1868380
data_reviews:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1868380#c10
data_sensitivity:
- technical
notification_emails:
- mjurgens@mozilla.com
- seceng-telemetry@mozilla.com
expires: never
upgraded_schemeless:
type: counter
description: >
Bug 1885893 - Only collect HTTPS-First telemetry on successful request r=freddyb This patch addresses the problem that we currently collect HTTPS-First telemetry for sites that are not reachable at all, be it through always causing a error or through always timing out. - On a downgrade, do not collect telemetry instantly, but instead save the telemetry data in the load state for the downgraded request - That telemetry data will then be copied over into the document load listener of the new request - On a successful request, if we have downgrade data in the load listener, we collect the downgrade telemetry, as the downgrade seems to have been successful - Similar to the downgrade case, we only count the upgrade metric once we encounter a successful request annotated with the information that it was upgraded by HTTPS-First, instead of counting it instantly on the decision to upgrade. This also means the upgrade metric will not include loads that are downgraded again anymore - Add a testcase for a site which is neither reachable via HTTP nor HTTPS, and ensure no telemetry is collected Differential Revision: https://phabricator.services.mozilla.com/D210792
2024-05-27 17:20:11 +03:00
Counts how often a load is successfully upgraded to HTTPS because of
Bug 1868380 - Add glean telemetry for HTTPS-First r=freddyb,simonf - Add new glean metrics.yaml for dom/security - Add 8 new metrics for (schemeless) HTTPS-First, see metrics.yaml for explanation - Add getter for timing on document load listener - Provide `nsHTTPSOnlyUtils::PotentiallyDowngradeHttpsFirstRequest` with complete document load listener so that it is able to access the timing - Adapt browser_httpsfirst.js and browser_schemeless.js tests to also check for correct telemetry values Differential Revision: https://phabricator.services.mozilla.com/D196072
2024-03-06 20:19:35 +03:00
schemeless HTTPS-First (`dom.security.https_first` disabled, but load
Bug 1885893 - Only collect HTTPS-First telemetry on successful request r=freddyb This patch addresses the problem that we currently collect HTTPS-First telemetry for sites that are not reachable at all, be it through always causing a error or through always timing out. - On a downgrade, do not collect telemetry instantly, but instead save the telemetry data in the load state for the downgraded request - That telemetry data will then be copied over into the document load listener of the new request - On a successful request, if we have downgrade data in the load listener, we collect the downgrade telemetry, as the downgrade seems to have been successful - Similar to the downgrade case, we only count the upgrade metric once we encounter a successful request annotated with the information that it was upgraded by HTTPS-First, instead of counting it instantly on the decision to upgrade. This also means the upgrade metric will not include loads that are downgraded again anymore - Add a testcase for a site which is neither reachable via HTTP nor HTTPS, and ensure no telemetry is collected Differential Revision: https://phabricator.services.mozilla.com/D210792
2024-05-27 17:20:11 +03:00
marked as schemeless). This does not include loads that get downgraded
again.
Bug 1868380 - Add glean telemetry for HTTPS-First r=freddyb,simonf - Add new glean metrics.yaml for dom/security - Add 8 new metrics for (schemeless) HTTPS-First, see metrics.yaml for explanation - Add getter for timing on document load listener - Provide `nsHTTPSOnlyUtils::PotentiallyDowngradeHttpsFirstRequest` with complete document load listener so that it is able to access the timing - Adapt browser_httpsfirst.js and browser_schemeless.js tests to also check for correct telemetry values Differential Revision: https://phabricator.services.mozilla.com/D196072
2024-03-06 20:19:35 +03:00
bugs:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1868380
data_reviews:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1868380#c10
data_sensitivity:
- technical
notification_emails:
- mjurgens@mozilla.com
- seceng-telemetry@mozilla.com
expires: never
downgraded:
type: counter
description: >
How many regular HTTPS-First (`dom.security.https_first` enabled)
Bug 1885893 - Only collect HTTPS-First telemetry on successful request r=freddyb This patch addresses the problem that we currently collect HTTPS-First telemetry for sites that are not reachable at all, be it through always causing a error or through always timing out. - On a downgrade, do not collect telemetry instantly, but instead save the telemetry data in the load state for the downgraded request - That telemetry data will then be copied over into the document load listener of the new request - On a successful request, if we have downgrade data in the load listener, we collect the downgrade telemetry, as the downgrade seems to have been successful - Similar to the downgrade case, we only count the upgrade metric once we encounter a successful request annotated with the information that it was upgraded by HTTPS-First, instead of counting it instantly on the decision to upgrade. This also means the upgrade metric will not include loads that are downgraded again anymore - Add a testcase for a site which is neither reachable via HTTP nor HTTPS, and ensure no telemetry is collected Differential Revision: https://phabricator.services.mozilla.com/D210792
2024-05-27 17:20:11 +03:00
upgrades fail and get downgraded again.
Bug 1868380 - Add glean telemetry for HTTPS-First r=freddyb,simonf - Add new glean metrics.yaml for dom/security - Add 8 new metrics for (schemeless) HTTPS-First, see metrics.yaml for explanation - Add getter for timing on document load listener - Provide `nsHTTPSOnlyUtils::PotentiallyDowngradeHttpsFirstRequest` with complete document load listener so that it is able to access the timing - Adapt browser_httpsfirst.js and browser_schemeless.js tests to also check for correct telemetry values Differential Revision: https://phabricator.services.mozilla.com/D196072
2024-03-06 20:19:35 +03:00
bugs:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1868380
data_reviews:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1868380#c10
data_sensitivity:
- technical
notification_emails:
- mjurgens@mozilla.com
- seceng-telemetry@mozilla.com
expires: never
downgraded_schemeless:
type: counter
description: >
How many schemeless HTTPS-First (`dom.security.https_first` disabled, but
Bug 1885893 - Only collect HTTPS-First telemetry on successful request r=freddyb This patch addresses the problem that we currently collect HTTPS-First telemetry for sites that are not reachable at all, be it through always causing a error or through always timing out. - On a downgrade, do not collect telemetry instantly, but instead save the telemetry data in the load state for the downgraded request - That telemetry data will then be copied over into the document load listener of the new request - On a successful request, if we have downgrade data in the load listener, we collect the downgrade telemetry, as the downgrade seems to have been successful - Similar to the downgrade case, we only count the upgrade metric once we encounter a successful request annotated with the information that it was upgraded by HTTPS-First, instead of counting it instantly on the decision to upgrade. This also means the upgrade metric will not include loads that are downgraded again anymore - Add a testcase for a site which is neither reachable via HTTP nor HTTPS, and ensure no telemetry is collected Differential Revision: https://phabricator.services.mozilla.com/D210792
2024-05-27 17:20:11 +03:00
load marked as schemeless) upgrades fail and get downgraded again.
Bug 1868380 - Add glean telemetry for HTTPS-First r=freddyb,simonf - Add new glean metrics.yaml for dom/security - Add 8 new metrics for (schemeless) HTTPS-First, see metrics.yaml for explanation - Add getter for timing on document load listener - Provide `nsHTTPSOnlyUtils::PotentiallyDowngradeHttpsFirstRequest` with complete document load listener so that it is able to access the timing - Adapt browser_httpsfirst.js and browser_schemeless.js tests to also check for correct telemetry values Differential Revision: https://phabricator.services.mozilla.com/D196072
2024-03-06 20:19:35 +03:00
bugs:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1868380
data_reviews:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1868380#c10
data_sensitivity:
- technical
notification_emails:
- mjurgens@mozilla.com
- seceng-telemetry@mozilla.com
expires: never
downgraded_on_timer:
type: rate
description: >
How many HTTPS-First (`dom.security.https_first` enabled) upgrades get
downgraded again because the HTTP request fired after 3s received a answer
faster than the HTTPS request.
denominator_metric: httpsfirst.downgraded
bugs:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1868380
data_reviews:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1868380#c10
data_sensitivity:
- technical
notification_emails:
- mjurgens@mozilla.com
- seceng-telemetry@mozilla.com
expires: never
downgraded_on_timer_schemeless:
type: rate
description: >
How many of schemeless HTTPS-First (`dom.security.https_first` disabled,
but load marked as schemeless) upgrades get downgraded again because the
HTTP request fired after 3s received a answer faster than the HTTPS
request
denominator_metric: httpsfirst.downgraded_schemeless
bugs:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1868380
data_reviews:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1868380#c10
data_sensitivity:
- technical
notification_emails:
- mjurgens@mozilla.com
- seceng-telemetry@mozilla.com
expires: never
downgrade_time:
type: timing_distribution
description: >
If a HTTPS-First (`dom.security.https_first` enabled) upgrade isn't
successful, measures the timespan between the navigation start and the
Bug 1885893 - Only collect HTTPS-First telemetry on successful request r=freddyb This patch addresses the problem that we currently collect HTTPS-First telemetry for sites that are not reachable at all, be it through always causing a error or through always timing out. - On a downgrade, do not collect telemetry instantly, but instead save the telemetry data in the load state for the downgraded request - That telemetry data will then be copied over into the document load listener of the new request - On a successful request, if we have downgrade data in the load listener, we collect the downgrade telemetry, as the downgrade seems to have been successful - Similar to the downgrade case, we only count the upgrade metric once we encounter a successful request annotated with the information that it was upgraded by HTTPS-First, instead of counting it instantly on the decision to upgrade. This also means the upgrade metric will not include loads that are downgraded again anymore - Add a testcase for a site which is neither reachable via HTTP nor HTTPS, and ensure no telemetry is collected Differential Revision: https://phabricator.services.mozilla.com/D210792
2024-05-27 17:20:11 +03:00
downgrade.
Bug 1868380 - Add glean telemetry for HTTPS-First r=freddyb,simonf - Add new glean metrics.yaml for dom/security - Add 8 new metrics for (schemeless) HTTPS-First, see metrics.yaml for explanation - Add getter for timing on document load listener - Provide `nsHTTPSOnlyUtils::PotentiallyDowngradeHttpsFirstRequest` with complete document load listener so that it is able to access the timing - Adapt browser_httpsfirst.js and browser_schemeless.js tests to also check for correct telemetry values Differential Revision: https://phabricator.services.mozilla.com/D196072
2024-03-06 20:19:35 +03:00
time_unit: millisecond
bugs:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1868380
data_reviews:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1868380#c10
data_sensitivity:
- technical
notification_emails:
- mjurgens@mozilla.com
- seceng-telemetry@mozilla.com
expires: never
downgrade_time_schemeless:
type: timing_distribution
description: >
Bug 1891185 - Collect different downgrade time on timer for HTTPS-First telemetry r=freddyb It does not make sense to collect the "downgrade time" as we currently do it when a upgrade was caused by a faster http request on a timer. We can not compare the navigation start timestamp with the current time, as the replacing http channel has started loading earlier than the current time. So leave out the case where the downgrade happens because of a faster http request on the timer, as we already know that the time overhead there is exactly 3s. Differential Revision: https://phabricator.services.mozilla.com/D207338
2024-04-29 16:52:15 +03:00
If a schemeless HTTPS-First (`dom.security.https_first` disabled, but load
marked as schemeless) upgrade isn't successful, measures the timespan
Bug 1885893 - Only collect HTTPS-First telemetry on successful request r=freddyb This patch addresses the problem that we currently collect HTTPS-First telemetry for sites that are not reachable at all, be it through always causing a error or through always timing out. - On a downgrade, do not collect telemetry instantly, but instead save the telemetry data in the load state for the downgraded request - That telemetry data will then be copied over into the document load listener of the new request - On a successful request, if we have downgrade data in the load listener, we collect the downgrade telemetry, as the downgrade seems to have been successful - Similar to the downgrade case, we only count the upgrade metric once we encounter a successful request annotated with the information that it was upgraded by HTTPS-First, instead of counting it instantly on the decision to upgrade. This also means the upgrade metric will not include loads that are downgraded again anymore - Add a testcase for a site which is neither reachable via HTTP nor HTTPS, and ensure no telemetry is collected Differential Revision: https://phabricator.services.mozilla.com/D210792
2024-05-27 17:20:11 +03:00
between the navigation start and the downgrade.
Bug 1868380 - Add glean telemetry for HTTPS-First r=freddyb,simonf - Add new glean metrics.yaml for dom/security - Add 8 new metrics for (schemeless) HTTPS-First, see metrics.yaml for explanation - Add getter for timing on document load listener - Provide `nsHTTPSOnlyUtils::PotentiallyDowngradeHttpsFirstRequest` with complete document load listener so that it is able to access the timing - Adapt browser_httpsfirst.js and browser_schemeless.js tests to also check for correct telemetry values Differential Revision: https://phabricator.services.mozilla.com/D196072
2024-03-06 20:19:35 +03:00
time_unit: millisecond
bugs:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1868380
data_reviews:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1868380#c10
data_sensitivity:
- technical
notification_emails:
- mjurgens@mozilla.com
- seceng-telemetry@mozilla.com
expires: never