Rejecting targets without a working HTTP 200/3XX URL

[jeremyn]

I've started rejecting targets where we can't find even one working HTTP 200 URL, for example see #7636 (comment) . Often both HTTP and HTTPS return the same non-200 code, like 403. My suggestion is to note these URLs under a new error category No working URL known.

@fuglede @gloomy-ghost @Hainish @J0WI What do you all think?

EDIT: We should count HTTP 3XX URLs as well as 200. I've updated the issue description.

[jeremyn]

I noticed @gloomy-ghost 's comment in #7481 (comment) , where they wrote:

I'm quite aggressive on adding targets. And I think that these kind of risks are still acceptable since they are easy to fix as well.

Problems caused by adding internal URLs may not be easy to fix. Internal URLs that are used to manage corporate firewalls, communications, VPNs etc may depend on complex applications from a third party. If a sysadmin finds a problem with one of these sites, they are going to spend a bunch of time narrowing the problem down to HTTPS Everywhere and then just disable it. If it ends up wasting enough of the third party vendor's (Dell, Cisco etc) time, the vendor will simply advise their customers not to use HTTPS Everywhere. The odds that someone from the third party will contact us to work out the problem are very low.

Another problem is that the "easy to fix" approach means we are willing to disable rules because of problems we can't test just because someone asks us to do that. That opens an easy attack path.

[gloomy-ghost]

The targets I asked to add in #7481 already have working https index pages (for login). So the risks of adding these targets should be similar with adding non-English sites which require logins. (I don't know will the other reviewers apply accounts to test sites like those sites though) Also the reporting rate of non-English sites will be even lower than internal sites in English because internal site's users at least have good English skills. e.g. My first PR to HTTPS Everywhere #6765, fixed a login problem of an Alexa top-100 site in China, which has existed for more than 2 years.

[jeremyn]

I'm not sure how to measure risk here. I think that it's more likely a corporate-type web application will have trouble than a site intended for the general public, and that it's less likely a corporate user will report a problem than a general public user.

[jeremyn]

We should count HTTP 3XX URLs as well as 200. I've updated the issue description. I've updated the issue description and first comment.

[gloomy-ghost]

I suggest to add a subdomain if it has the subdomain in certificate (not a wildcard) even we can't find any tests.

[jeremyn]

A subdomain being in the certificate just means that the site might, at some point, enable HTTPS on that domain.

[Hainish]

I agree with @jeremyn (and in fact our testing generally reflects this) that the absence of a 2XX (not just 200, since something like 207 can have useful content) or 3XX response, we should not accept the target.

Generally the absence of a 2XX or 3XX code indicates problems with the webserver, is hard to test, and may introduce problems in maintenance later.

[jeremyn]

Edge case: one of the domains in pull request #6230 is https://invite.hoccer.com , which gets a 404. I think it's okay to include because if you Google search for site:invite.hoccer.com, there's an invite. URL that looks like a personalized link which gets a 200. I don't want to include a personalized link in our tests though, so there's no test URL.

@Hainish Are the tests supposed to complain about 404s? Because they didn't here.

[gloomy-ghost]

@jeremyn It only complains when the http is 200 but https isn't. https://github.com/EFForg/https-everywhere/blob/master/test/rules/src/https_everywhere_checker/check_rules.py#L138-L147

[Hainish]

@gloomy-ghost when the test url response is 2XX but the rewritten test url isn't.

It seems like if we can not find a 2XX/3XX response within the https site, this is okay as long as the following conditions are met:

EITHER the http version of pages for that target gives the same response code and content OR it is clear that the http version of pages for that target indends users to access the site over https.

For this last point, an http site that responds with a 200 code and response body of "access this site over https", and when you do responds with a 404, or a 301/302 redirect from http to https are pretty much functionally equivalent.

[Hainish]

For some of these edge cases, I think it's also difficult to provide a hard and fast rule, and it's better to just rely on your best judgement. Over-formalization of process can get in the way of making reasonable decisions in odd circumstances.

[jeremyn]

@Hainish

and when you do responds with a 404

I don't understand this, did you make a typo?

For some of these edge cases, I think it's also difficult to provide a hard and fast rule, and it's better to just rely on your best judgement. Over-formalization of process can get in the way of making reasonable decisions in odd circumstances.

I think it's better to have over-formal rules and the reviewer has the discretion of relaxing the rules, instead of too-few rules and the reviewer comes across as arbitrary.

[Hainish]

@jeremyn no. I'm describing an edge-case where the http endpoint body just says "Use HTTPS" with a 200 code, and the HTTPS endpoint responds with 404 codes. Theoretically I don't see any problem with accepting a ruleset like this, since it is

clear that the http version of pages for that target indends users to access the site over https

Practically, it may not offer much utility to provide just 404 pages. But I could imagine even a 404 providing useful information to a user.