Filtering extensions might leak if HTTPS Everywhere is installed

See https://lists.eff.org/pipermail/https-everywhere/2012-April/001348.html (April 2012) (click "Next message: [HTTPS-Everywhere] compatibility with other add-on" to browse each message).

See also Some connections not blocked by RequestPolicy when HTTPS Everywhere is installed.

I don't use HTTPS Everywhere, so I'll leave it to you folks to research this further.

 

HTTPS Everywhere is a convenience beast. I have never had this problem with it.

 

A clarification: by "filtering extensions" I meant extensions like AdBlock Plus, Ghostery, RequestPolicy, etc.

 

I use all of those and have had no problems.

 

While using HTTPS-Everywhere I found connections being sent to it's main site. Call it "phoning home" if you will. Anyhow I took the liberty of blocking the entire range: 69:50.1.1 - 69.50.255.255

No ill effects with anything else so I wanted to make sure I had it covered, because it was using several addresses in that range. No idea what it was doing, but it's unnecessary.

I don't know if this is related to the OP or not.

 

The idea is that HTTPS Everywhere rewrites some HTTP to HTTPS, but the filtering extension "sees" the "before" HTTP instead of the "after" HTTPS, and so any unwanted "after" HTTPS connections are not blocked. According to the links in the first post, HTTPS Everywhere has functionality to allow filtering extensions to see the "after" HTTPS, but the filtering extension has to be specifically written to do so. RequestPolicy apparently does explicitly work with HTTPS Everywhere, but not perfectly; on the other hand, as of April 2012, the claim was made in the links in the first post that no other filtering extension besides RequestPolicy is explicitly working with HTTPS Everywhere to see the "after" HTTPS.

 

A brief look at the list of domains that HTTPS Everywhere rewrites reveals that potentially unwanted domains such as googlesyndication.com have rewrite rules. I'd not feel comfortable using HTTPS Everywhere with any of the filtering extensions unless tests have been done. Firefox users can test with its built-in Network Monitor.

 

I did some tests with Firefox (Windows 7 x64) on test page http://www.genengnews.com/gen-news-...when-genes-arise-from-noncoding-dna/81249416/. I enabled the HTTPS Everywhere rule for doubleclick.net, which is disabled by default. I then tested Ghostery, Adblock Plus (EasyList + EasyPrivacy), and RequestPolicy v1.0.0b3 in isolation on the test page. Each of these extensions blocked requests to doubleclick.net . Hopefully someone will carry out more tests.

 

[CHROME] conflict with other extensions using WebRequest API (Ghostery, AdBlock Plus, etc)

 

Ghostery developer's statement: https://www.wilderssecurity.com/showpost.php?p=2334465&postcount=45.