3 files changed, 92 insertions, 0 deletions
diff --git a/application/basilisk/base/content/docs/sslerrorreport/dataformat.rst b/application/basilisk/base/content/docs/sslerrorreport/dataformat.rst
new file mode 100644
index 000000000..f69dc7417
--- /dev/null
+++ b/application/basilisk/base/content/docs/sslerrorreport/dataformat.rst
@@ -0,0 +1,54 @@
+.. _sslerrorreport_dataformat:
+
+==============
+Payload Format
+==============
+
+An example report::
+
+  {
+    "hostname":"example.com",
+    "port":443,
+    "timestamp":1413490449,
+    "errorCode":-16384,
+    "failedCertChain":[
+      ],
+    "userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0",
+    "version":1,
+    "build":"20141022164419",
+    "product":"Firefox",
+    "channel":"default"
+  }
+
+Where the data represents the following:
+
+"hostname"
+  The name of the host the connection was being made to.
+
+"port"
+  The TCP port the connection was being made to.
+
+"timestamp"
+  The (local) time at which the report was generated. Seconds since 1 Jan 1970,
+  UTC.
+
+"errorCode"
+  The error code. This is the error code from certificate verification. Here's a small list of the most commonly-encountered errors:
+  https://wiki.mozilla.org/SecurityEngineering/x509Certs#Error_Codes_in_Firefox
+  In theory many of the errors from sslerr.h, secerr.h, and pkixnss.h could be encountered. We're starting with just MOZILLA_PKIX_ERROR_KEY_PINNING_FAILURE, which means that key pinning failed (i.e. there wasn't an intersection between the keys in any computed trusted certificate chain and the expected list of keys for the domain the user is attempting to connect to).
+
+"failedCertChain"
+  The certificate chain which caused the pinning violation (array of base64
+  encoded PEM)
+
+"user agent"
+  The user agent string of the browser sending the report
+
+"build"
+  The build ID
+
+"product"
+  The product name
+
+"channel"
+  The user's release channel
diff --git a/application/basilisk/base/content/docs/sslerrorreport/index.rst b/application/basilisk/base/content/docs/sslerrorreport/index.rst
new file mode 100644
index 000000000..2c4210113
--- /dev/null
+++ b/application/basilisk/base/content/docs/sslerrorreport/index.rst
@@ -0,0 +1,15 @@
+.. _sslerrorreport:
+
+===================
+SSL Error Reporting
+===================
+
+With the introduction of HPKP, it becomes useful to be able to capture data
+on pin violations. SSL Error Reporting is an opt-in mechanism to allow users
+to send data on such violations to mozilla.
+
+.. toctree::
+   :maxdepth: 1
+
+   dataformat
+   preferences
diff --git a/application/basilisk/base/content/docs/sslerrorreport/preferences.rst b/application/basilisk/base/content/docs/sslerrorreport/preferences.rst
new file mode 100644
index 000000000..ed6f384c2
--- /dev/null
+++ b/application/basilisk/base/content/docs/sslerrorreport/preferences.rst
@@ -0,0 +1,23 @@
+.. _healthreport_preferences:
+
+===========
+Preferences
+===========
+
+The following preferences are used by SSL Error reporting:
+
+"security.ssl.errorReporting.enabled"
+  Should the SSL Error Reporting UI be shown on pin violations? Default
+  value: ``true``
+
+"security.ssl.errorReporting.url"
+  Where should SSL error reports be sent? Default value:
+  ``https://incoming.telemetry.mozilla.org/submit/sslreports/``
+
+"security.ssl.errorReporting.automatic"
+  Should error reports be sent without user interaction. Default value:
+  ``false``. Note: this pref is overridden by the value of
+  ``security.ssl.errorReporting.enabled``
+  This is only set when specifically requested by the user. The user can set
+  this value (or unset it) by checking the "Automatically report errors in the
+  future" checkbox when about:neterror is displayed for SSL Errors.