Introduce concept of security settings and privacy settings to split up general settings.

When we introduced the plugin system settings and measurable settings there weren't that many settings. But now there are many settings that are all shown on the General settings page.

It can be hard and time consuming to look through all these settings and to find relevant ones. For example identifying the ones that are related to security is very hard as you kind of even have to read the text of many settings etc.

At the same time the page includes various privacy settings that should be shown in the Privacy -> Anonymise data page.

I propose a new concept that a plugin cannot only have SystemSettings but also SecuritySettings and PrivacySettings.

Security Settings would be shown in a System -> Security page. It would include settings around 2FA, Brute force, the new setting to only allow specific email domains", etc.

Privacy Settings would be shown in Privacy -> Settings page (it doesn't quite fit into the Anonymise data page as most settings aren't really anonymising data). It would include settings like disabling Heatmaps and Session Recording, as well as the Privacy Manager settings and the "Live" settings to disable visits log.

Implementation wise it would be maybe easiest if for every setting to have a property in the settings config to classify a system setting as "Security" or "Privacy". Then we would also not need to change the CorePluginsAdmin.setSystemSettings etc and would make migration to this new system easiest and most flexible without having to change any tests or code and while still being able to see all system settings in the code in the same place and being able to reuse the same backend etc.

Maybe this way we could even think about allowing a config being configured as privacy and as a security setting. This is for example the case for a new setting where we allow to restrict the email domains which is good for privacy and security.

Since this could be breaking API, it may be beneficial to do this as part of Matomo 5. Depending on how we implement this, it may not be breaking at all though. Eg if we just add a property to define a setting as a specific type of setting then it won't be breaking.

The UI should be also very easy to build for this as we can reuse the existing logic to just iterate over each type of setting maybe.

Ping @mattab

matomo-org / matomo

Introduce concept of security settings and privacy settings to split up general settings. #20168