InformAction Forums

Let us assume I have a rule which trusts a domain for HTTPS only and HTTPS Everywhere rewrites an HTTP request to that domain to HTTPS.
Does NoScript see the original HTTP or the rewritten HTTPS request? Has the order of installation any impact in that regard?

I have not actually looked into the code of HTTPS Everywhere, but I would assume that it's not "rewriting" any requests but rather redirecting them. In which case there is really not anything conflicting and the order would not matter.

I do use HTTPS Everywhere daily with NS and have not noticed any issues.

skriptimaahinen wrote:I have not actually looked into the code of HTTPS Everywhere, but I would assume that it's not "rewriting" any requests but rather redirecting them.

Correct. There's no issue. And they're both integrated in the Tor Browser by default.

Thanks for your answers! I am very confident about both extensions and "rewriting" may have been the wrong technical term. I just wanted to know, if a change of HTTP to HTTPS of requests by HTTPS Everywhere has an impact on whether they are being blocked or allowed by NoScript (I set domains permanently to TRUSTED for HTTPS only), and if the installation order makes a difference in that regard.

For experts who know how webextensions work and know if these extensions work in parallel seeing all the same or in series seeing the result of the previous plugin or work in a different way, the question may be trivial. However, don't forget that this isn't obvious to everyone.

In the meantime I have made a small experiment, however meaningful it may be: I have installed both extensions in two fresh profiles in reversed order. I disabled all restrictions globally to see the whole beauty and loaded http://www.theliteraryreview.org/ in both profiles. NoScript showed identical lists. The list with disabled HTTPS Everywhere, however, was different and showed less HTTPS entries.

I see your point on the installation order, so I too ran some tests on the page you provided, but did not find any difference depending on which extension was enabled first.

However I did notice one thing that I had not considered. The Googleapis connection shown in the NS popup is http, though HTTPS Everywhere has a rule to upgrade it to https. Now this is because NS sees only the connection the page is attempting to make, not what other extensions intend to do with the connection. The installation order does not change this. Unfortunately this does mean that if you have allowed only https connections to Googleapis, the scripts wont be loaded as NS will block the initial http connection attempt. However, if you do allow http connections for Googleapis, the actual connection will get upgraded to https by the HTTPS Everywhere. This is OK for NS, as the "red" rule actually allows both http and https connections (while the "green" only https). Unfortunately the upgrade to https is not conveyed by NS in any way and you need to use other network tools to check this.

And those entries that switch the secure status when HTTPS Everywhere is disabled/enabled? For example the bootstrapcdn.com is used to fetch fonts. And that request originates from the CSS file fetched from there. Now, NS does not handle or block CSS files, so the request is left to HTTPS Everywhere alone which fetches the file over https. When browser parses the CSS file and encounters the font-rules, it will try to fetch them. Now apparently the font-urls are defined as relative, so depending on which type of connection the CSS file was fetched over, the font-request will inherit the protocol. So HTTPS Everywhere does not need to upgrade the font-fetch separately and NS sees the protocol correctly.

Hope this answers something.

skriptimaahinen wrote:Hope this answers something.

Many thanks, @skriptimaahinen, for your detailed and insightful answer, that is exactly what I wanted to know.