How guides on this site are actually researched and kept current — not a generic policy statement, but the specific process behind the content you're reading.
Technical claims on this site — protocol behavior, historical dates, vulnerability details — are checked against primary sources before publication: IETF RFCs directly from rfc-editor.org, the National Vulnerability Database for CVE identifiers, the CA/Browser Forum's own published Baseline Requirements, and vendor announcements from the certificate authorities and browser vendors themselves. Where a fact could plausibly have gone stale (pricing, warranty amounts, product availability), we either verify it fresh or leave it out rather than publish a number we can't currently stand behind.
A concrete example: an early draft of one guide was going to cite RFC 9162 as the Certificate Transparency specification. Checking directly against IETF's own datatracker showed RFC 6962 is what every CT log in production actually implements — RFC 9162 defines a newer, formally correct but practically unadopted version. The citation was corrected before publishing. Historical CVE identifiers (Heartbleed, POODLE, BEAST, and others referenced across our SSL History category) were each independently checked against NVD or Wikipedia rather than cited from memory.
Where we cite adoption statistics, protocol timelines, or industry figures, we cite the specific source (Google's Chrome Transparency Report, CA/Browser Forum ballot records) rather than presenting a number without attribution. Figures that are estimates by nature — like browser telemetry-based HTTPS adoption percentages — are described as estimates, not presented as an exact census.
If you find an error — a stale figure, an outdated procedure, a broken link — the fastest way to get it fixed is our contact page. Corrections are logged, not silently edited; see the Corrections & Updates page for what's actually changed and when.
Loading comments…