Closed Bug 1488865 Opened 6 years ago Closed 5 years ago

import CRLite enrollment state into cert_storage

Categories

(Core :: Security: PSM, enhancement, P1)

enhancement

Tracking

()

RESOLVED FIXED
mozilla69
Tracking Status
firefox69 --- fixed

People

(Reporter: mgoodwin, Assigned: keeler)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [psm-assigned])

Attachments

(3 files)

No description provided.
Depends on: 1429797
Priority: -- → P2
Whiteboard: [psm-blocked]
Assignee: nobody → mgoodwin
Depends on: 1538161
Blocks: 1548030

FYI, this needs data-review since it adds telemetry.

Attached file Data Collection Review.md (deleted) —

Affects this bug and Bug 1545383. Thanks, Chris!

Attachment #9062379 - Flags: data-review?(chutten)
Depends on: 1548808

Filed bug 1548808 for an issue where the data in the intermediates remote settings collection differs from the interface exposed by nsICertStorage

Comment on attachment 9062379 [details] Data Collection Review.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. This collection is Telemetry so is documented in its definitions file [Histograms.json](https://hg.mozilla.org/mozilla-central/file/tip/toolkit/components/telemetry/Histograms.json) and the [Probe Dictionary](https://telemetry.mozilla.org/probe-dictionary/). 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? Yes and No. For the expiring probes (at least CRLITE_UPDATE_TIME_MS and CRLITE_UPDATE_ERRORS so far) they expire in Firefox 75. For non-expiring probes (not sure which will be), :jcj is responsible. 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. (( Even some mild hint of users being behind an Intranet isn't really Interaction data, IMO. )) Is the data collection request for default-on or default-off? Default on for 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? Some of the collection is permanent. But :jcj is responsible for renewing or removing the expiring parts of the collection before it expires in Firefox 75. --- Result: datareview+
Attachment #9062379 - Flags: data-review?(chutten) → data-review+

Thanks, Chris!

This patch saves the CRLite enrollment state of every preloaded intermediate to
cert_storage. This is an intermediate (hah) step towards actually checking
CRLite state. We still have to implement downloading and updating the CRLite
bloom filter cascades and implement checking these filters when we encounter a
certificate issued from an enrolled intermediate (this work will be done in
future bugs).

Assignee: mgoodwin → dkeeler
Priority: P2 → P1
Summary: Add item to blocklist-clients.js to fetch / sync server CRLite state → import CRLite enrollment state into cert_storage
Whiteboard: [psm-blocked] → [psm-assigned]
Pushed by dkeeler@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/04294661134a import CRLite enrollment state r=jcj,KevinJacobs
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69
Attachment #9061771 - Attachment is obsolete: true
Attachment #9061771 - Attachment is obsolete: false
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: