Https-everywhere: Should nonexisting www subdomains have rewriting to no-www subdomain with HTTPS?

[dimadin]

I have tried to find this in Ruleset Style Guide and elsewhere but I can't find anything. Problem is that there are sites on subdomain who don't have www subdomains.

For example, e-bank portals of two Serbian banks:
https://online.bancaintesa.rs/
https://online.telenorbanka.rs/

Or, another way, having working www subdomain but not working without www. Example, major Serbia telco:
https://www.mts.rs/ (https://mts.rs/ is not working).

Non tech savvy people often type www in front of hostname, I have seen that myself many times over the years. And in FAQ of HTTPS Everywhere it says:

Users are only protected against the SSL stripping attack if their browsers don't even try to connect to the HTTP version of the site even if the site would have redirected them to the HTTPS version. With HTTPS Everywhere, the browser won't even attempt the insecure HTTP connection, even if that's what you ask it to do.

So this leaves me confused: considering goal of HTTPS Everywhere, we should cover case with www subdomain (or vice versa) for these kind of sites (they deal with highly sensitive information and require login), but on the other hand <rule from="^http:" to="https:" /> won't work.

In any case, I believe situation like this should be covered in documentation for future reference.

[jeremyn]

Browsers by default already try simple variations on a given domain if the original input domain doesn't exist. For example, Firefox's behavior is documented at https://support.mozilla.org/en-US/kb/search-web-address-bar#w_domain-guessing . So there is no need for HTTPS Everywhere to do that itself.

More generally, we don't like to do "helpful" rewrites that are not strictly related to adding HTTPS. For example, this goal motivates our rule against snapping redirects at CONTRIBUTING.md#snapping-redirects.

Does that help?

[dimadin]

Browsers (at least Firefox, that I'm using) won't try guessing here because there is www in front.

So, I guess that we shouldn't have this kind of rewrites? Should we note that?

[jeremyn]

We should not rewrite www to ^ if ^ exists and www does not. (EDIT: This sentence was originally wrong, I've fixed it.)

We don't need to document this in CONTRIBUTING.md or elsewhere. In practice I don't think I have ever seen anyone try to do this. Our documentation is already very long and we don't need to discuss purely hypothetical problems.

@gloomy-ghost @J0WI Can I get a quick second opinion on whether I'm right here?

[cschanaj]

AFAIK, each target is required to have valid DNS records in order to pass the fetch-test (#11187), so I believe that such a practice is not encouraged. Moreover, we should avoid snapping redirects, as per the following line in CONTRIBUTING.md

..., such rulesets are less obviously correct and require more scrutiny. And the redirect can go out of date and cause problems. HTTPS Everywhere rulesets should change requests the minimum amount necessary to ensure a secure connection.

[pipboy96]

I believe that current rules are that if domain is NXDOMAIN according to authoritative NS, it can't be included either as a target or as redirect destination.