RequestPolicyContinued / requestpolicy

a web browser extension that gives you control over cross-site requests. Available for XUL/XPCOM-based browsers.
https://github.com/RequestPolicyContinued/requestpolicy/wiki
Other
252 stars 35 forks source link

Request Data Retention -- Privacy, Object Size, etc. #245

Open msxfm opened 10 years ago

msxfm commented 10 years ago

Issue by jsamuel Thursday Dec 22, 2011 at 19:02 GMT Originally opened as https://github.com/RequestPolicy/requestpolicy/issues/245


imported trac ticket
created: 2011-07-06 11:21:58
reporter: eibwen

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:

  1. User loads page; page makes standard requests
  2. User triggers ajax; page makes additional non-standard requests
  3. 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.

msxfm commented 10 years ago

Comment by jsamuel Thursday Dec 22, 2011 at 19:02 GMT


imported trac comment
created: 2011-07-06 11:57:33
author: eibwen

As an alternative, should we merely indicate "page loaded from cache" for cached requests and only log new requests that go through shouldLoad()?