Headers Tab Usage

This tab allows the spoofing, modifying and blocking of different header options

Explanation of options

Standard Options

• Disable Authorization header - Prevents the authorization header from being sent by the browser. Many browsers allow web sites to send hidden authentication data to third party sites. Example:

  This may either happen directly on the current page or in an iframe, and does NOT need JavaScript. If additionally iFrames and JavaScript are used, even the currently loaded page may get your ID. This data is deleted when the browser is closed, but, except for this, has the same effect as third party cookies. Note: This option can break some sites

• Enable DNT (Do Not Track) - This will send the DNT header with a value of 1 indicating that the user does not want to be tracked. The browser user has no control over whether the request is honoured or not by websites. See the DNT wikipedia page for more information.

• Send Spoofed If-None-Match headers - As ETags are cached by the browser, and returned with subsequent requests for the same resource, a tracking server can simply repeat any ETag received from the browser to ensure an assigned ETag persists indefinitely. To combat this we send a random alphanumerical string that never matches the resource and the browser is forced to redownload the item at every request. I would like to improve on this so we eventually send nothing but have not been able to get a better solution thus far . You can test it at http://lucb1e.com/rp/cookielesscookies/

• Spoof Via header - This is optional and sends a spoofed but valid random IP address or a user specified one. The via header is similar to the X-Forwarded-For header. It will make it look like the request was routed through a gateway.

  The Via general-header must be used by gateways and proxies to indicate the intermediate protocols and recipients. For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses HTTP/1.1 to forward the request to a public proxy at nowhere.com, which completes the request by forwarding it to the origin server at www.ics.uci.edu. The request received by www.ics.uci.edu would then have the following Via header field:

  Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

  Note: this will not hide your IP but it can make it look like you used a gateway or proxy

  • Random - A random IP address will be chosen.

  • Custom - A custom IP address can be specified.

    • It is validated in real time.

.

A green border indicates a valid IP and a red border indicates an invalid IP. In the case of an invalid IP. The last known valid IP will be used.

• Spoof X-Forwarded-For header - This is optional and sends a spoofed but valid random IP address or a user specified one. The X-Forwarded-For (XFF) HTTP header field is a de facto standard for identifying the originating IP address of a client connecting to a web server through an HTTP proxy or load balancer . for more information see https://en.wikipedia.org/wiki/X-Forwarded-For

  Note: this will not hide your IP but it can make it look like you used a proxy

  • Random - A random IP address will be chosen.

  • Custom - A custom IP address can be specified.

    • It is validated in real time. A green border indicates a valid IP and a red border indicates an invalid IP. In the case of an invalid IP. The last known valid IP will be used.

• Disable Referer - If checked this prevents the browser from sending the Referer header. The Referer request-header field allows the client to specify the address (URI) of the resource from which the URL has been requested.

• Spoof Source Referer - Wikipedia referer spoofing page

  • unchecked - send the referrer (if it has not been disabled by the option above).
  • checked - spoof the referrer and use the target URI instead.

• Referer X Origin Policy

  • Always send - always send referrer (default).
  • Match base domain- only send if base domains match.
  • Match host - only send if hosts match

• Referer Trimming Policy - This option specifies if the referer header is trimmed and how it is trimmed.

  • send full URI
  • scheme, host, port and path
  • scheme, host and port

Accept Header Options

The accept headers are enabled by default. This means that each of the headers will be used when a profile is selected. The header values are defined in the profile and match that profile.

Note: It is highly recommended to leave these enabled so the headers sent by your browser match the rest of the profile. If you disable these you will stand out if using a non firefox profile as the headers will not match

• Spoof Accepted Documents - Uses the Accept header defined in the current profile
• Spoof Accepted Encodings - Uses the Accept-Encoding header defined in the current profile
• Spoof Accepted Language - Uses the Accept-Language header defined in the current profile.

You can test headers at http://pgl.yoyo.org/http/browser-headers.php

Note: RAS profiles have support for different Accept language header values so sites will display a localized version of a page if it is available. For now only firefox based browsers have the choice of accept language headers for different languages. All other browsers still use US English. The fallback to US English will occur naturally so users can select any available language and it will be set if the current profile supports it.

I could easily find the correct language headers for different regions for firefox but I rely on users for the other browsers since I could not find them. If you tell me what your native accept language headers are I will add them in. Note they must be the default version of the browser for your region this is so I can be sure the headers are the default versions and will not make the user stand out. So if you're in Argentina for example download Chrome and visit http://pgl.yoyo.org/http/browser-headers.php and tell me the accept language header.

See RAS profiles explained to see how the accepted languages fit into a profile