Security Benefit: MAXIMUM is confusing in red.

[lgarron]

Strawman alternative: "risk of not implementing".

From https://twitter.com/kangsterizer/status/704454522781839360

[gdestuynder]

@marumari I believe we should just replace it by the recommended configuration states. The document can discuss how useful each individual items are, but its more useful to have a list of what you need to have "anyway". That solves the level/labeling issue.

Eg (pretty inaccurate values, but just to get the point across)

Modern

• Redirect from HTTP
• Resource loading
• HSTS
• CSP
• COOKIES
  [...]

Intermediate

• Redirect from HTTP
• HSTS
• Cookies
  [...]

old

• robots.txt
  [...]

[lgarron]

@marumari I believe we should just replace it by the recommended configuration states. The document can discuss how useful each individual items are, but its more useful to have a list of what you need to have "anyway". That solves the level/labeling issue.

Everyone and their cousin makes lists like that. It's nice to see the wiki make a stand and provide digestible data in a table (apart from the coloring issue this bug is about).

[april]

I agree with @lgarron, I don't like sorting things that particular way. Especially since the needs don't line up with what are in the TLS guidelines. For example, GitHub should use Intermediate TLS and Modern Web Security. Mozilla.org should use Backwards Compatible TLS and Modern Web Security. And so on. :)

[gdestuynder]

I strongly disagree. Here's why:

There are thousands of Mozilla websites, each have a diff config because they liked setting A better than setting B. How do you tell if they're using safe settings?
If your answer is: "just scan them for what is safe", then the real answer is "follow standard recommended configurations" because that is exactly what the recommended configuration has to contain.

Anything else you add to that is up to you of course. The standard recommended configuration only cares about ensuring you have the minimum that you always need for a defined target.
It may not contain anything that is not clearly making the website safer.

Note: its ok to have a bunch of additional docs that explain other options, and rationales for choosing which of course (and in fact, is a good idea).

In more simple words a pick-from-list achieves this:

[jeffbryner]

I agree that red as a positive color to indicate 'yes you should do this and it's a good thing' is confusing.

So as to not create another standard or scheme; how about changing the column header to 'importance' or 'priority' like we did in our POC test plan recently? Then it's more of a call out and red makes more sense.

While usually I'm a fan of packaged controls, I think for configurations like this it makes sense to have a buffet of configuration options where folks can pick the ones that get them the score that they want as they progress. (i.e. I can't do CSP now, I'll do hsts,etc. )

[gdestuynder]

I think the new proposal in #50 solves this better now.

You can pick and use a score (web guidelines). You can use configuration states (TLS Guidelines).
Either way, you must get a risk level assigned that is standardized.

For the guidance document what this means is that the table would no longer show the "Security benefit", instead it would should which sites should use which:

Example, should/must use these (totally fictitious/random):

All sites: Redirection from HTTP, Resource loading, contribute.json, etc.
Maximum and high risk impact sites: CSP, cookies, etc.

Thoughts?

[gdestuynder]

the above PR has been reviewed and is now live