-
Notifications
You must be signed in to change notification settings - Fork 17
conflict with HTTPS Everywhere #115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I've sent the attached patch to the email address on the HTTPS Everywhere page. The patch adds sending of rewrite notifications through the observer service. If this patch or something similar is added, RP can subscribe to the topic and use the information to allow requests that would have been allowed had they not be rewritten. |
This doesn't seem to be happening with Fx 3.7a6pre. It may be the case that a Fx change doesn't cause shouldLoad to be called in some of the situations it was before. Here's the RP output from a google search for "ipv6", then clicking on the wikipedia link. This is with RP 0.5.15a2 and HTTPS Everywhere 0.1.2. {{{ And with Fx 3.0.19 (same version of RP and HTTPS Everywhere): {{{ I initially noticed the problem with 3.6.3. It had the same behavior as 3.0.19. |
Actually, it could just be which order each extension's shouldLoad is called in. |
The !RequestPolicy changes to listen for the "https-everywhere-uri-rewrite" topic have been made in r359 and released in 0.5.16a1. (Oops, forgot to mention this ticket in the r359 commit message.) I wasn't able to successfully test on 3.0.19 because I couldn't get https_everywhere to work there. Testing on 3.6.10 with the patch provided to https_everywhere works. I haven't had a conflict between the two extension in the Fx 4 betas. I'll wait until https_everywhere is patched before closing this ticket. See https://trac.torproject.org/projects/tor/ticket/1574 for more info. |
The [https://www.eff.org/https-everywhere HTTPS Everywhere] extension rewrites HTTP requests to HTTPS equivalents. I've noticed this with link clicks (e.g. wikipedia links in google results). I haven't looked into the HTTPS Everywhere code yet, but it's safe to assume that RP doesn't realize the rewritten requests correspond to the original http:// link clicks and so is blocking them.
There are likely other requests besides link clicks that are affected. Some of these may get messy to deal with in a way that doesn't accidentally allow requests that shouldn't have been allowed.
The text was updated successfully, but these errors were encountered: