In one of my previous posts, I mentioned that I wrapped up the "Q2 2023 Apr-Jun" iteration and moved on to the next one: "Q3 2023 Jul-Sep". In this post, I want to briefly cover what I'm going to work on during this iteration. I'll highlight three main areas: improvements to the certificate templates, scheduled automatic web page resources checks, and shareable content.
More configurable certificate templates
Tracking issue: #secutils/8
The "Digital Certificates → Certificate templates" utility currently allows users to create a template for self-signed certificates, with options to tune parameters such as encryption algorithm, signature algorithm, key usage, and more. However, for the initial release, I limited the number of configurable certificate parameters, providing reasonable defaults for the rest. But there are more subtle aspects of digital certificates that users might want to control.
During this iteration, my focus will be on making a few more parameters configurable: key size (RSA, DSA) and curve name (EC). I'm trying to be careful in exposing only necessary parameters to avoid making the UI overly complex.
Scheduled web page resources checks
Tracking issue: #secutils/20
In the previous iteration, I introduced the “Web Scraping → Resources trackers” utility, but currently, you need to manually trigger the re-fetching of resources to detect changes since the last check. This behavior defeats the purpose of a monitoring-like utility and is meant to be a temporary stop-gap solution for early adopters who are eager to start tracking changes in web page resources and can tolerate the inconveniences of the early implementation.
During this iteration, my focus is on adding support for automatic scheduled resources checks and basic email alerts if any changes are detected. This work is already in progress, and I'm planning to write a dedicated blog post covering the implementation details later this month.
Selective web page resources checks
Tracking issue: #secutils/19
Moreover, the effectiveness of alerts depends on how users react to them. If Secutils.dev sends email alerts for every change in any web page resource, they might become quite noisy due to highly dynamic resources, and users may start ignoring them or disable them completely.
During this iteration, my goal is to allow users to choose which web page resources Secutils.dev should ignore when detecting changes. This way, users can customize the alerts to their specific needs and reduce unnecessary notifications.
Tracking issue: #secutils/21
Currently, almost all Secutils.dev functionality requires user authentication, making it challenging to share any generated content (e.g., content security policies, certificates, tracked resources) with people who don't have a Secutils.dev account. This hinders collaboration and adoption of Secutils.dev.
During this iteration, I want to lay the groundwork for shareable content in Secutils.dev. Although I may not have time to implement user-facing functionality yet, I'm planning to establish a solid foundation for adding such features in future iterations.
That wraps up today's post, thanks for taking the time to read it!