A plan for Q3 2023 iteration
Tags: buildinpublic, opensource, cybersecurity, microsaas
Published: 2023-09-21 10:00:00

> The original post was published on my blog on **August 1, 2023**, long before I realized it might be interesting to the dev.to community.

Hello!

In [**one of my previous posts**](https://secutils.dev/docs/blog/alpha2-release), I mentioned that I wrapped up the "Q2 2023 Apr-Jun" iteration and moved on to the next one: [**"Q3 2023 Jul-Sep"**](https://github.com/orgs/secutils-dev/projects/1/views/1). 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.

![Q3 2023 Jul-Sep iteration](https://secutils.dev/docs/img/blog/2023-08-01_q3_2023_iteration.png)

## More configurable certificate templates

**Tracking issue: [#secutils/8](https://github.com/secutils-dev/secutils/issues/8)**

The **["Digital Certificates → Self-signed certificates"](https://secutils.dev/docs/guides/digital_certificates)** 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](https://github.com/secutils-dev/secutils/issues/20)**

In the previous iteration, I introduced the [**“Web Scraping → Resources Trackers”**](https://secutils.dev/docs/guides/web_scraping/resources) 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](https://github.com/secutils-dev/secutils/issues/19)**

As mentioned in the previous section, I plan to send email alerts if [**Secutils.dev**](https://secutils.dev) detects any changes in web page resources. However, as discussed in the [**“Detecting changes in JavaScript and CSS isn't an easy task, Part 2”**](https://secutils.dev/docs/blog/detecting-changes-in-js-css-part-2#challenge-5-constantly-changing-resources) post, some resources are highly dynamic and can change every time the page is reloaded. Often, these changes are irrelevant to users, such as web page analytics scripts, and sending email alerts for every such change can quickly become costly.

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.

## Shareable content

**Tracking issue: [#secutils/21](https://github.com/secutils-dev/secutils/issues/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!

> **ℹ️ ASK:** If you found this post helpful or interesting, please consider showing your support by starring [**secutils-dev/secutils**](https://github.com/secutils-dev/secutils) GitHub repository.

> Also, feel free to follow me on [**Twitter**](https://twitter.com/aleh_zasypkin), [**Mastodon**](https://infosec.exchange/@azasypkin), or [**LinkedIn**](https://www.linkedin.com/in/azasypkin/).

> Thank you for being a part of the community!