Of these, historyRequests appears to be generated on demand and scoped to a singular back/fwd; however, the implementation is dependent upon the other objects, which do not appear to be of limited scope.
The recorded requests not appear to be removed except in limited circumstances such as policy change. Consequences include (but are not necessarily limited to):
Acts much like a data logger...
Does not appear to honor "Clear Recent History"
The object grows quite large after extended, many-tab, multi-window browsing sessions
Effect of session restore unknown -- ''might'' continue to grow across restored sessions
And yet, the context of this information is limited to page load, not browsing session. Granted, some retention beyond page unload may be necessary for cached requests; however:
Policy change does not appear to affect cached pages (although it may not be appropriate to force a reload either)
When the cache is cleared, corresponding request data should be cleared
Further, this data is keyed based on -- at most -- only the scheme, domain, and port. Whether requests (eg ajax) in one tab should be shown in another merely because the user has the same URL in both tabs should be considered. Yet this then complicates cached loads, eg:
User loads page; page makes standard requests
User triggers ajax; page makes additional non-standard requests
User loads page from cache in new tab; requests shown are:
a. "standard" requests only?
b. all requests -- even non-triggered ajax?
Further, need to determine cache interaction for non-top level pages. For example, a frameset page that itself is non-cached; however, it loads frames that had been cached, either as browsed directly or as a frame src.
Further still, the cache can be preserved across browsing sessions. How and/or is this implemented, and should this be? What about cache and browsing history protections (eg history detection via css styling) versus this implementation? If this were to be implemented, storing cached requests (eg as a pref -- or by other means) would only further correlations between the extension and a data logger.
At this point, it seems there are quite a few questions to be answered, and research may reveal several more; however, this seems necessary to determine proper scoping and handling of these requests.
Issue by jsamuel Thursday Dec 22, 2011 at 19:02 GMT Originally opened as https://github.com/RequestPolicy/requestpolicy/issues/245
There are a number of objects that store request data, including:
_rejectedRequests : {}, _allowedRequests : {}, _historyRequests : {}, _faviconRequests : {},
Of these, historyRequests appears to be generated on demand and scoped to a singular back/fwd; however, the implementation is dependent upon the other objects, which do not appear to be of limited scope.
The recorded requests not appear to be removed except in limited circumstances such as policy change. Consequences include (but are not necessarily limited to):
And yet, the context of this information is limited to page load, not browsing session. Granted, some retention beyond page unload may be necessary for cached requests; however:
Further, this data is keyed based on -- at most -- only the scheme, domain, and port. Whether requests (eg ajax) in one tab should be shown in another merely because the user has the same URL in both tabs should be considered. Yet this then complicates cached loads, eg:
Further, need to determine cache interaction for non-top level pages. For example, a frameset page that itself is non-cached; however, it loads frames that had been cached, either as browsed directly or as a frame src.
Further still, the cache can be preserved across browsing sessions. How and/or is this implemented, and should this be? What about cache and browsing history protections (eg history detection via css styling) versus this implementation? If this were to be implemented, storing cached requests (eg as a pref -- or by other means) would only further correlations between the extension and a data logger.
At this point, it seems there are quite a few questions to be answered, and research may reveal several more; however, this seems necessary to determine proper scoping and handling of these requests.