Document strictness settings (and effects)

[jsamuel]

imported trac ticket
created: 2009-08-08 19:44:54
reporter: justin

There needs to be documentation on the website, either a wiki page or a website page, to describe what the different strictness settings mean.

[jsamuel]

imported trac comment
created: 2010-05-02 19:02:31
author: eibwen

Documentation should also clarify the distinction between specificity and strictness, and how various strictness settings affect rules of different specificity.

Defining the terms 2nd level domain, full domain, and full domain with port & protocol may be prudent; however, the above seems much more important, particularly as it is far too easy to confuse the two.

Reflecting on this, I think I want to run at full domain with port & protocol strictness, with #74 implemented to optionally be more liberal when granting permissions, but remain strict when evaluating permissions.

Given the above, recommend documenting inline directly on the preferences dialog tab.

Raising priority to high given the implications of the perceived differences between specificity and strictness, and the current dependence (absent #74) to change strictness to permit with less specificity.

[jsamuel]

imported trac comment
created: 2010-05-10 13:16:24
author: eibwen

Upgrading to defect (from task) with highest priority (from high)

The RP UI does not clearly or sufficiently define "strictness". This is largely due to the coupled behavior (UI and possibly code) between:

• whitelist policies at different specificity (including singular origin-to-destination policies) and
• strictness of site verification to said whitelist

This is a defect as users may readily (and unwittingly) change the latter to generate the former. This is further complicated with bugs such as #91 and #103 where the latter is down selecting to a subset of the former, effectively changing the whitelist unbeknownst to the user.

[jsamuel]

imported trac comment
created: 2011-02-20 13:46:01
author: eibwen

See [ticket:135#comment:2] and [https://developer.mozilla.org/en/nsIURI nsIURI].

Derived from '''./modules/DomainUtil.jsm''':

'''Base Domain''' -- Stated Example: requestpolicy.com
{{{
nsIIDNService.convertToDisplayIDN(
nsIEffectiveTLDService.getBaseDomainFromHost(
nsIURI_object.host, 0
), {}
);
}}}

See [https://developer.mozilla.org/en/nsIIDNService#convertToDisplayIDN%28%29 nsIIDNService.convertToDisplayIDN()] and [https://developer.mozilla.org/en/nsIEffectiveTLDService#getBaseDomainFromHost%28%29 nsIEffectiveTLDService.getBaseDomainFromHost()].

'''Full Domain''' -- Stated Example: www.requestpolicy.com
{{{
nsIURI_object.host
}}}

'''Full Address''' -- Stated Example: {{{http://www.requestpolicy.com:81}}}
{{{
nsIURI_object.prePath
}}}

Note that firefox strips the standard port from prePath. As such, rules created through the menu for the standard ports will not include the port, in seeming contradiction to the example; however, the port should still be honored. Further, a rule explicitly stating the standard port may not work with the current string comparisons.

See #104 for an example of confusion over this issue.

---

Now I have a solid understanding of what "strictness" is and does; however, there is still a need to document this for the average user.

[jsamuel]

imported trac comment
created: 2011-09-05 10:28:58
author: justin

Version 1.0 hopes to get rid of these strictness modes altogether.