What are cross-site requests?

Cross-site requests are requests that your browser is told to make by a
website you are visiting to a completely different website. Though usually
legitimate requests, they often result in advertising companies and other
websites knowing your browsing habits, including specific pages you view
throughout the day.

Cross-site requests are also used in attacks on users who are browsing the web.
Among the attacks that cross-site requests are used in,
they are particularly dangerous with
Cross-Site Request Forgery
(CSRF) attacks
where your browser is told to make a request to another website and that other
website thinks you (the person) meant to make the request.

How does RequestPolicy help you where NoScript does not? RequestPolicy will protect
you from various attacks that NoScript will not
(such as CSRF attacks, though there some special cases that NoScript protects against)
and will give you greater privacy while browsing.

Also, RequestPolicy will give you finer-grained control over JavaScript and plugins when you use it
with NoScript. For example, if you whitelist a domain with NoScript to allow it to run JavaScript, then that domain
will also be allowed to run JavaScript when you are on any other site that you have whitelisted with NoScript.
RequestPolicy makes sure that when it is JavaScript from a third-party site, it will
still be restricted unless you have allowed those cross-site requests.

Conversely, NoScript gives you protection that RequestPolicy does not.
RequestPolicy will not keep you safe from malicious JavaScript or vulnerable plugins on the current
site you are visiting, So, NoScript is absolutely essential for browser security.

Having two separate tools that each do their specific jobs well is the best approach.
NoScript is an amazing extension and is
absolutely essential (like RequestPolicy) to using Firefox securely. It is best to use both
RequestPolicy and NoScript.

Which kinds of requests are blocked?

By default, any request the browser makes from the current site a user is on to a third-party site
is blocked. Users can then whitelist specific sites (with various levels of granularity)
to allow requests they approve of. The types of requests that are blocked include:

Note that
OCSP queries
and
CRL updates
are not blocked. This means that RequestPolicy will not interfere with your browser's attempts to
determine whether SSL certificates have been revoked.

Content of the current page that is from a different site.

Various tags in an HTML page tell the browser that more content
is needed to display the current page. Normally, the browser immediately
makes requests to third-party sites to obtain this content.
The content can include images, JavaScript files, style sheet files, and many others.

Redirections from the current site to a different site.

Redirects tell your browser to load an entirely different website address than the one
you are on or requested. Redirections can be caused by JavaScript, META refresh tags, and Location headers.

Content a page tells your browser to "prefetch".

Some browsers, such as Firefox, allow any webpage to tell your browser to load
other pages in the background. This is intended to allow a website to improve
your browsing experience by guessing which pages you are likely to visit next so
that those pages will load faster when you visit them.

In Firefox 3.1, DNS prefetching was also added. DNS prefetching is where your browser
tries to speed up future requests by resolving the IP
address of every link on webpages you visit (just in case you decide to click on them).

For more information on DNS prefetching in Mozilla browsers (such as Firefox), see the
Pat McManus' blog post.

How are sites classified as "third-party sites"?

A site is considered a third-party site if its registered domain name is
different than the registered domain of the page that initiated the request. For example, the domains:

example.com

www.example.com

a.b.c.example.com

all have the same registered domain name (example.com) and so are considered the same site.

There is some risk posed by this default, but this level of
granularity is the one with the optimal tradeoff of usability for privacy and security according
to the needs of most users.

If you want protection against attacks that use subdomains, you can enable more strict site
classification through the RequestPolicy preferences. Instead of classifying sites as the same based on
the registered domain, you can choose to base it on the full domain (e.g. a.b.c.example.com)
or even on the complete protocol + domain + port (e.g. http://a.b.c.example.com:81).

What changes to my browser are left behind after uninstalling RequestPolicy?

By default, when you uninstall or disable RequestPolicy, all changes RequestPolicy made
to your browser's settings will be undone. Primarily this means that your default prefetching
settings are restored to the browser's default settings. That is, DNS and link prefetching will be
re-enabled when you uninstall RequestPolicy.

However, if you have gone to RequestPolicy's preference window and under the "Advanced" preferences you
have disabled the options to "Restore default when RequestPolicy is uninstalled", then your browser's default
prefetch settings will not be restored when you disable or uninstall RequestPolicy.

Privacy note: RequestPolicy will leave various RequestPolicy-specific settings and configuration
files in your browser profile even after it has been uninstalled. For example, your whitelist will
still be available to other people who have access to your computer.
This is a known bug (see ticket #227).
A future version of RequestPolicy will
attempt to delete all RequestPolicy whitelist data, etc., when RequestPolicy is uninstalled.

In the mean time, if you are looking to remove all
RequestPolicy-related files and configurations, you should go to the page about:config in your
browser and "reset" every preference that starts with
"extensions.requestpolicy". Starting with RequestPolicy version 0.6,
you also should delete the "requestpolicy" directory which was created in your browser's
profile directory (if you used multiple browser profiles, you will need to locate the one where you
had installed RequestPolicy). If you have questions about verifying that you have correctly removed
RequestPolicy data, please don't hesitate to contact us.

Can websites detect that you are using RequestPolicy?

Is there a RequestPolicy for Chrome?

Not yet. Until 2012, Google Chrome did not have the necessary APIs so that
extensions could reliably block requests. Now that they've added those, there
just needs to be someone with hundreds of hours of time to figure out if
those APIs are sufficient and to try to port RequestPolicy to Chrome. :)