RequestPolicy/requestpolicy — Issue #100: Preference Dialog & Context Menu do not readily support all site request policies
Author: jsamuel
Created: 2011-12-22 18:52:24+00:00
State: open
Labels: extension

imported trac ticket
created: 2010-05-02 13:51:39
reporter: eibwen

There are at least three parameters for a site policy rule:
(a) Applicability: origin, destination, or origin-to-destination;
(b) Specificity: 2nd level domain, full domain, full domain + protocol + port; and
(c) Policy: DENY, Temporary ALLOW, ALLOW (and with [#6], BLACKLIST)

The current UI is structured to support distinctly separate applicability at predefined specificity, with policy state changes only (eg Temporarily ALLOW <-> ALLOW is not directly supported).

Further, the current UI is inconsistently structured. The Preferences dialog segregates each applicability to separate tabs, despite the fact that the same site may appear in all lists. Perhaps the export/import format is more conducive to editing; however, it should not be required for typical changes. The Context Menu separates "primary" origin from destination and origin-to-destination, and "secondary" origin(s) are segregated to a submenu; however, the destination and origin-to-destination applicability is not separated. The Specificity setting can only be changed from the Preferences dialog, and is not separately configurable for origins-to-destinations. Moreover, cross site requests more specific than the current setting are not shown, whereas the user may still want to implement policy, but be unaware of the request, and thus the need to change the setting.

As a result, users likely attempt to specify policy solely through the Context Menu with limited specificity setting changes. However, this does not seem to match the average use case, where users trust different origins and destinations (even as part of an origin-to-destination) separately. It also inhibits same policy state changes, such as users setting Temporarily ALLOW, confirming the result, and then upgrading to ALLOW.

The full matrix of possible combinations is significant, particularly as the origin-to-destination applicability should allow separate specificity. This will only get significantly more complex when BLACKLIST support is added.

This bug is intended to open a dialog about the UI usability and consistency issues to propose changes and make improvements.