Https-everywhere: Make a ruleset for example.org, example.net and example.com

[ghost]

Type: new ruleset

Domain: example.net
Domain: example.com
Domain: example.org

(What if someone wants to use them with HTTP? Then they just have to disable their ruleset in HTTPS Everywhere.)

[ghost]

https://github.com/EFForg/https-everywhere/pull/15105 https://github.com/EFForg/https-everywhere/pull/15104 https://github.com/EFForg/https-everywhere/pull/15103 Never thought it would be this easy :smile:

[Hainish]

@J0WI I think it would be good to provide some well-known HTTP endpoint for people who are trying to connect behind a captive portal. Often, people use these example domains for that purpose. We should probably give some alternative that doesn't involve completely disabling HTTPS Everywhere.

[J0WI]

Both, Chromium and Firefox have internal captive portal checks.
IMHO captive portals are harmful and we should not "support" their behavior.

[Hainish]

In fact, since https://tools.ietf.org/html/rfc2606 specifies that example.[com|net|org] is an IANA reserved domain and no sensitive information is transferred, we should probably exclude them for the purposes of captive portals. There is the danger of drive-by downloads on HTTP sites, but if that's what your threat model is you should probably be using the addon in HTTP nowhere mode anyway. I've removed these in https://github.com/EFForg/https-everywhere/commit/cef22501ffc5a67b52f4b327717ea8f433a7f5cd

[Hainish]

@J0WI I haven't seen this functionality in Firefox or Chromium on Linux. I have seen it as an Android OS-level feature, which has access to the network management layer.

Regardless of whether we support captive portals existing ideally, they do exist in reality. We shouldn't force users to disable HTTPS Everywhere (or know about an HTTP-only site that isn't a standard) in order to allow people to connect in situations where captive portals are in place.

[Hainish]

Removing these rulesets may not be optimal - I removed them in order to go forward with a release, but at the very least they should be disabled by default. Perhaps we can add a comment mentioning captive portals for the reason that it is disabled. This way, users will have to actively enable it, at which point they will see the 'captive portal' comment. Hopefully, this will be triggered in their memory if they do at some later point have to go through the captive portal workflow.

[J0WI]

This has been implemented in Firefox 53. The project was tracked here and here.
You may check the network.captive-portal-service.enabled pref.

The expected "workflow" for most users is accessing their favorite site (e.g. Google/Facebook/YouTube which are all HSTS preloaded anyway) => Does not work => captive portal hint pops up
Since more and more popular sites are supporting HSTS, they might have some troubles if the captive portal notice isn't shown. I'm not sure if example.[com|net|org] would be their choose to test internet connection.
I think unexpired users will rarely end up with example.[com|net|org], except if they are linked somewhere and their curios if the link is working.

Securing example.[com|net|org] would not change this workflow for more advanced users. If they are aware of example.[com|net|org] hosts they likely also know more or less what the broken https warning means and how such captive portals are working. So they will find a way to work around it.