Https-everywhere: Could HTTPS Everywhere benefit from HSTS preload list annotations?

[lgarron]

Type: other

cf. https://github.com/EFForg/https-everywhere/issues/7126

https://groups.google.com/a/chromium.org/forum/#!topic/hsts-discuss/XzMpDMqtkKc
https://github.com/chromium/hstspreload.org/issues/111

I just started a discussion about annotating Chromium HSTS preload list entries with a policy field to indicate what kind of entry they are. The vast majority of entries, submitted through hstspreload.org, are "bulk" entries, although are three kinds of bulk entries.

I don't know the latests state of HTTPS Everywhere, so I'd like to ask:

• Would you benefit from this kind of annotation?
• Is the specific strawman mentioned in the thread sufficiently useful? If not, what would be better?

[https-everywhere-bot[bot]]

Hey, I couldn't find the type of issue in your description. Can you edit your issue to add this (perhaps referring to the issue template?)

[https-everywhere-bot[bot]]

Thanks! Your edit helped me out. I'll take it from here now.

[ghost]

We remove preloaded domains from rulesets, so I guess no.

[lgarron]

We remove preloaded domains from rulesets, so I guess no.

Thanks, that looks like it has clear documentation!
I think the only hole that leaves is domains that are added and then removed.

Pending removals are shown at https://hstspreload.org/api/v2/pending-removal , but not all removals are guaranteed to show up there for long. Does HTTPS currently have a plan for dealing with entries that used to be secured but are no longer preloaded, nor in HTTPS Everywhere?

[cschanaj]

I agree with @koops76 that the annotations has little to none use case for HTTPSE, Travis cares only domain and the include_subdomains tags only AFAIK.

Does HTTPS currently have a plan for dealing with entries that used to be secured but are no longer preloaded, nor in HTTPS Everywhere?

Travis looks into the stable and development versions of the preloaded lists bundled with the browsers, and warns if and only if a domain is preloaded among all of them. So, as soon as a domain is removed from the development version, it is immediately possible for a contributor to create a corresponding ruleset.

However, I do not think that many contributor are actively adding/ responsible for securing the removed domains from the preloaded lists. This is mainly because our contributors are mostly volunteers, they are not obligate to secure a particular domain anyway...

@Hainish @cowlicks do you have a plan?

[Bisaloo]

I have to disagree here. Annotations would be really useful for HTTPS-Everywhere.

We still have rules for some domains because they were added as exceptions in the preload list but don't have all required headers to be removed by hsts-prune (eg torproject.org, twitter.com).

hsts-prune looks at headers because @lgarron previously said that domains failing to continuously meet requirements may be automatically removed from the preload list in the future.

Now, if we have a list of exceptions, we can safely remove them even if they don't meet "usual" preloading requirements without being at risk to see them removed in the near future.

[Bisaloo]

Linking this previous conversation between @lgarron and @Hainish, which is highly relevant to this issue:

https://github.com/EFForg/https-everywhere/issues/9085#issuecomment-303290946

[Hainish]

Yes, annotations are useful for the reasons stated in https://github.com/EFForg/https-everywhere/issues/9085#issuecomment-303290946 and summarized by @Bisaloo https://github.com/EFForg/https-everywhere/issues/13235#issuecomment-338281310

[Hainish]

Closing this issue. Thanks for the heads up @lgarron!

[lgarron]

Thanks!

My understanding here is that it would be useful to be able to distinguish between bulk entries and everything else, because only bulk entries are subject to a clear automatic removal policy at the moment (and the other entries are generally not removed). Let me know if I got that wrong.

[Hainish]

@lgarron yup, that's about the long and short of it!