msxfm
commented
10 years ago 
imported trac comment
created: 2010-05-02 16:23:26
author: eibwenProposal
Use select boxes for specificity and policy, with a special specificity option ANYWHERE to provide for all applicability options. Treat the specificity setting as a DEFAULT specificity selection, and pre-select options accordingly.
For example, options for a single page may look like (rows indicate different rules):
| FROM | TO | POLICY IS |
|---|---|---|
| www.example.com | static.example.com | ALLOW |
| example.com | http://this.othersite.example:80 | Temporarily ALLOW |
| static.example.com | ANYWHERE | DENY |
With options for a rule (rows indicate different options from SAME select box):
| FROM | TO | POLICY IS |
|---|---|---|
| ANYWHERE | ANYWHERE | DENY |
| example.com | site.example | Temporarily ALLOW |
| www.example.com | static.site.example | ALLOW |
| http://www.example.com:80 | http://static.site.example:80 | (BLACKLIST) |
See attachment for a screenshot of a mockup in Gtk+.
BENEFITS
- This organizes all policy rules regardless of applicability or policy.
- It provides for varying levels of specificity, without having to repeatedly toggle settings.
- It would eliminate all the submenus from the Context Menu.
- It could preserving the color scheme (GREEN for Temporarily ALLOW & ALLOW, ORANGE for "secondary" origin(s), RED for DENY).
- It provides for setting ALL policy rules without requiring reopening the menu.
- This could be optionally implemented with ACCEPT / CANCEL buttons to confirm changes, thereby permitting multiple changes and reloading only once.
HOWEVER
- The proposed use of select boxes is not traditional for the page Context Menu item. May not be traditional for Toolbar icon. It is appropriate for the statusbar icon.
- Multiple rules between same origin and destination with different specificity and policy is not clearly handled. One idea is that use of the ACCEPT button with different settings would automatically insert a new rule row; however, the principle of least surprise should apply here.
- ANYWHERE to ANYWHERE rules may be inadvertently set, surprising unwitting users. Perhaps disable the second ANYWHERE if a user already selected one, unless a special preferences setting is enabled?
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.