Shields: HSTS preload list status (HTTP security)

[yvele]

:clipboard: Description

A clear and concise description of the new badge.

• Which service is this badge for
  
  
  
  • Chrome's HTTP Strict Transport Security (HSTS) preload list
  
  
• What sort of information should this badge show?
  
  
  
  • HSTS status hsts | status
  
  
  • Status may be preloaded, pending or unknow
  
  
  • Link should points to https://hstspreload.org/?domain=github.com
  
  
• Examples
  
  
  
  • 
  
  
  • 
  
  
  • 
  
  

Edit: Replace no with unknow

:link: Data

Where can we get the data from?

• Is there a public API?
  
  
  
  • https://hstspreload.org/api/v2/status?domain=github.com
  
  
• Does the API requires an API key?
  
  
  
  • No
  
  
• Link to the API documentation.
  
  
  
  • https://hstspreload.org/
  
  

Edit: Replace no with unknow

:microphone: Motivation

Please explain why this feature should be implemented and how it would be used.

• What is the specific use case?
  
  
  
  • Show HTST approval status.
  
  
  • Track approval and regressions in real time. Alert on potential miss configuration.
  
  
  • Promote security for a safer Internet
  
  

Kind of related to #2912 and https://github.com/mozilla/http-observatory/issues/96

[owenvoke]

I've started work on this in a feature branch.

I noticed that the API returns unknown rather than no for both invalid and non-preload URIs. Should I keep it as no in the badge content?

[paulmelnikow]

I noticed that the API returns unknown rather than no for both invalid and non-preload URIs. Should I keep it as no in the badge content?

How about not preloaded?

Also I'm wondering if chrome hsts would be a more helpful label. I hadn't heard of this before, and it also seems like Firefox has its own list?

[calebcartwright]

How about not preloaded?

I'd vote for that as well

[owenvoke]

@paulmelnikow, that sounds good to me. :+1:

I think that the Firefox HSTS list is based on Chromes list afaik. :thinking: But if mentioning Chrome is more useful, I'm up for that.

[yvele]

Yes Firefox (and other browsers) use the same list

Most major browsers (Chrome, Firefox, Opera, Safari, IE 11 and Edge) also have HSTS preload lists based on the Chrome list. (See the HSTS compatibility matrix.)

Source: https://hstspreload.org/

I'm much more in favor of using the compact and explicit hsts which is explicit enough, see https://www.google.com/search?q=hsts

[yvele]

I've started work on this in a feature branch.

I noticed that the API returns unknown rather than no for both invalid and non-preload URIs. Should I keep it as no in the badge content?

unknow is more explicit than no, because pending also is no

How about not preloaded?

I'd vote for that as well

The problem is that pending is also in a "not preloaded" state.. If we use unknow we are coherent with HSTS API semantic, let's NOT invent a brand new semantic here. Let's focus on the badge 😉

Another remark, should we use orange instead of green for pending?

[owenvoke]

Ok 👍 Will change to unknown again 😋

And yeah, I was just using your examples for the colours 👍

Updated in the PR #2926 (haven't changed the colour to orange because I was just thinking, pending is kind of a good thing. 🤔

[yvele]

Yeah pending is a good thing but it's still not preloaded.. I was thinking about yellow (less alarmist than orange) 🤔

• 
• 
• 

[owenvoke]

That sounds great to me. 👍

[calebcartwright]

I'm a little confused how we could go from a message indicative of a definitive "no" to an inconclusive "unknown" state.

I know you'd prefer the hsts label, but if you want to use green|yellow|red badge colors then I'd suggest considering a badge label such as hsts preloaded with statuses such as yes, pending, no.

The concern with using unknow (which I assume should actually be unknown) is that badge colors are all associated with a status, and red is indicative of failure. It looks odd to have a color indicating failure with a conflicting, inconclusive message

[yvele]

I'm a little confused how we could go from a message indicative of a definitive "no" to an inconclusive "unknown" state.

Because when I made the issue I was stupid, and only thinking about myself. I prefer matching the HSTS workflow semantics

I know you'd prefer the hsts label, but if you want to use green|yellow|red badge colors then I'd suggest considering a badge label such as hsts preloaded with statuses such as yes, pending, no.

If you are choosing to add an hsts badge to your readme, of course unknow is a failure, and should be red. Otherwise you don't add an hsts badge at all.

The concern with using unknow (which I assume should actually be unknown) is that badge colors are all associated with a status, and red is indicative of failure. It looks odd to have a color indicating failure with a conflicting, inconclusive message

The thing with hsts and unknown (not unknow 😉 ) is that the API returns the same state whatever you have an hsts HTTP header, set to preload or not, and submitted or not. That's why there only is an unknown I think 🤔

Let's focus on the badge and NOT on the hsts API.. of let's open an issue on their repo 😄

My opinon: Stick to the API, focus on the badge

[paulmelnikow]

What we do at Shields is make badges that convey information as clearly as possible. That sometimes means using slightly different semantics or terminology than upstream APIs. We value consistency and clarity in the badges over strict adherence to the upstream terminology. You'll find lots of examples of code in Shields that smooths out the rough edges in APIs. Not that we always do this perfectly! But it's what we strive for. That's the sense in which we focus on the badge.

An argument could be made that unknown makes sense from the context of the API. However in the context of a badge, I agree with @calebcartwright that unknown is completely uninformational. It sounds like a transient error, whereas the intended message is "this host is not in the list." That's not the absence of information, it's a real failure.

I still think not preloaded could work, and to avoid any confusion with pending, that could be changed to preload pending.

Other possible alternatives: unknown host or not listed.

hsts preload is tempting, though since "preload" is more of a state than a noun, it feels nicer to push it into the right text if possible. Maybe commit status | in master is analogous: it's better than commit merged to master | yes.

[owenvoke]

I understand that unknown isn't particularly helpful, not preloaded is what is shown when using the hstspreload.org website. @paulmelnikow, so you are suggesting the following? 🙂

And @calebcartwright is suggesting:

~Personally I prefer the first, but I think I'll wait until we come to a conclusion before updating to the final look.~ 😋
Actually, I think I've changed my mind and prefer option 2 for readability and simplicity.

[yvele]

@paulmelnikow thanks for your arguments, I totally agree 👍

@pxgamer the second proposition from @calebcartwright looks super clean and super explicit 😮 👍

[owenvoke]

@yvele, I'm fine with that if everyone else is.

@paulmelnikow, what do you think of the 2nd set?

[paulmelnikow]

hsts preload is tempting, though since "preload" is more of a state than a noun, it feels nicer to push it into the right text if possible. Maybe commit status | in master is analogous: it's better than commit merged to master | yes.

This is my response from above.

Think I still feel that way; that

conveys meaning more elegantly than

in a similar way that

is more elegant than

[yvele]

Yeah but the badge is much more about specific HSTS preaload service than HSTS in general.

The HSTS preload service is not part of the HSTS (HTTP Strict-Transport-Security) specification.

It may be important not to reduce HSTS to HSTS preloading, and to be explicit in the label of that specific badge 🤔

This badge is more about HSTS preload, than HSTS in general

[paulmelnikow]

Hmm, that makes sense: that we're checking the list, not the website.

Given that, and after looking at these two projects:

• https://github.com/chromium/hstspreload.org
• https://github.com/chromium/hstspreload

I think this probably should have Chromium in the name. So how about this variant on the first version:

• 
• 
• 

[yvele]

Chromium is a bit restrictive as the list is used by Chrome, Firefox, IE, etc...

Most major browsers (Chrome, Firefox, Opera, Safari, IE 11 and Edge) also have HSTS preload lists based on the Chrome list.

https://hstspreload.org/

Also it's a bit long for nothing..

[owenvoke]

That seems quite long. But it definitely is informative on which hsts this is.

Thinking about this, should the links stay as /hsts/{uri}.svg, or be something like /hsts/preload/{uri}.svg?

[yvele]

To the best of my knowledge there is only one HSTS preload list 😉

[owenvoke]

I haven't heard of any others, but it is the Chromium project's list. :yum: I'm not too bothered about whether or not we include Chromium.

[yvele]

come on 🙄

Some people have to display many badges, on a single table in a readme.. one row of badge per environment. The name "Chromium" adds no relevant informations.. it's quite implicit to the HSTS preload list project.

[paulmelnikow]

My concern is about providing enough context to people who are reading this badges, particularly those who haven't heard of this. Let's keep the feedback constructive, please.

After reading some more and marinating for a couple days, I'm think I'm convinced. Let's do this:

1. Keep the badge label hsts preloaded with yes, pending, no.
2. Put "Chromium" in the title in the Shields badge listing, e.g. Chromium HSTS preload.
3. Link to the HSTS preload list and the list submission site in the badge documentation.

[yvele]

@paulmelnikow super cool!

Just a little thing about the documentation, are you sure you want to link to the HSTS preload list on GitHub https://github.com/chromium/hstspreload instead of the main Chromium project page https://www.chromium.org/hsts ? The homepage of the project is maybe more relevant (and instructive) 🤔

[paulmelnikow]

Hah, no, I think I must be confusing that repo with some other page I was looking at. I thought the actual list was in that repo, though it's somewhere else entirely: https://cs.chromium.org/chromium/src/net/http/transport_security_state_static.json

Honestly none of these links are very newcomer friendly! Though I guess https://chromium.org/hsts is the closest.

[owenvoke]

Just pushed points 1 and 2. For number 3, where do I add the links to?

[paulmelnikow]

How's this sound?

Strict-Transport-Security is an HTTP response header that signals that browsers should only access the site using HTTPS.

For a higher level of security, it's possible for a domain owner to preload this behavior into participating web browsers. Chromium maintains the HSTS preload list, which is the de facto standard that has been adopted by several browsers. This service checks a domain's status in that list.

Added: Sorry, I meant to say that I finally found a good intro! https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security#Preloading_Strict_Transport_Security

[owenvoke]

@paulmelnikow, here's how it looks:

[yvele]

@paulmelnikow Your intro is nice, but yes we should use https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security#Preloading_Strict_Transport_Security intro as it specify those really important things:

While the service is hosted by Google, all browsers have stated an intent to use (or actually started using) the preload list. However, it is not part of the HSTS specification and should not be treated as official.

[paulmelnikow]

Can you add it to the PR? The formatting looks odd. Are you using <p> tags? No worries if it doesn’t look perfect. The frontend styling is a work in process.

[owenvoke]

@paulmelnikow, done. It's using <p> tags, but should it be all one line? Or is there a line-length limit? (I wrapped it a bit.

[paulmelnikow]

It’s interpreted as plain HTML which isn’t whitespace sensitive (a space and a newline are treated the same). So line breaks are fine.