Share your questions, comments, and ideas about the Security chapter of the Web Almanac…
1 Like
Was just skimming the Security chapter of the Web Almanac.
as a review of the study results in this chapter shows, the coverage of several important security mechanisms extends only to a subset of the web, leaving a significant part of the ecosystem exposed to security or privacy bugs.
The low adoption of the tools out there by developers is not news. But it makes me wonder how much time we might allocate to new standards versus improving adoption of existing, powerful standards.
Anyone for a moratorium on new security headers? 
1 Like
I would be interested in DNS Certification Authority Authorization (CAA) adoption over time. It feels like adoption is slow but it would be nice to test that hypothesis and learn:
- absolute number of sites using it over time
- whether the largest sites / properties online are using it
- whether they are taking advantage of the optional
iodefsetting
Does this sound like something that could be included in the 2020 version of the Web Almanac?
Not sure how much DNS information is available in HTTPArchive but SSLPulse track this (though don’t think you can query it by site): https://www.ssllabs.com/ssl-pulse/
1 Like
And Scott also tracks it in his scans: https://scotthelme.co.uk/top-1-million-analysis-september-2019/#caa
1 Like
Thanks @tunetheweb. I’d seen SSLLab’s numbers already but I wasn’t aware that Scott had that data. Will give that a look. Much appreciated…
Enhancement request to consider for next year: usage of security.txt files.
Suspect it will be very low.
See here:
and the next part;
and Scott Helme’s own analysis here:
https://scotthelme.co.uk/top-1-million-analysis-september-2019/
There’s definitely a balance to be struck between:
- Only writing about the popular features that have a certain threshold of usage.
- Writing about interesting and/or up and coming features even if usage is currently low.
- Trying to be a fully comprehensive report listing as many stats as we can get.
I’d definitely veer to 2) as think it makes the report more interesting, but also avoids making it very lengthy, and potentially too much for those not in the security community. The Security chapter this year was already one of the longest ones!
I think one of the strengths of the Almanac is that it presents 20 chapters on various topics so introduces people to areas of web development they may be less familiar with - like security. Or SEO. Or any of the other topics. So I do worry about overloading the reports with too many little used, or niche stats which may be better served with dedicated reports in the security community (and similar for other stats)?
With that in mind would security.txt make the cut? That would be entirely up to the author(s) who write next year’s chapters!
Even if we did want to report on it, there’s also the question of how we check this? Currently the Almanac is mostly made up of the HTTP Archive monthly crawl of Home Pages and the Chrome UX Report - neither of which allow reporting of security.txt files. Lighthouse (run as part of the HTTP Archive crawl) does give robots.txt (used in SEO chapter) but not security.txt as far as I know. If it couldn’t be added then would it be worth having a separate crawler for that? Possibly, but when usage is as small as it seems from the other sources, it wouldn’t be a big priority if it was my choice. Though having another separate, smaller, crawler for specific paths on each domain does open a lot of other possibilities!
Your best chance in suggesting and pushing for stats you want cover is to get involved next year. Perhaps as a reviewer of the Security chapter? Interest form available here: https://almanac.httparchive.org/en/2019/methodology#looking-ahead
Hope that helps!
1 Like
Quick data point update on Security.txt adoption. Current count as of this writing in Scott’s crawler.ninja data is that it’s found on about 2,500 sites.
In September 2019, that number was about 1,600.