You can easily reproduce the problem on any page by simply altering a
forms action attribute to use the HTTP scheme with the developer console
(in Firefox and Chrome). I couldn't find a public available website with
the explained issue that also has a ruleset defined. I created the
following test page, although it doesn't match any HTTPS Everywhere
ruleset it might still be useful.
https://movlib.org/https-to-http-warning.html
The problem only targets forms. My proposition was to search only for
action attributes. Something along the lines:
for (var i = 0; i < document.forms.length; i++) {
document.forms[i].action = document.forms[i].action.replace("http://";
+ httpsEverywhere.currentDomain, "//" + httpsEverywhere.currentDomain);
}
An alternate approach could be to simply intercept form submissions and
check the target URL for above condition and rewrite it before the
actual submission occurs. This would help with injected forms.
Richard
On 8/20/2014 8:30 PM, Jacob S Hoffman-Andrews wrote:
I wasn't able to reproduce this prompt on Tumblr, in a fresh FF31.0
profile with only HTTPS Everywhere installed. Is there another site
that reproduces reliably?
I would be mildly in favor of search the page after load for form
elements where action points to an insecure URL that we can rewrite.
I'm more on the fence about rewriting the whole page. It might enabled
us to re-enable some rulesets that were disabled for MCB, but it would
work pretty inconsistently because of JavaScript insertions and runs
the risk of moving HTTPS Everywhere from "slow" to "really slow."
On 08/20/2014 02:27 PM, Nick Semenkovich wrote:
Chrome now warns about this too, per:
https://code.google.com/p/chromium/issues/detail?id=253249
Looks like it's on the beta channel (M37) which will probably hit
stable in ~one month.
On Wed, Aug 20, 2014 at 1:10 PM, Richard Fussenegger, BSc
<[email protected] <mailto:[email protected]>> wrote:
This topic was already raised once in the past (see
https://lists.eff.org/pipermail/https-everywhere/2011-June/000914.html)
but I'd like to discuss it again because it's pretty annoying and
might even be disturbing to new users of the extension.
I found that the main problem are websites that have the scheme
hard coded on form action attributes. I therefore propose that
the extension could parse the page and rewrite any URL pointing
to the current domain that has the http scheme set instead of the
secure one. I'm also willing to produce this feature but I don't
know if this is even possible with an extension like
HTTPS-Everywhere. You might be able to answer this or maybe you
have some arguments why this would be a bad idea.
Richard
_______________________________________________
HTTPS-Everywhere mailing list
[email protected]
<mailto:[email protected]>
https://lists.eff.org/mailman/listinfo/https-everywhere
--
Nick Semenkovich
Laboratory of Dr. Jeffrey I. Gordon
Medical Scientist Training Program
School of Medicine
Washington University in St. Louis
https://nick.semenkovich.com/
_______________________________________________
HTTPS-Everywhere mailing list
[email protected]
https://lists.eff.org/mailman/listinfo/https-everywhere
_______________________________________________
HTTPS-Everywhere mailing list
[email protected]
https://lists.eff.org/mailman/listinfo/https-everywhere
