See also https://github.com/DavidLiedke/https-everywhere/pull/1.

@Bisaloo You have an open PR #14769 to remove IP addresses in targets. For this PR, @epicminecrafting has suggested that we include IP addresses https://1.1.1.1 and https://1.0.0.1 as targets.

Are you opposed to all IP addresses as targets, or are the ones in your existing PR specifically bad in some way?

@epicminecrafting Submitting a PR against @DavidLiedke 's branch is a sort of awkward way to provide feedback, because it spreads out the discussion for this new ruleset between that PR and this one.

Could you please instead just add a comment here describing what changes you would like to see?

Are you opposed to all IP addresses as targets, or are the ones in your existing PR specifically bad in some way?

I'm opposed to all IP addresses as targets. I know this one is an edge case and an argument could be made that it is pretty much used as a domain name here. But exceptions make it hard to write automated tests and reduce maintainability.

And now? Changing something?
Adding die IP addresses as target or not?
Which ruleset name i have to use? Cloudflare-DNS.com or 1.1.1.1 like @epicminecrafting suggestion?

FYI, this domain is pending preloading so I wouldn't personally spend too much time on it but that's your choice.

@Bisaloo IP addresses can't be preloaded (I think) so we still need to keep an IP. Also we need to keep the domain until it's preloaded in all major browsers.

@DavidLiedke Add the IP address. You can use either name, but the primary name is 1.1.1.1.

According to https://tools.ietf.org/html/rfc6797#appendix-A , IP address domains are not covered by HSTS:

4. HSTS Hosts are identified only via domain names -- explicit IP
   address identification of all forms is excluded. This is for
   simplification and also is in recognition of various issues with
   using direct IP address identification in concert with PKI-based
   security.

So the HSTS header at https://1.1.1.1 and https://1.0.0.1 should not do anything.

The problem with IP address targets for me is that IP addresses are likely to be less stable relative to the site content they serve, than a domain name would be. For example today some particular IP address might serve a valid certificate, but tomorrow the IP is reassigned to someone else who serves different content without a certificate. So a ruleset that covers that IP address is likely to go out of date faster.

That doesn't apply here because Cloudflare is publicizing https://1.1.1.1 and https://1.0.0.1 so I expect they will stay around for a while.

I would start with these changes:

• Make 1.1.1.1.xml and 1.0.0.1.xml that each cover just those IP addresses. This is according to our/my current informal best practices that encourage one domain per ruleset. These should be linked to and from CloudFlare.xml like you have already done with CloudFlare-DNS.com.xml.
• Add (partial) to the ruleset name for CloudFlare-DNS.com.xml.

There are other minor problems that I can comment on after these changes are made.

@Bisaloo What do you think? If you agree with me then @DavidLiedke can go ahead and make these changes.

I stand by what I said in #15064 (comment). I understand how this is an edge case and that we should not have the same issues as with other IP addresses. However, I'm not a big fan of exceptions.

I still think it's not a good idea but I don't care enough to put my veto on this. So feel free to do as you see fit.

@jeremyn These two IPs are identical, so there's no point in putting them into separate rulesets.

@jeremyn

1.0.0.1.xml:

• Remove the CloudFlare sets insecure __cfduid and cf_clearance wildcard cookies for every client domain. comment.

1.1.1.1.xml:

• Remove the CloudFlare sets insecure __cfduid and cf_clearance wildcard cookies for every client domain. comment.

CloudFlare-DNS.com.xml:

• Remove the CloudFlare sets insecure __cfduid and cf_clearance wildcard cookies for every client domain. comment.
• Delete the securecookie or restrict the host to the www and 1dot1dot1dot1 subdomains.
• Add a test for http://1dot1dot1dot1.cloudflare-dns.com/cdn-cgi/scripts/cf.common.js .

CloudFlare.xml:

• Sort the filenames in the top comment as

        - 1.0.0.1.xml
        - 1.1.1.1.xml
        - CloudFlare_Challenge.com.xml
        - CloudFlare-DNS.com.xml
        - Cloudflarestatus.com.xml

I've updated the checklist through 39dd85c.

For the test, could you please make it look like this?

	<target host="1dot1dot1dot1.cloudflare-dns.com" />
		<test url="http://1dot1dot1dot1.cloudflare-dns.com/cdn-cgi/scripts/cf.common.js" />

@jeremyn done.

Thanks, merged.