Closed Bug 1683131 Opened 10 months ago Closed 7 months ago

Have telemetry probes to measure how much cost would it take to sniff a no-cors and cross-origin response

Categories

(Core :: DOM: Networking, task, P2)

task

Tracking

()

RESOLVED FIXED
89 Branch
Tracking Status
firefox89 --- fixed

People

(Reporter: tt, Assigned: edenchuang)

References

Details

(Whiteboard: [necko-triaged])

Attachments

(4 files)

  • Would be good to know the number of response that has a mismatched MIME type results with its sniffed results.
  • Would be good to know how much time would it take for sniffing for responses that weren't needed to be sniffed. (Also check the worst cases time)
Severity: -- → N/A
Priority: -- → P2
Whiteboard: [necko-triaged]

I think for useful results here we should implement https://github.com/annevk/orb except for step 14 (parsing JSON/JavaScript) and then add telemetry for step 14 in particular. Perhaps it's useful to compare how often we invoke the algorithm versus how often we hit that step? And when we hit that step we might want to report how big responses are to get an idea about performance impact? (The cost of sniffing for media should be marginal as it's only a couple bytes, I don't think we need to measure that.)

Had a meeting with Anne and we think that, in this bug, we actually want to know:

  • How much percentage of requests is blocked, is allowed, or needs to be parsed per source (e.g. media, video, ..etc)?
  • How much time does it take? (performance)
Assignee: nobody → ttung
Attachment #9199220 - Attachment description: Bug 1683131 - Telemetry; → Bug 1683131 - Add telemetry probes to reocrd time and result for checking a opauqe response is allowed or not;
Status: NEW → ASSIGNED
Attachment #9199220 - Attachment description: Bug 1683131 - Add telemetry probes to reocrd time and result for checking a opauqe response is allowed or not; → Bug 1683131 - Add telemetry probes to record time and result for checking a opaque response is allowed or not;
Attached file request-bug1683131.md
Attachment #9204850 - Flags: data-review?(chutten)

Comment on attachment 9204850 [details]
request-bug1683131.md

DATA COLLECTION REVIEW RESPONSE:

Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes.

Is there a control mechanism that allows the user to turn the data collection on and off?

Yes. This collection is Telemetry so can be controlled through Firefox's Preferences.

If the request is for permanent data collection, is there someone who will monitor the data over time?

No. This collection will expire in Firefox 93.

Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 1, Technical.

Is the data collection request for default-on or default-off?

Default on for all channels. (The request says nightly-only, which may be true for the feature, but OPAQUE_RESPONSE_BLOCKING is configured to be collectable in all channels)

Does the instrumentation include the addition of any new identifiers?

No.

Is the data collection covered by the existing Firefox privacy notice?

Yes.

Does there need to be a check-in in the future to determine whether to renew the data?

Yes. :tt is responsible for renewing or removing the collection before it expires in Firefox 93.


Result: datareview+

Attachment #9204850 - Flags: data-review?(chutten) → data-review+
Blocks: 1696111
No longer blocks: 1532642

Handover this to Eden.

Assignee: shes050117 → echuang
Attachment #9201987 - Attachment description: Bug 1683131 - Add a test for telemetry; → Bug 1683131 - Add a test for telemetry
Pushed by echuang@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2c7a45e20b50
Add telemetry probes to record time and result for checking a opaque response is allowed or not; r=necko-reviewers,annevk,dragana
https://hg.mozilla.org/integration/autoland/rev/276f016ddc67
Add a test for telemetry r=necko-reviewers,dragana
https://hg.mozilla.org/integration/autoland/rev/8ffef57e27d2
Fix namespace ambiguity issue on ipc::Endpoint after including nsHttpChannel in imgLoader; r=necko-reviewers,kershaw
Backout by abutkovits@mozilla.com:
https://hg.mozilla.org/mozilla-central/rev/eb3c49d8feaf
Backed out 12 changesets (bug 1683131, bug 1696111, bug 1695987) for causing crashes(Bug 1701151). a=backout
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: 89 Branch → ---
Attachment #9201987 - Attachment description: Bug 1683131 - Add a test for telemetry → WIP: Bug 1683131 - Add a test for telemetry
Attachment #9201987 - Attachment description: WIP: Bug 1683131 - Add a test for telemetry → Bug 1683131 - Add a test for telemetry
Pushed by echuang@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1b84c1b571ad
Add telemetry probes to record time and result for checking a opaque response is allowed or not; r=necko-reviewers,annevk,dragana
https://hg.mozilla.org/integration/autoland/rev/a10781b36673
Add a test for telemetry r=necko-reviewers,dragana
https://hg.mozilla.org/integration/autoland/rev/84a8d70fe0be
Fix namespace ambiguity issue on ipc::Endpoint after including nsHttpChannel in imgLoader; r=necko-reviewers,kershaw
Status: REOPENED → RESOLVED
Closed: 7 months ago7 months ago
Resolution: --- → FIXED
Target Milestone: --- → 89 Branch
See Also: → 1720613
You need to log in before you can comment on or make changes to this bug.