Feature Request: Filtered/Partial/Anonymous Allowing of Requests

[CorvusCorax]

Issue: Many web pages rely on active content to work correctly and need certain Javascript libraries. However a questionable practice is to load the required JS libraries from 3rd party sites instead of providing them themselves. (Popular example: ajax.googleapis.com) This

• Introduces a security flaw for the web page if the 3rd party script source is compromised
• Allows these 3rd party servers to track all the users.

Now in theory a privacy aware request policy user would have to block these 3rd party requests, because they do allow extensive user tracking. Doing so however often breaks the webpage in a non-recoverable way, so the user sometimes has no choice but to allow it.

Request Policy only lets you

• deny a 3rd party request altogether
• allow a 3rd party request completely, including referrer and session information and other parameters

Suggested improvement:

• Provide a third option, which allows the 3rd party request but in an anonymized way: --> No Referrer or a fake referrer is sent instead of the requesting page (for example https://localhost/) --> Access to cookies and other persistent user based information is disabled for the request (similar to the restrictions of private browsing) --> Browser information in the request header is altered/stripped, (user agent/browser version, languages, operating system, and everything else that can be used for fingerprinting) --> Caching TTL information provided by the server is deliberately ignored and replaced by a long default so subsequent requests can be served from browser cache whenever possible (without even checking with http HEAD of course) --> Optional: strip additional data sent from the primary page to the 3rd party server, such as some or all GET parameters in the URL which could help track the user. (Would likely need tweaking on a per site base, likely not worth it)

[CorvusCorax]

Just thought of a possible solution. There are already solutions to "anonymize" web requests. On one hand there's extensions that do that. But there's also local proxies like "privoxy" (often used in combination with TOR) to take care of that.

maybe a quick and dirty implementation of this would be to send these "filtered" requests through a proxy server instead of a direct connection. That should be much easier to implement than all the detailed request handling, and a dedicated program can then be used to handle them - with its own black and whitelists and rules.

request policy would then act as a frontend, routing requests either

• through Firefox default connection (direct or system wide proxy)
• through a privacy enabled custom proxy service (to be set somewhere in advanced settings)
• not at all (blocked)

[Watilin]

I support this idea, but a the same time I think we’re tripping on the edge of Request Policy’s scope.

Take a look at NoScript for example: an add-on to block JavaScript and other active content. This is its main purpose. But at the same time it demonstrates a case of featuritis: it comes with an XSS filter, a clickjacking protection, and that “Application Boundary Enforcer” thing, a sort of complicated web firewall which is activated by default and confuses users. NoScript has been criticized for reaching out of its scope because of this.

I like add-ons that do one job and that do it well. This proxy solution you’re proposing is a good idea indeed, but confusing for newcomers, who already have to learn the mechanics of Request Policy.

I agree some 3rd-party requests need to be “cleaned up”, but I think it’s not Request Policy’s job. By entrusting another add-on with this task, we allow both Request Policy and this other add-on to be more efficient and not grow an overly complex codebase.