HTTPS Everywhere Atlas

Embedded content loaded from third-party domains (for example, YouTube, Google Analytics, ad networks, or CDNs) may also be affected. You can test this by loading the web page in question in a browser with HTTPS Everywhere installed and pulling down the HTTPS Everywhere rules menu. This will show a list of HTTPS Everywhere rules that were applied as the page was loaded, including rules that might have affected embedded content from other domains.

The stable (as yet unreleased) branch contains the following rule that is disabled by default (so very few users' browsing is likely to be affected by their action):

<!--
Disabled because:

Currently Deezer's website *generally* redirects as follows:

	https://deezer.com/      301 Moved Permanantly (to www.deezer.com)
	https://www.deezer.com/  302 Found             (to plain-http URL)
	http://www.deezer.com/   200 OK

That is, if we apply an http -> httpS rule to [www.]deezer.com most paths will
end up being loaded via plain-http anyway.  The one (known) exception is the
path /ajax/gw-light.php which Deezer's servers do not redirect to plain-http.

If we apply the http -> httpS rule for [www.]deezer.com, the top-level document
ends up being redirected to load via plain-http, but then makes non-redirected
httpS XHR POST requests to gw-light.php.  Since it makes these XHR requests
without requesting cross-origin permissions the requests fail.  The main
symptom of this failure is that clicking on the left-hand navigation bar does
nothing.
--><ruleset name="Deezer.com (Buggy)" default_off="breaks left-hand navigation bar links">

	<!--	Direct rewrites:
				-->
	<target host="deezer.com"/>
	<target host="cdns-files.deezer.com"/>
	<target host="www.deezer.com"/>

<!--
We can't currently add the following since the served certificates are not
valid for these domains.

	<target host="cdn-images.deezer.com" />
	<target host="e-cdn-files.deezer.com" />
-->

	<rule from="^http:" to="https:"/>

</ruleset>

Deezer.xml    File a bug

The release branch contains the following rules that are disabled by default (so very few users' browsing is likely to be affected by their action):

<!--
Disabled because:

Currently Deezer's website *generally* redirects as follows:

	https://deezer.com/      301 Moved Permanantly (to www.deezer.com)
	https://www.deezer.com/  302 Found             (to plain-http URL)
	http://www.deezer.com/   200 OK

That is, if we apply an http -> httpS rule to [www.]deezer.com most paths will
end up being loaded via plain-http anyway.  The one (known) exception is the
path /ajax/gw-light.php which Deezer's servers do not redirect to plain-http.

If we apply the http -> httpS rule for [www.]deezer.com, the top-level document
ends up being redirected to load via plain-http, but then makes non-redirected
httpS XHR POST requests to gw-light.php.  Since it makes these XHR requests
without requesting cross-origin permissions the requests fail.  The main
symptom of this failure is that clicking on the left-hand navigation bar does
nothing.
--><ruleset name="Deezer.com (Buggy)" default_off="breaks left-hand navigation bar links">

	<!--	Direct rewrites:
				-->
	<target host="deezer.com"/>
	<target host="cdns-files.deezer.com"/>
	<target host="www.deezer.com"/>

<!--
We can't currently add the following since the served certificates are not
valid for these domains.

	<target host="cdn-images.deezer.com" />
	<target host="e-cdn-files.deezer.com" />
-->

	<rule from="^http:" to="https:"/>

</ruleset>

File a bug

The HTTPS Everywhere developers welcome corrections and updates to rules. Please see our developer information and documentation of the ruleset format. If filing a bug in the Tor Project's Trac bug tracker, you can use the shared username and password cypherpunks / writecode; please ensure that the bug is marked as applying to HTTPS Everywhere.

Information current as of:


current release ff5b4642b 2019-06-27 14:21:20 -0700;
next release c0a0e49cd 2019-10-16 02:46:21 +0300;