Skip to content
This repository has been archived by the owner on Apr 9, 2021. It is now read-only.

Whitelist Tab Usage

Jump to bottom
dillbyrne edited this page Nov 16, 2016 · 6 revisions

This section allows specifying a whitelist profile and sites for which it is applied

Whitelist Tab

Explanation of options

  • Enable whitelist support - Since the whitelist will add to page load times. (times can vary depending on the size of the list). An option is provided for user to disable the whitelist so that the checks can be skipped and page load time is not affected for users who do not wish to use the whitelist.

The whitelist is disabled by default and the user must explicitly enable it using a checkbox on the whitelist tab.

  • Whitelist Profile

The whitelist browser profile will be used for all URLs in the whitelist instead of the currently spoofed profile. If the real profile is enabled and the current url is in the whitelist then the real profile will be used instead but in all other cases when visiting a whitelisted site with a spoofed profile the whitelist profile is used. If the real profile is used certain options can still be whitelisted such as permitting the canvas for example.

The user can specify a whitelist using a dropdown item on the whitelist tab. Whitelist profile 1

whitelist profile 2

the profile options are

  • UserAgent
  • AppCodeName
  • AppName
  • Appversion
  • Platform
  • Vendor
  • VendorSub
  • OsCpu
  • Accept Defaults Header
  • Accept Encoding Header
  • Accept Language Header

When support for this feature becomes available it will use the latest windows version of firefox for the default values of the whitelisted profile which can then be changed by the user.

  • Whitelist Rules

The whitelist currently uses a JSON format that is validated in realtime. A green border means the json is valid and has been loaded into the addon. A red border means the json is invalid and the last known valid configuration will be used for requests. Note that if an invalid entry was entered and the panel was hidden ( if the user clicked outside the addon) then when the whitelist panel is presented again it will show the last valid state to the user.

Example whitelist validation

Note

The whitelist is supposed to be used for problematic sites. While I have tested it with a couple of hundered entries. It is not recommended to use lots of entries as it will slow down page load times simply due to all the checking that has to be done to make it work as intended. This should not be a problem as most users should not have that many problematic sites and if they do perhaps RAS is not the tool for them. I say this because when a site is whitelisted it will use the specified whitelisted profile and will therefore not benefit from the regular profile changes.

The whitelisted profile can be configured by the user, but it is shared for all whitelisted sites to ensure a compatible fallback. I will not be making an option to specify a profile per site

Whitelist Syntax and Options

  • Adding URLs

A whitelist entry must contain a url. The URL can be a subdomain like mail.google.com or a base domain like google.com or a full URL google.com/only_match_this_exact_url. You don't need to include www or http(s) in the whitelist url. RAS will check if the whitelist URL string is in the whitelist. For best results and protections by RAS specify only what you need.

  • URL options

In addition to specifying urls in the whitelist. Options can be added to each entry to customize how it handles certain headers and javascript options. These options will not work without a specified url for the site in question. The options take the form of

"options":["option1name","option2name","optionNname"]

So far it has the following options. The options listed are the names to use in the whitelist

  • Header Options

    • referer - It will send the referer header to the site if you have referers otherwise blocked
    • xff - It will not send the spoofed X-Forwarded-For header if you have set to send it
    • via - It will not send a spoofed Via header if you have set to send it
    • ifnonematch - It will not send the spoofed If-None-Match header if you have set it to send it
    • authorization - It will enable to send the Authorization Headers if you have disabled it

  • Javascript Options

    • winName - It will disable window.name protection on the site if you have it set otherwise
    • canvas - It will allow canvas support if you have it disabled otherwise.
    • screen - It will not spoof the screen and window dimensions if set
    • plugins - It will allow navigator.plugins array to be read if you have blocked plugins
    • date - It will not spoof the date and timezone offsets if set (Note Date spoofing still needs to be reimplemented due to script injection braking in ff45)

  • Examples

    • On site1.com - Canvas support will be permitted (if it is blocked). A spoofed X-Forwarded-For header will not be sent. The screen dimensions will not be spoofed and the window.name protection will be disabled if it was enabled.

    • On site2.example.com - The date and timezone will not be spoofed. A referer header will not be blocked. A spoofed if-none-match header will not sent . A spoofed via header will not be sent.

    • On subdomain.site3.com/page.html only the whitelisted profile will be used. All other options set by RAS will remain the same.

[
{"url": "site1.com","options": ["canvas","xff","screen","winName"]},
{"url": "site2.example.com","options": ["date","referer","ifnonematch","via"]},
{"url": "subdomain.site3.com/page.html"}
]

In addition to the whitelist browser profile being used for these sites the above options will be applied

Clone this wiki locally