Bugzilla

># Request for data collection review form
>
>**All questions are mandatory. You must receive review from a data steward peer on your responses to these questions before shipping new data collection.**
>
>1) What questions will you answer with this data?
>
>How often do we use various certificate revocation checking mechanisms? In particular, for what percentage of revocation checks do we use the CRLite (a fast and privacy preserving revocation checking mechanism that Mozilla developed).
>
>2) Why does Mozilla need to answer these questions?
>
>CRLite continously ingests data from certificate transparency logs and from certificate revocation lists. There are some problems in the ingestion pipeline that we cannot detect automatically. For instance, if a new certificate transparency log becomes popular and we forget to enroll it in the program. When these problems occur, CRLite's efficacy will gradually drop off. This probe will be used to alert us to major changes in the efficacy of CRLite.
>
>3) What alternative methods did you consider to answer these questions? Why were they not sufficient?
>
>Various third parties provide estimates for the number of certificates in use on the web, and we know the number of certificates ingested by CRLite. However, this ratio is a poor estimate for the efficacy of CRLite, as users do not encounter certificates randomly. CRLite could be very useful without covering a large portion of certificates, and vice versa.
>
>4) Can current instrumentation answer these questions?
>
>No.
>
>5) List all proposed measurements and indicate the category of data collection for each measurement, using the [Firefox data collection categories](https://wiki.mozilla.org/Data_Collection) found on the Mozilla wiki.   
>
>**Note that the data steward reviewing your request will characterize your data collection based on the highest (and most sensitive) category.**
>
><table>
>  <tr>
>    <td>Measurement Description</td>
>    <td>Data Collection Category</td>
>    <td>Tracking Bug #</td>
>  </tr>
>  <tr>
>    <td>CERT_REVOCATION_MECHANISMS: a categorical histogram comparing the use of CRLite and OCSP</td>
>    <td>Category 2: interaction data</td>
>    <td>1794450</td>
>  </tr>
></table>
>
>6) Please provide a link to the documentation for this data collection which describes the ultimate data set in a public, complete, and accurate way.
>    * This collection is documented in its definitions files Histograms.json, Scalars.yaml, and/or Events.yaml and in the Probe Dictionary at https://probes.telemetry.mozilla.org.
>
>7) How long will this data be collected?  Choose one of the following:
>    * I want to permanently monitor this data. (put someone’s name here)
>
>8) What populations will you measure?
>    * All
>
>9) If this data collection is default on, what is the opt-out mechanism for users?
>    * General telemetry opt-out.
>
>10) Please provide a general description of how you will analyze this data.
>    * STMO dashboard / alerts
>
>11) Where do you intend to share the results of your analysis?
>    * Internal cryptoeng team meetings
>
>12) Is there a third-party tool (i.e. not Glean or Telemetry) that you are proposing to use for this data collection? If so:
>    * no
>

># Request for data collection review form
>
>**All questions are mandatory. You must receive review from a data steward peer on your responses to these questions before shipping new data collection.**
>
>1) What questions will you answer with this data?
>
>How often do we use various certificate revocation checking mechanisms? In particular, for what percentage of revocation checks do we use the CRLite (a fast and privacy preserving revocation checking mechanism that Mozilla developed).
>
>2) Why does Mozilla need to answer these questions?
>
>CRLite continously ingests data from certificate transparency logs and from certificate revocation lists. There are some problems in the ingestion pipeline that we cannot detect automatically. For instance, if a new certificate transparency log becomes popular and we forget to enroll it in the program. When these problems occur, CRLite's efficacy will gradually drop off. This probe will be used to alert us to major changes in the efficacy of CRLite.
>
>3) What alternative methods did you consider to answer these questions? Why were they not sufficient?
>
>Various third parties provide estimates for the number of certificates in use on the web, and we know the number of certificates ingested by CRLite. However, this ratio is a poor estimate for the efficacy of CRLite, as users do not encounter certificates randomly. CRLite could be very useful without covering a large portion of certificates, and vice versa.
>
>4) Can current instrumentation answer these questions?
>
>No.
>
>5) List all proposed measurements and indicate the category of data collection for each measurement, using the [Firefox data collection categories](https://wiki.mozilla.org/Data_Collection) found on the Mozilla wiki.   
>
>**Note that the data steward reviewing your request will characterize your data collection based on the highest (and most sensitive) category.**
>
><table>
>  <tr>
>    <td>Measurement Description</td>
>    <td>Data Collection Category</td>
>    <td>Tracking Bug #</td>
>  </tr>
>  <tr>
>    <td>CERT_REVOCATION_MECHANISMS: a categorical histogram comparing the use of CRLite and OCSP</td>
>    <td>Category 2: interaction data</td>
>    <td>1794450</td>
>  </tr>
></table>
>
>6) Please provide a link to the documentation for this data collection which describes the ultimate data set in a public, complete, and accurate way.
>    * This collection is documented in its definitions files Histograms.json, Scalars.yaml, and/or Events.yaml and in the Probe Dictionary at https://probes.telemetry.mozilla.org.
>
>7) How long will this data be collected?  Choose one of the following:
>    * I want to permanently monitor this data. (John Schanck)
>
>8) What populations will you measure?
>    * All
>
>9) If this data collection is default on, what is the opt-out mechanism for users?
>    * General telemetry opt-out.
>
>10) Please provide a general description of how you will analyze this data.
>    * STMO dashboard / alerts
>
>11) Where do you intend to share the results of your analysis?
>    * Internal cryptoeng team meetings
>
>12) Is there a third-party tool (i.e. not Glean or Telemetry) that you are proposing to use for this data collection? If so:
>    * no
>

whoops, that file was missing an answer.