keeneticos KeeneticOS 5.2 Application Filter – Removal of Category Support, Existing Rule Lifecycle, Record-Level Change Tracking, and Rule Import/Export

[bayraktarozcan]

Hello,

I am using KeeneticOS 5.2 on the Developer Channel.

I previously submitted detailed feedback and feature requests regarding the Application Filter through a different communication channel with Keenetic Support rather than through this forum. I am opening this topic here because the issue has evolved and I would like to document it more comprehensively from the perspectives of functionality, configuration lifecycle, data traceability, portability, and security policy management.

In my previous requests, I raised the following subjects:

• the ability to block an application category while allowing a specific application within that category as an exception;

• the status of the permit / deny filter profile structure on the CLI in current KeeneticOS versions;

• the relationship between that CLI capability and the Web Interface;

• and, more generally, the ability to use category-level policies together with application-level exceptions.

Keenetic Support previously informed me that these requests had been forwarded to the relevant teams for evaluation.

Later, with KeeneticOS 5.2 Alpha 10, I noticed that category entries were removed from application search results when creating an Application Filter rule under [NWI-4798].

This change is also explicitly documented in the KeeneticOS 5.2 Alpha 10 release notes.

Keenetic Support previously explained that this was not a bug, that existing category-based rules would continue to operate, and that newly created Application Filter rules would only allow application-level selection while the new approach was being evaluated for a later Beta stage.

I understand this explanation. However, the issue is no longer simply whether a category field is visible in the Web Interface. The broader issue is how this change affects the functional expression of security policies, the lifecycle of existing configurations, the traceability of classification data, configuration portability, and the maintainability of the feature.

1. Future Behavior of Existing Category-Based Rules

First, I would like the future behavior of existing category-based rules to be clearly documented.

For example, assume that an existing rule is:

Social category → Block

Keenetic Support has stated that existing category-based rules will continue to operate.

However, there is an important technical question behind this statement:

Does the existing rule continue to reference the category logically and therefore automatically follow future changes in that category's membership?

For example:

• If a new application is added to the category, will the existing rule automatically include it?

• If an application is removed from the category, will the existing rule automatically stop applying to it?

• If an application is moved to another category, will the existing rule's behavior change automatically?

• If an application's classification changes, how will the existing rule behave?

There are two fundamentally different technical models here.

Model 1 — Dynamic Category Reference

The rule is logically bound to the category:

Category X → DENY

When an application is added to Category X, it automatically becomes subject to the existing policy.

Model 2 — Static Application Expansion

When the rule is created, the applications belonging to the category at that particular moment are expanded into an effective static application set.

From an operational and security-policy perspective, these two models are not equivalent.

Therefore, in addition to stating that existing category rules continue to work, I would like the following to be explicitly documented:

Do existing category-based rules dynamically follow future changes in category membership?

This distinction is particularly important because the fundamental benefit of category-based policy is that the user manages a semantic group instead of maintaining a manually curated list of individual applications.

2. Removing Category Selection and the Previously Requested Exception Capability

I would like to make an important distinction so that my previous requests are not misunderstood.

The existing Application Filter already provided:

Category → Block

That functionality existed before the current change.

By contrast, the following capability did not exist:

Blocked Category → Specific Application → Allow

This was precisely one of the missing capabilities that I requested in my previous submissions.

In other words, the situation can be summarized as follows:

Existing functionality

Category → Block

Previously requested but unavailable functionality

Specific Application within a Blocked Category → Allow

New situation introduced with Alpha 10

Category selection has also been removed when creating new Application Filter rules.

Therefore, [NWI-4798] did not remove a previously existing category-exception function, because such a function had never been available.

My previous request was specifically asking Keenetic to add that missing capability.

After that request had been made, category selection itself was also removed from new rule creation.

From my perspective, this creates a broader functional issue:

The previously requested category + application exception model was not introduced, and the category-level policy creation capability was subsequently removed from newly created rules as well.

This distinction is important because otherwise the change could be interpreted as merely removing a redundant or confusing interface element. It is not redundant: category-level policy creation itself is a meaningful functional capability.

3. Why an Application-Only Model Is Not Sufficient

Keenetic's own Application Filter documentation describes the feature as being able to block specific applications as well as traffic categories, including the ability to apply those rules to individual clients and network segments. The documented Blacklist rule also includes an "Applications and categories to block" selection mechanism.

Therefore, the problem is not simply that the old interface has been redesigned.

The actual issue is that the abstraction level available for defining a policy has changed.

For example, suppose a category contains 100 applications.

With category-based policy, the user can define:

Category → Block

with a single policy.

That is precisely the advantage of categorization: the policy follows the semantic group rather than a manually maintained application list.

Now consider the more realistic requirement that only one application within that category should remain available.

The desired policy is:

Category → Block

and:

Specific Application within that Category → Allow

This second capability was already missing and was the subject of my previous request.

After category selection was removed from new rules, the situation became even more restrictive because the category itself can no longer be selected when defining a new policy.

The user may therefore have to reproduce a category-level policy by manually selecting individual applications, for example:

Application 1 → Block

Application 2 → Block

Application 3 → Block

...

Application 100 → Block

This is not merely a matter of requiring more clicks.

The abstraction level of the policy changes from:

Category

to:

Individual Application List

This results in:

• more rules or selections,

• more configuration effort,

• greater risk of human error,

• lower readability,

• higher maintenance requirements,

• and additional manual work whenever category membership changes.

Most importantly, the policy becomes dependent on the applications the user knows and selects at that moment rather than on the semantic category itself.

For this reason, I believe the change should be evaluated as a change in functional policy expression, not merely as a user interface simplification.

4. Reconsidering the Category + Application Exception Model

The underlying requirement remains the same:

Category → Block

while:

Specific Application within that Category → Allow

should be possible.

I do not insist on one particular user interface implementation.

For example, the feature could be implemented as:

Model A — Explicit Allow/Deny Rules

Category X → DENY

Application Y → PERMIT

where the application-specific rule acts as an explicit exception.

Model B — Exception Within a Category

Category X → DENY

Category X / Application Y → EXCEPTION

A separate Whitelist / Allow List could also be considered as a simple alternative.

The important requirement is not the name of the mechanism or the exact user interface.

The important requirement is that users should be able to define a broad category-level policy and then create controlled application-level exceptions within that policy.

Rule precedence should also be explicit, deterministic, and predictable.

For example, if:

All clients / segment → Category X → DENY

and:

Specific client → Application Y → PERMIT

both apply, the user must be able to determine in advance which rule takes precedence.

A model based on rule scope and specificity could be considered, followed by explicit priority where necessary.

For example:

More specific rule → Less specific rule → Default policy

could provide a predictable evaluation model.

The exact implementation can of course be determined by Keenetic. The requirement is that overlapping rules should have a clearly defined and documented result.

5. Application and Protocol Lists: Record-Level Dates and Change Metadata

Keenetic publishes separate application and protocol lists for the Main and Developer update channels.

I would like to clarify an important point regarding these files.

I am not referring only to the modification or publication date of the file as a whole.

What I am specifically asking for is record-level change information inside the list itself.

For example, one application may have been added recently, while another may have been present for several years. Another application may have had its category changed later.

If the current spreadsheet contains only the present state of each record, the user cannot reliably determine which entries are new and which are longstanding entries.

This becomes even more important for Developer Channel users, where the classification dataset may change over time.

Therefore, I strongly recommend that every application/protocol record contain, at minimum:

ID

Name

Category

Date Added / First Published

Last Modified

Change Type

Status

For example, the change type could indicate:

Added

Modified

Renamed

Category Changed

Deprecated

and the status could indicate:

Active

Deprecated

Removed

If technically appropriate, First Seen and Last Modified fields would also be useful.

The most important requirement here is:

The date on which each individual record was added must be identifiable.

This is necessary to distinguish newly added applications from older entries.

For example, updating the spreadsheet today does not tell the user whether a particular row was added today, six months ago, or several years ago.

A file-level timestamp alone cannot provide this information.

The current files already indicate the relevant operating system and update-channel scope, so I am not proposing a separate catalog-version concept as a replacement for that information.

My request is more direct:

Each individual record should have enough metadata to make its own lifecycle and change history traceable.

Where appropriate, it would also be useful to indicate in which KeeneticOS release or build the record was introduced or changed.

This would make the application/protocol lists substantially more useful for advanced users, troubleshooting, policy maintenance, and historical comparison.

6. Impact of Classification Changes on Existing Policies

If existing category-based rules are preserved, the effect of classification changes on those rules should also be clearly documented.

For example:

• If a new application is added to a category, is it automatically covered by an existing category rule?

• If an application is removed from a category, does the category rule automatically stop covering it?

• If an application moves to another category, does its effective policy change automatically?

• If an application's name changes, is the existing rule preserved?

• If an application is deprecated or no longer classified, what happens to an existing rule referring to it?

• If the classification data differs between the Main and Developer channels, how is policy behavior determined?

These questions all lead to the same underlying issue:

How exactly is an Application Filter policy bound to classification data that changes over time?

This should be clearly documented because the security outcome of an existing rule may depend on future changes in the underlying classification dataset.

7. Import and Export of Application Filter Rules

KeeneticOS already provides mechanisms for saving and restoring device configuration through the startup-config file.

However, backing up the entire device configuration and being able to export only the Application Filter policy are two different management requirements.

Therefore, I suggest providing a dedicated import/export mechanism specifically for Application Filter rules.

For example, a machine-readable format could contain:

Rule ID

Rule Name

Enabled

Action

Clients

Segments

Application IDs

Category IDs

Schedule

Priority

Creation Date

Last Modified

KeeneticOS Version

Update Channel

Configuration Schema Version

Stable identifiers should preferably be used instead of relying only on display names.

During import, it would also be useful to validate:

• applications that no longer exist,

• renamed applications,

• applications that are no longer classified,

• obsolete category IDs,

• rule conflicts,

• unsupported or missing objects,

• and compatibility issues.

Ideally, the user should be able to preview the changes before applying them.

For example:

18 rules found

12 rules will be created

2 rules will be modified

3 applications are not present in the current classification data

1 object is no longer supported

Such a mechanism would be useful for:

• backup,

• device replacement,

• configuration migration,

• applying the same policy to multiple devices,

• testing and controlled rollout,

• and rollback.

It would also make the Application Filter much easier to manage in environments where many rules are involved.

8. Showing the Matching Rule in Diagnostics

For the Application Filter, seeing only that traffic was "blocked" is not always sufficient for troubleshooting.

Where technically feasible, the Application Traffic Analyser, system logs, or a dedicated diagnostics view could expose the following relationship:

Client → Application → Category → Matching Rule → Result

For example:

Client: Device A

Application: X

Category: Y

Matching Rule: Category Y → Block

Exception Rule: Application X → Allow

Result: Allowed

Or:

Client: Device B

Application: Z

Category: Y

Matching Rule: Category Y → Block

Result: Blocked

This would be particularly useful when:

• applications are reclassified,

• category membership changes,

• multiple overlapping rules exist,

• or the observed behavior differs from the user's expectation.

It would also make support and troubleshooting considerably more efficient because the user could directly determine:

Why was this traffic allowed or blocked?

9. Security, Configuration Management, and Data Traceability

I believe this issue should not be evaluated solely as a user interface matter.

The Application Filter is a security policy mechanism, and the classification data on which that policy depends may change over time.

Therefore, several characteristics become relevant:

• traceability of the underlying data,

• change visibility,

• predictable policy behavior,

• configuration portability,

• validation before deployment,

• rollback capability,

• and the ability to determine why a particular result occurred.

These principles are also reflected in established networking and security engineering practices.

For example, IETF YANG defines revision information for data models and provides explicit mechanisms for tracking changes over time. PCI DSS secure change-management requirements include documenting the reason and security impact of changes, testing changes to ensure that they do not adversely affect security, and maintaining procedures to return to a secure state. Microsoft Security Update Guide entries expose release and update timestamps, while Red Hat maintains a changelog for its security data.

I am not suggesting that Keenetic is subject to these documents as direct compliance requirements.

Rather, these are useful examples of a broader engineering principle:

When technical data influences security-related behavior, its lifecycle and changes should be sufficiently traceable to understand the resulting policy state.

The same principle is applicable to an application classification dataset used to determine network filtering behavior.

10. NWI-4798 and the Balance Between Usability and Functionality

I understand from the previous response from Keenetic Support that NWI-4798 was introduced because category-based filtering behavior was not considered sufficiently clear by some users and that the new approach was being evaluated for a later Beta stage.

However, usability and functionality do not necessarily have to be treated as alternatives.

If category selection was considered difficult to understand, one possible solution is to redesign how the category functionality is presented rather than removing the category-level capability from new policy creation.

For example, a redesigned interface could provide separate:

Applications

and:

Categories

views.

Alternatively, selecting a category could display the applications that belong to it and allow the user to refine the policy from there.

This would make the feature easier to understand without removing the underlying policy abstraction.

Therefore, my request is not simply to revert NWI-4798 exactly as it was.

The broader request is:

Preserve the functional ability to define category-based policies, while improving the user interface and making the underlying behavior clearer and more predictable.

11. General Resource, Compatibility, and Regression Considerations Across KeeneticOS

This request is not intended to be treated as a model-specific feature request.

The Application Filter is a KeeneticOS feature, and therefore the proposed functionality should be evaluated at the KeeneticOS level and across the supported device classes on which the relevant traffic-classification and filtering components are available.

If there are platform-specific limitations relating to CPU, memory, traffic-processing architecture, hardware acceleration, or other implementation constraints, these should naturally be evaluated for the affected device classes.

However, the existence of platform-specific resource differences should not, by itself, be assumed to make the requested policy model impractical.

The proposed category + application exception mechanism can conceptually be implemented as a policy-evaluation capability on top of the application and category classification results that the existing Application Filter already relies on.

In other words, if the classification layer already determines:

Application = X

and:

Category = Y

then evaluating:

Category Y → DENY

against:

Application X → PERMIT

is fundamentally a policy-decision problem.

The appropriate question is therefore not simply whether the feature can exist, but what the actual implementation and performance impact would be across the supported KeeneticOS platforms.

For that reason, I suggest that the feature be evaluated with normal compatibility and regression testing across the relevant device classes rather than being considered only from the perspective of a single hardware platform.

12. Final Feature Requests

I would therefore like to summarize the requested improvements as follows:

1. Restore or redesign category-based policy creation.

When creating a new Application Filter rule, users should be able to define a category-level blocking policy again, either through the previous interface or through a redesigned interface that preserves the same functional capability.

2. Add application-level exceptions within blocked categories.

The following policy should be expressible:

Category → Block

and:

Specific Application within that Category → Allow

A separate Whitelist / Allow List, an explicit PERMIT rule, or an exception mechanism within the category are all possible implementation approaches.

3. Define deterministic rule precedence.

Conflicting category and application rules should have an explicit and predictable evaluation order.

4. Document the lifecycle behavior of existing category rules.

It should be clearly documented whether existing category-based rules automatically follow additions, removals, moves, and reclassifications of applications within the classification data.

5. Add record-level timestamps and change metadata to the application/protocol lists.

Most importantly, each individual record should contain information showing when it was first added and, where applicable, when it was last changed.

This would allow users to distinguish new entries from older entries and to understand the lifecycle of the classification data.

6. Add dedicated import/export support for Application Filter policies.

Users should be able to back up, migrate, review, and restore Application Filter rules independently from the complete device configuration.

7. Provide rule-matching diagnostics.

Where technically feasible, the system should show:

Client → Application → Category → Matching Rule → Result

so that users can determine why traffic was allowed or blocked.

8. Clarify the long-term direction of NWI-4798.

It would be helpful to know whether the removal of category selection from new Application Filter rules is temporary, part of a redesigned implementation that will return later in the Beta/Preview stage, or intended to become the permanent design.

Conclusion

My objective is not simply to restore the previous Web Interface.

The broader objective is to ensure that the Application Filter remains a scalable, maintainable, traceable, and sufficiently expressive security-policy mechanism.

The distinction is important:

Category → Block

was an existing capability.

Blocked Category → Specific Application → Allow

was not an existing capability. It was a feature request that I had previously submitted because it was missing.

That requested capability has still not been introduced, while category selection itself has subsequently been removed from new rule creation.

As a result, users who need broad category-based policies may now have to reproduce those policies by selecting individual applications. For larger categories, this significantly increases configuration and maintenance effort and undermines one of the main advantages of category-based filtering.

In addition, if the underlying application classification data changes over time, users need to know when individual records were added or modified, how those changes affect existing policies, and which rule ultimately determined a given filtering result.

For these reasons, I believe the subject should be evaluated not merely as a UI change, but as a matter of policy expression, configuration lifecycle, classification-data management, change traceability, portability, and predictable security behavior.

I kindly ask the relevant Keenetic teams to evaluate these points as part of the ongoing development and design process.

Thank you for your attention.

Best regards.