Evaluate what we do with extensions interfering with HTTPS Upgrade Telemetry
Categories
(Core :: DOM: Security, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox130 | --- | fixed |
People
(Reporter: ckerschb, Assigned: ckerschb)
References
Details
(Whiteboard: [domsecurity-active])
Attachments
(1 file)
We have a mismatch with our HTTPS Upgrade Telemetry (which we added within Bug 1883954) when web extensions upgrade the request. In particular running test_ext_webrequest_upgrade.html highlights the problem. The load starts as http but gets upgraded by the webextension and not through any of our upgrading mechanisms.
| Assignee | ||
Comment 1•1 year ago
|
||
We have several options:
a) We do nothing and ignore this sideffect
b) We could extend our enum by WEB_EXTENSION_UPGRADE and set it on the loadinfo within HttpBaseChannel::UpgradeToSecure()
c) When recording the telemetry we exempt loads that were modified by web-extensions.
I am personally for (c), though I don't know how to figure that out. The triggeringPrincipal is still the original page that triggered the load. If there is any other bit that we could observe that an extension interfered/modified the load, then I think it would be great to query that and ignore such loads for our telemetry.
Kershaw, Freddy, what are your thoughts?
Comment 2•1 year ago
|
||
I'm leaning towards b) for two reasons:
- We know what to do and where.
- We can filter or single these situations out selectively.
| Assignee | ||
Updated•1 year ago
|
Comment 3•1 year ago
|
||
I also prefer option b.
Note that UpgradeToSecure() is currently used only by web extensions, but it may be used by others in the future. While using WEB_EXTENSION_UPGRADE in HttpBaseChannel::UpgradeToSecure is acceptable for now, it’s important to consider making it future-proof.
| Assignee | ||
Comment 4•1 year ago
|
||
Comment 6•1 year ago
|
||
| bugherder | ||
Description
•