[HTTPS-Everywhere] Downgrade rules vs exclusions

[Seth David Schoen]

Jacob S Hoffman-Andrews writes:

> In trivial-validate.py we get a lot of warnings about rules that
> redirect to HTTP. This seems like a normal thing, since some parts
> of sites may not support HTTPS. But there's an alternate mechanism,
> exclusions. Can anyone fill me in on why both mechanisms exist?
> Would it be correct to reformulate all downgrade rules as exclusions
> instead? Two examples below.

Peter reminded me that these exist because sometimes a site itself, when
accessed over HTTPS (in a way that the site developer isn't expecting)
will render references to other HTTPS resources that don't exist.

A simple example would be if a site has a top-level page that contains

<li><a href="/login">Log in</a></li>
<li><a href="/about">About us</a></li>

Perhaps the /login resource is available in HTTPS but the /about resource
isn't (and produces an HTTP 403 when visited, or something).  In that
case, if we rewrite the top-level page to HTTPS, we've caused the site
to create a valid secure link to /login (which we want!) but an invalid
secure link to /about (which will annoy users).  In that case, we can use
a downgrade rule to send those users to the insecure page that we know
will work, instead of showing them the error.  There's no obvious way to
produce equivalent functionality with an exclusion, because the problem
is an indirect result of our rewriting, rather than a direct result of it.

-- 
Seth Schoen  <schoen at eff.org>
Senior Staff Technologist                       https://www.eff.org/
Electronic Frontier Foundation                  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x107